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

[Henrik Nord]

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@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 
> <mailto: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 <mailto: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
>                 <mailto: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 <mailto:erlang-patches@REDACTED>
>             http://erlang.org/mailman/listinfo/erlang-patches
>
>
>
>     -- 
>     /Henrik Nord Erlang/OTP
>
>

-- 
/Henrik Nord Erlang/OTP

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140618/b8fbb1f1/attachment.htm>