Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
RFC 5386

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

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".