Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
RFC 5386
Document | Type |
RFC - Proposed Standard
(November 2008; Errata)
Was draft-ietf-btns-core (btns WG)
|
|
---|---|---|---|
Authors | Nicolás Williams , Michael Richardson | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5386 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Tim Polk | ||
Send notices to | (None) |
Network Working Group N. Williams Request for Comments: 5386 Sun Category: Standards Track M. Richardson SSW November 2008 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). Williams & Richardson Standards Track [Page 1] RFC 5386 BTNS IPsec November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Example #1: A Security Gateway . . . . . . . . . . . . . . 5 3.2. Example #2: A Mixed End-System . . . . . . . . . . . . . . 7 3.3. Example #3: A BTNS-Only System . . . . . . . . . . . . . . 8 3.4. Miscellaneous Comments . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.1. Connection Latching and Channel Binding . . . . . . . . . 9 4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 1. Introduction Here we describe how to establish unauthenticated IPsec SAs using IKEv2 [RFC4306] and unauthenticated public keys. No new on-the-wire protocol elements are added to IKEv2. The [RFC4301] processing model is assumed. This document does not define an opportunistic BTNS mode of IPsec whereby nodes may fall back to unprotected IP when their peers do not support IKEv2, nor does it describe "leap-of-faith" modes or "connection latching". See [RFC5387] for the applicability and uses of BTNS and definitions of these terms. This document describes BTNS in terms of IKEv2 and [RFC4301]'s concepts. There is no reason why the same methods cannot be used with IKEv1 [RFC2408], [RFC2409], and [RFC2401]; however, those specifications do not include the PAD concepts, and therefore it may not be possible to implement BTNS on all compliant RFC2401 implementations. 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 & Richardson Standards Track [Page 2] RFC 5386 BTNS IPsec November 2008 2. BTNS The IPsec processing model is hereby modified as follows: o A new ID type is added: 'PUBLICKEY'. IDs of this type have public keys as values. This ID type is not used on the wire. o PAD entries that match on PUBLICKEY IDs are referred to as "BTNS PAD entries". All other PAD entries are referred to as "non-BTNS PAD entries". o BTNS PAD entries may match on specific peer PUBLICKEY IDs (or public key fingerprints) or on all peer public keys. The latter is referred to as the "wildcard BTNS PAD entry".Show full document text