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

[Juergen Schoenwaelder <[e-mail]>]

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/>