One document matched: draft-funk-tls-inner-application-extension-01.txt
Differences from draft-funk-tls-inner-application-extension-00.txt
TLS Working Group Paul Funk
Internet-Draft Funk Software, Inc.
Category: Standards Track Simon Blake-Wilson
<draft-funk-tls-inner-application-extension-01.txt> Basic Commerce &
Industries, Inc.
Ned Smith
Intel Corp.
Hannes Tschofenig
Siemens AG
Thomas Hardjono
VeriSign Inc.
February 2005
TLS Inner Application Extension
(TLS/IA)
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001 - 2005). All Rights
Reserved.
Abstract
Internet-Draft February 2005
This document defines a new TLS extension called "Inner
Application". When TLS is used with the Inner Application extension
(TLS/IA), additional messages are exchanged after completion of the
TLS handshake, in effect providing an extended handshake prior to
the start of upper layer data communications. Each TLS/IA message
contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from
the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and
Diameter have the same meaning in TLS/AI; that is, each attribute
code point refers to the same logical attribute in any of these
protocols. Arbitrary "applications" may be implemented using the AVP
exchange. Possible applications include EAP or other forms of user
authentication, client integrity checking, provisioning of
additional tunnels, and the like. Use of the RADIUS/Diameter
namespace provides natural compatibility between TLS/IA applications
and widely deployed AAA infrastructures.
It is anticipated that TLS/IA will be used with and without
subsequent protected data communication within the tunnel
established by the handshake. For example, TLS/IA may be used to
secure an HTTP data connection, allowing more robust password-based
user authentication to occur than would otherwise be possible using
mechanisms available in HTTP. TLS/IA may also be used for its
handshake portion alone; for example, EAP-TTLSv1 encapsulates a
TLS/IA handshake in EAP as a means to mutually authenticate a client
and server and establish keys for a separate data connection.
Table of Contents
1 Introduction................................................... 3
1.1 A Bit of History .......................................... .. 4
1.2 TLS With or Without Upper Layer Data Communications.......... 5
2 The Inner Application Extension to TLS......................... 5
2.1 TLS/IA Overview.............................................. 7
2.2 Message Exchange ............................................ 8
2.3 Inner Secret................................................. 9
2.3.1 Computing the Inner Secret................................. 9
2.3.2 Exporting the Final Inner Secret........................... 10
2.3.3 Application Session Key Material........................... 10
2.4 Session Resumption........................................... 12
2.5 Error Termination............................................ 12
2.6 Negotiating the Inner Application Extension.................. 12
2.7 InnerApplication Protocol.................................... 13
2.7.1 InnerApplicationExtension.................................. 13
2.7.2 InnerApplication Message................................... 14
2.7.3 IntermediatePhaseFinished and FinalPhaseFinished Messages.. 14
2.7.4 The ApplicationPayload Message ............................ 15
2.8 Alerts....................................................... 15
3 Encapsulation of AVPs within ApplicationPayload Messages....... 16
3.1 AVP Format................................................... 16
3.2 AVP Sequences................................................ 17
3.3 Guidelines for Maximum Compatibility with AAA Servers........ 18
Paul Funk expires August 2005 [Page 2]
Internet-Draft February 2005
4 Tunneled Authentication within Application Phases ............. 18
4.1 Implicit challenge........................................... 18
4.2 Tunneled Authentication Protocols............................ 19
4.2.1 EAP........................................................ 20
4.2.2 CHAP....................................................... 20
4.2.3 MS-CHAP.................................................... 21
4.2.4 MS-CHAP-V2................................................. 21
4.2.5 PAP........................................................ 23
4.3 Performing Multiple Authentications.......................... 23
5 Example Message Sequences...................................... 24
5.1 Full Initial Handshake with Multiple Application Phases ..... 24
5.2 Resumed Session with Single Application Phase................ 25
5.3 Resumed Session with No Application Phase.................... 26
6 Security Considerations........................................ 26
7 References .................................................... 29
7.1 Normative References......................................... 29
7.2 Informative References....................................... 30
8 Authors' Addresses ........................................... 30
9 Intellectual Property Statement............................... 31
1 Introduction
This specification defines the TLS "Inner Application" extension.
The term "TLS/IA" refers to the TLS protocol when used with the
Inner Application extension.
In TLS/IA, the setup portion of TLS is extended to allow an
arbitrary exchange of information between client and server within a
protected tunnel established during the TLS handshake and prior to
the start of upper layer TLS data communications. The TLS handshake
itself is unchanged; the subsequent Inner Application exchange is
conducted under the confidentiality and integrity protection
afforded by the TLS handshake.
The primary motivation for providing such communication is to allow
robust user authentication to occur as part of an "extended"
handshake, in particular, user authentication that is based on
password credentials, which is best conducted under the protection
of an encrypted tunnel to preclude dictionary attack by
eavesdroppers. For example, Extensible Authentication Protocol (EAP)
may be used to authenticate using any of a wide variety of methods
as part of this extended handshake. The multi-layer approach of
TLS/IA, in which a strong authentication, typically based on a
server certificate, is used to protect a password-based
authentication, distinguishes it from other TLS variants that rely
entirely on a pre-shared key or password for security; for example
[TLS-PSK].
The protected exchange accommodates any type of client-server
application, not just authentication, though authentication may
Paul Funk expires August 2005 [Page 3]
Internet-Draft February 2005
often be the prerequisite that allows other applications to proceed.
For example, TLS/IA may be used to set up HTTP connections,
establish IPsec security associations (as an alternative to IKE),
obtain credentials for single sign-on, provide for client integrity
verification, and so on.
The new messages that are exchanged between client and server are
encoded as sequences of Attribute-Value-Pairs (AVPs) from the
RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace
provides natural compatibility between TLS/IA applications and
widely deployed AAA infrastructures. This namespace is extensible,
allowing new AVPs and, thus, new applications to be defined as
needed, either by standards bodies or by vendors wishing to define
proprietary applications.
The TLS/IA exchange comprises one or more "phases", each of which
consists of an arbitrary number of AVP exchanges followed by a
confirmation exchange. Authentications occurring in any phase must
be confirmed prior to continuing to the next phase. This allows
applications to implement security dependencies in which particular
assurances are required prior to exchange of additional information.
1.1 A Bit of History
The TLS protocol has its roots in the Netscape SSL protocol, which
was originally intended to secure HTTP. It provides either one-way
or mutual authentication of client and server based on certificates.
In its most typical use in HTTP, the client authenticates the server
based on the server's certificate and establishes a tunnel through
which HTTP traffic is passed.
For the server to authenticate the client within the TLS handshake,
the client must have its own certificate. In cases where the client
must be authenticated without a certificate, HTTP, not TLS,
mechanisms would have to be employed. For example, HTTP headers have
been defined to perform user authentications. However, these
mechanisms are primitive compared to other mechanisms, most notably
EAP, that have been defined for contexts other than HTTP.
Furthermore, any mechanisms defined for HTTP cannot be utilized when
TLS is used to protect non-HTTP traffic.
The TLS protocol has also found an important use in authentication
for network access, originally within PPP for dial-up access and
later for wireless and wired 802.1X access. Several EAP types have
been defined that utilize TLS to perform mutual client-server
authentication. The first to appear, EAP-TLS, uses the TLS handshake
to authenticate both client and server based on the certificate of
each.
Subsequent protocols, such EAP-TTLSv0 and EAP-PEAP, utilize the TLS
handshake to allow the client to authenticate the server based on
Paul Funk expires August 2005 [Page 4]
Internet-Draft February 2005
the latter's certificate, then utilize the tunnel established by the
TLS handshake to perform user authentication, typically based on
password credentials. Such protocols are called "tunneled" EAP
protocols. The authentication mechanism used inside the tunnel may
itself be EAP, and the tunnel may also be used to convey additional
information between client and server.
TLS/IA is in effect a merger of the two types of TLS usage described
above, based on the recognition that tunneled authentication would
be useful in other contexts besides EAP. However, the tunneled
protocols mentioned above are not directly compatible with a more
generic use of TLS, because they utilize the tunneled data portion
of TLS, thus precluding its use for other purposes such as carrying
HTTP traffic.
The TLS/IA solution to this problem is to insert an additional
message exchange between the TLS handshake and the subsequent data
communications phase, carried in a new record type distinct from the
record type that carries upper layer data. Thus, the data portion of
the TLS exchange becomes available for HTTP or any other protocol or
connection that needs to be secured.
1.2 TLS With or Without Upper Layer Data Communications
It is anticipated that TLS/IA will be used with and without
subsequent protected data communication within the tunnel
established by the handshake.
For example, TLS/IA may be used to secure an HTTP data connection,
allowing more robust password-based user authentication to occur
within the TLS/IA extended handshake than would otherwise be
possible using mechanisms available in HTTP.
TLS/IA may also be used for its handshake portion alone. For
example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP
as a means to mutually authenticate a client and server and
establish keys for a separate data connection; no subsequent TLS
data portion is required. Another example might be use of TLS/IA
directly over TCP to provide a user with credentials for single
sign-on.
2 The Inner Application Extension to TLS
The Inner Application extension to TLS follows the guidelines of
[RFC3546].
A new extension type is defined for negotiating use of TLS/IA
- The InnerApplicationExtension extension type. The client proposes
use of this extension by including a InnerApplicationExtension
message in its ClientHello handshake message, and the server
Paul Funk expires August 2005 [Page 5]
Internet-Draft February 2005
confirms its use by including a InnerApplicationExtension message
in its ServerHello handshake message.
A new record type (ContentType) is defined for use in TLS/IA:
- The InnerApplication record type. This record type carries all
messages that implement the inner application extension. These
messages will occur after the TLS handshake and prior to exchange
of data.
A new message type is defined for use within the InnerApplication
record type:
- The InnerApplication message. This message may encapsulate any of
three subtypes:
- The ApplicationPayload message. This message is used to carry
AVP (Attribute-Value Pair) sequences within the TLS/IA
extended handshake, in support of client-server applications
such as authentication.
- The IntermediatePhaseFinished message. This message confirms
session keys established during the current TLS/IA phase, and
indicates that at least one additional phase is to follow.
- The FinalPhaseFinished message. This message confirms session
keys established during the current TLS/IA phase, and
indicates that no further phases are to follow.
Two new alert codes are defined for use in TLS/IA:
- The InnerApplicationFailure alert. This error alert allows either
party to terminate the TLS/IA extended handshake due to a failure
in an application implemented via AVP sequences carried in
ApplicationPayload messages.
- The InnerApplicationVerification alert. This error alert allows
either party to terminate the TLS/IA extended handshake due to
incorrect verification data in a received
IntermediatePhaseFinished or FinalPhaseFinished message.
The following new assigned numbers are used in TLS/IA:
- "InnerApplicationExtension" extension type:37703
- "InnerApplication" record type: 24
- "InnerApplicationFailure" alert code: 208
- "InnerApplicationVerification" alert code:209
Paul Funk expires August 2005 [Page 6]
Internet-Draft February 2005
[Editor's note: I have not checked these types yet against types
defined in RFCs or drafts. The TLS RFC specifies that new record
types use the next number after ones already defined; hence I used
24, though I don't know if that is already taken.]
2.1 TLS/IA Overview
In TLS/IA, zero or more "application phases are inserted after the
TLS handshake and prior to ordinary data exchange. The last such
application phase is called the "final phase"; any application
phases prior to the final phase are called "intermediate phases".
Intermediate phases are only necessary if interim confirmation of
session keys generated during an application phase is desired.
Each application phase consists of ApplicationPayload handshake
messages exchanged by client and server to implement applications
such as authentication, plus concluding messages for cryptographic
confirmation. These messages are encapsulated in records with
ContentType of InnerApplication.
All application phases prior to the final phase use
IntermediatePhaseFinished rather than FinalPhaseFinished as the
concluding message. The final phase concludes with the
FinalPhaseFinished message.
Application phases may be omitted entirely only when session
resumption is used, provided both client and server agree that no
application phase is required. The client indicates in its
ClientHello whether it is willing to omit application phases in a
resumed session, and the server indicates in its ServerHello whether
any application phases are to ensue.
In each application phase, the client sends the first
ApplicationPayload message. ApplicationPayload messages are then
traded one at a time between client and server, until the server
concludes the phase by sending, in response to an ApplicationPayload
message from the client, an IntermediatePhaseFinished sequence to
conclude an intermediate phase, or a FinalPhaseFinished sequence to
conclude the final phase. The client then responds with its own
IntermediatePhaseFinished or FinalPhaseFinished message.
Note that the server MUST NOT send an IntermediatePhaseFinished or
FinalPhaseFinished message immediately after sending an
ApplicationPayload message. It must allow the client to send an
ApplicationPayload message prior to concluding the phase. Thus,
within any application phase, there will be one more
ApplicationPayload message sent by the client than sent by the
server.
Paul Funk expires August 2005 [Page 7]
Internet-Draft February 2005
The server determines which type of concluding message is used,
either IntermediatePhaseFinished or FinalPhaseFinished, and the
client MUST echo the same type of concluding message. 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
an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence
contains a typed data element. The exchanged AVPs allow client and
server to implement "applications" within a secure tunnel. An
application may be any procedure that someone may usefully define. A
typical application might be authentication; for example, the server
may authenticate the client based on password credentials using EAP.
Other possible applications include distribution of keys, validating
client integrity, setting up IPsec parameters, setting up SSL VPNs,
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
Paul Funk expires August 2005 [Page 8]
Internet-Draft February 2005
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
send an ApplicationPayload message containing no AVPs. The client,
for example, may have no AVPs to send in its first or last
ApplicationPayload message during an application phase.
2.3 Inner Secret
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 inner authentications that may have been performed
during each application phase.
The inner secret is initialized at the conclusion of the TLS
handshake and permuted at the conclusion of each application phase.
The inner secret that results from the final application phase is
the final inner secret.
When a new (non-resumed) session is negotiated, the resulting final
inner secret is saved as part of the session state for use in
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 permutation",
SecurityParameters.server_random +
SecurityParameters.client_random +
session_key_material) [0..48];
session_key_material is the concatenation of session_key vectors,
one for each session key generated during the current phase, where:
Paul Funk expires August 2005 [Page 9]
Internet-Draft February 2005
opaque session_key<1..2^16-1>;
In other words, each session key is prefixed by a 2-octet length to
produce the session_key vector.
Since multiple session keys may be produced during a single
application phase, the following method is used to determine the
order of concatenation: Each session key is treated as an unsigned
big-endian numeric value, and the set of session keys is ordered
from lowest to highest. The session keys are then converted to
session_key vectors and concatenated in the determined order to form
session_key_material.
If no session keys were generated during the current phase,
session_key_material will be null.
Note that session_key_material itself is not a vector and therefore
not prefixed with the length of the entire collection of session_key
vectors.
2.3.2 Exporting the Final Inner Secret
Note that, within TLS itself, the inner secret is used for
verification only, not for encryption. However, the inner secret
resulting from the final application phase may be exported for use
as a key from which additional session keys may be derived for
arbitrary purposes, including encryption of data communications
separate from TLS.
An exported inner secret should not be used directly as a session
key. Instead, additional keys should be derived from the inner
secret, for example by using a PRF, and the client and server
randoms should be incorporated into the derivation. This ensures
cryptographic separation between use of the inner secret for session
key confirmation and additional use of the inner secret outside
TLS/IA.
Note that for a resumed session that does not include an application
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
are bound to the authentication. Such keying material is normally
intended for use in a subsequent data connection for encryption and
validation. For example, EAP-TLS, MS-CHAP-V2 and its alter ego EAP-
MS-CHAP-V2 each generate session keys.
Paul Funk expires August 2005 [Page 10]
Internet-Draft February 2005
Any session keys generated during an application phase MUST be used
to permute the TLS/IA inner secret between one phase and the next,
and MUST NOT be used for any other purpose.
Each authentication protocol may define how the session key it
generates is mapped to an octet sequence of some length for the
purpose of TLS/IA mixing. However, for protocols which do not
specify this (including the multitude of protocols that pre-date
TLS/IA) the following rules are defined. The first rule that applies
SHALL be the method for determining the session key:
- If the authentication protocol produces an MSK (as defined in
[RFC3784]), the MSK is used as the session key. Note that an MSK
is 64 octets.
- If the authentication protocol maps its keying material to the
RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key
[RFC2548], then the keying material for those attributes are
concatenated, with MS-MPPE-Recv-Key first (Note that this rule
applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.)
- If the authentication protocol uses a pseudo-random function to
generate keying material, that function is used to generate 64
octets for use as keying material.
Providing verification of the binding of session keys to the TLS
master secret is necessary to preclude man-in-the-middle attacks
against tunneled authentication protocols, as described in [MITM].
In such an attack, an unsuspecting client is induced to perform an
untunneled authentication with an attacker posing as a server; the
attacker then introduces the authentication protocol into a tunneled
authentication protocol, fooling an authentic server into believing
that the attacker is the authentic user.
By mixing both the TLS master secret and session keys generated
during application phase authentication into the inner secret used
for application phase verification, such attacks are thwarted, as it
guarantees that the same client both terminated the TLS handshake
and performed the application phase authentication. Note that the
session keys generated during authentication must be
cryptographically related to the authentication and not derivable
from data exchanged during authentication in order for the keying
material to be useful in thwarting such attacks.
In addition, the fact that the inner secret cryptographically
incorporates session keys from application phase authentications
provides additional protection when the inner secret is exported for
the purpose of generating additional keys for use outside of the TLS
exchange. If such an exported secret did not include keying material
from inner authentications, an eavesdropper who somehow knew the
server's private key could, in an RSA-based handshake, determine the
Paul Funk expires August 2005 [Page 11]
Internet-Draft February 2005
exported secret and hence would be able to compute the additional
keys that are based on it. When inner authentication keying material
is incorporated into the exported secret, such an attack becomes
impossible.
2.4 Session Resumption
A TLS/IA initial handshake phase may be resumed using standard
mechanisms defined in [RFC2246]. When the TLS session is resumed,
client and server may not deem it necessary to exchange AVPs in one
or more additional application phases, as the resumption itself may
provide all the security needed.
The client indicates within the InnerApplicationExtension message in
ClientHello whether it requires AVP exchange when session resumption
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
layer data communications immediately upon completion of the TLS
handshake. The server indicates whether application phases are to
follow the TLS handshake in its InnerApplication extension message
in ServerHello.
Note that [RFC3546] specifically states that when session resumption
is used, the server MUST ignore any extensions in the ClientHello.
However, it is not possible to comply with this requirement for the
Inner Application extension, since even in a resumed session it may
be necessary to include application phases, and whether they must be
included is negotiated in the extension message itself. Therefore,
the [RFC3546] provision is specifically overridden for the single
case of the Inner Application extension, which is considered an
exception to this rule.
A TLS/IA session MAY NOT be resumed if an application phase resulted
in failure, even though the TLS handshake itself succeeded. Both
client and server MUST NOT save session state for possible future
resumption unless the TLS handshake and all subsequent application
phases succeed.
2.5 Error Termination
The TLS/IA handshake may be terminated by either party sending a
fatal alert, following standard TLS procedures.
2.6 Negotiating the Inner Application Extension
Use of the InnerApplication extension follows [RFC3546]. The client
proposes use of this extension by including the
InnerApplicationExtension message in the client_hello_extension_list
of the extended ClientHello. If this message is included in the
ClientHello, the server MAY accept the proposal by including the
InnerApplicationExtension message in the server_hello_extension_list
Paul Funk expires August 2005 [Page 12]
Internet-Draft February 2005
of the extended ServerHello. If use of this extension is either not
proposed by the client or not confirmed by the server, the
InnerApplication record type MUST NOT be used.
2.7 InnerApplication Protocol
All specifications of TLS/IA messages follow the usage defined in
[RFC2246].
2.7.1 InnerApplicationExtension
enum {
no(0), yes(1), (255)
} AppPhaseOnResumption;
struct {
AppPhaseOnResumption app_phase_on_resumption;
} InnerApplicationExtension;
If the client wishes to propose use of the Inner Application
extension, it must include the InnerApplicationExtension message in
the extension_data vector in the Extension structure in its extended
ClientHello message.
If the server wishes to confirm use of the Inner Application
extension that has been proposed by the client, it must include the
InnerApplicationExtension message in the extension_data vector in
the Extension structure in its extended ServerHello message.
The AppPhaseOnResumption enumeration allow client and server to
negotiate an abbreviated, single-phase handshake when session
resumption is employed. If the client sets app_phase_on_resumption
to "no", and if the server resumes the previous session, then the
server MAY set app_phase_on_resumption to "no" in the
InnerApplication message it sends to the client. If the server sets
app_phase_on_resumption to "no", no application phases occur and the
TLS connection proceeds to upper layer data exchange immediately
upon conclusion of the TLS handshake.
The server MUST set app_phase_on_resumption to "yes" if the client
set app_phase_on_resumption to "yes" or if the server does not
resume the session. The server MAY set app_phase_on_resumption to
"yes" for a resumed session even if the client set
app_phase_on_resumption to "no", as the server may have reason to
proceed with one or more application phases.
If the server sets app_phase_on_resumption to "yes" for a resumed
session, then the client MUST initiate an application phase at the
conclusion of the TLS handshake.
Paul Funk expires August 2005 [Page 13]
Internet-Draft February 2005
The value of app_phase_on_resumption applies to the current
handshake only; that is, it is possible for app_phase_on_resumption
to have different values in two handshakes that are both resumed
from the same original TLS session.
2.7.2 InnerApplication Message
enum {
application_payload(0), intermediate_phase_finished(1),
final_phase_finished(2), (255)
} InnerApplicationType;
struct {
InnerApplicationType msg_type;
uint24 length;
select (InnerApplicationType) {
case application_payload: ApplicationPayload;
case intermediate_phase_finished:
IntermediatePhaseFinished;
case final_phase_finished: FinalPhaseFinished;
} body;
} InnerApplication;
The InnerApplication message carries any of the message types
defined for the InnerApplication protocol.
2.7.3 IntermediatePhaseFinished and FinalPhaseFinished Messages
struct {
opaque verify_data[12];
} PhaseFinished;
PhaseFinished IntermediatePhaseFinished;
PhaseFinished FinalPhaseFinished;
verify_data
PRF(inner_secret, finished_label) [0..11];
finished_label
when sent by the client, the string "client phase finished"
when sent by the server, the string "server phase finished"
The IntermediatePhaseFinished and FinalPhaseFinished messages have
the same structure and include verification data based on the
current inner secret. IntermediatePhaseFinished is sent by the
server and echoed by the client to conclude an intermediate
application phase, and FinalPhaseFinished is used in the same manner
to conclude the final application phase.
Paul Funk expires August 2005 [Page 14]
Internet-Draft February 2005
2.7.4 The ApplicationPayload Message
The ApplicationPayload message carries an AVP sequence during an
application handshake phase. It is defined as follows:
struct {
opaque avps[InnerApplication.length];
} ApplicationPayload;
avps
The AVP sequence, treated as an opaque sequence of octets.
InnerApplication.length
The length field in the encapsulating InnerApplication
message.
Note that the "avps" element has its length defined in square
bracket rather than angle bracket notation, implying a fixed rather
than variable length vector. This avoids having the length of the
AVP sequence specified redundantly both in the encapsulating
InnerApplication message and as a length prefix in the avps element
itself.
2.8 Alerts
Two new alert codes are defined for use during an application phase.
The AlertLevel for either of these alert codes MUST be set to
"fatal".
InnerApplicationFailure
An InnerApplicationFailure error alert may be sent by either
party during an application phase. This indicates that the
sending party considers the negotiation to have failed due to an
application carried in the AVP sequences, for example, a failed
authentication.
InnerApplicationVerification
An InnerApplicationVerification error alert is sent by either
party during an application phase to indicate that the received
IntermediatePhaseFinished or FinalPhaseFinished is invalid, that
is, contains verification data that does not match what is
expected.
Note that other alerts are possible during an application phase; for
example, decrypt_error. The InnerApplicationFailure alert relates
specifically to the failure of an application implemented via AVP
sequences; for example, failure of an EAP or other authentication
method, or information passed within the AVP sequence that is found
unsatisfactory.
Paul Funk expires August 2005 [Page 15]
Internet-Draft February 2005
3 Encapsulation of AVPs within ApplicationPayload Messages
During application phases of the TLS handshake, information is
exchanged between client and server through the use of attribute-
value pairs (AVPs). This data is encrypted using the then-current
cipher state established during the preceding handshake phase.
The AVP format chosen for TLS/IA is compatible with the Diameter AVP
format. This does not in any way represent a requirement that
Diameter be supported by any of the devices or servers participating
in the TLS/IA conversation, whether directly as client or server or
indirectly as a backend authenticator. Use of this format is merely
a convenience. Diameter is a superset of RADIUS and includes the
RADIUS attribute namespace by definition, though it does not limit
the size of an AVP as does RADIUS. RADIUS, in turn, is a widely
deployed AAA protocol and attribute definitions exist for all
commonly used password authentication protocols, including EAP.
Thus, Diameter is not considered normative except as specified in
this document. Specifically, the AVP Codes used in TLS/IA are
semantically equivalent to those defined for Diameter, and, by
extension, RADIUS.
Use of the RADIUS/Diameter namespace allows a TLS/IA server to
easily translate between AVPs it uses to communicate with clients
and the protocol requirements of AAA servers that are widely
deployed. Plus, it provides a well-understood mechanism to allow
vendors to extend that namespace for their particular requirements.
3.1 AVP Format
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
The AVP Code is four octets and, combined with the Vendor-ID
field if present, identifies the attribute uniquely. The first
Paul Funk expires August 2005 [Page 16]
Internet-Draft February 2005
256 AVP numbers represent attributes defined in RADIUS. AVP
numbers 256 and above are defined in Diameter.
AVP Flags
The AVP Flags field is one octet, and provides the receiver with
information necessary to interpret the AVP.
The 'V' (Vendor-Specific) bit indicates whether the optional
Vendor-ID field is present. When set to 1, the Vendor-ID field is
present and the AVP Code is interpreted according to the
namespace defined by the vendor indicated in the Vendor-ID field.
The 'M' (Mandatory) bit indicates whether support of the AVP is
required. When set to 0, this indicates that the AVP may be
safely ignored if the receiving party does not understand or
support it. When set to 1, if the receiving party does not
understand or support the AVP it MUST fail the negotiation by
sending an InnerApplicationFailure error alert.
The 'r' (reserved) bits are unused and must be set to 0.
AVP Length
The AVP Length field is three octets, and indicates the length of
this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
(if present) and Data.
Vendor-ID
The Vendor-ID field is present if and only if the 'V' bit is set
in the AVP Flags field. It is four octets, and contains the
vendor's IANA-assigned "SMI Network Management Private Enterprise
Codes" [RFC1700] value. Vendors defining their own AVPs must
maintain a consistent namespace for use of those AVPs within
RADIUS, Diameter and TLS/IA.
A Vendor-ID value of zero is semantically equivalent to absence
of the Vendor-ID field altogether.
3.2 AVP Sequences
Data encapsulated within the TLS Record Layer must consist entirely
of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet
boundary relative to the first AVP in the sequence. If an AVP is not
a multiple of 4 octets, it must be padded with 0s to the next 4-
octet boundary.
Note that the AVP Length does not include the padding.
Paul Funk expires August 2005 [Page 17]
Internet-Draft February 2005
3.3 Guidelines for Maximum Compatibility with AAA Servers
When maximum compatibility with AAA servers is desired, the
following guidelines for AVP usage are suggested:
- Non-vendor-specific AVPs should be selected from the set of
attributes defined for RADIUS; that is, attributes with codes
less than 256. This provides compatibility with both RADIUS and
Diameter.
- Vendor-specific AVPs should be defined in terms of RADIUS.
Vendor-specific RADIUS attributes translate to Diameter
automatically; the reverse is not true. RADIUS vendor-specific
attributes use RADIUS attribute 26 and include vendor ID, vendor-
specific attribute code and length; see [RFC2865] for details.
4 Tunneled Authentication within Application Phases
TLS/IA permits user authentication information to be tunneled within
an application phase between client and server, protecting the
security of the authentication information against active and
passive attack.
Any type of password or other authentication may be tunneled. Also,
multiple tunneled authentications may be performed. Normally,
tunneled authentication is used when the client has not been issued
a certificate and the TLS handshake provides only one-way
authentication of the server to the client; however, in certain
cases it may be desired to perform certificate authentication of the
client during the initial handshake phase as well as tunneled user
authentication in a subsequent application phase.
This section establishes rules for using common authentication
mechanisms within TLS/IA. Any new authentication mechanism should in
general be covered by these rules if it is defined as an EAP type.
Authentication mechanisms whose use within TLS/IA is not covered
within this specification may require separate standardization,
preferably within the standard that describes the authentication
mechanism in question.
4.1 Implicit challenge
Certain authentication protocols that use a challenge/response
mechanism rely on challenge material that is not generated by the
authentication server, and therefore require special handling.
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
client then hashes the challenge with the password and forwards the
response to the NAS. The NAS then forwards both challenge and
response to a AAA server. But because the AAA server did not itself
Paul Funk expires August 2005 [Page 18]
Internet-Draft February 2005
generate the challenge, such protocols are susceptible to replay
attack.
If the client were able to create both challenge and response,
anyone able to observe a CHAP or MS-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
a mechanism to produce a challenge that the client cannot control or
predict.
When a challenge-based authentication mechanism is used, both client
and server use the TLS PRF function to generate as many octets as
are required for the challenge, using the constant string "inner
application challenge", based on the then-current master secret and
random values established during the initial handshake phase:
IA_challenge = PRF(final_inner_secret,
"inner application challenge",
SecurityParameters.server_random +
SecurityParameters.client_random);
4.2 Tunneled Authentication Protocols
This section describes the rules for tunneling specific
authentication protocols within TLS/IA.
For each protocol, the RADIUS RFC that defines the relevant
attribute formats is cited. Note that these attributes are
encapsulated as described in section 3.1; that is, as Diameter
attributes, not as RADIUS attributes. In other words, the AVP Code,
Length, Flags and optional Vendor-ID are formatted as described in
section 3.1, while the Data is formatted as described by the cited
RADIUS RFC.
All tunneled authentication protocols except EAP must be initiated
by the client in the first ApplicationPayload message of an
application phase. EAP may be initiated by the client in the first
ApplicationPayload message of an application phase; it may also be
initiated by the server in any ApplicationPayload message.
The authentication protocols described below may be performed
directly by the TLS/IA server or may be forwarded to a backend AAA
server. For authentication protocols that generate session keys, the
backend server must return those session keys to the TLS/IA server
in order to allow the protocol to succeed within TLS/IA. RADIUS or
Diameter servers are suitable backend AAA servers for this purpose.
RADIUS servers typically return session keys in MS-MPPE-Recv-Key and
MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return
session keys in the EAP-Master-Session-Key AVP [AAA-EAP].
Paul Funk expires August 2005 [Page 19]
Internet-Draft February 2005
4.2.1 EAP
EAP is described in [RFC3784]; RADIUS attribute formats are
described in [RFC3579].
When EAP is the tunneled authentication protocol, each tunneled EAP
packet between the client and server is encapsulated in an EAP-
Message AVP.
Either client or server may initiate EAP.
The client is the first to transmit within any application phase,
and it may include an EAP-Response/Identity AVP in its
ApplicationPayload message to begin an EAP conversation.
Alternatively, if the client does not initiate EAP the server may,
by including an EAP-Request/Identity AVP in its ApplicationPayload
message.
The client's EAP-Response/Identity provides the actual username; the
privacy of the user's identity is now guaranteed by the TLS
encryption. This username must be a Network Access Identifier (NAI)
[RFC2486]; that is, it must be in the following format:
username@realm
The @realm portion is optional, and is used to allow the server to
forward the EAP message sequence to the appropriate server in the
AAA infrastructure when necessary.
The EAP authentication between client and server proceeds normally,
as described in [RFC3784]. However, upon completion the server does
not send an EAP-Success or EAP-Failure AVP. Instead, the server
signals success when it concludes the application phase by issuing a
Finished or PhaseFinished message, or it signals failure by issuing
an InnerApplicationFailure alert.
Note that the client may also issue an InnerApplicationFailure
alert, for example, when authentication of the server fails in a
method providing mutual authentication.
4.2.2 CHAP
The CHAP algorithm is described in [RFC1994]; RADIUS attribute
formats are described in [RFC2865].
Both client and server generate 17 octets of challenge material,
using the constant string "inner application challenge" as described
above. These octets are used as follows:
CHAP-Challenge [16 octets]
CHAP Identifier [1 octet]
Paul Funk expires August 2005 [Page 20]
Internet-Draft February 2005
The client initiates CHAP by including User-Name, CHAP-Challenge and
CHAP-Password AVPs in the first ApplicationPayload message in any
application phase. The CHAP-Challenge value is taken from the
challenge material. The CHAP-Password consists of CHAP Identifier,
taken from the challenge material; and CHAP response, computed
according to the CHAP algorithm.
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
Identifier in the CHAP-Password AVP are equal to the values
generated as challenge material. If either item does not match
exactly, the server must reject the client. Otherwise, it validates
the CHAP-Challenge to determine the result of the authentication.
4.2.3 MS-CHAP
The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
formats are described in [RFC2548].
Both client and server generate 9 octets of challenge material,
using the constant string "inner application challenge" as described
above. These octets are used as follows:
MS-CHAP-Challenge [8 octets]
Ident [1 octet]
The client initiates MS-CHAP by including User-Name, MS-CHAP-
Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload
message in any application phase. The MS-CHAP-Challenge value is
taken from the challenge material. The MS-CHAP-Response consists of
Ident, taken from the challenge material; Flags, set according the
client preferences; and LM-Response and NT-Response, computed
according to the MS-CHAP algorithm.
Upon receipt of these AVPs from the client, the server must verify
that the value of the MS-CHAP-Challenge AVP and the value of the
Ident in the client's MS-CHAP-Response AVP are equal to the values
generated as challenge material. If either item does not match
exactly, the server must reject the client. Otherwise, it validates
the MS-CHAP-Challenge to determine the result of the authentication.
4.2.4 MS-CHAP-V2
The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
formats are described in [RFC2548].
Both client and server generate 17 octets of challenge material,
using the constant string "inner application challenge" as described
above. These octets are used as follows:
Paul Funk expires August 2005 [Page 21]
Internet-Draft February 2005
MS-CHAP-Challenge [16 octets]
Ident [1 octet]
The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload
message in any application phase. The MS-CHAP-Challenge value is
taken from the challenge material. The MS-CHAP2-Response consists of
Ident, taken from the challenge material; Flags, set to 0; Peer-
Challenge, set to a random value; and Response, computed according
to the MS-CHAP-V2 algorithm.
Upon receipt of these AVPs from the client, the server must verify
that the value of the MS-CHAP-Challenge AVP and the value of the
Ident in the client's MS-CHAP2-Response AVP are equal to the values
generated as challenge material. If either item does not match
exactly, the server must reject the client. Otherwise, it validates
the MS-CHAP2-Challenge.
If the MS-CHAP2-Challenge received from the client is correct, the
server tunnels the MS-CHAP2-Success AVP to the client.
Upon receipt of the MS-CHAP2-Success AVP, the client is able to
authenticate the server. In its next InnerApplicationPayload message
to the server, the client does not include any MS-CHAP-V2 AVPs.
(This may result in an empty InnerApplicationPayload if no other
AVPs need to be sent.)
If the MS-CHAP2-Challenge received from the client is not correct,
the server tunnels an MS-CHAP2-Error AVP to the client. This AVP
contains a new Ident and a string with additional information such
as error reason and whether a retry is allowed. If the error reason
is an expired password and a retry is allowed, the client may
proceed to change the user's password. If the error reason is not an
expired password or if the client does not wish to change the user's
password, it issues an InnerApplicationFailure alert.
If the client does wish to change the password, it tunnels MS-CHAP-
NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server.
The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge
received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge AVP simply
echoes the new Challenge.
Upon receipt of these AVPs from the client, the server must verify
that the value of the MS-CHAP-Challenge AVP and the value of the
Ident in the client's MS-CHAP2-CPW AVP match the values it sent in
the MS-CHAP2-Error AVP. If either item does not match exactly, the
server must reject the client. Otherwise, it validates the MS-CHAP2-
CPW AVP.
If the MS-CHAP2-CPW AVP received from the client is correct, and the
server is able to change the user's password, the server tunnels the
Paul Funk expires August 2005 [Page 22]
Internet-Draft February 2005
MS-CHAP2-Success AVP to the client and the negotiation proceeds as
described above.
Note that additional AVPs associated with MS-CHAP-V2 may be sent by
the server; for example, MS-CHAP-Domain. The server must tunnel such
authentication-related AVPs along with the MS-CHAP2-Success.
4.2.5 PAP
PAP RADIUS attribute formats are described in [RFC2865].
The client initiates PAP by including User-Name and User-Password
AVPs in the first ApplicationPayload message in any application
phase.
In RADIUS, User-Password is padded with nulls to a multiple of 16
octets, then encrypted using a shared secret and other packet
information.
A TLS/IA, however, does not RADIUS-encrypt the password since all
application phase data is already encrypted. The client SHOULD,
however, null-pad the password to a multiple of 16 octets, to
obfuscate its length.
Upon receipt of these AVPs from the client, the server may be able
to decide whether to authenticate the client immediately, or it may
need to challenge the client for more information.
If the server wishes to issue a challenge to the client, it MUST
tunnel the Reply-Message AVP to the client; this AVP normally
contains a challenge prompt of some kind. It may also tunnel
additional AVPs if necessary, such the Prompt AVP. Upon receipt of
the Reply-Message AVPs, the client tunnels User-Name and User-
Password AVPs again, with the User-Password AVP containing new
information in response to the challenge. This process continues
until the server determines the authentication has succeeded or
failed.
4.3 Performing Multiple Authentications
In some cases, it is desirable to perform multiple user
authentications. For example, a server may want first to
authenticate the user by password, then by token card.
The server may perform any number of additional user authentications
using EAP, simply by issuing a EAP-Request with a new protocol type
once the previous authentication has completed..
For example, a server wishing to perform MD5-Challenge followed by
Generic Token Card would first issue an EAP-Request/MD5-Challenge
AVP and receive a response. If the response is satisfactory, it
Paul Funk expires August 2005 [Page 23]
Internet-Draft February 2005
would then issue EAP-Request/Generic Token Card AVP and receive a
response. If that response were also satisfactory, it would consider
the user authenticated.
5 Example Message Sequences
This section presents a variety of possible TLS/IA message
sequences. These examples do not attempt to exhaustively depict all
possible scenarios.
Parentheses indicate optional TLS messages. Brackets indicate
optional message exchanges. Ellipsis (. . .) indicates optional
repetition of preceding messages.
5.1 Full Initial Handshake with Multiple Application Phases
The diagram below depicts a full initial handshake phase followed by
two application phases.
Note that the client concludes the intermediate phase and starts the
final phase in an uninterrupted sequence of three messages:
ChangeCipherSpec and PhaseFinished belong to the intermediate phase,
and ApplicationPayload belongs to the final phase.
Client Server
------ ------
*** TLS Handshake:
ClientHello -------->
ServerHello
(Certificate)
ServerKeyExchange
(CertificateRequest)
<-------- ServerHelloDone
(Certificate)
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
*** Intermediate Phase:
ApplicationPayload -------->
[
<-------- ApplicationPayload
ApplicationPayload -------->
Paul Funk expires August 2005 [Page 24]
Internet-Draft February 2005
...
]
<--------
IntermediatePhaseFinished
IntermediatePhaseFinished
*** Final Phase:
ApplicationPayload -------->
[
<-------- ApplicationPayload
ApplicationPayload -------->
...
]
<-------- FinalPhaseFinished
FinalPhaseFinished -------->
5.2 Resumed Session with Single Application Phase
The diagram below depicts a resumed session followed by a single
application phase.
Note that the client concludes the initial phase and starts the
final phase in an uninterrupted sequence of three messages:
ChangeCipherSpec and PhaseFinished belong to the initial phase, and
ApplicationPayload belongs to the final phase.
Client Server
------ ------
*** TLS Handshake:
ClientHello -------->
ServerHello
ChangeCipherSpec
<-------- Finished
ChangeCipherSpec
Finished
*** Final Phase:
ApplicationPayload -------->
[
<-------- ApplicationPayload
ApplicationPayload -------->
...
]
<-------- FinalPhaseFinished
Paul Funk expires August 2005 [Page 25]
Internet-Draft February 2005
FinalPhaseFinished -------->
5.3 Resumed Session with No Application Phase
The diagram below depicts a resumed session without any subsequent
application phase. This will occur if the client indicates in its
ClientInnerApplication message that no application phase is required
and the server concurs.
Note that this message sequence is identical to that of a standard
TLS resumed session.
Client Server
------ ------
*** TLS Handshake:
ClientHello -------->
ServerHello
ChangeCipherSpec
<-------- Finished
ChangeCipherSpec
Finished -------->
6 Security Considerations
This document introduces a new TLS extension called "Inner
Application". When TLS is used with the Inner Application extension
(TLS/IA), additional messages are exchanged during the TLS
handshake. Hence a number of security issues need to be taken into
consideration. Since the security heavily depends on the information
(called "applications") which are exchanged between the TLS client
and the TLS server as part of the TLS/IA extension we try to
classify them into two categories: The first category considers the
case where the exchange results in the generation of keying
material. This is, for example, the case with many EAP methods. 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
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:
- Architecture and Trust Model
For many of the use cases in this document we assume that three
functional entities participate in the protocol exchange: TLS
client, TLS server and a AAA infrastructure (typically consisting
of a AAA server and possibly a AAA broker). The protocol exchange
described in this document takes place between the TLS client and
the TLS server. The interaction between the AAA client (which
Paul Funk expires August 2005 [Page 26]
Internet-Draft February 2005
corresponds to the TLS server) and the AAA server is described in
the respective AAA protocol documents and therefore outside the
scope of this document. The trust model behind this architecture
with respect to the authentication, authorization, session key
establishment and key transport within the AAA infrastructure is
discussed in [KEYING].
- Authentication
This document assumes that the TLS server is authenticated to the
TLS client as part of the authentication procedure of the initial
TLS Handshake. This approach is similar to the one chosen with
the EAP support in IKEv2 (see [IKEv2]). Typically, public key
based server authentication is used for this purpose. More
interesting is the client authentication property whereby
information exchanged as part of the Inner Application is used to
authenticate (or authorize) the client. For example, if EAP is
used as an inner application then EAP methods are used to perform
authentication and key agreement between the EAP peer (most
likely the TLS client) and the EAP server (i.e., AAA server).
- Authorization
Throughout this document it is assumed that the TLS server can be
authorized by the TLS client as a legitimate server as part of
the authentication procedure of the initial TLS Handshake. The
entity acting as TLS client can be authorized either by the TLS
server or by the AAA server (if the authorization decision is
offloaded). Typically, the authenticated identity is used to
compute the authorization decision but credential-based
authorization mechanisms may be used as well.
- Man-in-the-Middle Attack
Man-in-the-middle attacks have become a concern with tunneled
authentication protocols because of the discovered
vulnerabilities (see [MITM]) of a missing cryptographic binding
between the independent protocol sessions. This document also
proposes a tunneling protocol, namely individual inner
application sessions are tunneled within a previously executed
session. The first protocol session in this exchange is the
initial TLS Handshake. To avoid man-in-the-middle attacks a
number of sections address how to establish such a cryptographic
binding (see Section 2.3 and Error! Reference source not found.).
- User Identity Confidentiality
The TLS/IA extension allows splitting the authentication of the
TLS server from the TLS client into two separate sessions. As one
of the advantages, this provides active user identity
confidentiality since the TLS client is able to authenticate the
Paul Funk expires August 2005 [Page 27]
Internet-Draft February 2005
TLS server and to establish a unilateral authenticated and
confidentiality-protected channel prior to starting the client-
side authentication.
- Session Key Establishment
TLS [RFC2246] defines how session key material produced during
the TLS Handshake is generated with the help of a pseudo-random
function to expand it to keying material of the desired length
for later usage in the TLS Record Layer. Section 2.3 gives some
guidelines with regard to the master key generation. Since the
TLS/IA extension supports multiple exchanges whereby each phase
concludes with a generated keying material. In addition to the
keying material established as part of TLS itself, most inner
applications will produce their keying material. For example,
keying material established as part of an EAP method must be
carried from the AAA server to the AAA client. Details are
subject to the specific AAA protocol (for example, EAP usage in
Diameter [AAA-EAP].
- Denial of Service Attacks
This document does not modify the initial TLS Handshake and as
such, does not introduce new vulnerabilities with regard to DoS
attacks. Since the TLS/IA extension allows to postpone the
client-side authentication to a later stage in the protocol
phase. As such, it allows malicious TLS clients to initiate a
number of exchanges while remaining anonymous. As a consequence,
state at the server is allocated and computational efforts are
required at the server side. Since the TLS client cannot be
stateless this is not strictly a DoS attack.
- Confidentiality Protection and Dictionary Attack Resistance
Similar to the user identity confidentiality property the usage
of the TLS/IA extension allows to establish a unilateral
authenticated tunnel which is confidentiality protected. This
tunnel protects the inner application information elements to be
protected against active adversaries and therefore provides
resistance against dictionary attacks when password-based
authentication protocols are used inside the tunnel. In general,
information exchanged inside the tunnel experiences
confidentiality protection.
- Downgrading Attacks
This document defines a new extension. The TLS client and the TLS
server indicate the capability to support the TLS/IA extension as
part of the client_hello_extension_list and the
server_hello_extension_list payload. More details can be found in
Section 2.6. To avoid downgrading attacks whereby an adversary
Paul Funk expires August 2005 [Page 28]
Internet-Draft February 2005
removes a capability from the list is avoided by the usage of the
Finish or PhaseFinished message as described in Section Error!
Reference source not found..
7 References
7.1 Normative References
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
1700, October 1994.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, November 1998.
[RFC2433] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2486] Aboba, B., and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, January 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC3579] Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September
2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, July 2003.
[RFC3784] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "PPP Extensible Authentication Protocol
(EAP)", RFC 3784, June 2004.
Paul Funk expires August 2005 [Page 29]
Internet-Draft February 2005
7.2 Informative References
[RFC1661] Simpson, W. (Editor), "The Point-to-Point Protocol
(PPP)", STD 51, RFC 1661, July 1994.
[RFC2716] Aboba, B., and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-
eap-ttls-05.txt, July 2004.
[EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G.,
and S. Josefsson, "Protected EAP Protocol (PEAP) Version
2", draft-josefsson-pppext-eap-tls-eap-08.txt, July
2004.
[TLS-PSK] Eronen, P., and H. Tschofenig, "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", draft-
ietf-tls-psk-01.txt, August 2004.
[802.1X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication",
http://www.saunalahti.fi/~asokan/research/mitm.html,
Nokia Research Center, Finland, October 24 2002.
[KEYING] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP
Key Management Framework", draft-ietf-eap-keying-01.txt
(work in progress), October 2003.
[IKEv2] C.Kaufman, "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-16.txt (work in progress),
September 2004.
[AAA-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", draft-ietf-
aaa-eap-03.txt (work in progress), October 2003.
8 Authors' Addresses
Questions about this memo can be directed to:
Paul Funk
Funk Software, Inc.
222 Third Street
Cambridge, MA 02142
Paul Funk expires August 2005 [Page 30]
Internet-Draft February 2005
USA
Phone: +1 617 497-6339
E-mail: paul@funk.com
Simon Blake-Wilson
Basic Commerce & Industries, Inc.
96 Spadina Ave, Unit 606
Toronto, Ontario M5V 2J6
Canada
Phone: +1 416 214-5961
E-mail: sblakewilson@bcisse.com
Ned Smith
Intel Corporation
MS: JF1-229
2111 N.E. 25th Ave.
Hillsboro, OR 97124
USA
Phone: +1 503 264-2692
E-mail: ned.smith@intel.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739\
Germany
Phone: +49 89 636 40390
E-mail: Hannes.Tschofenig@siemens.com
Thomas Hardjono
VeriSign Inc.
487 East Middlefield Road
M/S MV6-2-1
Mountain View, CA 94043
USA
Phone: +1 650 426-3204
E-mail: thardjono@verisign.com
9 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
Paul Funk expires August 2005 [Page 31]
Internet-Draft February 2005
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2001 - 2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Paul Funk expires August 2005 [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-23 00:16:01 |