One document matched: draft-williams-btns-unauthenticated-bits-00.txt

NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Expires: October 31, 2005                                 April 29, 2005


An Unauthenticated, or Leap-of-Faith-Authorization Mode for Bump-In-The-
  Stack Implementations of IPsec Using Internet Key Exchange Protocols
            draft-williams-btns-unauthenticated-bits-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 October 31, 2005.

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) using public keys as IKE identities and
   unauthenticated public keys and/or certificates as IKE credentials.
   This unauthenticated SA negotiation protocol works by having IKE
   peers assert public keys as identities using a new IKE ID payload



Williams                Expires October 31, 2005                [Page 1]

Internet-Draft             Unauthenticated IKE                April 2005


   type for the purpose.  Unauthenticated IPsec is herein referred to by
   its popular acronym, "BTNS" (Better Than Nothing Security).

   This document focuses on BITS (bump in the stack) mode IPsec, leaving
   specification of unauthenticated native IPsec to a separate document.
   We assume an RFC2401bis processing model, specifically a PAD (peer
   authorization database) separate from the SPD (security policy
   database).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
   2.  Unauthenticated IKE Using Public Keys as IDs . . . . . . . . .  4
   3.  BTNS and Leap-of-Faith Authorization . . . . . . . . . . . . .  5
   3.1 PAD Extension for Leap-of-Faith BTNS . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9































Williams                Expires October 31, 2005                [Page 2]

Internet-Draft             Unauthenticated IKE                April 2005


1.  Introduction

   A number of applications can benefit from the availability of
   "unauthenticated" IPsec, applications such as "better than nothing
   security" (BTNS) [I-D.touch-anonsec], where unauthenticated key
   exchanges are subject to initial, but not subsequent MITM attacks,
   and "channel binding" applications where a binding between
   authentication at applications layers and secure channels at lower
   layers (in this case IPsec) allows for leveraging of existing
   authentication infrastructures that cannot be easily used for
   authentication in IKE.

   Here we describe how to establish unauthenticated IPsec SAs using
   IKEv1 [RFC2408] [RFC2409] or IKEv2 [IKEv2] and unauthenticated public
   keys.  A new ID payload type is introduced, ID_PUBLICKEY, by which
   IKE peers can assert public keys as IDs; the public keys are sent in
   the CERT payload using either the raw RSA key CERT or an unexpired
   x.509 certificate, valid or otherwise, self-signed or otherwise.  A
   concept of leap-of-faith addition of PAD entries for BTNS peers is
   also introduced.

   The [RFC2401bis] processing model is assumed, specifically the PAD as
   a concept separate from the SPD.

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 October 31, 2005                [Page 3]

Internet-Draft             Unauthenticated IKE                April 2005


2.  Unauthenticated IKE Using Public Keys as IDs

   An IKE peer wishing to negotiate unauthenticated SAs indicates this
   using an ID payload of type ID_PUBLICKEY (type number to be assigned
   by the IANA), with an empty (zero-length) payload body, and includes
   one or more CERT payloads, which MUST all have the same public key,
   whose corresponding private keys, will be used for computing the AUTH
   (IKEv2) or SIG (IKEv1) payloads.  It's peer may accept or reject this
   ID; if it accepts then it will validate the digital signatures in the
   AUTH (IKEv2) or SIG (IKEv1) payloads using the public key from one of
   the CERT payload(s) received.

   When asserting a public key as ID, IKE peers, both v1 and v2, MUST
   use the "Raw RSA Key" CERT (11) defined in [IKEv2] to send their
   public keys and MAY also use unexpired RSA x.509 certificates, and an
   appropriate CERT, for this purpose, and can expect their peers to
   ignore anything part of such certificates other than the
   'subjectPublicKey' or 'validity' fields.

   IKE peers, both v1 and v2, when receiving a peer's ID_PUBLICKEY MAY,
   of course, reject the exchange according to local policy (i.e., if
   the peer is not authorized to assert the given public key as its ID).

   IKE peers, both v1 and v2, SHOULD, when their peers assert at a
   public key as ID, ignore any fields of an x.509 cert sent in a CERT
   payload other than 'validity' and 'subjectPublicKey' and SHOULD avoid
   any certificate validation, including certificate revocation list
   (CRL) checking and/or certificate status checking (e.g., via OCSP).

   When a peer whose address is not found in the PAD asserts a public
   key as its ID IKE MUST either reject the exchange or, if policy
   allows it, add an entry to its PAD linking the peer's address to its
   asserted public key.  This is often known as "leap of faith"
   authorization.

















