Authentication Protocol for Mobile IPv6
Note: This ballot was opened for revision 07 and is now closed.
(Thomas Narten) (was Yes) Discuss
Discuss (2005-02-24 for -)
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...
Comment (2005-02-24 for -)
> responsible for performing Registration of a Mobile Node at a home s/Registration/registration/? (Why capitalized?) > and Accounting (AAA) server in Home network (AAAH) based on a shared > key based security association between the Mobile Node and the > respective authenticating entity. This shared key based security > association (shared-key based SA) may be statically provisioned or hyphens in "shared-key-based security"? > Mobile Node MAY use Mobile Node Identifier Option as defined in s/Mobile/A Mobile/ (or The...) > [MN_Ident] or Home Address to identify itself while authenticating s/Home/the Home/ > When a Binding Update or Binding Acknowledgement is received without > an authentication option and the entity receiving it is configured to > use authentication option or has the shared-key based security > association for authentication option, the entity should silently > discard the received message. the above is worded weakly. I would assume that the HA needs to be configured to reqiure authentication, either IPsec or this method. Above can almost be read to imply that a HA might not use either. > SPI: > > Security Parameter Index > This document doesn't seem to define SPI precisely. It would be good to provide a reference to the proper MIP document that describes them (i.e, what there properties are, who assigns them, etc.) > Alignment requirements : > > The alignment requirement for this option is 4n + 1. provide a reference to the RFC that defines the alignment rquirements? > Home Agent used within this specification consists of a SPI, a key, s/a SPI/an SPI/ > 16 octets in length. The authentication algorithm is HMAC_SHA1. The Reference for HMAC_SHA1? > the mobility header upto and including the SPI value of this option. s/upto/up to/ (multiple occurances) > The Mobility message replay protection option MAY be used in Binding why not a should? > If the timestamp is valid, the Home Agent copies the entire Timestamp > field into the Timestamp field in the BA it returns to the Mobile > Node. If the timestamp is not valid, the Home Agent copies only the > low-order 32 bits into the BA, and supplies the high-order 32 bits > from its own time of day. This last part seems odd. > code MIPV6-ID-MISMATCH. The Home Agent does not create a binding seems like you could find a better, more intuitive name. e.g., something like MIPV6-TS-INVALID (for timestamp). > infrastructure. It can be used to generate a per session key between s/per session/per-session/
(Margaret Cullen) No Objection
(David Kessens) No Objection
(Sam Hartman) (was Discuss, No Objection) Abstain
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.
(Russ Housley) (was Discuss) Abstain
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.