Network Working Group V. Narayanan Internet-Draft Qualcomm, Inc. Intended status: Informational December 18, 2006 Expires: June 21, 2007 Security Analysis of RFC4285 draft-vidya-rfc4285-security-analysis-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract RFC4285 [1] provides a means of using pre-shared key (PSK) based or AAA-based credentials for Mobile IPv6. It is intended to provide a light-weight security mechanism for MIP6 signaling. However, the protocol comes with a set of security issues that are worth looking at. This document presents a security analysis on the protocol. Narayanan Expires June 21, 2007 [Page 1] Internet-Draft rfc4285-security-analysis December 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Feature Analysis of RFC4285 . . . . . . . . . . . . . . . . . . 3 4. RFC4285-based Message Authentication . . . . . . . . . . . . . 5 5. RFC4285-based Key Management . . . . . . . . . . . . . . . . . 6 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Narayanan Expires June 21, 2007 [Page 2] Internet-Draft rfc4285-security-analysis December 2006 1. Introduction RFC4285 [1] provides a means of using pre-shared key (PSK) based or AAA-based credentials for Mobile IPv6. It is intended to provide a light-weight security mechanism for MIP6 signaling. However, the protocol comes with a set of security issues that are worth looking at. The IESG note on the document indicates that a thorough security analysis has not been done on the protocol and the note warns against use of the mechanism. Regardless, absent technical details on the issues, it is tough to discourage the use of the AUTH protocol for MIP6 protection. Recently, several architectures are adopting the RFC4285-style security for MIP6 protection. Given the similarities with MIP4 security and the lightweight nature of it compared to IKEv2/IPsec, it is quite compelling to use this for MIP6. However, it is very important to consider the tradeoffs that come with it. This document provides a security analysis of the AUTH protocol and highlights some concerns with it. Further, it provides some detail on the issues with the keying aspects of the protocol. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. This document uses terminology defined in [3], [1], [4], [5] and [6]. 3. Feature Analysis of RFC4285 This section provides an overview of some of the concerns with RFC4285-style security. o RFC4285-based implementations use the MN-AAA key to subsequently derive an MH-HA key. This allows AAA-based credentials to bootstrap an MN-HA key, even when the HA is dynamically assigned. In such instances, the MN-AAA key is used to authenticate the first BU and may also be included in subsequent BUs. The MN-HA key is derived from the MN-AAA key. Use of the MN-AAA key to generate the Authentication Data for some BUs and use of the same MN-AAA key to generate MN-HA keys is not good cryptographic practice. A key used for generating child keys must never be directly used in protecting any data, since different cryptographic operations (e.g., MAC vs a PRF operation) use the key in different ways, assisting an attacker in arriving at the key. Narayanan Expires June 21, 2007 [Page 3] Internet-Draft rfc4285-security-analysis December 2006 o Lack of algorithm agility - there is currently no means of negotiating the algorithm to use either for the MAC or for the PRF used to arrive at the MN-HA key. Moving to stronger future algorithms involves more work, since it requires spec and implementation revisions, rather than the addition of an algorithm option. o SA indexing - The SA lookup mechanism is not clearly specified in the document. While the document defines the Mobility SPI as "A number in the range [0-4294967296] used to index into the shared- key-based mobility security associations", the SPI does not uniquely reference the MN-HA or MN-AAA SA. The SPI is later referenced in the document as a fixed value that indicates the MAC algorithm (the only current value being for SHA1). Based on MIP4 operation, which is similar to the AUTH protocol, it can be deduced that the NAI (and home address when available) references the key to be used. Having the NAI be the index to the SA brings up a few problems: * It leaves room for ambiguity when there may be multiple keys referenced by the same NAI (say, when the MN has more than one Home Address (HoA) or is associated with more than one HA) * The referencing is different for the MN, HA and AAA (e.g., MN needs to use NAI + HA or NAI + AAA; HA needs to use HoA + NAI; AAA potentially uses just NAI or HA + NAI). Details on the actual referencing for each entity are also not provided in the document. * User privacy is not available, since the NAI is used as a key index and sent in the clear in every Binding Update. With location privacy becoming more and more important, there is a lot of emphasis on privacy or temporary NAIs (e.g., in EAP) and for IP address privacy (e.g., in MIP6). The use of NAI in the clear with the AUTH protocol conflicts with any user and location privacy requirements that a system may have. o The document specifies the incorrect key length for HMAC_SHA1 - this is definitely a fixable problem, but, creates room for interoperability issues with implementations that have the correct HMAC_SHA1 and are looking to re-use that here. o Address authorization - HoA authorization is one of the primary goals of securing Mobile IP. The key in AUTH protocol is tied to the NAI through manual provisioning at the AAA server. The document provides little detail on how the HoA is tied to the SA to prevent a node from using an incorrect HoA to prevent redirection attacks. It can be deduced that if the HA (or AAA) Narayanan Expires June 21, 2007 [Page 4] Internet-Draft rfc4285-security-analysis December 2006 assigned a particular HoA to the MN and tied that to the NAI, which in turn is tied to the key, address authorization is feasible. However, more details are need to allow the MN to perform stateless autoconfiguration or obtain multiple IP addresses and still obtain authorization for such IP addresses. Since the protocol does not mandate the verification of the HoA in the BU with that tied to the key, it leaves room for implementation issues with address authorization. o Replay protection - RFC4285 provides the optional use of timestamps for replay protection. It provides a means of synchronizing timestamps at the MN and HA without using NTP. When the MN sends an incorrect timestamp in a Binding Update (BU), the HA returns the correct timestamp in a Binding Acknowledgement (BA), so that the MN can try sending a BU again with the correct timestamp. This operation opens the HA to more DoS attacks and provides an attacker more attempts at replays, since the HA will actually respond to replayed packets. Silent discarding of a replayed packet is a better security practice than responding to it. 4. RFC4285-based Message Authentication The default mode of MIP6 protection is using IPsec. ESP (Encapsulated Security Payload) [5] is a recommended protocol for use with IPsec. While the protocol provides a means of both encryption and integrity protection, the use of encryption is optional. Sometimes, ESP is referred to as having too much overhead for protecting MIP6 signaling. Comparing the fields that exist with RFC4285-based security and ESP, we find that there is really not a difference in the kind of overhead present in either protocol. Also, it is important to recall that MIP6 signaling does not occur frequently enough for such overhead to be a concern. Fields present in ESP-based security: Initialization Vector (optional), SPI, Sequence number, Padding (optional), Integrity Check Value (ICV). Fields present in RFC4285-based security: MN ID, Replay option (optional), SPI, Authentication Data Using ESP-NULL essentially provides better protection with the about the same overhead. Narayanan Expires June 21, 2007 [Page 5] Internet-Draft rfc4285-security-analysis December 2006 5. RFC4285-based Key Management IKEv2 (Internet Key Exchange v2) [6] provides a means of establishing IPsec SAs between the MN and HA. When using IPsec for MIP6 protection, IKEv2 is typically used as the key management protocol. Several modes of operation are allowed with IKEv2, including, the use of PSKs, AAA-based credentials, certificates (self-signed and PKI- based), etc. AAA-based credentials are usable with IKEv2 with the use of EAP (Extensible Authentication Protocol) [7] in IKEv2. The main advantage of the AUTH protocol is the fewer roundtrips needed for deriving an MN-HA SA. Due to the capability of using AAA- based credentials to allow dynamic derivation of an MN-HA key, the AUTH protocol may be considered to play a role in key management. Hwever, the AUTH protocol is really not so much a key management protocol - it facilitates key retrieval from the AAA server or offers PSK-based protection between MN and HA. A question that needs to be answered is this - given that IKEv2/EAP is likely performed only during bootstrapping, why is it a concern? Regardless of the answer to that question, here are some issues with applying RFC4285 as a keying mechanism: o No algorithm agility o No possibility of protected ID exchange, causing privacy concerns o No cryptographic key separation o No protection against weak PSKs (e.g., IKEv2 would still result in strong session keys, even if the PSK was relatively weak; in the AUTH protocol, the PSK is directly used for protection and also used for deriving other keys) o Key naming and lookup concerns (since the NAI is used as a key name) - lack of a means of deriving/negotiating a unique key index for the SA o Weaker replay protection If the above need to be fixed, the resultant protocol is going to look more or less like IKEv2. For instance, protected ID exchange requires the protocol to be at least a 2-roundtrip protocol. Given that basic IKEv2 is essentially a 2-roundtrip protocol with single- roundtrip re-keying capability, there should not be a problem in its use for MIP6. The lack of plug-in to AAA credentials, except via EAP, has been Narayanan Expires June 21, 2007 [Page 6] Internet-Draft rfc4285-security-analysis December 2006 quoted as a problem. EAP adds at least a couple of extra roundtrips to the exchange. For most cases, this should be acceptable, given that this only occurs during bootstrapping. If that is unacceptable, fetching an IKEv2 PSK from the AAA server would be far better than re-designing a keying protocol with loss of valuable features. The number of message exchanges needed during failover conditions of the Home Agent has been quoted as one of the concerns for the use of IKEv2-EAP as well. However, this is a generic concern of IPsec failover and this must be addressed as part of IPsec. Efforts are underway to address that concern and MIP6 would be able to leverage that. On the other hand, the use of IKEv2 buys all those above features. In addition, it will allow creation of child SAs for other purposes as well. In many environments, the HA is used as a traffic aggregation point and may have the need for establishing IPsec SAs for other purposes. These can be effectively created as child SAs for the respective purposes. 6. Conclusions In most deployed systems, features like location and user privacy are concern enough and that calls for the use of a protocol such as IKEv2 for key management. In environments where the above stated tradeoffs are acceptable, it may be sufficient to employ RFC4285-style security. Even still, a revision to the document is required to correct the key length and clarify SA indexing procedures, etc. Also, based on the analysis, this protocol is not viewed as a practically suffcient security solution for general purpose use. 7. Security Considerations This document performs a security analysis of RFC4285 and highlights the security tradeoffs of using RFC4285 for protection of MIP6 signaling. This document does not introduce any security considerations of its own. 8. Acknowledgements The author would like to thank Vijay Deverapalli, Lakshminath Dondeti and Uppinder Babbar for their review and comments on the document. Narayanan Expires June 21, 2007 [Page 7] Internet-Draft rfc4285-security-analysis December 2006 9. References [1] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [7] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Author's Address Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Email: vidyan@qualcomm.com Narayanan Expires June 21, 2007 [Page 8] Internet-Draft rfc4285-security-analysis December 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Narayanan Expires June 21, 2007 [Page 9]