Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05

[Vincent Roca <[e-mail]>]

Hi Juergen,

I was not aware of the existence of this boilerplate.
Of course, it changes a lot the situation. Thanks for
the pointer.

Concerning AES in SNMPv3, I guess that today no
SEC AD would object if you add RFC3826 as an
additional reference, even if not (yet!) in the official
boilerplate ;-)
Cheers,

  Vincent


On Apr. 11 2011, 16:06, Juergen Schoenwaelder wrote:

> On Mon, Apr 11, 2011 at 03:50:47PM +0200, Vincent Roca wrote:
> 
>> ** Clarification needed:
>> It is said:
>>  "Even if the network itself is secure (for example by using IPsec),
>>   even then, there is no control as to who on the secure network is
>>   allowed to access and GET/SET (read/change/create/delete) the objects
>>   in this MIB module."
>> I'm rather surprised that no ACL (or similar) functionality
>> be available. If IPsec is enabled, then hosts are authenticated
>> (using one of several techniques) and it's no longer a big deal
>> to check the authorizations associated to the peer. So that's
>> surprising.
>> 
>> BTW, you can maybe remove the redundant "even then," in above
>> sentence.
> 
> This is boilerplate text reflecting agreements reached between the SEC
> ADs and the OPS ADs at that time and used since then (including the
> somewhat irritating "even then,".
> 
>> ** Wrong reference:
>> It is said:
>>  "It is RECOMMENDED that implementers consider the security features as
>>   provided by the SNMPv3 framework (see [RFC3410], section 8) [...]"
>> Section  is not the section of interest as it only focuses
>> on the standardization status. More interesting sections in RFC3410
>> are:
>> - section 6.3 "SNMPv3 security and administration", and in particular
>> - section 7, in particular section 7.8 "user based security model".
>> 
>> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an
>> issue, now it is. The last sentence of RFC3410/section 7.8 mentions
>> on-going work on using AES in the user-based security model. If this
>> work gave birth to an RFC, that's probably a good document to refer
>> too.
> 
> RFC 3826 details how to use AES with SNMPv3. Again, this never made it
> into the boilerplate. Perhaps some new enthusiastic ADs get engaged to
> revise the boilerplate? ;-)
> 
>> ** Obscur:
>> The last sentence of this section:
>>  "It is then a customer/operator... them."
>> could easily be improved (split the sentence, please). As such it
>> remains rather obscure.
> 
> Again, this is what the boilerplate says. Here is the pointer:
> 
> http://ops.ietf.org/mib-security.html
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>