Authentication Protocol for Mobile IPv6
RFC 4285

The security review that was conducted early in the devleopment of this
document was largely ignored.  Since this document will be published as an
Informational RFC and the 3GPP2 community is waiting for the document, I
am choosing to ABSTAIN rather than perform the detailed review necessary
to determine which of the concerns raised by in the security review ought
to be addressed.  However, I would really like to see an applicabilty
statement added to this document so that this approach is not used outside
of the 3GPP2 environment without careful consideration.  In other words,
please tell the reader what in the 3GPP2 environment makes this a more
attractive (and secure) alternative to IPsec.

I have significant process and technical concerns with the document.
From a process standpoint, two security reviews were solicited and
provided to the working group when the working group was considering
adopting the draft as a work item.  The security reviews were provided
by Radia Perlman and myself.  The working group never responded to
these comments.  The reviews questioned whether this architecture made
sense and suggested alternatives to consider and questions to answer
before going down the path of adopting this approach.  I believe that
these comments suggest that there may be a conflict in the consensus
of the security area when considering this document with the consensus
of the MIP6 working group.  We should determine what the IETF
consensus is on this document; tools available to help us accomplish
this include an IETF-wide last call or  polling portions of the
security community.  


On a technical level, I'm concerned about this document both because
it is hard to review from a security standpoint and because it will
make future mip6 work significantly harder to review from a security
standpoint.  This document attempts to establish a way of
authenticating MIP6 traffic without the use of IPsec.  The IPsec
solution is fairly well complete: IKE provides for the use of a
variety of credential types to set up security associations; IPsec
provides for confidentiality and authentication of messages.
Assumptions about IPsec and the available services are included
throughout MIP6, particularly in route optimization.  However these
assumptions have not been written down in any formal mip6 security
service model.  So if the mip6 security architecture is going to be
replaced by something other than ipsec it will be challenging to
determine what properties that replacement model needs to provide.  In
addition, future work will need to either duplicate security analysis
both for the non-ipsec model and the ipsec model or to ignore one of
the security models. This protocol only provides part of the services
that IPsec provides., this protocol only provides part of the
non-IPsec solution .  IT authenticates binding updates from the MN to
the HA.  In effect, the document authors are saying that they don't
like IPsec and so they are going to get rid of it and only build the
part that corresponds to AH.  That might be OK for 3GPP; they may have
proprietary parts of the rest of the infrastructure and not need to
invent replacements for the rest of the IPsec dependencies.  However
outside of such an environment this document presents a much weaker
security picture than the existing MIPV6 specifications.  As such it
is my preference that this document not be published as an IETF
specification.  I would rather see the IESG approve the code point and
3GPP2 publish the document as one of their specifications.  (I
recognize this would require an IETF consensus against publication; it
is reasonable for the IESG to see if such a consensus exists but not
to block this document absent such a consensus.)

I would also be happy if we actually do the rest of the work necessary
to replacing IPsec.  At a minimum that would include documenting the
MIP6 security service model so that we can see what MIP6 and future
extensions require out of security.  We would then document how the
IPsec and non-IPsec solution fit this service model.  We'd also need
to finish defining the non-IPsec solution.  This would involve some
sort of confidentiality solution for RO and prefix discovery.  It
would also require some mechanism for getting keys to use for this
mechanism and the confidentiality mechanism.  That mechanism would
need to eventually be able to support a full EAP exchange, although it
might not be required to actually specify EAP support initially.  I
realize this solution requires more time and effort than the MIP6
working group probably wants to spend, but I list it in the interest
of enumerating possible solutions.

If we are going to publish this specification and we are not actually
going to complete the security solution, we need a very strong
applicability statement/IESG note warning.