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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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
Show full document text