NETWORK WORKING GROUP N. Williams Internet-Draft Sun Expires: February 2, 2006 August 2005 Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec draft-williams-btns-00.txt 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 February 2, 2006. 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) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No IKE extensions are needed, but a Peer Authorization Database (PAD) extension in the form of an ID selector wildcard, 'UNKNOWN', specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). Williams Expires February 2, 2006 [Page 1] Internet-Draft BTNS IPsec August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Asymmetric and Symmetric BTNS SAs . . . . . . . . . . . . . 5 3. Leap-of-Faith BTNS . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . 7 5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Williams Expires February 2, 2006 [Page 2] Internet-Draft BTNS IPsec August 2005 1. Introduction A number of users and applications can benefit from the availability of "unauthenticated" IPsec or "better than nothing security" (BTNS), where unauthenticated key exchanges are subject to initial, but not subsequent MITM attacks, as described in [I-D.ietf-btns-prob-and- applic]. Here we describe how to establish unauthenticated IPsec SAs using IKEv1 [RFC2408] [RFC2409] or IKEv2 [I-D.ietf-ipsec-ikev2] and unauthenticated public keys or certificates. No new bits-on-the-wire are added to IKE or IKEv2, but a new wildcard for ID selectors in PAD/SPD entries is added: 'UNKNOWN.' The [I-D.ietf-ipsec-rfc2401bis] processing model is assumed, specifically the PAD as a concept separate from the SPD. This document does not define an opportunistic BTNS mode of IPsec whereby nodes may fallback on unprotected IP when their peers do not support IKE or IKEv2, but it does describe an optional leap-of-faith BTNS mode. 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 February 2, 2006 [Page 3] Internet-Draft BTNS IPsec August 2005 2. BTNS The IPsec processing model, IKE and IKEv2 are hereby modified as follows: o An optional new ID type is added, 'PUBLICKEY', for use in PAD and SPD entries, so that ID selectors can match on public key values. This ID type is be used for the optional leap-of-faith BTNS mode (see below), but users could use it to manually create PAD/SPD entries in a manual equivalent of leap-of-faith BTNS. o A new wildcard ID selector value for use in PAD and SPD entries is added, 'UNKNOWN', which matches any peer ID. o For BTNS IKE and IKEv2 MUST coerce the IDs of peers whose CERT payloads could not be validated (in certain conditions, see below) to PUBLICKEY IDs whose values correspond to the public key used by the peer (if the peer used a certificate, then the certificate's subjectPublicKey) that can only be matched by either the 'UNKNOWN' ID selector wildcard value or a PUBLICKEY ID selector with that same key as its value; of course, HASH/AUTH payloads must be validated. Nodes wishing to be treated as BTNS nodes by their peers SHOULD use CERT payloads generated for the purpose (i.e., ephemeral, non-pre- shared self-signed certificates or bare RSA public keys). The conditions under which a BTNS-capable IKE/IKEv2 implementation MUST accept an IKE_SA that it would otherwise reject are such where the reasons for rejection relate only to the peer's CERT payload, namely: o the peer's CERT was a bare RSA public key and not pre-shared to the other peer; o the peer's CERT was a self-signed certificate not pre-shared to the other peer; o the peer's CERT was a certificate for which no validation chain could be constructed and validated by the other peer to one of its trust anchors. Similar conditions relating to other CERT payload types are not described herein. In other words, BTNS-capable nodes coerce the IDs of peers whose AUTH payloads were valid but whose CERTs could not be validated (due to their being unknown bare public keys, self-signed certificates or Williams Expires February 2, 2006 [Page 4] Internet-Draft BTNS IPsec August 2005 certificates from unknown PKIs) to IDs which can only be matched by the new 'UNKNOWN' PAD/SPD ID selector wildcard value or by ID selectors of the new 'PUBLICKEY' whose value matches the given key. 2.1. Asymmetric and Symmetric BTNS SAs The key exchange protocols for IPsec are not modified by BTNS, only processing of peers that would otherwise be rejected by non-BTNS peers is modified. The rest of the IPsec processing model is modified only to introduce a way to match unauthenticated peer IDs in the PAD/SPD. Nodes therefore may not know that peers may accept them only for authorization as unauthenticated peers. As a result there is no distinction between symmetric BTNS SAs (where both peers are unauthenticated) and asymmetric SAs (where only one of the peers is unauthenticated) beyond the each peer's willingness to authorize unauthenticated peers to specific resources. Williams Expires February 2, 2006 [Page 5] Internet-Draft BTNS IPsec August 2005 3. Leap-of-Faith BTNS Implementors may provide a PAD entry attribute used to indicate that the given PAD entry is a template that should, when matched, cause new PAD and SPD entries to be created binding the matching peer's IP address and BTNS ID (i.e., public key) by using the PUBLICKEY ID selector to match on the peer's public key. Entries created this way have to be persistent, for some value of "persistent," though we RECOMMEND that "persistent" mean "until manually removed." Williams Expires February 2, 2006 [Page 6] Internet-Draft BTNS IPsec August 2005 4. Security Considerations Unauthenticated security association negotiation is subject to MITM attacks and should be used with care. Where security infrastructures are lacking this may indeed be better than nothing. 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/or 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. Creation of PAD and SPD entries in a leap-of-faith manner creates a number of problems, most notably a denial-of-service (DoS) attack where an attacker can consume all address available for use in this way. Such attacks need not even be conscious: device mobility can achieve the same effect. A possible mitigation for this problem would be to allow leap-of-faith BTNS to be used only for address ranges where no mobile devices are expected and which attackers may not be able to take over for other reasons. Another possible mitigation would be to prompt a user about each leap-of-faith BTNS policy entry instantiation. [...] 5. Normative [I-D.ietf-btns-prob-and-applic] Touch, J., "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Williams Expires February 2, 2006 [Page 7] Internet-Draft BTNS IPsec August 2005 draft-ietf-btns-prob-and-applic-00 (work in progress), July 2005. [I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [I-D.ietf-ipsec-rfc2401bis] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), April 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Williams Expires February 2, 2006 [Page 8] Internet-Draft BTNS IPsec August 2005 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires February 2, 2006 [Page 9] Internet-Draft BTNS IPsec August 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 February 2, 2006 [Page 10]