usmAddUserName v usmAddUser

D. R. Evans N7DR____arrl.net
Sat Sep 21 02:35:05 CEST 2002


Just when I think I understand something, it seems like when I look a bit 
deeper it turns out that I don't understand it at all. Sigh....

Starting with the receive_trap and snmpInform examples as they are 
supplied, the code works fine.

Both of these, I notice, use usmAddUserName to tell the engine about the 
existence of a user. The actual source code in AddUserName makes reference 
to a usmUserNameTable, whose purpose isn't entirely clear -- what is clear, 
though, is that it is different from a regular usmUserTable.

Anyway, I want to be able to add a user when I have the following 
information at my disposal for both the initiator of an inform and for the 
responder to the inform (i.e., in pre-v3 parlance, the agent and the 
manager):

engineID, engineIDBoots, engineIDTime, usmUserName, authorization_key, 
privacy_key.

With this information, it seems that one cannot simply follow the examples 
and call usmAddUserName(), because that uses passwords instead of keys. 
Instead, it looks like one ought to be able to substitute a call to 
usmAddUser(), since that function uses keys instead of passwords.

So it seems reasonable, as a first stab hack-ish attempt at performing an 
authenticated exchange, to put something like this into both 
receive_trap.cpp and snmpInform.cpp:

status = usmAddUser((unsigned char*)<other side's engineid>,
                    strlen(<other side's engineid>),
           (unsigned char*)"meauthnopriv", strlen("meauthnopriv"),   
           (unsigned char*)"meauthnopriv", strlen("meauthnopriv"),
           SNMPv3_usmHMACMD5AuthProtocol, 
           (unsigned char*)"meauth",
           strlen("meauth"),
           SNMPv3_usmNoPrivProtocol, (unsigned char*)"", strlen(""));

This seems like it should set the securityName and usmUserName to 
"meauthnopriv", the authentication key to "meauth" and the authentication 
protocol to MD5.

BUT if one now sends an inform, the response that comes back produces the 
following output:

scoped PDU:
30 82 00 33  04 0C 72 65  63 65 69 76  65 5F 74 72
61 70 04 00  A8 21 02 02  03 E9 02 01  00 02 01 00
30 82 00 13  30 82 00 0F  06 0A 2B 06  01 06 03 0F
01 01 03 00  41 01 02
Parsing contextEngineID with length = 0xc
Parsing contextName with length = 0x0
ASN parse error (Wrong Type. Not an integer)
***Receiving a ReportPDU ***
mp finished (OK)
Received a report pdu: SNMPv3: USM: Unknown SecurityName
Oid = 1.3.6.1.6.3.15.1.1.3.0
Value = 3452816845

It's not clear whether the "ASN parse error" is really meaningful, but it 
is clear that the "Unknown SecurityName" is a problem.

I have played with this for several hours now, trying variations on the 
theme described above. These variations all seem to fail in predictable, 
sensible ways. But I don't understand why the code I originally used fails 
with the "Unknown SecurityName" error.

So does anyone know the correct way to add a user when one has keys but no 
passwords?

  Doc Evans




More information about the AGENTPP mailing list