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

[Scott Lystig Fritchie]

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.

If I try to change the password of a user with SHA auth and DES priv
settings, then "snmpusm" says:

    Error in packet.
    Reason: wrongValue (The set value is illegal or unsupported in some
    way)
    Failed object:
    SNMP-USER-BASED-SM-MIB::usmUserPrivKeyChange."enginea0"."superuser-sha"

I believe that the wrongValue error is coming from this clause inside
snmp_user_based_sm_mib:validate_key_change/4:

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

The 'wrongValue' error I'm getting is the 'priv' case where the
privacy protocol is ?usmDESPrivProtocol ... but Len is 40, not 32.(**)

I'm scratching my head, wondering if "snmpusm" is really sending too
many bytes, or if validate_key_change() (or some other function)
should be truncating what "snmpusm" is sending.

-Scott

(*) 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.

(**) In a test with a Windows app, Unbrowse 1.5, the same thing
happens trying to change the privacy passphrase of a user with SHA
auth and AES priv settings: Len is 40, not 32.  Ditto using Unbrowse
for a privacy change for a SHA + DES user.

To summarize, both "snmpusm" 5.1.2 and Unbrowse 1.5 are sending 40
bytes of privacy key change info for a SHA auth user, not 32 like
snmp_user_based_sm_mib:validate_key_change/4 is expecting.