Authentication Protocol for Mobile IPv6
Note: This ballot was opened for revision 07 and is now closed.
Thomas Narten Former IESG member
(was Yes) Discuss
Discuss [Treat as non-blocking comment] (2005-02-24) Unknown
Substantive: > This document introduces new mobility options to aid in > authentication of the Mobile Node to the Home Agent or AAAH server. > The confidentiality protection of Return Routability messages and > authentication/integrity protection of Mobile Prefix Discovery (MPD) > is outside the scope of this document. what is required to get RR to work in this scenario? Even if out of scope, this document should make it clear whether there are fundamental issues or whether the details simply aren't included because 3GPP2 has no plans for using RO. > New values for this namespace can be allocated using Standards Action > [RFC2434]. seems overly restrictive. Especially since _this_ document is informational and creates one for 3GPP2. Isn't IETF RFC good enough? > 7. Security Considerations > > This document proposes new authentication options to authenticate the > control message between Mobile Node, Home Agent and/or home AAA (as > an alternative to IPsec). The new options provide for authentication > of Binding Update and Binding Acknowledgement messages. The MN-AAA > authentication options provides for authentication with AAA > infrastructure. It can be used to generate a per session key between > Mobile Node and Home Agent for subsequent authentication of BU/BA > between Mobile Node and Home Agent via the MN-HA authentication > option. I find it odd that this document doesn't anywhere say how one generates a session key, if that is indeed what this document is used for...
David Kessens Former IESG member
No Objection () Unknown
Margaret Cullen Former IESG member
No Objection () Unknown
Allison Mankin Former IESG member
Abstain () Unknown
Russ Housley Former IESG member
(was Discuss) Abstain
Abstain (2005-08-23) Unknown
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.
Sam Hartman Former IESG member
(was Discuss, No Objection) Abstain
Abstain (2005-10-13) Unknown
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.