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.

This is a rather lengthy document.  I have begun by reviewing the
introductory sections, sections 5 and 6, and the security considerations
section.  The security considerations section of this I-D is very well
written and thorough, and I believe it covers all of the threats and
risks of IPv6 mobility support, though little is said about
cryptographic aspects of the protocol, nor cryptographic algorithm
agility.  A more thorough review may follow this one.

A few comments:

 - Bibliographic reference style.

   I find references with name anchors much easier to use than numeric
   anchors.  For example, "[RFC1234]" versus "[17]", as well as named
   references for references to documents other than RFCs.  I can very
   quickly decide whether I'm familiar with a given reference or must
   look it up, and the way I read I-Ds and RFCs I can more quickly
   lookup an RFC if I don't have to first jump to the references section
   of the document I'm reading.

   This is really a personal bias of mine, thus safely ignored.  If I
   were reading HTML renderings of this document I could just click
   through the references, but even so, it helps to be able to recognize
   a reference at a glance -- that's hard to do when references are
   numbered.

 - Binding of home addresses to mobile node credentials when using
   IKEv2.

   The security considerations text suggests that it will or may be
   common for home addresses to be listed in PKIX certificates as
   subject alternative names for the purpose of enabling home address
   authorization checks.  I believe that such an authorization approach
   requires at least additional text to the effect that the certificate
   issuer must check that home addresses claimed by requestors have not
   already been handed out to others whose certificates are still live.

   Given that a database is necessary in order to authorize home
   addresses, the only question is whether that database should be
   accessibly only by CAs or also by home agents, and I find no reason
   why home agents shouldn't have read access to it.  Besides, the IPsec
   model (RFC4301) already requires a DB that can easily be extended to
   host mobile address authorization information: the SAD.  I would
   prefer text discouraging the use of certificate subject alternative
   names (or any other certificate extensions) for authorization of home
   addresses as I suspect that CAs are not really and likely never will
   be prepared to perform the home address authorization check.

 - Enrolment/assignment of home address bindings to mobile node
   credentials.

   Nothing much is said about automation of enrolment of home address
   bindings to mobile node credentials.  I see that there is work in
   progress in that space, via CGA (cryptographically-generated
   addresses).  Such work should be referenced in both, the security
   considerations and future work sections of this I-D.

   If such work is not in progress, then such work ought to be, though
   there isn't anything that can be done about that here.  A dynamic
   association protocol seems likely to be quite useful in at least some
   scenarios.

 - Hash/MAC algorithm agility.

   This protocol uses SHA-1 and HMAC-SHA-1 for the return routability
   tests (whereby a mobile node's correspondent nodes test the mobile
   node's home and care-of addresses are both routable).  Nothing is
   said about hash agility, nor about the cryptographic properties of
   SHA-1 that the protocol depends on (collision resistance? first
   pre-image resistance? 2nd pre-image resistance? pseudo-random number
   generation?).

   We (the IETF) still believe that HMAC-SHA-1 is secure, therefore I
   will ignore that question for now.

   I believe that the protocol does not depend on collision resistance,
   since to find collisions an attacker would need to see the inputs to
   the hash function, and if it could see them then there are other
   attacks the attacker could mount.  I believe the protocol also does
   not depend on any pre-image resistance...

   ...I believe the protocol depends only on SHA-1 being a PRG.  As such
   I am not sure that hash agility is at all important.  And since it
   seems to me that hash agility could easily be added in the future
   (via a "mobile option" in Home Test Init, Care Of Test Init messages
   and their replies, as well as Binding messages), I think hash
   algorithm agility is a non-issue for this protocol.  However, a few
   words on the subject in the Security Considerations section may prove
   useful.

 - Mobile-to-mobile operation does not appear to be covered.  Is it
   supported?

   Are there any security considerations that might be special to
   mobile-to-mobile communications?

   I believe mobile-to-mobile operation is implicitly supported, and
   should work well enough.  I don't believe there's any special
   security considerations regarding mobile-to-mobile operation, but
   maybe I missed something?

Nico
--