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

From: Vincent Roca <[email-masked]>
Date: Mon, 11 Apr 2011 15:50:47 +0200

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

Globally, the "Security Considerations" section is well
written and provides details for the associated risks.
It clearly RECOMMENDs the use of SNMPv3, which should not come
as a surprise given the risks associated to previous versions.
This "Security Considerations" section is globally similar
to that of RFC4295 (MIPv6 MIB).

A few comments:

** What about the completeness of the two lists provided in
section 6?
For instance the MIB defines the pmip6Capabilities object with
attribute MAX-ACCESS read-only (see p. 13). However this object
is not listed in the security considerations sections. Is it
a mistake? If yes, then does anything miss (I didn't check)?

** 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.

** 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.

** 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.

I hope this is useful.
Cheers,

   Vincent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Apr 2011 16:06:19 +0200

> BTW, you can maybe remove the redundant "even then," in above

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,".
 
> work gave birth to an RFC, that's probably a good document to refer

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? ;-)
 
> could easily be improved (split the sentence, please). As such it

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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Vincent Roca <[email-masked]>
Date: Mon, 11 Apr 2011 16:29:42 +0200

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Apr 2011 15:09:17 +0300

Thanks for your review, Vincent. Authors, any comments?

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Apr 2011 07:36:34 -0700

Hi Jari,

We will address these comments.

Thanks Vincent for the review.

Regards
Sri

---

From: Vincent Roca <[email-masked]>
Date: Wed, 13 Apr 2011 08:50:59 +0200

Hi Glenn,

> This is not a mistake. Since it is read only, its value cannot
> be changed by an attacker. And, revealing the capabilities cannot
> be as harmful as other objects e.g. pmip6Status. [ I will agree
> that a miscreant may want to physically destroy all objects that
> have LMA and or MAG capabilities in order to shutdown a PMIPv6
> network. The pmip6Capabilities object may be misused in that manner. But
> that is a generic argument, and holds for ALL the PMIPv6MIB
> objects.] So, we have not listed this object as one which is
> "particularly sensitive and/or private".
> The generic risk aspects are covered in the last paragraph of the
> security considerations section [copied from the boilerplate].
> The 2 lists are complete to our knowledge.
> Please let us know if there are any risks/vulnerabilities that
> are worth mentioning.

If there are good reasons not to list this object, I don't have
any objection.

> The remaining comments relate to the boilerplate which we have
> followed to the dot.

Yes, this is what Juergen explained. Maybe it's time to update
the boilerplate a little bit, but that's a different topic.

Cheers,

  Vincent

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 13 Apr 2011 15:42:13 +0900

Hi,
  Thanks for the review. The response follows.

Cheers, Glenn