Internet DRAFT - draft-williams-btns


NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Expires: February 2, 2006                                    August 2005

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on February 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   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-

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

   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

   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,

   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

              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.

              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-17 (work in progress),
              October 2004.

              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


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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Williams                Expires February 2, 2006               [Page 10]