Williams                Expires October 31, 2005                [Page 4]

Internet-Draft             Unauthenticated IKE                April 2005


3.  BTNS and Leap-of-Faith Authorization

   The PAD is a configuration that indicates, to IKE for example, what
   IDs a peer otherwise identified by its IP address may assert, and,
   therefore, how each peer may be authenticated.  In this model, in
   order to obtain the desired protection for BTNS peers against
   subsequent MITMs each peer must establish a somewhat persistent peer
   address-to-BTNS-ID mapping in its PAD.  We say "somewhat" persistent
   because a BITS implementation of IPsec may not have any way to
   determine, on its own, when such a mapping is no longer necessary,
   but permanent address-to-BTNS-ID mappings are problematic and
   undesirable.

   Specifically, BTNS leap of faith authorization causes problems when
   it is used by peers using dynamically allocated addresses, whenever
   address allocations change, and whenever a BTNS peer re-generates its
   private-public key pair.

   Problems arise, in the peer address/credential change situation, due
   to the inability to signal to other peers the upcoming or already
   effected change; IKE extensions may be feasible which correct this
   problem.

   Problems arise, in the dynamic address allocation case, from an
   inability to detect when communication with a given BTNS peer is no
   longer ongoing, such that the leap-of-faith PAD entry for it may be
   removed; this is a limitation of BITS (and BITW) IPsec modes, and
   though native mode IPsec may help, for example, by providing
   programming interfaces to applications, it isn't clear that native
   mode implementations will always be able to safely make such a
   determination either.

   This, then, is a crucial feature of BTNS mode IPsec: that it is most
   useful (and least harmful) when used between systems with statically
   allocated addresses and whose BTNS keys change infrequently.

   Another crucial feature of BTNS mode IPsec: it MUST be possible to
   manually edit a PAD on a BITS (or BITW) implementation to remove
   stale BTNS entries.

3.1  PAD Extension for Leap-of-Faith BTNS

   If IKE automatically creates PAD entries for peers that use BTNS and
   which had no applicable PAD entries then a denial of service (DoS)
   attack is possible where an attacker causes a PAD entry to be
   created, at some host, for one or more peers for whose addresses the
   host had no PAD entries.




Williams                Expires October 31, 2005                [Page 5]

Internet-Draft             Unauthenticated IKE                April 2005


   To avoid this attack we propose a simple PAD extension whereby the
   willingness to use BTNS is specified for one or more addresses,
   possibly specified using range syntax.

   BITS BTNS implementations MUST provide such a facility.














































Williams                Expires October 31, 2005                [Page 6]

Internet-Draft             Unauthenticated IKE                April 2005


4.  Security Considerations

   The BTNS mode of BITS mode IPsec presented herein relies on a leap-
   of-faith addition of PAD entries linking peer IP addresses to their
   asserted public keys; these entries are mostly persistent and,
   through their persistence create the possibility of denial of service
   (DoS) attacks where an attacker causes many illegitimate PAD entries
   to be created in other systems' PADs.  No method for automatic
   recovery from incorrect BTNS PAD entries is given herein -- only
   manual intervention is envisioned for BITS implementations of IPsec
   w/ BTNS.  In other words, BITS BTNS is subject to DoS attacks.

   Unauthenticated security association negotiation is subject to MITM
   attacks and should be used with care.

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

5.  Normative

   [I-D.touch-anonsec]
              Touch, J., "ANONsec: Anonymous IPsec to Defend Against
              Spoofing Attacks", draft-touch-anonsec-00 (work in
              progress), May 2004.

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



Williams                Expires October 31, 2005                [Page 7]

Internet-Draft             Unauthenticated IKE                April 2005


              October 2004.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2401bis]
              Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", draft-ietf-ipsec-rfc2401bis-05 (work
              in progress), December 2004.

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


Author's Address

   Nicolas Williams
   Sun Microsystems
   5300 Riata Trace Ct
   Austin, TX  78727
   US

   Email: Nicolas.Williams@sun.com
























Williams                Expires October 31, 2005                [Page 8]

Internet-Draft             Unauthenticated IKE                April 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 October 31, 2005                [Page 9]