NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Intended status: Standards Track April 21, 2008
Expires: October 23, 2008
End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys
draft-williams-ipsec-channel-binding-01.txt
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-
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 23, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Williams Expires October 23, 2008 [Page 1]
Internet-Draft IPsec End-Point Channel Bindings April 2008
Abstract
This document specifies the end-point 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. Specifically, we use hashes of the end-
points' public keys.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. IPsec Unique Channel Bindings . . . . . . . . . . . . . . . 4
2.1. API Requirements . . . . . . . . . . . . . . . . . . . . . . 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 October 23, 2008 [Page 2]
Internet-Draft IPsec End-Point Channel Bindings April 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 [RFC3280]. IPsec APIs [I-D.ietf-btns-ipsec-apireq] are
out of scope for this document, but some requirements for such APIs
are provided here.
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 (see
[I-D.williams-ipsec-unique-channel-binding]).
The primary feature of IPsec end-point channel bindings as specified
here is this: there is no reference to the actual contents of any key
exchanges other than the public keys used therein. Algorithm
negotiations, nonces, session keys, and so on are of no consequence.
And no additional message exchanges of any kind are needed in order
to establish the end-point channel bindings for an IPsec channel.
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 23, 2008 [Page 3]
Internet-Draft IPsec End-Point Channel Bindings April 2008
2. IPsec Unique Channel Bindings
The end-point 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:
HASH(HASH(ID1) XOR HASH(ID2))
Where HASH() is a cryptographic hash function selected by the
application requesting the end-point channel bindings.
Implementations MUST support the use of SHA-256 [RFC4634]. ID1 and
ID2 are the raw public keys of each peer. If a peer uses a
certificate, the value of the subjectPublicKey field (a BIT STRING)
of the certificate's subjectPublicKeyInfo field is to be used
verbatim. If a peer uses a Raw RSA CERT payload, then the
Certificate Data portion of that CERT payload will be used verbatim.
XOR is used here to avoid having to determine an order in which end-
point IDs should be used.
The rationale for using hashes of public keys is: to greatly reduce
the size of channel binding data that might need to be tracked in
kernel-mode implementations (as we'd otherwise use the raw public key
bit strings, which can be in excess of a kilobyte).
2.1. API Requirements
Because of the use of a hash function which must be selected by the
application, implementations of IPsec connection latching and end-
point channel bindings MUST provide a way, in the API for obtaining
channel bindings, for the application to select the hash function to
use.
Since hash agility here depends on the application and its ability to
negotiate hash functions for this purpose, implementations MUST
provide an API for listing the supported hash functions.
Williams Expires October 23, 2008 [Page 4]
Internet-Draft IPsec End-Point Channel Bindings April 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
[RFC5056]).
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-sha-256
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 October 23, 2008 [Page 5]
Internet-Draft IPsec End-Point Channel Bindings April 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 Internet Key Exchange
(IKEv2) protocol [RFC4306], ESP/AH [RFC4303] [RFC4302], IPsec
connection latching [I-D.ietf-btns-connection-latching], and the
application's authentication and channel binding mechanism
(potentially too many to reference here, but a common example is
likely to be the Kerberos V mechanism [RFC4121] for the Generic
Security Services API (GSS-API) [RFC2743]. 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 in time, but a pair of peers. This is sufficient to
detect man-in-the-middle attacks via channel binding. There are no
additional security considerations, relating to the type of this
channel binding, beyond those described in [RFC5056].
Use of non-pre-shared Raw RSA public keys or certificates that cannot
be validated to a given trust anchor is supported in the Better Than
Nothing (BTNS) [I-D.ietf-btns-prob-and-applic] [I-D.ietf-btns-core]
model. When combined with connection latching and channel binding
BTNS can provide all the security that an application requires but
without having to deploy an IPsec authentication infrastructure
(e.g., a PKI, manual pre-sharing of raw RSA public keys and/or self-
signed certificates).
The construction of IPsec end-point channel bindings described herein
depends on the strength of the public key algorithms used by the
IPsec peers to authenticate each other. Because we use hashes of
_public_ keys this construction does not require confidentiality
protection of the channel bindings.
We use a hash function in the construction of IPsec channel bindings.
Correspondingly, we provide for hash agility, but we push the
responsibility for hash agility to the application. Applications
cannot know what hash function their peers support without
negotiating a hash function. Supporting multiple hash functions
requires computing the end-point channel bindings for each supported
hash function, and it requires storing, in each IPsec channel, all
the those end-point channel bindings. Thus minimizing the number of
supported hash functions is important.
Williams Expires October 23, 2008 [Page 6]
Internet-Draft IPsec End-Point Channel Bindings April 2008
5. References
5.1. Normative References
[I-D.ietf-btns-connection-latching]
Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching-06 (work in progress),
February 2008.
[I-D.ietf-btns-ipsec-apireq]
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.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
5.2. Informative References
[I-D.ietf-btns-core]
Williams, N. and M. Richardson, "Better-Than-Nothing-
Security: An Unauthenticated Mode of IPsec",
draft-ietf-btns-core-06 (work in progress), January 2008.
[I-D.ietf-btns-prob-and-applic]
Williams Expires October 23, 2008 [Page 7]
Internet-Draft IPsec End-Point Channel Bindings April 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.
[I-D.williams-ipsec-unique-channel-binding]
Williams, N., "Unique Channel Bindings for IPsec Using
IKEv2", draft-williams-ipsec-unique-channel-binding-00
(work in progress), April 2008.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
Williams Expires October 23, 2008 [Page 8]
Internet-Draft IPsec End-Point Channel Bindings April 2008
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires October 23, 2008 [Page 9]
Internet-Draft IPsec End-Point Channel Bindings April 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
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
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Williams Expires October 23, 2008 [Page 10]