draft-ietf-nfsv4-channel-bindings-02.txt   draft-ietf-nfsv4-channel-bindings-03.txt 
NETWORK WORKING GROUP N. Williams NETWORK WORKING GROUP N. Williams
Internet-Draft Sun Internet-Draft Sun
Expires: January 13, 2005 July 15, 2004 Expires: August 23, 2005 February 22, 2005
On the Use of Channel Bindings to Secure Channels On the Use of Channel Bindings to Secure Channels
draft-ietf-nfsv4-channel-bindings-02.txt draft-ietf-nfsv4-channel-bindings-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2005. This Internet-Draft will expire on August 23, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document defines and formalizes the concept of channel bindings This document defines and formalizes the concept of channel bindings
to secure layers and defines the channel bindings for several types to secure layers and defines the channel bindings for several types
of secure channels. of secure channels.
The concept of channel bindings allows applications to prove that the The concept of channel bindings allows applications to prove that the
end-points of two secure channels at different network layers are the end-points of two secure channels at different network layers are the
same by binding authentication at one channel to the session same by binding authentication at one channel to the session
skipping to change at page 2, line 13 skipping to change at page 2, line 13
may significantly improve performance for some applications. may significantly improve performance for some applications.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3 1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Authentication protocols and channel bindings . . . . . . . . 7 4. Authentication protocols and channel bindings . . . . . . . . 7
4.1 The GSS-API and channel bindings . . . . . . . . . . . . . 7 4.1 The GSS-API and channel bindings . . . . . . . . . . . . . 7
4.2 SASL and channel bindings . . . . . . . . . . . . . . . . 7 4.2 SASL and channel bindings . . . . . . . . . . . . . . . . 7
5. Channel bindings for various secure layers . . . . . . . . . . 8 5. Channel bindings for various secure layers . . . . . . . . . . 9
5.1 Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 8 5.1 Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 9
5.2 Bindings to TLS channels . . . . . . . . . . . . . . . . . 8 5.2 Bindings to TLS channels . . . . . . . . . . . . . . . . . 9
5.3 Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 8 5.3 Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 9
5.3.1 Interfaces for creating IPsec channels . . . . . . . . 9 5.3.1 Interfaces for creating IPsec channels . . . . . . . . 10
5.4 Bindings to other types of channels . . . . . . . . . . . 9 5.4 Bindings to other types of channels . . . . . . . . . . . 10
6. Benefits of channel bindings to secure channels . . . . . . . 10 6. Benefits of channel bindings to secure channels . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Over the years several attempts have been made to delegate session Over the years several attempts have been made to delegate session
skipping to change at page 7, line 46 skipping to change at page 7, line 46
being proposed separately. [NOTE: Indirect reference to CCM...] being proposed separately. [NOTE: Indirect reference to CCM...]
However, it does not, at this time, seem feasible to use SPNEGO with However, it does not, at this time, seem feasible to use SPNEGO with
such pseudo-mechanisms for negotiating the use of channel bindings. such pseudo-mechanisms for negotiating the use of channel bindings.
4.2 SASL and channel bindings 4.2 SASL and channel bindings
SASL does not provide for the use of channel bindings during SASL does not provide for the use of channel bindings during
initialization of SASL contexts. initialization of SASL contexts.
SASL applications MAY define their own exchange of integrity- SASL applications MAY define their own exchange of
protected channel bindings using established SASL integrity layers. integrity-protected channel bindings using established SASL integrity
layers.
Alternatively, SASL applications MAY use the GSS-* SASL mechanisms Alternatively, SASL applications MAY use the GSS-* SASL mechanisms
(which correspond to GSS-API mechanisms) to ensure the use of channel (which correspond to GSS-API mechanisms) to ensure the use of channel
bindings through the GSS-API's facilities; this approach may require bindings through the GSS-API's facilities; this approach may require
more study and specification elsewhere. more study and specification elsewhere.
5. Channel bindings for various secure layers 5. Channel bindings for various secure layers
Not every secure session protocol or interface provides for secure Not every secure session protocol or interface provides for secure
channels, and not every secure session protocol provides data channels, and not every secure session protocol provides data
skipping to change at page 8, line 37 skipping to change at page 9, line 37
Note that the TLS "session ID," in spite of being named similarly to Note that the TLS "session ID," in spite of being named similarly to
the SSHv2 session ID, is not suitable for use as channel bindings the SSHv2 session ID, is not suitable for use as channel bindings
because it is assigned by the server, so a MITM could assign the same because it is assigned by the server, so a MITM could assign the same
session ID on the client side as it gets from the server. session ID on the client side as it gets from the server.
5.3 Bindings to IPsec 5.3 Bindings to IPsec
IPsec does not provide for secure channels by itself, as it protects IPsec does not provide for secure channels by itself, as it protects
individual packets. Further, the IPsec SAs used to protect the individual packets. Further, the IPsec SAs used to protect the
packets for some channel (e.g., a TCP connection) need not be related packets for some channel (e.g., a TCP connection) over its lifetime
in any way that allows for construction of channel bindings. need not be related in any way that allows for construction of
channel bindings.
There is a set of IPsec parameters that may be kept constant for all There is a set of IPsec parameters that may be kept constant for all
IP packets for a given channel (e.g., a TCP connection): IP packets for a given channel (e.g., a TCP connection):
o the peers' authenticated IPsec IDs o the peers' authenticated IPsec IDs
o the SA types (e.g., transport mode ESP) o the SA types (e.g., transport mode ESP)
o the privacy and integrity protection algorithms used o the privacy and integrity protection algorithms used
[QUESTION: Should IPsec traffic selectors, that is, the protocol
(TCP, UDP, SCTP) and port numbers used for the channel be
included?]
Provided interfaces for binding a channel to these IPsec parameters Provided interfaces for binding a channel to these IPsec parameters
it is possible to construct a channel secured by IPsec. it is possible to construct a channel secured by IPsec.
The channel bindings for such a channel, then, are the values of The channel bindings for such a channel, then, are the values of
those IPsec parameters to which the channel is bound. those IPsec parameters to which the channel is bound.
Requirements for such interfaces to IPsec are specified in Requirements for such interfaces to IPsec are specified in
[IPSP-APIREQ]. [IPSP-APIREQ].
5.3.1 Interfaces for creating IPsec channels 5.3.1 Interfaces for creating IPsec channels
skipping to change at page 9, line 23 skipping to change at page 10, line 20
In order to build an IPsec channel some additional application In order to build an IPsec channel some additional application
programming interfaces are needed to: programming interfaces are needed to:
o indicate that an as yet unconnected channel is to be bound to o indicate that an as yet unconnected channel is to be bound to
IPsec IDs and IPsec IDs and
o explicitly specify one, the other or both of those IDs o explicitly specify one, the other or both of those IDs
o implicitly specify one, the other or both of those IDs (e.g., the o implicitly specify one, the other or both of those IDs (e.g., the
ID corresponding to the current application program instance) ID corresponding to the current application program instance)
o indirectly specify one, the other or both of those IDs (e.g., o indirectly specify one, the other or both of those IDs (e.g.,
through IP addresses or hostnames) through IP addresses or hostnames)
o explicitly specify ESP and/or AH and associated algorithms
and/or and/or
o discover the IPsec IDs to which a channel is bound o discover the IPsec parameters to which a channel is bound
For connection-less datagram transports the IDs to be used need to be For connection-less datagram transports the IDs to be used need to be
specified/discovered on a per-datagram basis. specified/discovered on a per-datagram basis.
See [IPSP-APIREQ]. See [IPSP-APIREQ].
5.4 Bindings to other types of channels 5.4 Bindings to other types of channels
Channel bindings for other secure session protocols are not specified Channel bindings for other secure session protocols are not specified
here. here.
skipping to change at page 14, line 41 skipping to change at page 15, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/