Re: snmp agent inform w/AES privacy not working

Thank you, that info will help a lot.  I have to postpone looking at these
tests; things just got really busy here.


On Wed, Jun 18, 2014 at 5:00 AM, Henrik Nord <[email protected]> wrote:

>
> On 2014-06-17 16:44, Daniel Goertzen wrote:
>
> 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?
>
> Current build runs clean here (apart from one windows that apparently
> failed all yesterday).
> So there might be something funky going on on your side.
> It would help if you list the test cases that are failing.
>
> probably a configuration issue
>
>
>
>
>  My erlang is...
>
>  goertzen@ubuntu64 ~/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 <[email protected]> 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 <
>>>> [email protected]
>>>>
>>>>> 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 <
>>>>> [email protected]> 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
>>>> [email protected]
>>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>>
>>>
>>>
>> --
>>  /Henrik Nord Erlang/OTP
>>
>>
>
> --
> /Henrik Nord Erlang/OTP
>
>

_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches