< draft-funk-tls-inner-application-extension-01.txt   draft-funk-tls-inner-application-extension-02.txt >
TLS Working Group Paul Funk TLS Working Group Paul Funk
Internet-Draft Funk Software, Inc. Internet-Draft Juniper Networks
Category: Standards Track Simon Blake-Wilson Category: Standards Track Simon Blake-Wilson
<draft-funk-tls-inner-application-extension-01.txt> Basic Commerce & <draft-funk-tls-inner-application-extension-02.txt> Basic Commerce &
Industries, Inc. Industries, Inc.
Ned Smith Ned Smith
Intel Corp. Intel Corp.
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Thomas Hardjono Thomas Hardjono
VeriSign Inc. VeriSign Inc.
February 2005 March 2006
TLS Inner Application Extension TLS Inner Application Extension
(TLS/IA) (TLS/IA)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." 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 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001 - 2005). All Rights Copyright (C) The Internet Society (2006). All Rights Reserved.
Reserved.
Abstract Abstract
This document defines a new TLS extension called "Inner This document defines a new TLS extension called "Inner
Application". When TLS is used with the Inner Application extension Application". When TLS is used with the Inner Application extension
(TLS/IA), additional messages are exchanged after completion of the (TLS/IA), additional messages are exchanged after completion of the
TLS handshake, in effect providing an extended handshake prior to TLS handshake, in effect providing an extended handshake prior to
the start of upper layer data communications. Each TLS/IA message the start of upper layer data communications. Each TLS/IA message
contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from
the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and
Diameter have the same meaning in TLS/AI; that is, each attribute Diameter have the same meaning in TLS/AI; that is, each attribute
code point refers to the same logical attribute in any of these code point refers to the same logical attribute in any of these
protocols. Arbitrary "applications" may be implemented using the AVP protocols. Arbitrary "applications" may be implemented using the AVP
skipping to change at page 2, line ? skipping to change at page 2, line ?
established by the handshake. For example, TLS/IA may be used to established by the handshake. For example, TLS/IA may be used to
secure an HTTP data connection, allowing more robust password-based secure an HTTP data connection, allowing more robust password-based
user authentication to occur than would otherwise be possible using user authentication to occur than would otherwise be possible using
mechanisms available in HTTP. TLS/IA may also be used for its mechanisms available in HTTP. TLS/IA may also be used for its
handshake portion alone; for example, EAP-TTLSv1 encapsulates a handshake portion alone; for example, EAP-TTLSv1 encapsulates a
TLS/IA handshake in EAP as a means to mutually authenticate a client TLS/IA handshake in EAP as a means to mutually authenticate a client
and server and establish keys for a separate data connection. and server and establish keys for a separate data connection.
Table of Contents Table of Contents
1 Introduction................................................... 3 1 Introduction......................................................3
1.1 A Bit of History .......................................... .. 4 1.1 A Bit of History..............................................4
1.2 TLS With or Without Upper Layer Data Communications.......... 5 1.2 TLS With or Without Upper Layer Data Communications...........5
2 The Inner Application Extension to TLS......................... 5 2 The Inner Application Extension to TLS............................5
2.1 TLS/IA Overview.............................................. 7 2.1 TLS/IA Message Exchange.......................................7
2.2 Message Exchange ............................................ 8 2.2 Inner Secret..................................................9
2.3 Inner Secret................................................. 9 2.2.1 Application Session Key Material.........................10
2.3.1 Computing the Inner Secret................................. 9 2.3 Session Resumption...........................................11
2.3.2 Exporting the Final Inner Secret........................... 10 2.4 Error Termination............................................12
2.3.3 Application Session Key Material........................... 10 2.5 Negotiating the Inner Application Extension..................12
2.4 Session Resumption........................................... 12 2.6 InnerApplication Protocol....................................12
2.5 Error Termination............................................ 12 2.6.1 InnerApplicationExtension................................12
2.6 Negotiating the Inner Application Extension.................. 12 2.6.2 InnerApplication Message.................................13
2.7 InnerApplication Protocol.................................... 13 2.6.3 IntermediatePhaseFinished and FinalPhaseFinished Messages13
2.7.1 InnerApplicationExtension.................................. 13 2.6.4 The ApplicationPayload Message...........................14
2.7.2 InnerApplication Message................................... 14 2.7 Alerts .......................................................14
2.7.3 IntermediatePhaseFinished and FinalPhaseFinished Messages.. 14 3 Encapsulation of AVPs within ApplicationPayload Messages.........15
2.7.4 The ApplicationPayload Message ............................ 15 3.1 AVP Format...................................................15
2.8 Alerts....................................................... 15 3.2 AVP Sequences................................................17
3 Encapsulation of AVPs within ApplicationPayload Messages....... 16 3.3 Guidelines for Maximum Compatibility with AAA Servers........17
3.1 AVP Format................................................... 16 4 Tunneled Authentication within Application Phases................17
3.2 AVP Sequences................................................ 17 4.1 Implicit challenge...........................................18
3.3 Guidelines for Maximum Compatibility with AAA Servers........ 18 4.2 Tunneled Authentication Protocols............................18
4 Tunneled Authentication within Application Phases ............. 18 4.2.1 EAP ......................................................19
4.1 Implicit challenge........................................... 18 4.2.2 CHAP .....................................................20
4.2 Tunneled Authentication Protocols............................ 19 4.2.3 MS-CHAP..................................................20
4.2.1 EAP........................................................ 20 4.2.4 MS-CHAP-V2...............................................21
4.2.2 CHAP....................................................... 20 4.2.5 PAP ......................................................22
4.2.3 MS-CHAP.................................................... 21 4.3 Performing Multiple Authentications..........................23
4.2.4 MS-CHAP-V2................................................. 21 5 Example Message Sequences........................................23
4.2.5 PAP........................................................ 23 5.1 Full Initial Handshake with Intermediate and Final Application
4.3 Performing Multiple Authentications.......................... 23 Phases 23
5 Example Message Sequences...................................... 24 5.2 Resumed Session with Single Application Phase................24
5.1 Full Initial Handshake with Multiple Application Phases ..... 24 5.3 Resumed Session with No Application Phase....................25
5.2 Resumed Session with Single Application Phase................ 25 6 Security Considerations..........................................25
5.3 Resumed Session with No Application Phase.................... 26 7 References.......................................................28
6 Security Considerations........................................ 26 7.1 Normative References.........................................28
7 References .................................................... 29 7.2 Informative References.......................................29
7.1 Normative References......................................... 29 8 Authors' Addresses...............................................30
7.2 Informative References....................................... 30 9 Intellectual Property Statement..................................31
8 Authors' Addresses ........................................... 30
9 Intellectual Property Statement............................... 31
1 Introduction 1 Introduction
This specification defines the TLS "Inner Application" extension. This specification defines the TLS "Inner Application" extension.
The term "TLS/IA" refers to the TLS protocol when used with the The term "TLS/IA" refers to the TLS protocol when used with the
Inner Application extension. Inner Application extension.
In TLS/IA, the setup portion of TLS is extended to allow an In TLS/IA, the setup portion of TLS is extended to allow an
arbitrary exchange of information between client and server within a arbitrary exchange of information between client and server within a
protected tunnel established during the TLS handshake and prior to protected tunnel established during the TLS handshake and prior to
the start of upper layer TLS data communications. The TLS handshake the start of upper layer TLS data communications. The TLS handshake
itself is unchanged; the subsequent Inner Application exchange is itself is unchanged; the subsequent Inner Application exchange is
conducted under the confidentiality and integrity protection conducted under the confidentiality and integrity protection that is
afforded by the TLS handshake. afforded by the TLS handshake.
The primary motivation for providing such communication is to allow The primary motivation for providing this facility is to allow
robust user authentication to occur as part of an "extended" robust user authentication to occur as part of an "extended"
handshake, in particular, user authentication that is based on handshake, in particular, user authentication that is based on
password credentials, which is best conducted under the protection password credentials, which is best conducted under the protection
of an encrypted tunnel to preclude dictionary attack by of an encrypted tunnel to preclude dictionary attack by
eavesdroppers. For example, Extensible Authentication Protocol (EAP) eavesdroppers. For example, the Extensible Authentication Protocol
may be used to authenticate using any of a wide variety of methods (EAP) may be used for authentication using any of a wide variety of
as part of this extended handshake. The multi-layer approach of methods as part of this extended handshake. The multi-layer approach
TLS/IA, in which a strong authentication, typically based on a of TLS/IA, in which a strong authentication, typically based on a
server certificate, is used to protect a password-based server certificate, is used to protected a password-based
authentication, distinguishes it from other TLS variants that rely authentication, distinguishes it from other TLS variants that rely
entirely on a pre-shared key or password for security; for example entirely on a pre-shared key or password for security (such as [TLS-
[TLS-PSK]. PSK]).
The protected exchange accommodates any type of client-server The protected exchange accommodates any type of client-server
application, not just authentication, though authentication may application, not just authentication, though authentication may
often be the prerequisite that allows other applications to proceed. often be the prerequisite for other applications to proceed. For
For example, TLS/IA may be used to set up HTTP connections, example, TLS/IA may be used to set up HTTP connections, establish
establish IPsec security associations (as an alternative to IKE), IPsec security associations (as an alternative to IKE), obtain
obtain credentials for single sign-on, provide for client integrity credentials for single sign-on, provide client integrity
verification, and so on. verification, and so on.
The new messages that are exchanged between client and server are The new messages that are exchanged between client and server are
encoded as sequences of Attribute-Value-Pairs (AVPs) from the encoded as sequences of Attribute-Value-Pairs (AVPs) from the
RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace
provides natural compatibility between TLS/IA applications and provides natural compatibility between TLS/IA applications and
widely deployed AAA infrastructures. This namespace is extensible, widely deployed AAA infrastructures. This namespace is extensible,
allowing new AVPs and, thus, new applications to be defined as allowing new AVPs and, thus, new applications to be defined as
needed, either by standards bodies or by vendors wishing to define needed, either by standards bodies or by vendors wishing to define
proprietary applications. proprietary applications.
The TLS/IA exchange comprises one or more "phases", each of which The TLS/IA exchange comprises one or more "phases", each of which
consists of an arbitrary number of AVP exchanges followed by a consists of an arbitrary number of AVP exchanges followed by a
confirmation exchange. Authentications occurring in any phase must confirmation exchange. Authentications occurring in any phase must
be confirmed prior to continuing to the next phase. This allows be confirmed prior to continuing to the next phase. This allows
applications to implement security dependencies in which particular applications to implement security dependencies in which particular
assurances are required prior to exchange of additional information. assurances are required prior to the exchange of additional
information.
1.1 A Bit of History 1.1 A Bit of History
The TLS protocol has its roots in the Netscape SSL protocol, which The TLS protocol has its roots in the Netscape SSL protocol, which
was originally intended to secure HTTP. It provides either one-way was originally intended to protect HTTP traffic. It provides either
or mutual authentication of client and server based on certificates. one-way or mutual certificate-based authentication of client and
In its most typical use in HTTP, the client authenticates the server server. In its most typical use in HTTP, the client authenticates
based on the server's certificate and establishes a tunnel through the server based on the server's certificate and establishes a
which HTTP traffic is passed. tunnel through which HTTP traffic is passed.
For the server to authenticate the client within the TLS handshake, For the server to authenticate the client within the TLS handshake,
the client must have its own certificate. In cases where the client the client must have its own certificate. In cases where the client
must be authenticated without a certificate, HTTP, not TLS, must be authenticated without a certificate, HTTP, not TLS,
mechanisms would have to be employed. For example, HTTP headers have mechanisms would have to be employed. For example, HTTP headers have
been defined to perform user authentications. However, these been defined to perform user authentications. However, these
mechanisms are primitive compared to other mechanisms, most notably mechanisms are primitive compared to other mechanisms, most notably
EAP, that have been defined for contexts other than HTTP. EAP, that have been defined for contexts other than HTTP.
Furthermore, any mechanisms defined for HTTP cannot be utilized when Furthermore, any mechanisms defined for HTTP cannot be utilized when
TLS is used to protect non-HTTP traffic. TLS is used to protect non-HTTP traffic.
The TLS protocol has also found an important use in authentication The TLS protocol has also found an important use in authentication
for network access, originally within PPP for dial-up access and for network access, originally within PPP for dial-up access and
later for wireless and wired 802.1X access. Several EAP types have later for wireless and wired 802.1X access. Several EAP types have
been defined that utilize TLS to perform mutual client-server been defined that utilize TLS to perform mutual client-server
authentication. The first to appear, EAP-TLS, uses the TLS handshake authentication. The first to appear, EAP-TLS, uses the TLS handshake
to authenticate both client and server based on the certificate of to authenticate both client and server based on their certificates.
each.
Subsequent protocols, such EAP-TTLSv0 and EAP-PEAP, utilize the TLS Subsequently proposed protocols, such EAP-TTLSv0 and EAP-PEAP,
handshake to allow the client to authenticate the server based on utilize the TLS handshake to allow the client to authenticate the
the latter's certificate, then utilize the tunnel established by the server based on the latter's certificate, and then use the protected
TLS handshake to perform user authentication, typically based on channel established by the TLS handshake to perform user
password credentials. Such protocols are called "tunneled" EAP authentication, typically based on a password. Such protocols are
protocols. The authentication mechanism used inside the tunnel may called "tunneled" EAP protocols. The authentication mechanism used
itself be EAP, and the tunnel may also be used to convey additional inside the tunnel may itself be EAP, and the tunnel may also be used
information between client and server. to convey additional information between client and server.
TLS/IA is in effect a merger of the two types of TLS usage described While tunneled authentication would be useful in other contexts
above, based on the recognition that tunneled authentication would besides EAP, the tunneled protocols mentioned above cannot be
be useful in other contexts besides EAP. However, the tunneled employed in a more general use of TLS, since the outermost protocol
protocols mentioned above are not directly compatible with a more is EAP, not TLS. Furthermore, these protocols use the TLS tunnel to
generic use of TLS, because they utilize the tunneled data portion carry authentication exchanges, and thus preclude use of the TLS
of TLS, thus precluding its use for other purposes such as carrying tunnel for other purposes such as carrying HTTP traffic.
HTTP traffic.
The TLS/IA solution to this problem is to insert an additional TLS/IA provides a means to perform user authentication and other
message exchange between the TLS handshake and the subsequent data message exchanges between client and server strictly within TLS.
communications phase, carried in a new record type distinct from the TLS/IA can thus be used both for flexible user authentication within
record type that carries upper layer data. Thus, the data portion of a TLS session and as a basis for tunneled authentication within EAP.
the TLS exchange becomes available for HTTP or any other protocol or
connection that needs to be secured. The TLS/IA approach is to insert an additional message exchange
between the TLS handshake and the subsequent data communications
phase. This message exchange is carried in a new record type, which
is distinct from the record type that carries upper layer data.
Thus, the data portion of the TLS exchange becomes available for
HTTP or another protocol that needs to be secured.
1.2 TLS With or Without Upper Layer Data Communications 1.2 TLS With or Without Upper Layer Data Communications
It is anticipated that TLS/IA will be used with and without It is anticipated that TLS/IA will be used with and without
subsequent protected data communication within the tunnel subsequent protected data communication within the tunnel
established by the handshake. established by the handshake.
For example, TLS/IA may be used to secure an HTTP data connection, For example, TLS/IA may be used to protect an HTTP connection,
allowing more robust password-based user authentication to occur allowing more robust password-based user authentication to occur
within the TLS/IA extended handshake than would otherwise be within the TLS/IA extended handshake than would otherwise be
possible using mechanisms available in HTTP. possible using mechanisms available in HTTP.
TLS/IA may also be used for its handshake portion alone. For TLS/IA may also be used for its handshake portion alone. For
example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP
as a means to mutually authenticate a client and server and as a means to mutually authenticate a client and server and
establish keys for a separate data connection; no subsequent TLS establish keys for a separate data connection; no subsequent TLS
data portion is required. Another example might be use of TLS/IA data portion is required. Another example might be the use of TLS/IA
directly over TCP to provide a user with credentials for single directly over TCP in order to provide a user with credentials for
sign-on. single sign-on.
2 The Inner Application Extension to TLS 2 The Inner Application Extension to TLS
The Inner Application extension to TLS follows the guidelines of The Inner Application extension to TLS follows the guidelines of
[RFC3546]. [RFC3546].
A new extension type is defined for negotiating use of TLS/IA A new extension type is defined for negotiating use of TLS/IA:
- The InnerApplicationExtension extension type. The client proposes - The InnerApplicationExtension extension type. The client proposes
use of this extension by including a InnerApplicationExtension use of this extension by including a InnerApplicationExtension
message in its ClientHello handshake message, and the server message in its ClientHello handshake message, and the server
confirms its use by including a InnerApplicationExtension message confirms its use by including a InnerApplicationExtension message
in its ServerHello handshake message. in its ServerHello handshake message.
A new record type (ContentType) is defined for use in TLS/IA: A new record type (ContentType) is defined for use in TLS/IA:
- The InnerApplication record type. This record type carries all - The InnerApplication record type. This record type carries all
messages that implement the inner application extension. These messages that are exchanged after the TLS handshake and prior to
messages will occur after the TLS handshake and prior to exchange exchange of data.
of data.
A new message type is defined for use within the InnerApplication A new message type is defined for use within the InnerApplication
record type: record type:
- The InnerApplication message. This message may encapsulate any of - The InnerApplication message. This message may encapsulate any of
three subtypes: the three following subtypes:
- The ApplicationPayload message. This message is used to carry - The ApplicationPayload message. This message is used to carry
AVP (Attribute-Value Pair) sequences within the TLS/IA AVP (Attribute-Value Pair) sequences within the TLS/IA
extended handshake, in support of client-server applications extended handshake, in support of client-server applications
such as authentication. such as authentication.
- The IntermediatePhaseFinished message. This message confirms - The IntermediatePhaseFinished message. This message confirms
session keys established during the current TLS/IA phase, and session keys established during the current TLS/IA phase, and
indicates that at least one additional phase is to follow. indicates that at least one additional phase is to follow.
- The FinalPhaseFinished message. This message confirms session - The FinalPhaseFinished message. This message confirms session
keys established during the current TLS/IA phase, and keys established during the current TLS/IA phase, and
indicates that no further phases are to follow. indicates that no further phases are to follow.
Two new alert codes are defined for use in TLS/IA: Two new alert codes are defined for use in TLS/IA:
- The InnerApplicationFailure alert. This error alert allows either - The InnerApplicationFailure alert. This error alert allows either
party to terminate the TLS/IA extended handshake due to a failure party to terminate the TLS/IA extended handshake due to a failure
in an application implemented via AVP sequences carried in in an application implemented via AVP sequences carried in
ApplicationPayload messages. ApplicationPayload messages.
- The InnerApplicationVerification alert. This error alert allows - The InnerApplicationVerification alert. This error alert allows
either party to terminate the TLS/IA extended handshake due to either party to terminate the TLS/IA extended handshake due to
incorrect verification data in a received incorrect verification data in a received
IntermediatePhaseFinished or FinalPhaseFinished message. IntermediatePhaseFinished or FinalPhaseFinished message.
The following new assigned numbers are used in TLS/IA: The following new assigned numbers are used in TLS/IA:
- "InnerApplicationExtension" extension type:37703 - "InnerApplicationExtension" extension type: 37703
- "InnerApplication" record type: 24 - "InnerApplication" record type: 24
- "InnerApplicationFailure" alert code: 208 - "InnerApplicationFailure" alert code: 208
- "InnerApplicationVerification" alert code:209 - "InnerApplicationVerification" alert code: 209
[Editor's note: I have not checked these types yet against types [Editor's note: I have not checked these types yet against types
defined in RFCs or drafts. The TLS RFC specifies that new record defined in RFCs or drafts. The TLS RFC specifies that new record
types use the next number after ones already defined; hence I used types use the next number after ones already defined; hence I used
24, though I don't know if that is already taken.] 24, though I don't know if that is already taken.]
2.1 TLS/IA Overview 2.1 TLS/IA Message Exchange
In TLS/IA, zero or more "application phases are inserted after the In TLS/IA, zero or more "application phases are inserted after the
TLS handshake and prior to ordinary data exchange. The last such TLS handshake and prior to ordinary data exchange. The last such
application phase is called the "final phase"; any application application phase is called the "final phase"; any application
phases prior to the final phase are called "intermediate phases". phases prior to the final phase are called "intermediate phases".
Intermediate phases are only necessary if interim confirmation of Intermediate phases are only necessary if interim confirmation of
session keys generated during an application phase is desired. session keys generated during an application phase is desired.
Each application phase consists of ApplicationPayload handshake Each application phase consists of ApplicationPayload handshake
messages exchanged by client and server to implement applications messages exchanged by client and server to implement applications
such as authentication, plus concluding messages for cryptographic such as authentication, plus concluding messages for cryptographic
confirmation. These messages are encapsulated in records with confirmation. These messages are encapsulated in records with
ContentType of InnerApplication. ContentType of InnerApplication.
All application phases prior to the final phase use All application phases prior to the final phase conclude with an
IntermediatePhaseFinished rather than FinalPhaseFinished as the exchange of IntermediatePhaseFinished messages, or conclude with a
concluding message. The final phase concludes with the FinalPhaseFinished message from the server and an
FinalPhaseFinished message. IntermediatePhaseFinished message from the client, by which the
client indicates its desire to keep the handshake open for one or
more additional phases. The final phase concludes with an exchange
of FinalPhaseFinished messages.
Application phases may be omitted entirely only when session Application phases may be omitted entirely only when session
resumption is used, provided both client and server agree that no resumption is used, provided both client and server agree that no
application phase is required. The client indicates in its application phase is required. The client indicates in its
ClientHello whether it is willing to omit application phases in a ClientHello whether it is willing to omit application phases in a
resumed session, and the server indicates in its ServerHello whether resumed session, and the server indicates in its ServerHello whether
any application phases are to ensue. any application phases are to ensue.
In each application phase, the client sends the first In each application phase, the client sends the first
ApplicationPayload message. ApplicationPayload messages are then ApplicationPayload message. ApplicationPayload messages are traded
traded one at a time between client and server, until the server one at a time between client and server, until the server concludes
concludes the phase by sending, in response to an ApplicationPayload the phase by sending, in response to an ApplicationPayload message
message from the client, an IntermediatePhaseFinished sequence to from the client, an IntermediatePhaseFinished or FinalPhaseFinished
conclude an intermediate phase, or a FinalPhaseFinished sequence to sequence to conclude the phase. The client then responds with its
conclude the final phase. The client then responds with its own own IntermediatePhaseFinished or FinalPhaseFinished message.
IntermediatePhaseFinished or FinalPhaseFinished message.
The server determines which type of concluding message it wants to
use, either IntermediatePhaseFinished or FinalPhaseFinished. If the
server sent an IntermediatePhaseFinished, the client MUST respond
with an IntermediatePhaseFinished. If the server sent a
FinalPhaseFinished, the client MAY respond with a FinalPhaseFinished
to complete the handshake, or MAY respond with an
IntermediatePhaseFinished to cause the handshake to continue. Thus,
conclusion of the entire handshake occurs only when both client and
server have been satisfied.
Note that the server MUST NOT send an IntermediatePhaseFinished or Note that the server MUST NOT send an IntermediatePhaseFinished or
FinalPhaseFinished message immediately after sending an FinalPhaseFinished message immediately after sending an
ApplicationPayload message. It must allow the client to send an ApplicationPayload message. It must allow the client to send an
ApplicationPayload message prior to concluding the phase. Thus, ApplicationPayload message prior to concluding the phase. Thus,
within any application phase, there will be one more within any application phase, there will be one more
ApplicationPayload message sent by the client than sent by the ApplicationPayload message sent by the client than sent by the
server. server.
The server determines which type of concluding message is used, At the start of each application phase, the server MUST wait for the
either IntermediatePhaseFinished or FinalPhaseFinished, and the client's opening ApplicationPayload message before it sends its own
client MUST echo the same type of concluding message. Each ApplicationPayload message to the client. The client MUST NOT
IntermediatePhaseFinished or FinalPhaseFinished message provides initiate conclusion of an application phase by sending the first
cryptographic confirmation of any session keys generated during the IntermediatePhaseFinished or FinalPhaseFinished message; it MUST
current and any prior applications phases. allow the server to initiate the conclusion of the phase.
Each IntermediatePhaseFinished or FinalPhaseFinished message
provides cryptographic confirmation of any session keys generated
during the current and any prior applications phases.
Each ApplicationPayload message contains opaque data interpreted as Each ApplicationPayload message contains opaque data interpreted as
an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence
contains a typed data element. The exchanged AVPs allow client and contains a typed data element. The exchanged AVPs allow client and
server to implement "applications" within a secure tunnel. An server to implement "applications" within a secure tunnel. An
application may be any procedure that someone may usefully define. A application may be any procedure that someone may usefully define. A
typical application might be authentication; for example, the server typical application might be authentication; for example, the server
may authenticate the client based on password credentials using EAP. may authenticate the client based on password credentials using EAP.
Other possible applications include distribution of keys, validating Other possible applications include distribution of keys, validating
client integrity, setting up IPsec parameters, setting up SSL VPNs, client integrity, setting up IPsec parameters, setting up SSL VPNs,
and so on. and so on.
An "inner secret" is computed during each application phase that
mixes the TLS master secret with any session keys that have been
generated during the current and any previous application phases. At
the conclusion of each application phase, a new inner secret is
computed and is used to create verification data that is exchanged
via the IntermediatePhaseFinished or FinalPhaseFinished messages. By
mixing session keys of inner authentications with the TLS master
secret, certain man-in-the-middle attacks are thwarted [MITM].
2.2 Message Exchange
Each intermediate application phase consists of ApplicationPayload
messages sent alternately by client and server, and a concluding
exchange of IntermediatePhaseFinished messages. The first and last
ApplicationPayload message in each intermediate phase is sent by the
client; the first IntermediatePhaseFinished message is sent by the
server. Thus the client begins the exchange with an
ApplicationPayload message and the server determines when to
conclude it by sending IntermediatePhaseFinished. When it receives
the server's IntermediatePhaseFinished message, the client sends its
own IntermediatePhaseFinished message, followed by an
ApplicationPayload message to begin the next handshake phase.
The final application proceeds in the same manner as the
intermediate phase, except that the FinalPhaseFinished message is
sent by the server and echoed by the client, and the client does not
send an ApplicationPayload message for the next phase because there
is no next phase.
At the start of each application phase, the server MUST wait for the
client's opening ApplicationPayload message before it sends its own
ApplicationPayload message to the client. The client MAY NOT
initiate conclusion of an application handshake phase by sending the
first IntermediatePhaseFinished or FinalPhaseFinished message; it
MUST allow the server to initiate the conclusion of the phase.
Note that it is perfectly acceptable for either client or server to Note that it is perfectly acceptable for either client or server to
send an ApplicationPayload message containing no AVPs. The client, send an ApplicationPayload message containing no AVPs. The client,
for example, may have no AVPs to send in its first or last for example, may have no AVPs to send in its first or last
ApplicationPayload message during an application phase. ApplicationPayload message during an application phase.
2.3 Inner Secret An "inner secret" is computed during each application phase that
cryptographically combines the TLS master secret with any session
keys that have been generated during the current and any previous
application phases. At the conclusion of each application phase, a
new inner secret is computed and is used to create verification data
that is exchanged via the IntermediatePhaseFinished or
FinalPhaseFinished messages. By mixing session keys of inner
authentications with the TLS master secret, certain man-in-the-
middle attacks are thwarted [MITM].
2.2 Inner Secret
The inner secret is a 48-octet value used to confirm that the The inner secret is a 48-octet value used to confirm that the
endpoints of the TLS handshake are the same entities as the endpoints of the TLS handshake are the same entities as the
endpoints of the inner authentications that may have been performed endpoints of the inner authentications that may have been performed
during each application phase. during each application phase.
The inner secret is initialized at the conclusion of the TLS The inner secret is initialized to the master secret at the
handshake and permuted at the conclusion of each application phase. conclusion of the TLS handshake. At the conclusion of each
application phase, prior to computing verification data for
The inner secret that results from the final application phase is inclusion in the IntermediatePhaseFinished or FinalPhaseFinished
the final inner secret. message, each party permutes the inner secret using a PRF that
includes session keys produced during the current application phase.
When a new (non-resumed) session is negotiated, the resulting final The value that results replaces the current inner secret and is used
inner secret is saved as part of the session state for use in to compute the verification data.
session resumption.
2.3.1 Computing the Inner Secret
At the conclusion of the TLS handshake, each party initializes the
inner secret to:
- the master secret, if this is a new session
- the previously computed final inner secret of the original
session, if this is a resumed session
At the conclusion of each application phase, prior to computing
verification data for inclusion in the IntermediatePhaseFinished or
FinalPhaseFinished message, each party permutes the inner secret
using a PRF that includes session keys produced during the current
application phase. The value that results replaces the current inner
secret and is used to compute the verification data.
inner_secret = PRF(inner_secret, inner_secret = PRF(inner_secret,
"inner secret permutation", "inner secret permutation",
SecurityParameters.server_random + SecurityParameters.server_random +
SecurityParameters.client_random + SecurityParameters.client_random +
session_key_material) [0..48]; session_key_material) [0..48];
session_key_material is the concatenation of session_key vectors, session_key_material is the concatenation of session_key vectors,
one for each session key generated during the current phase, where: one for each session key generated during the current phase, where:
skipping to change at page 10, line 25 skipping to change at page 9, line 50
session_key vectors and concatenated in the determined order to form session_key vectors and concatenated in the determined order to form
session_key_material. session_key_material.
If no session keys were generated during the current phase, If no session keys were generated during the current phase,
session_key_material will be null. session_key_material will be null.
Note that session_key_material itself is not a vector and therefore Note that session_key_material itself is not a vector and therefore
not prefixed with the length of the entire collection of session_key not prefixed with the length of the entire collection of session_key
vectors. vectors.
2.3.2 Exporting the Final Inner Secret
Note that, within TLS itself, the inner secret is used for Note that, within TLS itself, the inner secret is used for
verification only, not for encryption. However, the inner secret verification only, not for encryption. However, the inner secret
resulting from the final application phase may be exported for use resulting from the final application phase may be exported for use
as a key from which additional session keys may be derived for as a key from which additional session keys may be derived for
arbitrary purposes, including encryption of data communications arbitrary purposes, including encryption of data communications
separate from TLS. separate from TLS.
An exported inner secret should not be used directly as a session An exported inner secret should not be used directly for any
key. Instead, additional keys should be derived from the inner cryptographic purpose. Instead, additional keys should be derived
secret, for example by using a PRF, and the client and server from the inner secret, for example by using a PRF. This ensures
randoms should be incorporated into the derivation. This ensures
cryptographic separation between use of the inner secret for session cryptographic separation between use of the inner secret for session
key confirmation and additional use of the inner secret outside key confirmation and additional use of the inner secret outside
TLS/IA. TLS/IA.
Note that for a resumed session that does not include an application 2.2.1 Application Session Key Material
phase, the final inner secret of that session is identical to that
of the original session; hence, incorporation of randoms becomes
critically important to ensure the cryptographic separation of the
keys derived from sessions sharing a common original session.
2.3.3 Application Session Key Material
Many authentication protocols used today generate session keys that Many authentication protocols used today generate session keys that
are bound to the authentication. Such keying material is normally are bound to the authentication. Such keying material is normally
intended for use in a subsequent data connection for encryption and intended for use in a subsequent data connection for encryption and
validation. For example, EAP-TLS, MS-CHAP-V2 and its alter ego EAP- validation. For example, EAP-TLS, MS-CHAP-V2, and EAP-MS-CHAP-V2
MS-CHAP-V2 each generate session keys. generate session keys.
Any session keys generated during an application phase MUST be used Any session keys generated during an application phase MUST be used
to permute the TLS/IA inner secret between one phase and the next, to permute the TLS/IA inner secret between one phase and the next,
and MUST NOT be used for any other purpose. and MUST NOT be used for any other purpose.
Each authentication protocol may define how the session key it Each authentication protocol may define how the session key it
generates is mapped to an octet sequence of some length for the generates is mapped to an octet sequence of some length for the
purpose of TLS/IA mixing. However, for protocols which do not purpose of TLS/IA mixing. However, for protocols which do not
specify this (including the multitude of protocols that pre-date specify this (including the multitude of protocols that pre-date
TLS/IA) the following rules are defined. The first rule that applies TLS/IA) the following rules are defined. The first rule that applies
SHALL be the method for determining the session key: SHALL be the method for determining the session key.
- If the authentication protocol produces an MSK (as defined in - If the authentication protocol produces an MSK (as defined in
[RFC3784]), the MSK is used as the session key. Note that an MSK [RFC3784]), the MSK is used as the session key. Note that an MSK
is 64 octets. is 64 octets.
- If the authentication protocol maps its keying material to the - If the authentication protocol maps its keying material to the
RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key
[RFC2548], then the keying material for those attributes are [RFC2548], then the keying material for those attributes are
concatenated, with MS-MPPE-Recv-Key first (Note that this rule concatenated, with MS-MPPE-Recv-Key first (Note that this rule
applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.) applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.)
skipping to change at page 11, line 42 skipping to change at page 11, line 5
against tunneled authentication protocols, as described in [MITM]. against tunneled authentication protocols, as described in [MITM].
In such an attack, an unsuspecting client is induced to perform an In such an attack, an unsuspecting client is induced to perform an
untunneled authentication with an attacker posing as a server; the untunneled authentication with an attacker posing as a server; the
attacker then introduces the authentication protocol into a tunneled attacker then introduces the authentication protocol into a tunneled
authentication protocol, fooling an authentic server into believing authentication protocol, fooling an authentic server into believing
that the attacker is the authentic user. that the attacker is the authentic user.
By mixing both the TLS master secret and session keys generated By mixing both the TLS master secret and session keys generated
during application phase authentication into the inner secret used during application phase authentication into the inner secret used
for application phase verification, such attacks are thwarted, as it for application phase verification, such attacks are thwarted, as it
guarantees that the same client both terminated the TLS handshake guarantees that the same client acted as the endpoint for both the
and performed the application phase authentication. Note that the TLS handshake and the application phase authentication. Note that
session keys generated during authentication must be the session keys generated during authentication must be
cryptographically related to the authentication and not derivable cryptographically bound to the authentication and not derivable from
from data exchanged during authentication in order for the keying data exchanged during authentication in order for the keying
material to be useful in thwarting such attacks. material to be useful in thwarting such attacks.
In addition, the fact that the inner secret cryptographically In addition, the fact that the inner secret cryptographically
incorporates session keys from application phase authentications incorporates session keys from application phase authentications
provides additional protection when the inner secret is exported for provides additional protection when the inner secret is exported for
the purpose of generating additional keys for use outside of the TLS the purpose of generating additional keys for use outside of the TLS
exchange. If such an exported secret did not include keying material exchange. If such an exported secret did not include keying material
from inner authentications, an eavesdropper who somehow knew the from inner authentications, an eavesdropper who somehow knew the
server's private key could, in an RSA-based handshake, determine the server's private key could, in an RSA-based handshake, determine the
exported secret and hence would be able to compute the additional exported secret and hence would be able to compute the additional
keys that are based on it. When inner authentication keying material keys that are based on it. When inner authentication keying
is incorporated into the exported secret, such an attack becomes material, unknown to the attacker, is incorporated into the exported
impossible. secret, such an attack becomes infeasible.
2.4 Session Resumption 2.3 Session Resumption
A TLS/IA initial handshake phase may be resumed using standard A TLS/IA initial handshake phase may be resumed using standard
mechanisms defined in [RFC2246]. When the TLS session is resumed, mechanisms defined in [RFC2246]. When the TLS session is resumed,
client and server may not deem it necessary to exchange AVPs in one client and server may not deem it necessary to exchange AVPs in one
or more additional application phases, as the resumption itself may or more additional application phases, as the resumption itself may
provide all the security needed. provide the necessary security.
The client indicates within the InnerApplicationExtension message in The client indicates within the InnerApplicationExtension message in
ClientHello whether it requires AVP exchange when session resumption ClientHello whether it requires AVP exchange when session resumption
occurs. If it indicates that it does not, then the server may at its occurs. If it indicates that it does not, then the server may at its
option omit application phases and the two parties proceed to upper option omit application phases and the two parties proceed to upper
layer data communications immediately upon completion of the TLS layer data communications immediately upon completion of the TLS
handshake. The server indicates whether application phases are to handshake. The server indicates whether application phases are to
follow the TLS handshake in its InnerApplication extension message follow the TLS handshake in its InnerApplication extension message
in ServerHello. in ServerHello.
Note that [RFC3546] specifically states that when session resumption Note that [RFC3546] specifically states that when session resumption
is used, the server MUST ignore any extensions in the ClientHello. is used, the server MUST ignore any extensions in the ClientHello.
However, it is not possible to comply with this requirement for the However, it is not possible to comply with this requirement for the
Inner Application extension, since even in a resumed session it may Inner Application extension, since even in a resumed session it may
be necessary to include application phases, and whether they must be be necessary to include application phases, and whether they must be
included is negotiated in the extension message itself. Therefore, included is negotiated in the extension message itself. Therefore,
the [RFC3546] provision is specifically overridden for the single the [RFC3546] provision is explicitly overridden for the single case
case of the Inner Application extension, which is considered an of the Inner Application extension, which is considered an exception
exception to this rule. to this rule.
A TLS/IA session MAY NOT be resumed if an application phase resulted A TLS/IA session MAY NOT be resumed if an application phase resulted
in failure, even though the TLS handshake itself succeeded. Both in failure, even though the TLS handshake itself succeeded. Both
client and server MUST NOT save session state for possible future client and server MUST NOT save session state for possible future
resumption unless the TLS handshake and all subsequent application resumption unless the TLS handshake and all subsequent application
phases succeed. phases have been successfully executed.
2.5 Error Termination 2.4 Error Termination
The TLS/IA handshake may be terminated by either party sending a The TLS/IA handshake may be terminated by either party sending a
fatal alert, following standard TLS procedures. fatal alert, following standard TLS procedures.
2.6 Negotiating the Inner Application Extension 2.5 Negotiating the Inner Application Extension
Use of the InnerApplication extension follows [RFC3546]. The client Use of the InnerApplication extension follows [RFC3546]. The client
proposes use of this extension by including the proposes use of this extension by including the
InnerApplicationExtension message in the client_hello_extension_list InnerApplicationExtension message in the client_hello_extension_list
of the extended ClientHello. If this message is included in the of the extended ClientHello. If this message is included in the
ClientHello, the server MAY accept the proposal by including the ClientHello, the server MAY accept the proposal by including the
InnerApplicationExtension message in the server_hello_extension_list InnerApplicationExtension message in the server_hello_extension_list
of the extended ServerHello. If use of this extension is either not of the extended ServerHello. If use of this extension is either not
proposed by the client or not confirmed by the server, the proposed by the client or not confirmed by the server, the
InnerApplication record type MUST NOT be used. InnerApplication record type MUST NOT be used.
2.7 InnerApplication Protocol 2.6 InnerApplication Protocol
All specifications of TLS/IA messages follow the usage defined in All specifications of TLS/IA messages follow the usage defined in
[RFC2246]. [RFC2246].
2.7.1 InnerApplicationExtension 2.6.1 InnerApplicationExtension
enum { enum {
no(0), yes(1), (255) no(0), yes(1), (255)
} AppPhaseOnResumption; } AppPhaseOnResumption;
struct { struct {
AppPhaseOnResumption app_phase_on_resumption; AppPhaseOnResumption app_phase_on_resumption;
} InnerApplicationExtension; } InnerApplicationExtension;
If the client wishes to propose use of the Inner Application If the client wishes to propose use of the Inner Application
skipping to change at page 14, line 10 skipping to change at page 13, line 24
If the server sets app_phase_on_resumption to "yes" for a resumed If the server sets app_phase_on_resumption to "yes" for a resumed
session, then the client MUST initiate an application phase at the session, then the client MUST initiate an application phase at the
conclusion of the TLS handshake. conclusion of the TLS handshake.
The value of app_phase_on_resumption applies to the current The value of app_phase_on_resumption applies to the current
handshake only; that is, it is possible for app_phase_on_resumption handshake only; that is, it is possible for app_phase_on_resumption
to have different values in two handshakes that are both resumed to have different values in two handshakes that are both resumed
from the same original TLS session. from the same original TLS session.
2.7.2 InnerApplication Message 2.6.2 InnerApplication Message
enum { enum {
application_payload(0), intermediate_phase_finished(1), application_payload(0), intermediate_phase_finished(1),
final_phase_finished(2), (255) final_phase_finished(2), (255)
} InnerApplicationType; } InnerApplicationType;
struct { struct {
InnerApplicationType msg_type; InnerApplicationType msg_type;
uint24 length; uint24 length;
select (InnerApplicationType) { select (InnerApplicationType) {
case application_payload: ApplicationPayload; case application_payload: ApplicationPayload;
case intermediate_phase_finished: case intermediate_phase_finished:
IntermediatePhaseFinished; IntermediatePhaseFinished;
case final_phase_finished: FinalPhaseFinished; case final_phase_finished: FinalPhaseFinished;
} body; } body;
} InnerApplication; } InnerApplication;
The InnerApplication message carries any of the message types The InnerApplication message carries any of the message types
defined for the InnerApplication protocol. defined for the InnerApplication protocol.
2.7.3 IntermediatePhaseFinished and FinalPhaseFinished Messages 2.6.3 IntermediatePhaseFinished and FinalPhaseFinished Messages
struct { struct {
opaque verify_data[12]; opaque verify_data[12];
} PhaseFinished; } PhaseFinished;
PhaseFinished IntermediatePhaseFinished; PhaseFinished IntermediatePhaseFinished;
PhaseFinished FinalPhaseFinished; PhaseFinished FinalPhaseFinished;
verify_data verify_data
PRF(inner_secret, finished_label) [0..11]; PRF(inner_secret, finished_label) [0..11];
finished_label finished_label
when sent by the client, the string "client phase finished" when sent by the client, the string "client phase finished"
when sent by the server, the string "server phase finished" when sent by the server, the string "server phase finished"
The IntermediatePhaseFinished and FinalPhaseFinished messages have The IntermediatePhaseFinished and FinalPhaseFinished messages have
the same structure and include verification data based on the the same structure and include verification data based on the
current inner secret. IntermediatePhaseFinished is sent by the current inner secret. IntermediatePhaseFinished is sent by the
server and echoed by the client to conclude an intermediate server and echoed by the client to conclude an intermediate
application phase, and FinalPhaseFinished is used in the same manner application phase, and FinalPhaseFinished is used in the same manner
to conclude the final application phase. to conclude the final application phase.
2.7.4 The ApplicationPayload Message 2.6.4 The ApplicationPayload Message
The ApplicationPayload message carries an AVP sequence during an The ApplicationPayload message carries an AVP sequence during an
application handshake phase. It is defined as follows: application handshake phase. It is defined as follows:
struct { struct {
opaque avps[InnerApplication.length]; opaque avps[InnerApplication.length];
} ApplicationPayload; } ApplicationPayload;
avps avps
The AVP sequence, treated as an opaque sequence of octets. The AVP sequence, treated as an opaque sequence of octets.
skipping to change at page 15, line 28 skipping to change at page 14, line 41
The length field in the encapsulating InnerApplication The length field in the encapsulating InnerApplication
message. message.
Note that the "avps" element has its length defined in square Note that the "avps" element has its length defined in square
bracket rather than angle bracket notation, implying a fixed rather bracket rather than angle bracket notation, implying a fixed rather
than variable length vector. This avoids having the length of the than variable length vector. This avoids having the length of the
AVP sequence specified redundantly both in the encapsulating AVP sequence specified redundantly both in the encapsulating
InnerApplication message and as a length prefix in the avps element InnerApplication message and as a length prefix in the avps element
itself. itself.
2.8 Alerts 2.7 Alerts
Two new alert codes are defined for use during an application phase. Two new alert codes are defined for use during an application phase.
The AlertLevel for either of these alert codes MUST be set to The AlertLevel for either of these alert codes MUST be set to
"fatal". "fatal".
InnerApplicationFailure InnerApplicationFailure
An InnerApplicationFailure error alert may be sent by either An InnerApplicationFailure error alert may be sent by either
party during an application phase. This indicates that the party during an application phase. This indicates that the
sending party considers the negotiation to have failed due to an sending party considers the negotiation to have failed due to an
application carried in the AVP sequences, for example, a failed application carried in the AVP sequences, for example, a failed
authentication. authentication.
InnerApplicationVerification InnerApplicationVerification
An InnerApplicationVerification error alert is sent by either An InnerApplicationVerification error alert is sent by either
party during an application phase to indicate that the received party during an application phase to indicate that the received
IntermediatePhaseFinished or FinalPhaseFinished is invalid, that IntermediatePhaseFinished or FinalPhaseFinished is invalid.
is, contains verification data that does not match what is
expected.
Note that other alerts are possible during an application phase; for Note that other alerts are possible during an application phase; for
example, decrypt_error. The InnerApplicationFailure alert relates example, decrypt_error. The InnerApplicationFailure alert relates
specifically to the failure of an application implemented via AVP specifically to the failure of an application implemented via AVP
sequences; for example, failure of an EAP or other authentication sequences; for example, failure of an EAP or other authentication
method, or information passed within the AVP sequence that is found method, or information passed within the AVP sequence that is found
unsatisfactory. unsatisfactory.
3 Encapsulation of AVPs within ApplicationPayload Messages 3 Encapsulation of AVPs within ApplicationPayload Messages
During application phases of the TLS handshake, information is During application phases of the TLS handshake, information is
exchanged between client and server through the use of attribute- exchanged between client and server through the use of attribute-
value pairs (AVPs). This data is encrypted using the then-current value pairs (AVPs). This data is encrypted using the current cipher
cipher state established during the preceding handshake phase. state.
The AVP format chosen for TLS/IA is compatible with the Diameter AVP The AVP format chosen for TLS/IA is compatible with the Diameter AVP
format. This does not in any way represent a requirement that format. This does not in any way represent a requirement that
Diameter be supported by any of the devices or servers participating Diameter be supported by any of the devices or servers participating
in the TLS/IA conversation, whether directly as client or server or in the TLS/IA conversation, whether directly as client or server or
indirectly as a backend authenticator. Use of this format is merely indirectly as a backend authenticator. Use of this format is merely
a convenience. Diameter is a superset of RADIUS and includes the a convenience. Diameter is a superset of RADIUS and includes the
RADIUS attribute namespace by definition, though it does not limit RADIUS attribute namespace by definition, though it does not limit
the size of an AVP as does RADIUS. RADIUS, in turn, is a widely the size of an AVP as does RADIUS. RADIUS, in turn, is a widely
deployed AAA protocol and attribute definitions exist for all deployed AAA protocol and attribute definitions exist for the
commonly used password authentication protocols, including EAP. encapsulation of EAP as well as all commonly used non-EAP password
authentication protocols.
Thus, Diameter is not considered normative except as specified in Thus, Diameter is not considered normative except as specified in
this document. Specifically, the AVP Codes used in TLS/IA are this document. Specifically, the AVP Codes used in TLS/IA are
semantically equivalent to those defined for Diameter, and, by semantically equivalent to those defined for Diameter, and, by
extension, RADIUS. extension, RADIUS.
Use of the RADIUS/Diameter namespace allows a TLS/IA server to Use of the RADIUS/Diameter namespace allows a TLS/IA server to
easily translate between AVPs it uses to communicate with clients translate between AVPs it uses to communicate with clients and the
and the protocol requirements of AAA servers that are widely protocol requirements of AAA servers that are widely deployed.
deployed. Plus, it provides a well-understood mechanism to allow Additionally, it provides a well-understood mechanism to allow
vendors to extend that namespace for their particular requirements. vendors to extend that namespace for their particular requirements.
3.1 AVP Format 3.1 AVP Format
The format of an AVP is shown below. All items are in network, or The format of an AVP is shown below. All items are in network, or
big-endian, order; that is, they have most significant octet first. big-endian, order; that is, they have most significant octet first.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 25 skipping to change at page 17, line 40
- Vendor-specific AVPs should be defined in terms of RADIUS. - Vendor-specific AVPs should be defined in terms of RADIUS.
Vendor-specific RADIUS attributes translate to Diameter Vendor-specific RADIUS attributes translate to Diameter
automatically; the reverse is not true. RADIUS vendor-specific automatically; the reverse is not true. RADIUS vendor-specific
attributes use RADIUS attribute 26 and include vendor ID, vendor- attributes use RADIUS attribute 26 and include vendor ID, vendor-
specific attribute code and length; see [RFC2865] for details. specific attribute code and length; see [RFC2865] for details.
4 Tunneled Authentication within Application Phases 4 Tunneled Authentication within Application Phases
TLS/IA permits user authentication information to be tunneled within TLS/IA permits user authentication information to be tunneled within
an application phase between client and server, protecting the an application phase between client and server, protecting the
security of the authentication information against active and authentication information against active and passive attack.
passive attack.
Any type of password or other authentication may be tunneled. Also, Any type of authentication method may be tunneled. Also, multiple
multiple tunneled authentications may be performed. Normally, tunneled authentications may be performed. Normally, tunneled
tunneled authentication is used when the client has not been issued authentication is used when the TLS handshake provides only one-way
a certificate and the TLS handshake provides only one-way
authentication of the server to the client; however, in certain authentication of the server to the client; however, in certain
cases it may be desired to perform certificate authentication of the cases it may be desirable to perform certificate authentication of
client during the initial handshake phase as well as tunneled user the client during the initial handshake phase as well as tunneled
authentication in a subsequent application phase. user authentication in a subsequent application phase.
This section establishes rules for using common authentication This section establishes rules for using well known authentication
mechanisms within TLS/IA. Any new authentication mechanism should in mechanisms within TLS/IA. Any new authentication mechanism should,
general be covered by these rules if it is defined as an EAP type. in general, be covered by these rules if it is defined as an EAP
Authentication mechanisms whose use within TLS/IA is not covered type. Authentication mechanisms whose use within TLS/IA is not
within this specification may require separate standardization, covered within this specification may require separate
preferably within the standard that describes the authentication standardization, preferably within the standard that describes the
mechanism in question. authentication mechanism in question.
4.1 Implicit challenge 4.1 Implicit challenge
Certain authentication protocols that use a challenge/response Certain authentication protocols that use a challenge/response
mechanism rely on challenge material that is not generated by the mechanism rely on challenge material that is not generated by the
authentication server, and therefore require special handling. authentication server, and therefore require special handling.
In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the
Network Access Server (NAS) issues a challenge to the client, the Network Access Server (NAS) issues a challenge to the client, the
client then hashes the challenge with the password and forwards the client then hashes the challenge with the password and forwards the
response to the NAS. The NAS then forwards both challenge and response to the NAS. The NAS then forwards both challenge and
response to a AAA server. But because the AAA server did not itself response to a AAA server. But because the AAA server did not itself
generate the challenge, such protocols are susceptible to replay generate the challenge, such protocols are susceptible to replay
attack. attack.
If the client were able to create both challenge and response, Since within TLS/IA the client also plays the role of NAS, the
anyone able to observe a CHAP or MS-CHAP exchange could pose as that replay problem is exacerbated. If the client were able to create
user by replaying that challenge and response into a TLS/IA both challenge and response, anyone able to observe a CHAP or MS-
conversation. CHAP exchange could pose as that user by replaying that challenge
and response into a TLS/IA conversation.
To make these protocols secure in TLS/IA, it is necessary to provide To make these protocols secure in TLS/IA, it is necessary to provide
a mechanism to produce a challenge that the client cannot control or a mechanism that produces a challenge that the client cannot control
predict. or predict.
When a challenge-based authentication mechanism is used, both client When a challenge-based authentication mechanism is used, both client
and server use the TLS PRF function to generate as many octets as and server use the TLS PRF function to generate as many octets as
are required for the challenge, using the constant string "inner are required for the challenge, using the constant string "inner
application challenge", based on the then-current master secret and application challenge", based on the master secret and random values
random values established during the initial handshake phase: established during the TLS handshake, as follows.
IA_challenge = PRF(final_inner_secret, IA_challenge = PRF(SecurityParameters.master_secret,
"inner application challenge", "inner application challenge",
SecurityParameters.server_random + SecurityParameters.server_random +
SecurityParameters.client_random); SecurityParameters.client_random);
4.2 Tunneled Authentication Protocols 4.2 Tunneled Authentication Protocols
This section describes the rules for tunneling specific This section describes the rules for tunneling specific
authentication protocols within TLS/IA. authentication protocols within TLS/IA.
For each protocol, the RADIUS RFC that defines the relevant For each protocol, the RADIUS RFC that defines the relevant
skipping to change at page 20, line 14 skipping to change at page 19, line 30
4.2.1 EAP 4.2.1 EAP
EAP is described in [RFC3784]; RADIUS attribute formats are EAP is described in [RFC3784]; RADIUS attribute formats are
described in [RFC3579]. described in [RFC3579].
When EAP is the tunneled authentication protocol, each tunneled EAP When EAP is the tunneled authentication protocol, each tunneled EAP
packet between the client and server is encapsulated in an EAP- packet between the client and server is encapsulated in an EAP-
Message AVP. Message AVP.
Either client or server may initiate EAP. Either the client or the server may initiate EAP.
The client is the first to transmit within any application phase, The client is the first to transmit within any application phase,
and it may include an EAP-Response/Identity AVP in its and it may include an EAP-Response/Identity AVP in its
ApplicationPayload message to begin an EAP conversation. ApplicationPayload message to begin an EAP conversation.
Alternatively, if the client does not initiate EAP the server may, Alternatively, if the client does not initiate EAP the server may,
by including an EAP-Request/Identity AVP in its ApplicationPayload by including an EAP-Request/Identity AVP in its ApplicationPayload
message. message.
The client's EAP-Response/Identity provides the actual username; the The client's EAP-Response/Identity provides the username, which MUST
privacy of the user's identity is now guaranteed by the TLS be a Network Access Identifier (NAI) [RFC2486]; that is, it MUST be
encryption. This username must be a Network Access Identifier (NAI) in the following format:
[RFC2486]; that is, it must be in the following format:
username@realm username@realm
The @realm portion is optional, and is used to allow the server to The @realm portion is optional, and is used to allow the server to
forward the EAP message sequence to the appropriate server in the forward the EAP message sequence to the appropriate server in the
AAA infrastructure when necessary. AAA infrastructure when necessary.
The EAP authentication between client and server proceeds normally, The EAP authentication between client and server proceeds normally,
as described in [RFC3784]. However, upon completion the server does as described in [RFC3784]. However, upon completion the server does
not send an EAP-Success or EAP-Failure AVP. Instead, the server not send an EAP-Success or EAP-Failure AVP. Instead, the server
skipping to change at page 21, line 15 skipping to change at page 20, line 31
The client initiates CHAP by including User-Name, CHAP-Challenge and The client initiates CHAP by including User-Name, CHAP-Challenge and
CHAP-Password AVPs in the first ApplicationPayload message in any CHAP-Password AVPs in the first ApplicationPayload message in any
application phase. The CHAP-Challenge value is taken from the application phase. The CHAP-Challenge value is taken from the
challenge material. The CHAP-Password consists of CHAP Identifier, challenge material. The CHAP-Password consists of CHAP Identifier,
taken from the challenge material; and CHAP response, computed taken from the challenge material; and CHAP response, computed
according to the CHAP algorithm. according to the CHAP algorithm.
Upon receipt of these AVPs from the client, the server must verify Upon receipt of these AVPs from the client, the server must verify
that the value of the CHAP-Challenge AVP and the value of the CHAP that the value of the CHAP-Challenge AVP and the value of the CHAP
Identifier in the CHAP-Password AVP are equal to the values Identifier in the CHAP-Password AVP are equal to the values
generated as challenge material. If either item does not match generated as challenge material. If either item does not match, the
exactly, the server must reject the client. Otherwise, it validates server must reject the client. Otherwise, it validates the CHAP-
the CHAP-Challenge to determine the result of the authentication. Challenge to determine the result of the authentication.
4.2.3 MS-CHAP 4.2.3 MS-CHAP
The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
formats are described in [RFC2548]. formats are described in [RFC2548].
Both client and server generate 9 octets of challenge material, Both client and server generate 9 octets of challenge material,
using the constant string "inner application challenge" as described using the constant string "inner application challenge" as described
above. These octets are used as follows: above. These octets are used as follows:
skipping to change at page 23, line 46 skipping to change at page 23, line 11
the Reply-Message AVPs, the client tunnels User-Name and User- the Reply-Message AVPs, the client tunnels User-Name and User-
Password AVPs again, with the User-Password AVP containing new Password AVPs again, with the User-Password AVP containing new
information in response to the challenge. This process continues information in response to the challenge. This process continues
until the server determines the authentication has succeeded or until the server determines the authentication has succeeded or
failed. failed.
4.3 Performing Multiple Authentications 4.3 Performing Multiple Authentications
In some cases, it is desirable to perform multiple user In some cases, it is desirable to perform multiple user
authentications. For example, a server may want first to authentications. For example, a server may want first to
authenticate the user by password, then by token card. authenticate the user by password, then by a hardware token.
The server may perform any number of additional user authentications The server may perform any number of additional user authentications
using EAP, simply by issuing a EAP-Request with a new protocol type using EAP, simply by issuing a EAP-Request with a new protocol type
once the previous authentication has completed.. once the previous authentication has completed.
For example, a server wishing to perform MD5-Challenge followed by For example, a server wishing to perform MD5-Challenge followed by
Generic Token Card would first issue an EAP-Request/MD5-Challenge Generic Token Card would first issue an EAP-Request/MD5-Challenge
AVP and receive a response. If the response is satisfactory, it AVP and receive a response. If the response is satisfactory, it
would then issue EAP-Request/Generic Token Card AVP and receive a would then issue EAP-Request/Generic Token Card AVP and receive a
response. If that response were also satisfactory, it would consider response. If that response were also satisfactory, it would consider
the user authenticated. the user authenticated.
5 Example Message Sequences 5 Example Message Sequences
This section presents a variety of possible TLS/IA message This section presents a variety of possible TLS/IA message
sequences. These examples do not attempt to exhaustively depict all sequences. These examples are not meant to exhaustively depict all
possible scenarios. possible scenarios.
Parentheses indicate optional TLS messages. Brackets indicate Parentheses indicate optional TLS messages. Brackets indicate
optional message exchanges. Ellipsis (. . .) indicates optional optional message exchanges. An ellipsis (. . .) indicates optional
repetition of preceding messages. repetition of preceding messages.
5.1 Full Initial Handshake with Multiple Application Phases 5.1 Full Initial Handshake with Intermediate and Final Application
Phases
The diagram below depicts a full initial handshake phase followed by The diagram below depicts a full initial handshake phase followed by
two application phases. two application phases.
Note that the client concludes the intermediate phase and starts the Note that the client concludes the intermediate phase and starts the
final phase in an uninterrupted sequence of three messages: final phase in an uninterrupted sequence of three messages:
ChangeCipherSpec and PhaseFinished belong to the intermediate phase, ChangeCipherSpec and PhaseFinished belong to the intermediate phase,
and ApplicationPayload belongs to the final phase. and ApplicationPayload belongs to the final phase.
Client Server Client Server
skipping to change at page 26, line 39 skipping to change at page 25, line 55
This document introduces a new TLS extension called "Inner This document introduces a new TLS extension called "Inner
Application". When TLS is used with the Inner Application extension Application". When TLS is used with the Inner Application extension
(TLS/IA), additional messages are exchanged during the TLS (TLS/IA), additional messages are exchanged during the TLS
handshake. Hence a number of security issues need to be taken into handshake. Hence a number of security issues need to be taken into
consideration. Since the security heavily depends on the information consideration. Since the security heavily depends on the information
(called "applications") which are exchanged between the TLS client (called "applications") which are exchanged between the TLS client
and the TLS server as part of the TLS/IA extension we try to and the TLS server as part of the TLS/IA extension we try to
classify them into two categories: The first category considers the classify them into two categories: The first category considers the
case where the exchange results in the generation of keying case where the exchange results in the generation of keying
material. This is, for example, the case with many EAP methods. EAP material. This is, for example, the case with certain EAP methods.
is one of the envisioned main "applications". The second category
focuses on cases where no session key is generated. The security
treatment of the latter category is discouraged since it is
vulnerability to man-in-the-middle attacks if the two sessions
cannot be bound to each other as shown in [MITM].
Subsequently, we investigate a number of security issues: EAP is one of the envisioned main "applications". The second
category focuses on cases where no session key is generated. The
security treatment of the latter category is discouraged since it is
subject to man-in-the-middle attacks if the two sessions cannot be
bound to each other as suggested in [MITM].
In the following, we investigate a number of security issues:
- Architecture and Trust Model - Architecture and Trust Model
For many of the use cases in this document we assume that three For many of the use cases in this document we assume that three
functional entities participate in the protocol exchange: TLS functional entities participate in the protocol exchange: TLS
client, TLS server and a AAA infrastructure (typically consisting client, TLS server and a AAA infrastructure (typically consisting
of a AAA server and possibly a AAA broker). The protocol exchange of a AAA server and possibly a AAA broker). The protocol exchange
described in this document takes place between the TLS client and described in this document takes place between the TLS client and
the TLS server. The interaction between the AAA client (which the TLS server. The interaction between the AAA client (which
corresponds to the TLS server) and the AAA server is described in corresponds to the TLS server) and the AAA server is described in
skipping to change at page 27, line 37 skipping to change at page 27, line 4
Throughout this document it is assumed that the TLS server can be Throughout this document it is assumed that the TLS server can be
authorized by the TLS client as a legitimate server as part of authorized by the TLS client as a legitimate server as part of
the authentication procedure of the initial TLS Handshake. The the authentication procedure of the initial TLS Handshake. The
entity acting as TLS client can be authorized either by the TLS entity acting as TLS client can be authorized either by the TLS
server or by the AAA server (if the authorization decision is server or by the AAA server (if the authorization decision is
offloaded). Typically, the authenticated identity is used to offloaded). Typically, the authenticated identity is used to
compute the authorization decision but credential-based compute the authorization decision but credential-based
authorization mechanisms may be used as well. authorization mechanisms may be used as well.
- Man-in-the-Middle Attack - Man-in-the-Middle Attack
Man-in-the-middle attacks have become a concern with tunneled Man-in-the-middle attacks have become a concern with tunneled
authentication protocols because of the discovered authentication protocols because of the discovered
vulnerabilities (see [MITM]) of a missing cryptographic binding vulnerabilities (see [MITM]) of a missing cryptographic binding
between the independent protocol sessions. This document also between the independent protocol sessions. This document also
proposes a tunneling protocol, namely individual inner proposes a tunneling protocol, namely individual inner
application sessions are tunneled within a previously executed application sessions are tunneled within a previously executed
session. The first protocol session in this exchange is the session. The first protocol session in this exchange is the
initial TLS Handshake. To avoid man-in-the-middle attacks a initial TLS Handshake. To avoid man-in-the-middle attacks,
number of sections address how to establish such a cryptographic Section 2.2 addresses how to establish such a cryptographic
binding (see Section 2.3 and Error! Reference source not found.). binding.
- User Identity Confidentiality - User Identity Confidentiality
The TLS/IA extension allows splitting the authentication of the The TLS/IA extension allows splitting the authentication of the
TLS server from the TLS client into two separate sessions. As one TLS server from the TLS client into two separate sessions. As one
of the advantages, this provides active user identity of the advantages, this provides active user identity
confidentiality since the TLS client is able to authenticate the confidentiality since the TLS client is able to authenticate the
TLS server and to establish a unilateral authenticated and TLS server and to establish a unilateral authenticated and
confidentiality-protected channel prior to starting the client- confidentiality-protected channel prior to starting the client-
side authentication. side authentication.
- Session Key Establishment - Session Key Establishment
TLS [RFC2246] defines how session key material produced during TLS [RFC2246] defines how session key material produced during
the TLS Handshake is generated with the help of a pseudo-random the TLS Handshake is generated with the help of a pseudo-random
function to expand it to keying material of the desired length function to expand it to keying material of the desired length
for later usage in the TLS Record Layer. Section 2.3 gives some for later usage in the TLS Record Layer. Section 2.2 gives some
guidelines with regard to the master key generation. Since the guidelines with regard to the master key generation. Since the
TLS/IA extension supports multiple exchanges whereby each phase TLS/IA extension supports multiple exchanges whereby each phase
concludes with a generated keying material. In addition to the concludes with a generated keying material. In addition to the
keying material established as part of TLS itself, most inner keying material established as part of TLS itself, most inner
applications will produce their keying material. For example, applications will produce their keying material. For example,
keying material established as part of an EAP method must be keying material established as part of an EAP method must be
carried from the AAA server to the AAA client. Details are carried from the AAA server to the AAA client. Details are
subject to the specific AAA protocol (for example, EAP usage in subject to the specific AAA protocol (for example, EAP usage in
Diameter [AAA-EAP]. Diameter [AAA-EAP].
skipping to change at page 28, line 37 skipping to change at page 28, line 4
such, does not introduce new vulnerabilities with regard to DoS such, does not introduce new vulnerabilities with regard to DoS
attacks. Since the TLS/IA extension allows to postpone the attacks. Since the TLS/IA extension allows to postpone the
client-side authentication to a later stage in the protocol client-side authentication to a later stage in the protocol
phase. As such, it allows malicious TLS clients to initiate a phase. As such, it allows malicious TLS clients to initiate a
number of exchanges while remaining anonymous. As a consequence, number of exchanges while remaining anonymous. As a consequence,
state at the server is allocated and computational efforts are state at the server is allocated and computational efforts are
required at the server side. Since the TLS client cannot be required at the server side. Since the TLS client cannot be
stateless this is not strictly a DoS attack. stateless this is not strictly a DoS attack.
- Confidentiality Protection and Dictionary Attack Resistance - Confidentiality Protection and Dictionary Attack Resistance
Similar to the user identity confidentiality property the usage Similar to the user identity confidentiality property the usage
of the TLS/IA extension allows to establish a unilateral of the TLS/IA extension allows to establish a unilateral
authenticated tunnel which is confidentiality protected. This authenticated tunnel which is confidentiality protected. This
tunnel protects the inner application information elements to be tunnel protects the inner application information elements to be
protected against active adversaries and therefore provides protected against active adversaries and therefore provides
resistance against dictionary attacks when password-based resistance against dictionary attacks when password-based
authentication protocols are used inside the tunnel. In general, authentication protocols are used inside the tunnel. In general,
information exchanged inside the tunnel experiences information exchanged inside the tunnel experiences
confidentiality protection. confidentiality protection.
- Downgrading Attacks - Downgrading Attacks
This document defines a new extension. The TLS client and the TLS This document defines a new extension. The TLS client and the TLS
server indicate the capability to support the TLS/IA extension as server indicate the capability to support the TLS/IA extension as
part of the client_hello_extension_list and the part of the client_hello_extension_list and the
server_hello_extension_list payload. More details can be found in server_hello_extension_list payload. More details can be found in
Section 2.6. To avoid downgrading attacks whereby an adversary Section 2.5. To avoid downgrading attacks whereby an adversary
removes a capability from the list is avoided by the usage of the removes a capability from the list is avoided by the usage of the
Finish or PhaseFinished message as described in Section Error! IntermediatePhaseFinished or FinalPhaseFinished message as
Reference source not found.. described in Section 2.1.
7 References 7 References
7.1 Normative References 7.1 Normative References
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", RFC [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
1700, October 1994. 1700, October 1994.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996. Protocol (CHAP)", RFC 1994, August 1996.
skipping to change at page 30, line 52 skipping to change at page 30, line 22
[AAA-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [AAA-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", draft-ietf- Authentication Protocol (EAP) Application", draft-ietf-
aaa-eap-03.txt (work in progress), October 2003. aaa-eap-03.txt (work in progress), October 2003.
8 Authors' Addresses 8 Authors' Addresses
Questions about this memo can be directed to: Questions about this memo can be directed to:
Paul Funk Paul Funk
Funk Software, Inc. Juniper Networks
222 Third Street 222 Third Street
Cambridge, MA 02142 Cambridge, MA 02142
USA USA
Phone: +1 617 497-6339 Phone: +1 617 497-6339
E-mail: paul@funk.com E-mail: pfunk@juniper.net
Simon Blake-Wilson Simon Blake-Wilson
Basic Commerce & Industries, Inc. Basic Commerce & Industries, Inc.
96 Spadina Ave, Unit 606 96 Spadina Ave, Unit 606
Toronto, Ontario M5V 2J6 Toronto, Ontario M5V 2J6
Canada Canada
Phone: +1 416 214-5961 Phone: +1 416 214-5961
E-mail: sblakewilson@bcisse.com E-mail: sblakewilson@bcisse.com
Ned Smith Ned Smith
skipping to change at page 32, line 27 skipping to change at page 31, line 48
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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 (2001 - 2005). This document is Copyright (C) The Internet Society (2006). This document is subject
subject to the rights, licenses and restrictions contained in BCP to the rights, licenses and restrictions contained in BCP 78, and
78, and except as set forth therein, the authors retain all their except as set forth therein, the authors retain all their rights.
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. 90 change blocks. 
303 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/