draft-ietf-nfsv4-channel-bindings-03.txt   draft-ietf-nfsv4-channel-bindings-04.txt 
NETWORK WORKING GROUP N. Williams NETWORK WORKING GROUP N. Williams
Internet-Draft Sun Internet-Draft Sun
Expires: August 23, 2005 February 22, 2005 Expires: December 31, 2006 June 29, 2006
On the Use of Channel Bindings to Secure Channels On the Use of Channel Bindings to Secure Channels
draft-ietf-nfsv4-channel-bindings-03.txt draft-ietf-nfsv4-channel-bindings-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 23, 2005. This Internet-Draft will expire on December 31, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
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
protection at the other channel. The use of channel bindings allows protection at the other channel. The use of channel bindings allows
applications to delegate session protection to lower layers, which applications to delegate session protection to lower layers, which
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 . . . . . . . . 8
4.1 The GSS-API and channel bindings . . . . . . . . . . . . . 7 4.1. The GSS-API and channel bindings . . . . . . . . . . . . . 8
4.2 SASL and channel bindings . . . . . . . . . . . . . . . . 7 4.2. SASL and channel bindings . . . . . . . . . . . . . . . . 8
5. Channel bindings for various secure layers . . . . . . . . . . 9 5. Channel bindings for various secure layers . . . . . . . . . . 10
5.1 Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 9 5.1. Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 10
5.2 Bindings to TLS channels . . . . . . . . . . . . . . . . . 9 5.2. Bindings to TLS channels . . . . . . . . . . . . . . . . . 10
5.3 Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 9 5.3. Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 10
5.3.1 Interfaces for creating IPsec channels . . . . . . . . 10 5.4. Bindings to other types of channels . . . . . . . . . . . 11
5.4 Bindings to other types of channels . . . . . . . . . . . 10 6. Benefits of channel bindings to secure channels . . . . . . . 12
6. Benefits of channel bindings to secure channels . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 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 5, line 9 skipping to change at page 5, line 9
would allow them to offload session security to the secure lower would allow them to offload session security to the secure lower
layer. layer.
One solution involves ensuring the use of secure name services for One solution involves ensuring the use of secure name services for
hostname to network address translation along with the use of secure hostname to network address translation along with the use of secure
networks (e.g., IPsec). This approach can prevent the MITM attack networks (e.g., IPsec). This approach can prevent the MITM attack
described above, but does not offer applications any guarantees that described above, but does not offer applications any guarantees that
there is no MITM in the lower layer. there is no MITM in the lower layer.
This document describes another solution: the use of "channel This document describes another solution: the use of "channel
bindings" (a GSS-API concept [RFC2743]) to bind authentication at bindings" (a GSS-API concept [RFC2743] [RFC2744]) to bind
application layers to secure transports at lower layers in the authentication at application layers to secure transports at lower
network stack. layers in the network stack.
"Channel bindings" are data which securely identify a secure channel "Channel bindings" are data which securely identify a secure channel
such that, when verified to match on both endpoints of end-to-end such that, when verified to match on both endpoints of end-to-end
application connections, leave no doubt that the endpoints of two application connections, leave no doubt that the endpoints of two
secure channels (the one identified by the bindings and the one used secure channels (the one identified by the bindings and the one used
to exchange/verify the bindings) are the same. to exchange/verify the bindings) are the same.
Because many applications exist which provide for authentication at Because many applications exist which provide for authentication at
the application layer, because many such applications use generic the application layer, because many such applications use generic
authentication frameworks, such as the GSS-API and SASL and are authentication frameworks, such as the GSS-API and SASL and are
skipping to change at page 6, line 7 skipping to change at page 6, line 7
A formal definition of the channel bindings concept is given below, A formal definition of the channel bindings concept is given below,
as well as the specific formulation of channel bindings for various as well as the specific formulation of channel bindings for various
protocols that provide for session security. protocols that provide for session security.
Specific instructions for the use of channel bindings with GSS-API Specific instructions for the use of channel bindings with GSS-API
instructions is given elsewhere. instructions is given elsewhere.
3. Definitions 3. Definitions
The GSS-API [RFC2743] is a generic interface to GSS-API security Definitions:
mechanisms which provides for authentication and session
cryptographic protection. One facility provided by the GSS-API is a o Secure channel: a packet, datagram or octet stream connection
concept of "channel bindings" which consists of some data which must between two end-points that affords cryptographic integrity and,
be provided, if at all, by both, initiators and acceptors, and which optionally, confidentiality to data exchanged over it.
the GSS-API security mechanisms ensure are the same for both, the
initiator and acceptor of any given GSS-API security context - if the o Channel binding: ensuring that no man-in-the-middle exists between
channel bindings provided by them do not match then the mechanism two end-points authenticated at one network layer but using a
fails to establish the security context. secure channel at a lower network layer.
o Channel bindings o Channel bindings
Generally some data which names a channel or its end-points.
Generally some data which names a channel or its end-points
such that if this data can be shown, at a higher network layer,
to be the same at both ends of a channel then there are no
MITMs between the two end-points at that higher network layer.
The security properties and channel bindings of the channel, The security properties and channel bindings of the channel,
once established, MUST NOT change for the lifetime of the once established, MUST NOT change for the lifetime of the
channel. channel.
More formally, there are two types of channel bindings: More formally, there are two types of channel bindings:
+ bindings that name a channel in a cryptographically secure + bindings that name a channel in a cryptographically secure
manner (e.g., the session ID in SSHv2; see below); manner (e.g., the session ID in SSHv2; see below);
+ bindings that name the authenticated end-points of a channel
(e.g., as in IPsec; see below) which are, in turn, securely + bindings that name the authenticated end-points, or even a
bound to the channel. single end-point, of a channel (e.g., as in IPsec; see
below) which are, in turn, securely bound to the channel.
Applications can exchange authenticated, integrity-protected Applications can exchange authenticated, integrity-protected
verifiers of channel bindings data to prove that the end-points verifiers of channel bindings data to prove that the end-points
of some channel are the logically the same as the application of some channel are the logically the same as the application
endpoints and thus, there can be no MITM at the lower layer. endpoints and thus, there can be no MITM at the lower layer.
o Channel bindings to network addresses o Channel bindings to network addresses
The GSS-API originally defined only channel bindings to network The GSS-API originally defined only channel bindings to network
addresses. addresses.
The network addresses of a channel's end-points typically say The network addresses of a channel's end-points typically say
nothing about the protection afforded by that channel, and nothing about the protection afforded by that channel, and
where the channel can be said to be secure the network where the channel can be said to be secure the network
addresses may not be securely bound to the channel anyways. addresses may not be securely bound to the channel anyways.
In practice channel bindings to network addresses have mostly In practice channel bindings to network addresses have mostly
just caused trouble with Network Address Translation (NAT). just caused trouble with Network Address Translation (NAT).
4. Authentication protocols and channel bindings 4. Authentication protocols and channel bindings
Some authentication services provide for channel bindings, such as Some authentication services provide for channel bindings, such as
the GSS-API and some GSS-API mechanisms, whereas others may not, such the GSS-API and some GSS-API mechanisms, whereas others may not, such
as SASL. as SASL (however, ongoing work may add channel binding support to
SASL).
Where suitable channel bindings facilities are not provided Where suitable channel bindings facilities are not provided,
application protocol designers may include a separate, protected application protocol designers may include a separate, protected
(where the authentication service provides message protection (where the authentication service provides message protection
services) exchange of channel bindings material. services) exchange of channel bindings material.
4.1 The GSS-API and channel bindings 4.1. The GSS-API and channel bindings
The GSS-API provides for the use of channel bindings during The GSS-API provides for the use of channel bindings during
initialization of GSS-API security contexts, though GSS-API initialization of GSS-API security contexts, though GSS-API
mechanisms are not required to support this facility. mechanisms are not required to support this facility.
This channel bindings facility is described in detail in RFC2744. This channel bindings facility is described in detail in RFC2744.
GSS-API applications must agree a priori, through negotiation or GSS-API applications must agree a priori, through negotiation or
otherwise, on the use of channel bindings. This is because the otherwise, on the use of channel bindings. This is because the GSS-
GSS-API does not have a way to indicate that a security context was API does not have a way to indicate that a security context was
successfully established but that the channel bindings supplied could successfully established but that the channel bindings supplied could
not be verified to be the same for both peers. not be verified to be the same for both peers.
Fortunately, it is possible to design GSS-API pseudo-mechanisms that Fortunately, it is possible to design GSS-API pseudo-mechanisms that
simply wrap around existing mechanisms for the purpose of allowing simply wrap around existing mechanisms for the purpose of allowing
applications to negotiate the use of channel bindings within their applications to negotiate the use of channel bindings within their
existing methods for negotiating GSS-API mechanisms. For example, existing methods for negotiating GSS-API mechanisms. For example,
NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as
does the SSHv2 protocol [SECSH-GSSAPI]. Such pseudo-mechanisms are does the SSHv2 protocol [SECSH-GSSAPI]. Such pseudo-mechanisms are
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
initialization of SASL contexts.
SASL applications MAY define their own exchange of SASL [RFC2222] does not yet provide for the use of channel bindings
integrity-protected channel bindings using established SASL integrity during initialization of SASL contexts.
layers.
Alternatively, SASL applications MAY use the GSS-* SASL mechanisms Work is ongoing [I-D.ietf-sasl-gs2] to specify how SASL, particularly
(which correspond to GSS-API mechanisms) to ensure the use of channel it's new bridge to the GSS-API, performs channel binding. SASL will
bindings through the GSS-API's facilities; this approach may require likely differ from the GSS-API in its handling of channel binding
more study and specification elsewhere. failure (i.e., when there may be a MITM) in that channel binding
success/failure only affects the negotiation of SASL security layers.
I.e., when channel binding succeeds SASL should select no security
layers, leaving session cryptographic protection to the secure
channel that has been bound to.
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
suitable for use as channel bindings. suitable for use as channel bindings.
5.1 Bindings to SSHv2 channels 5.1. Bindings to SSHv2 channels
SSHv2 provides both, a secure channel and material (the SSHv2 SSHv2 [RFC4251] provides both, a secure channel and material (the
"session ID") that is suitable for use as channel bindings. SSHv2 "session ID") that is suitable for use as channel bindings.
Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the
channel bindings for SSHv2. channel bindings for SSHv2.
5.2 Bindings to TLS channels 5.2. Bindings to TLS channels
TLS provides both, a secure channel and material (the TLS "finished" TLS provides both, a secure channel and material (the TLS "finished"
messages), that is suitable for use as channel bindings. messages), that is suitable for use as channel bindings.
Alternatively the TLS PRF can be applied to a suitable constant octet
string to obtain value that is cryptographically bound to the given
TLS session.
Thus it is RECOMMENDED that the concatenation of the client's and The specification of channel bindings for TLS channels is still
server's "finished" messages, in that order, be used as the channel ongoing.
bindings for TLS.
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
individual packets. Further, the IPsec SAs used to protect the
packets for some channel (e.g., a TCP connection) over its lifetime
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
IP packets for a given channel (e.g., a TCP connection):
o the peers' authenticated IPsec IDs
o the SA types (e.g., transport mode ESP)
o the privacy and integrity protection algorithms used
Provided interfaces for binding a channel to these IPsec parameters
it is possible to construct a channel secured by IPsec.
The channel bindings for such a channel, then, are the values of
those IPsec parameters to which the channel is bound.
Requirements for such interfaces to IPsec are specified in
[IPSP-APIREQ].
5.3.1 Interfaces for creating IPsec channels
In order to build an IPsec channel some additional application
programming interfaces are needed to:
o indicate that an as yet unconnected channel is to be bound to
IPsec IDs and
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
ID corresponding to the current application program instance)
o indirectly specify one, the other or both of those IDs (e.g.,
through IP addresses or hostnames)
o explicitly specify ESP and/or AH and associated algorithms
and/or
o discover the IPsec parameters to which a channel is bound IPsec [RFC4301] does not provide for secure channels by itself, as it
protects individual packets. Further, the IPsec SAs used to protect
the packets for some channel (e.g., a TCP connection) over its
lifetime need not be related in any way that allows for construction
of channel bindings.
For connection-less datagram transports the IDs to be used need to be There is ongoing work to specify an IPsec secure channel construction
specified/discovered on a per-datagram basis. called "connection latching" [I-D.ietf-btns-connection-latching].
See [IPSP-APIREQ]. Given connection latching the channel bindings for IPsec should
consist of the locally-observed ID types and values for the two end-
points of the IKE_SA that fathered the CHILD SA that triggered the
connection latch. A canonical encoding for these channel bindings
has not yet been agreed upon.
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.
6. Benefits of channel bindings to secure channels 6. Benefits of channel bindings to secure channels
The use of channel bindings to delegate session cryptographic The use of channel bindings to delegate session cryptographic
protection include: protection include:
o Performance improvements by avoiding double protection of o Performance improvements by avoiding double protection of
skipping to change at page 13, line 5 skipping to change at page 13, line 25
Anonymous secure channels SHOULD NOT be used without authentication Anonymous secure channels SHOULD NOT be used without authentication
and corresponding use of their channel bindings at higher network and corresponding use of their channel bindings at higher network
layers. layers.
The security of channel bindings depends on the security of the The security of channel bindings depends on the security of the
channels, the construction of the bindings and the security of the channels, the construction of the bindings and the security of the
authentication and integrity protection used to exchange channel authentication and integrity protection used to exchange channel
bindings. bindings.
8. References 8. Normative
8.1 Normative [I-D.ietf-btns-connection-latching]
Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching-00 (work in progress),
February 2006.
[I-D.ietf-sasl-gs2]
Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2
Mechanism Family", draft-ietf-sasl-gs2-00 (work in
progress), February 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 : [RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000. C-bindings", RFC 2744, January 2000.
8.2 Informative
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues
and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M. and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
Author's Address [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.com [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The author would like to thank Mike Eisler for his work on the The author would like to thank Mike Eisler for his work on the
Channel Conjunction Mechanism I-D and for bringing the problem to a Channel Conjunction Mechanism I-D and for bringing the problem to a
head, Sam Hartman for pointing out that channel bindings provide a head, Sam Hartman for pointing out that channel bindings provide a
general solution to the channel binding problem, Jeff Altman for his general solution to the channel binding problem, Jeff Altman for his
suggestion of using the TLS finished messages as the TLS channel suggestion of using the TLS finished messages as the TLS channel
bindings, Bill Sommerfeld, for his help in developing channel bindings, Bill Sommerfeld, for his help in developing channel
bindings for IPsec, and Radia Perlman for her most helpful comments. bindings for IPsec, and Radia Perlman for her most helpful comments,
Simon Josefsson for his work on the new SASL GSS-API bridge and his
suggestion that the TLS PRF be used to generate channel bindings to
TLS, and to many others.
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 15, line 41 skipping to change at page 17, 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 (2005). This document is subject Copyright (C) The Internet Society (2006). 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. 41 change blocks. 
144 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/