[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Intended status: Standards Track                          March 21, 2008
Expires: September 22, 2008

         Channel Bindings for IPsec Using IKEv2 and Public Keys

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 September 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Williams               Expires September 22, 2008               [Page 1]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008


   This document specifies the channel bindings for "IPsec channels"
   where the peers used the Internet Key Exchange protocol version 2
   (IKEv2) and where they used public keys and/or certificates to
   authenticate each other

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Conventions used in this document  . . . . . . . . . . . . .  3
   2.    IPsec Channel Bindings . . . . . . . . . . . . . . . . . . .  4
   3.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  5
   4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
   5.    References . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.1.  Normative References . . . . . . . . . . . . . . . . . . . .  7
   5.2.  Informative References . . . . . . . . . . . . . . . . . . .  7
         Author's Address . . . . . . . . . . . . . . . . . . . . . .  9
         Intellectual Property and Copyright Statements . . . . . . . 10

Williams               Expires September 22, 2008               [Page 2]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

1.  Introduction

   Given the ability to construct IPsec channels
   [I-D.ietf-btns-connection-latching] and the ability to bind
   authentication at application layers to such secure channels
   [RFC5056] the only missing components are: a definition of IPsec
   channel bindings, and Application Programming Interfaces (APIs) by
   which applications can obtain them.

   Here we specify the "end-point channel bindings" [RFC5056] for IPsec
   channels when peers use IKev2 [RFC4306] and public keys and/or
   certificates.  IPsec APIs [I-D.ietf-btns-ipsec-apireq] are out of
   scope for this document.

   IPsec channels where the peers were authenticated by methods other
   than public key cryptography, such as EAP [RFC3748] or pre-shared
   keys (PSK), or where IKEv2 was not used (e.g., manual keying), are
   out of scope for this document.  Channel bindings for such IPsec
   channels should be specified elsewhere, if at all.

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 September 22, 2008               [Page 3]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

2.  IPsec Channel Bindings

   The channel bindings for IPsec channels established via connection
   latching [I-D.ietf-btns-connection-latching] between peers that use
   IKEv2 [RFC4306] and public keys (with or without PKIX certificates
   [RFC3280]) SHALL be:

      the octet-string that results from the concatenation of the two
      peers' raw public keys as they appear in the subjectPublicKey
      field of their corresponding certificates' subjectPublicKeyInfo,
      or as they appear in their IKEv2 CERT payload when the "Raw RSA
      Key" CERT payload type has been used (see section 3.6 of
      [RFC4306].  The order of concatenation SHALL be the binary
      collation order of the two public keys, in increasing order.

   The "binary collation order" is the "i;octet" collation registered in
   the "Collation Registry for Internet Application Protocols"

   Because public keys in certificates are bit strings but the i;octet
   collation operates on octet strings, public keys appearing in
   certificates MUST be padded with zero bits to a number of bits that
   is divisible by eight.

   We provide end-point channel bindings (the peers' public keys) as the
   IPsec channel binding because the construction of IPsec channels by
   connection latching [I-D.ietf-btns-connection-latching] does not
   unambiguously identify a single IKE_SA or CHILD SA pair from which
   "unique channel bindings" could be derived.

   We use a binary collation to determine the order of concatenation
   because connection latching does not unambiguously identify the
   initiator of the channel (besides, even TCP supports a notion of
   simultaneous connections, in which case both peers are the
   initiators).  By using a collation to pick which key follows the
   other we obtain an encoding of the end-point channel bindings that
   both peers can agree on without negotiation.

Williams               Expires September 22, 2008               [Page 4]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

3.  IANA Considerations

   This document creates a type of channel binding, and so requires
   registration in the IANA channel binding registry (set out by

   The registration procedure will be followed when this document enters
   the RFC-Editor queue.  The registration will be as follows:

   o  Channel binding unique prefix (name): IPsec-end-point-IKEv2-pubkey

   o  Channel binding type: end-point

   o  Channel type: IPsec

   o  Published specification: <TBD>

   o  Channel binding is secret: no

   o  Description: see Section 2

   o  Intended usage: COMMON

   o  Contact: this document's author/editor

   o  Owner/Change controller: IETF

Williams               Expires September 22, 2008               [Page 5]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

4.  Security Considerations

   The security considerations of [RFC5056],
   [I-D.ietf-btns-connection-latching], and IPsec generally [RFC4301]
   apply.  The security of an application using channel binding to IPsec
   channels depends critically on the overall security of each of these
   components: IPsec [RFC4301], including the IPsec key exchange
   protocol [RFC4306], ESP/AH [RFC4303] [RFC4302], IPsec connection
   latching, and the application's authentication and channel binding
   mechanism.  A compromise of any one of those components may
   compromise the application to varying degrees.

   This document describes end-point channel bindings for some IPsec
   channels.  End-point channel bindings do not uniquely identify a
   connection, but, in this case, a pair of peers.  There are no
   additional security considerations, relating to the type of this
   channel binding, beyond those described in [RFC5056].

   The construction of IPsec end-point channel bindings described herein
   depends on the strength of the public keys and public key algorithms
   used by the IPsec peers to authenticate each other, as well as on
   IKEv2.  As such is adds no weakness beyond any weaknesses in the
   those cryptosystems.  And because these are _public_ keys this
   construction does not require confidentiality protection of the
   channel bindings.

Williams               Expires September 22, 2008               [Page 6]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

5.  References

5.1.  Normative References

              Williams, N., "IPsec Channels: Connection Latching",
              draft-ietf-btns-connection-latching-04 (work in progress),
              December 2007.

              Richardson, M. and B. Sommerfeld, "Requirements for an
              IPsec API", draft-ietf-btns-ipsec-apireq-00 (work in
              progress), April 2006.

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

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
              Application Protocol Collation Registry", RFC 4790,
              March 2007.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, November 2007.

5.2.  Informative References

              Williams, N. and M. Richardson, "Better-Than-Nothing-
              Security: An Unauthenticated Mode of IPsec",
              draft-ietf-btns-core-06 (work in progress), January 2008.

Williams               Expires September 22, 2008               [Page 7]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

              Touch, J., Black, D., and Y. Wang, "Problem and
              Applicability Statement for Better Than Nothing Security
              (BTNS)", draft-ietf-btns-prob-and-applic-06 (work in
              progress), October 2007.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

Williams               Expires September 22, 2008               [Page 8]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

Author's Address

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

   Email: Nicolas.Williams@sun.com

Williams               Expires September 22, 2008               [Page 9]

Internet-Draft        IPsec Pubkey Channel Bindings           March 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   This document and the information contained herein are provided on an

Intellectual Property

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Williams               Expires September 22, 2008              [Page 10]