[erlang-patches] snmp agent inform w/AES privacy not working

[Daniel Goertzen]

This isn't the most interesting corner of OTP and I submitted this as R17
was heading out the door, so I can see how this would be forgotten. ;)


I could use a hint: When I run the current SNMP tests I get a number of
failures...

Testing tests.snmp_test: TEST COMPLETE, 359 ok, 15 failed, 46 skipped of
420 test cases

... Is this normal, or is there something broken on my system that I need
to fix before proceeding?


My erlang is...

goertzen@REDACTED ~/otp/release/tests/test_server [(detached from
OTP-17.0.2)]
$ $ERL_TOP/bin/erl
Erlang/OTP 17 [erts-6.0.1] [source-deacab9] [64-bit] [smp:3:3]
[async-threads:10] [hipe] [kernel-poll:false]

Eshell V6.0.1  (abort with ^G)
1>


Thanks,
Dan.






On Tue, Jun 17, 2014 at 6:58 AM, Henrik Nord <henrik@REDACTED> wrote:

>
> On 2014-06-17 13:16, Raimo Niskanen wrote:
>
>> On Mon, Jun 16, 2014 at 08:28:59AM -0500, Daniel Goertzen wrote:
>>
>>> Ping.
>>>
>>> Has this patch gone anywhere?  I was thinking of adding tests and turning
>>> this into a github pull request if that would help this patch get in.
>>>
>> Yes.  Absolutely.  Test cases would help us accept the patch.
>> And a pull request I guess would also not hurt although should
>> not be essential.
>>
> As Raimo stated, it should not be essential. Although this mailing list,
> and patches sent to it,
> are manually handled and could be missed.
> Pull requests are automatically added to our backlog of open source
> contributions.
> (if they pass some rudimentary tests, such as compiling etc)
>
> Our apologies for missing this for so long.
>
>
>
>>
>>> On Tue, Feb 25, 2014 at 11:56 AM, Daniel Goertzen <
>>> daniel.goertzen@REDACTED
>>>
>>>> wrote:
>>>> The SNMP agent AES initialization vector calculation is definitely
>>>> wrong.
>>>>   The IV is composed from the authoritative engine boots, engine time,
>>>> and a
>>>> random locally generated number.  The agent is currently always using
>>>> the
>>>> *local* engine to get engine boots and engine time, which happens to be
>>>> correct for GET, SET, and TRAP, but is wrong for INFORM.
>>>>
>>>> The attached patch fixes it.  When composing a packet for transmission,
>>>> the existing code collects the correct engine parameters, so this patch
>>>> just uses those for the AES IV instead of going off and getting the
>>>> wrong
>>>> local engine params.  The patch looks bigger than it really is because
>>>> the
>>>> order of packet composition had to be changed slightly.
>>>>
>>>> With this patch applied, I am able to send AES encrypted informs.  AES
>>>> encrypted traps also continued to work.
>>>>
>>>> Cheers,
>>>> Dan.
>>>>
>>>>
>>>> On Mon, Feb 24, 2014 at 4:57 PM, Daniel Goertzen <
>>>> daniel.goertzen@REDACTED> wrote:
>>>>
>>>>  I am struggling to get SNMP informs with AES privacy working.  I have
>>>>> no
>>>>> problems with DES privacy on informs.
>>>>>
>>>>> In snmpa_usm.erl I see that the *local engine* boots and time is passed
>>>>> to snmp_usm:aes_encrypt() which forms part of the IV....
>>>>>
>>>>>
>>>>>
>>>>> However RFC 3826 states that the *authoritative* engine boots and time
>>>>> should be used, and in the case of informs the authoritative engine is
>>>>> the
>>>>> inform target engine, not the local engine....
>>>>>
>>>>> [from RFC 3826]
>>>>>
>>>>> 3.1.2.1.  AES Encryption Key and IV
>>>>>
>>>>>     The first 128 bits of the localized key Kul are used as the AES
>>>>>     encryption key.  The 128-bit IV is obtained as the concatenation of
>>>>>     the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP
>>>>>     engine's 32-bit snmpEngineTime, and a local 64-bit integer.  The
>>>>> 64-
>>>>>     bit integer is initialized to a pseudo-random value at boot time.
>>>>>
>>>>>
>>>>>
>>>>> Could this be why AES privacy is not working for informs?
>>>>>
>>>>> Dan.
>>>>>
>>>>>
>>>>  _______________________________________________
>>> erlang-patches mailing list
>>> erlang-patches@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>
>>
>>
> --
> /Henrik Nord Erlang/OTP
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140617/21c84e6f/attachment.htm>