NETWORK WORKING GROUP N. Williams Internet-Draft Sun Expires: October 31, 2005 April 29, 2005 An Unauthenticated, or Leap-of-Faith-Authorization Mode for Bump-In-The- Stack Implementations of IPsec Using Internet Key Exchange Protocols draft-williams-btns-unauthenticated-bits-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 October 31, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) using public keys as IKE identities and unauthenticated public keys and/or certificates as IKE credentials. This unauthenticated SA negotiation protocol works by having IKE peers assert public keys as identities using a new IKE ID payload Williams Expires October 31, 2005 [Page 1] Internet-Draft Unauthenticated IKE April 2005 type for the purpose. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). This document focuses on BITS (bump in the stack) mode IPsec, leaving specification of unauthenticated native IPsec to a separate document. We assume an RFC2401bis processing model, specifically a PAD (peer authorization database) separate from the SPD (security policy database). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions used in this document . . . . . . . . . . . . . . 3 2. Unauthenticated IKE Using Public Keys as IDs . . . . . . . . . 4 3. BTNS and Leap-of-Faith Authorization . . . . . . . . . . . . . 5 3.1 PAD Extension for Leap-of-Faith BTNS . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Williams Expires October 31, 2005 [Page 2] Internet-Draft Unauthenticated IKE April 2005 1. Introduction A number of applications can benefit from the availability of "unauthenticated" IPsec, applications such as "better than nothing security" (BTNS) [I-D.touch-anonsec], where unauthenticated key exchanges are subject to initial, but not subsequent MITM attacks, and "channel binding" applications where a binding between authentication at applications layers and secure channels at lower layers (in this case IPsec) allows for leveraging of existing authentication infrastructures that cannot be easily used for authentication in IKE. Here we describe how to establish unauthenticated IPsec SAs using IKEv1 [RFC2408] [RFC2409] or IKEv2 [IKEv2] and unauthenticated public keys. A new ID payload type is introduced, ID_PUBLICKEY, by which IKE peers can assert public keys as IDs; the public keys are sent in the CERT payload using either the raw RSA key CERT or an unexpired x.509 certificate, valid or otherwise, self-signed or otherwise. A concept of leap-of-faith addition of PAD entries for BTNS peers is also introduced. The [RFC2401bis] processing model is assumed, specifically the PAD as a concept separate from the SPD. 1.1 Conventions used in this document 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 [RFC2119]. Williams Expires October 31, 2005 [Page 3] Internet-Draft Unauthenticated IKE April 2005 2. Unauthenticated IKE Using Public Keys as IDs An IKE peer wishing to negotiate unauthenticated SAs indicates this using an ID payload of type ID_PUBLICKEY (type number to be assigned by the IANA), with an empty (zero-length) payload body, and includes one or more CERT payloads, which MUST all have the same public key, whose corresponding private keys, will be used for computing the AUTH (IKEv2) or SIG (IKEv1) payloads. It's peer may accept or reject this ID; if it accepts then it will validate the digital signatures in the AUTH (IKEv2) or SIG (IKEv1) payloads using the public key from one of the CERT payload(s) received. When asserting a public key as ID, IKE peers, both v1 and v2, MUST use the "Raw RSA Key" CERT (11) defined in [IKEv2] to send their public keys and MAY also use unexpired RSA x.509 certificates, and an appropriate CERT, for this purpose, and can expect their peers to ignore anything part of such certificates other than the 'subjectPublicKey' or 'validity' fields. IKE peers, both v1 and v2, when receiving a peer's ID_PUBLICKEY MAY, of course, reject the exchange according to local policy (i.e., if the peer is not authorized to assert the given public key as its ID). IKE peers, both v1 and v2, SHOULD, when their peers assert at a public key as ID, ignore any fields of an x.509 cert sent in a CERT payload other than 'validity' and 'subjectPublicKey' and SHOULD avoid any certificate validation, including certificate revocation list (CRL) checking and/or certificate status checking (e.g., via OCSP). When a peer whose address is not found in the PAD asserts a public key as its ID IKE MUST either reject the exchange or, if policy allows it, add an entry to its PAD linking the peer's address to its asserted public key. This is often known as "leap of faith" authorization. Williams Expires October 31, 2005 [Page 4] Internet-Draft Unauthenticated IKE April 2005 3. BTNS and Leap-of-Faith Authorization The PAD is a configuration that indicates, to IKE for example, what IDs a peer otherwise identified by its IP address may assert, and, therefore, how each peer may be authenticated. In this model, in order to obtain the desired protection for BTNS peers against subsequent MITMs each peer must establish a somewhat persistent peer address-to-BTNS-ID mapping in its PAD. We say "somewhat" persistent because a BITS implementation of IPsec may not have any way to determine, on its own, when such a mapping is no longer necessary, but permanent address-to-BTNS-ID mappings are problematic and undesirable. Specifically, BTNS leap of faith authorization causes problems when it is used by peers using dynamically allocated addresses, whenever address allocations change, and whenever a BTNS peer re-generates its private-public key pair. Problems arise, in the peer address/credential change situation, due to the inability to signal to other peers the upcoming or already effected change; IKE extensions may be feasible which correct this problem. Problems arise, in the dynamic address allocation case, from an inability to detect when communication with a given BTNS peer is no longer ongoing, such that the leap-of-faith PAD entry for it may be removed; this is a limitation of BITS (and BITW) IPsec modes, and though native mode IPsec may help, for example, by providing programming interfaces to applications, it isn't clear that native mode implementations will always be able to safely make such a determination either. This, then, is a crucial feature of BTNS mode IPsec: that it is most useful (and least harmful) when used between systems with statically allocated addresses and whose BTNS keys change infrequently. Another crucial feature of BTNS mode IPsec: it MUST be possible to manually edit a PAD on a BITS (or BITW) implementation to remove stale BTNS entries. 3.1 PAD Extension for Leap-of-Faith BTNS If IKE automatically creates PAD entries for peers that use BTNS and which had no applicable PAD entries then a denial of service (DoS) attack is possible where an attacker causes a PAD entry to be created, at some host, for one or more peers for whose addresses the host had no PAD entries. Williams Expires October 31, 2005 [Page 5] Internet-Draft Unauthenticated IKE April 2005 To avoid this attack we propose a simple PAD extension whereby the willingness to use BTNS is specified for one or more addresses, possibly specified using range syntax. BITS BTNS implementations MUST provide such a facility. Williams Expires October 31, 2005 [Page 6] Internet-Draft Unauthenticated IKE April 2005 4. Security Considerations The BTNS mode of BITS mode IPsec presented herein relies on a leap- of-faith addition of PAD entries linking peer IP addresses to their asserted public keys; these entries are mostly persistent and, through their persistence create the possibility of denial of service (DoS) attacks where an attacker causes many illegitimate PAD entries to be created in other systems' PADs. No method for automatic recovery from incorrect BTNS PAD entries is given herein -- only manual intervention is envisioned for BITS implementations of IPsec w/ BTNS. In other words, BITS BTNS is subject to DoS attacks. Unauthenticated security association negotiation is subject to MITM attacks and should be used with care. Use with applications that bind authentication at higher network layers to secure channels at lower layers may provide one secure way to use unauthenticated IPsec, but this is not specified herein and, furthermore, implies native mode IPsec, which this document mostly ignores. For such applications a possible benefit of using unauthenticated IPsec may be the ability to use IPsec, with associated special purpose cryptographic hardware, for transport protection without having to deploy an authentication infrastructure suitable for use with IKE. "Channel binding" is a technology currently being defined elsewhere at the IETF and, therefore, outside the scope of this document. Since channel binding is typically performed once per-session such applications need a way to construct "IPsec channels" using IPsec to protect common transport protocols layered above IP. This means that channel binding applications require application programming interfaces (APIs) for binding datagrams of connection-less transports (e.g., UDP) and entire connections for connection-oriented transports (e.g., TCP) to a single set of of IPsec SAs, authenticated or otherwise, where each such SA re-keys a prior SA in the same set or is established using the same ID and, when unauthenticated IKE is used, using the same public key. Such APIs are not specified herein; the work to specify such APIs is ongoing. 5. Normative [I-D.touch-anonsec] Touch, J., "ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks", draft-touch-anonsec-00 (work in progress), May 2004. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), Williams Expires October 31, 2005 [Page 7] Internet-Draft Unauthenticated IKE April 2005 October 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401bis] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-05 (work in progress), December 2004. [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires October 31, 2005 [Page 8] Internet-Draft Unauthenticated IKE April 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Williams Expires October 31, 2005 [Page 9]