[erlang-questions] Two SNMP questions: SHA auth + authPriv, authenticationFailure trap

[Martin Bjorklund]

Scott Lystig Fritchie <fritchie@REDACTED> wrote:
> Following up to my own posting....
> 
> >>>>> "mjb" == Martin Bjorklund <mbj@REDACTED> writes:
> 
> mjb> Note how Secret16 is always used. and it is derived from md5.
> mjb> The code should use the first 16 bytes for the SHA entry.
> 
> I am a bit puzzled by something I noticed yesterday when using
> NET-SNMP's "snmpusm" utility (version 5.1.2) to try changing
> passwords.(*)  It seems to be the same kind (?) of misunderstanding of
> how many bytes should be used for the privacy key?  But it isn't clear
> to me who may be at fault, "snmpusm" or OTP.

In the RFC, it says:

  usmUserPrivKeyChange OBJECT-TYPE
      SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES

which is probably why the OTP code is the way it is.


But I think the bug is in OTP.   Note that the set_key_change/4 (which
eventually is called to actually perform the set) looks up the auth
protocol for the user, and calls extract_new_key/3 with that auth
protocol.  So validate_key_change/4 should do the corresponding
validation.  Thus, the code should be something like:


	    %% Check that the length makes sense
	    Len = length(KeyC),
	    AuthP = get_auth_proto(RowIndex, Cols),
	    case Type of
		auth ->
		    case AuthP of
			?usmNoAuthProtocol -> ok;
			?usmHMACMD5AuthProtocol when Len == 32 -> ok;
			?usmHMACSHAAuthProtocol when Len == 40 -> ok;
			_ -> wrongValue(KeyChangeCol)
		    end;
		priv ->
		    KLen = if AuthP == ?usmHMACMD5AuthProtocol -> 32;
			      AuthP == ?usmHMACSHAAuthProtocol -> 40;
			      true -> -1
			   end,
		    case get_priv_proto(RowIndex, Cols) of
			?usmNoPrivProtocol -> ok;
			?usmDESPrivProtocol when Len == KLen -> ok;
			?usmAesCfb128Protocol when Len == KLen -> ok;
			_ -> wrongValue(KeyChangeCol)
		    end
	    end;


It would be great if you could verify this in your test setup.

> (*) The 5.4 version of "snmpusm" uses a different method for changing
> passwords, I think.  It appears to be using the "Own" columns in
> usmUserTable.

But this doesn't work either, does it?


/martin