Internet DRAFT - draft-hanna-eap-ttls-agility
draft-hanna-eap-ttls-agility
Network Working Group Steve Hanna
Internet Draft Juniper Networks
Intended status: Standards Track Paul Funk
Expires: March 2008 Juniper Networks
September 24, 2007
Key Agility Extensions for EAP-TTLSv0
draft-hanna-eap-ttls-agility-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 24, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines new Attribute Value Pairs (AVPs) that add
cryptographic algorithm agility and other security features
(protected results and cryptographic binding of inner authentications
to the outer tunnel) to EAP-TTLSv0.
Hanna Expires March 24, 2008 [Page 1]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
Table of Contents
1. Introduction............................................ 2
2. Terminology ............................................ 3
3. AVP Format.............................................. 3
4. Negotiating MSK and EMSK Computation.................... 5
4.1. MSK-Computation AVP................................ 6
MSK Computation Method................................. 7
4.2. Values ............................................ 7
5. Key Confirmation........................................ 7
5.1. Key-Confirmation-Option AVP........................ 9
5.2. Key-Confirmation AVP.............................. 10
6. Secure Completion ..................................... 11
6.1. Secure-Completion-Option AVP ..................... 13
6.2. TTLS-Success AVP.................................. 14
6.3. TTLS-Failure AVP.................................. 15
7. Cryptographic Computations............................. 15
7.1. Use of TLS PRF.................................... 15
7.2. Composite Key Computation......................... 16
7.3. MSK/EMSK computation using the "Mixed" mechanism.. 17
7.4. Key Confirmation computation ..................... 17
8. Security Considerations................................ 18
8.1. Cryptographic Algorithm Agility................... 18
8.2. Protection Against MITM Attacks................... 18
8.3. Protection Against Truncation Attacks............. 19
8.4. Protection Against Forged Results................. 19
9. IANA Considerations.................................... 19
9.1. Allocation of AVP Codes .......................... 19
9.2. Creation of New Registries........................ 20
10. References ........................................... 21
10.1. Normative References............................. 21
10.2. Informative References .......................... 21
Authors' Addresses........................................ 22
Intellectual Property Statement .......................... 22
1. Introduction
EAP-TTLSv0 [TTLSv0] is a "tunneled EAP method". This means that it
defines an authentication protocol for use with the Extensible
Authentication Protocol [EAP] and that this authentication protocol
creates a secure tunnel that can carry other authentication protocols
and other data exchanges. EAP-TTLSv0 has many advantages such as
extensibility, the ability to more securely carry legacy
authentication protocols, and widespread usage. But it also has
several issues: lack of cryptographic algorithm agility,
vulnerability to possible Man-in-the-Middle attacks when used with
Hanna Expires March 24, 2008 [Page 2]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
certain legacy protocols as described in [MITM], and vulnerability to
truncation attacks.
This specification defines three extensions to EAP-TTLSv0 that
address these issues by adding algorithm agility, protected results,
and cryptographic binding of inner authentications to the outer
tunnel. The extensions are defined using AVPs with semantics that
allow for a gradual transition as clients and servers are upgraded to
support the extensions. At first, clients can request the extensions
in a backward-compatible manner but proceed with the authentication
if the server does not support them. Servers can allow clients to use
the extensions or not. Over time, clients and servers can change
their policy to require the extensions, thus protecting against
downgrade attacks. For a description of how the extensions defined in
this document provide algorithm agility, protected results, and
cryptobinding, see the Security Considerations section.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
3. AVP Format
This document defines several AVPs to be used with EAP-TTLSv0. All of
these AVPs begin with the AVP header fields defined in [TTLSv0] and
use those fields in the same way. This section describes how those
fields are used and interpreted so that each AVP definition below
does not need to duplicate this text. Any normative text in this
section is normative with respect to all AVPs defined in this
document.
The format of an EAP-TTLSv0 AVP is shown below. All items are in
network (i.e. big-endian) order.
Hanna Expires March 24, 2008 [Page 3]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
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 (when V bit is 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
The IANA will assign AVP Codes for the AVPs defined in this document
when this document moves to RFC status (as defined in [TTLSv0] and
[RFC3588]). In the mean time, this document defines vendor-specific
AVP Codes that may be used by setting the 'V' bit. Once this document
moves to RFC status, implementations MUST accept the new standard AVP
Codes, MAY accept the vendor-specific AVP Codes, and SHOULD only send
the standard AVP Codes.
The 'V' (Vendor-Specific) bit MUST be set to 1 when a vendor-specific
AVP Code is used. Otherwise, it MUST be set to 0. When this bit is
set to 1, the Vendor-ID field MUST be present. Otherwise, it MUST be
absent.
The 'M' (Mandatory) bit may be set to 0 or 1, depending on the
preferences and policies of the party sending this AVP. If the M bit
is set to 1, the party receiving this AVP MUST either support this
AVP Code or fail the authentication. If the M bit is set to 0, the
receiving party may safely ignore this AVP.
The 'r' (reserved) bits MUST be set to 0 by the sending party and
MUST be ignored by the receiving party, at least for this version of
this specification. Future versions of this specification may use
these bits for extensibility.
The AVP Length field MUST be set to the length in octets of this AVP
including the AVP Code, AVP Length, AVP Flags (V, M, and r), Vendor-
ID (if present) and Data.
The Vendor-ID field is omitted when the V flag is 0. The vendor-
specific AVP Codes defined in this specification all have a Vendor-ID
of 2636.
The contents and meaning of the Data field are different for each AVP
defined below.
Hanna Expires March 24, 2008 [Page 4]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
4. Negotiating MSK and EMSK Computation
Secure computation of a Master Session Key (MSK) and Extended Master
Session Key (EMSK) is a critical part of any strong EAP method. The
mechanism defined in [TTLSv0] for computing the MSK and EMSK always
uses the TLS 1.1 PRF based on MD5 and SHA1. This is not algorithm
agile. Also, the MSK and EMSK computation method defined in [TTLSv0]
does not mix in keying material from inner authentications so
cryptographic binding of the inner and outer authentications is not
achieved.
The new MSK-Computation AVP allows the TTLS client and TTLS server to
negotiate the MSK and EMSK computation method to be used. A new MSK
and EMSK computation method defined in section 7.3 of this
specification achieves algorithm agility and adds cryptographic
binding. To ensure maximum flexibility for the future, other MSK and
EMSK computation methods can be defined and negotiated using the same
MSK-Computation AVP.
Options for MSK and EMSK computation defined in this specification
include:
- Default computation, as defined in [TTLSv0]
- Mixed computation method as defined in section 7.3
In order to negotiate a computation method other than the TTLSv0
default, the client sends an MSK-Computation AVP in the first phase 2
TTLS message sent to the TTLS server. This AVP indicates which MSK
computation methods the client is willing to use. If the client does
not include an MSK-Computation AVP in the first phase 2 TTLS message
sent to the TTLS server, the default computation methods (as
specified in [TTLSv0]) are used.
If the default MSK computation method (as specified in [TTLSv0]) is
not acceptable to the client, the client SHOULD set the M (Mandatory)
bit in the MSK-Computation AVP to indicate that the server must
support this AVP or terminate the authentication.
A TTLS server that supports the MSK-Computation AVP MUST respond to
an MSK-Computation AVP received from the client by selecting one of
those computations or by failing the authentication if it will not
accept any of the computations listed by the client. The server MAY
make its selection by sending an MSK-Computation AVP in any TTLS
message prior to the completion of the authentication; that is, the
server is allowed to defer its selection if necessary.
Hanna Expires March 24, 2008 [Page 5]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
Note that when the TTLS server relays an inner authentication to
another server, its ability to mix inner method MSKs with the TLS
master secret depends on the MSK of the relayed authentication being
conveyed by the other server to the TTLS server. For example, a
RADIUS TTLS server may proxy an inner authentication to a home RADIUS
server, which would normally return the MSK to the TTLS server via
MPPE-Recv-Key and MPPE-Send-Key attributes. Some RADIUS servers may
not return the MSK in this manner. In that case, the RADIUS TTLS
server will not be able to use an MSK computation method that
requires mixing in the inner MSK. That's why the TTLS server is
allowed to delay committing to a particular MSK computation method
until the end of the handshake. It may not know whether the home
RADIUS server will return the MSK (or even whether a home RADIUS
server will be used). The TTLS server SHOULD commit to an MSK
computation method as soon as possible. The TTLS client MAY refuse to
continue with an authentication if the TTLS server has not committed
to an MSK computation method by a particular point (e.g. when
particularly sensitive credentials are requested).
4.1. MSK-Computation AVP
The basic format of the MSK-Computation AVP is defined in section 3
above. This section only describes aspects that are specific to the
MSK-Computation AVP.
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 (when V bit is 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSK Computation Method 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP Code for the MSK-Computation AVP will be assigned by IANA
when this document moves to RFC status. In the mean time, a vendor-
specific AVP Code of 256 with a Vendor-ID field of 2636 should be
used for experimental purposes.
The body of the MSK-Computation AVP contains one or more 32-bit MSK
computation method values (defined in section 4.3 below), each of
which specifies a mechanism for computing the MSK and EMSK.
Hanna Expires March 24, 2008 [Page 6]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
The client MAY list multiple values, in order from most to least
preferred. The TTLS server MUST list only one value.
4.2. MSK Computation Method Values
A standard set of MSK computation method values for use in the MSK-
Computation AVP is defined in this section. To enable extensibility,
each value contains a vendor-id in the first (high order) 24 bits and
a selector in the last (low order) 8 bits. Values defined in this
specification use a vendor-id of 0. Vendors MUST use the vendor's
IANA-assigned Private Enterprise Number [PEN].
The following set of standard MSK computation method values are
defined at this time:
- 0 Default computation as defined in [TTLSv0]
- 1 Mixed computation mechanism as defined in section 7.3
Additional standard MSK computation method values may be defined at a
later time by publishing an RFC that defines these values.
5. Key Confirmation
Key Confirmation permits the client and TTLS server each to prove to
the other that it is in possession of all keys resulting from inner
authentications, in addition to the TLS master secret. This is done
to preclude a type of man-in-the-middle attack in which the attacker,
acting as a server, induces a legitimate client to perform an
authentication which the attacker then acts as a client to feed into
the EAP-TTLS negotiation as an inner method (as described in [MITM]).
Note that use of the Mixed mechanism for MSK computation may provide
a comparable safeguard, by ensuring that the MSK resulting from the
EAP-TTLS negotiation cannot be known by such a man-in-the-middle
attacker, and therefore cannot be used in a subsequent data
connection, thus allowing authentication to succeed but denying the
attacker the fruits of that successful authentication.
Key Confirmation is negotiated using the Key-Confirmation-Option AVP
and implemented using the Key-Confirmation AVP. The client MAY issue
a Key-Confirmation-Option AVP in its first phase 2 TTLS message to
the TTLS server, indicating one or both of the following Key
Confirmation Option values:
- Disabled
Hanna Expires March 24, 2008 [Page 7]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
- Enabled
By listing both Disabled and Enabled options, the client can indicate
that it is willing to proceed with or without Key Confirmation. If
this is the case, the client should set the M bit for the Key-
Confirmation-Option AVP to 0 so that servers that do not support this
AVP can be supported. If, on the other hand, the client requires Key
Confirmation to be used, it may set the M bit for the Key-
Confirmation-Option AVP to 1 so that servers that do not support this
AVP will fail the authentication.
The Key-Confirmation-Option AVP MUST appear in the client's first
phase 2 TTLS message to the TTLS server if it appears at all. Absence
of the Key-Confirmation-Option AVP is equivalent to selecting the
"Disabled" option.
If the client transmits a Key-Confirmation-Option AVP that includes
an option acceptable to the TTLS server, the TTLS server MUST respond
with a Key-Confirmation-Option AVP in its first phase 2 TTLS message
to the client indicating its selection (Enabled or Disabled). If the
TTLS server is unwilling to accommodate the client's Key Confirmation
preference, it MUST fail the authentication.
Once negotiated, Key Confirmation MAY be initiated by the TTLS server
in any TTLS message, by issuing a Key-Confirmation AVP to the client.
A Key Confirmation that occurs after all MSK-generating inner
authentication methods have completed is called the "final Key
Confirmation", and any Key Confirmation that occurs early (with fewer
than all inner MSKs) is called an "intermediate Key Confirmation".
If the TTLS server indicated "Enabled" in its Key-Confirmation-Option
AVP, the TTLS server MAY initiate one or more intermediate Key
Confirmations and MUST initiate a final Key Confirmation. If the TTLS
server indicated "Disabled" in its Key-Confirmation-Option AP, the
TTLS server MUST NOT initiate any intermediate Key Confirmations or
final Key Confirmations.
When the client receives a valid Key-Confirmation AVP from the TTLS
server, it MUST include its own Key-Confirmation AVP in its next TTLS
message to the TTLS server. If the client receives an invalid Key-
Confirmation AVP from the TTLS server, it MUST abandon the
authentication or otherwise cause it to fail.
If the client wants to require the server to send a final Key
Confirmation, it should set the M (Mandatory) bit on the Key-
Confirmation-Option AVP to ensure that servers that do not support
this AVP will terminate the authentication. If the client sets the M
Hanna Expires March 24, 2008 [Page 8]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
bit and then the server responds with a first EAP-TTLS message that
does not include a Key-Confirmation-Option AVP or includes an invalid
or unacceptable Key-Confirmation-Option AVP , or the TTLS server
sends an invalid Key-Confirmation AVP at any point, the TTLS client
should consider the authentication failed. If the TTLS server sends a
Key-Confirmation-Option AVP indicating that key confirmation is
Enabled and then the TTLS client receives an EAP-Success message
without receiving a final Key Confirmation, the client SHOULD NOT
consider the session properly established.
If the TTLS server receives an invalid Key-Confirmation AVP from the
TTLS client or fails to receive any Key-Confirmation AVP in response
to one sent, the TTLS server SHOULD fail the authentication and send
an EAP-Failure message. If secure completion has been negotiated and
no TTLS-Success or TTLS-Failure message has been sent, a TTLS-Failure
message should be sent before the EAP-Failure message. If secure
completion has been negotiated and a TTLS-Success or TTLS-Failure
message has already been sent, only an EAP-Failure message should be
sent.
Intermediate Key Confirmation might be used when multiple inner
authentications are performed and it is desirable to validate the
results of a first authentication prior to performing a subsequent
authentication, possibly for security or performance reasons. Use of
intermediate Key Confirmation is anticipated to be atypical.
Because intermediate Key Confirmations expose information about the
results of previous EAP methods, clients SHOULD NOT engage in an
intermediate Key Confirmation unless they have already authenticated
the server and determined that it is sufficiently trusted to expose
this information.
5.1. Key-Confirmation-Option AVP
The basic format of the Key-Confirmation-Option AVP is defined in
section 3 above. This section only describes aspects that are
specific to the Key-Confirmation-Option AVP.
Hanna Expires March 24, 2008 [Page 9]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
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 (when V bit is 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Option Value 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP Code for the Key-Confirmation-Option AVP will be assigned by
IANA when this document moves to RFC status. In the mean time, a
vendor-specific AVP Code of 257 with a Vendor-ID field of 2636 should
be used for experimental purposes.
The body of the Key-Confirmation-Option AVP contains one or more 32-
bit Key Confirmation Option Values. To enable extensibility, each
value contains a vendor-id in the first (high order) 24 bits and a
selector in the last (low order) 8 bits. Standard values (defined in
this or future IETF specifications) use a vendor-id of 0. Vendors
MUST use the vendor's IANA-assigned Private Enterprise Number [PEN].
The following standard Key Confirmation Option values are defined at
this time:
0 Disabled
1 Enabled
Additional standard Key Confirmation Option values may be defined at
a later time by publishing an RFC that defines these values.
The client MAY list multiple Key Confirmation Option values, in order
from most to least preferred. The server MUST list only one value.
5.2. Key-Confirmation AVP
The basic format of the Key-Confirmation AVP is defined in section 3
above. This section only describes aspects that are specific to the
Key-Confirmation AVP.
Hanna Expires March 24, 2008 [Page 10]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
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 (when V bit is 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Confirmation Data (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP Code for the Key-Confirmation AVP will be assigned by IANA
when this document moves to RFC status. In the mean time, a vendor-
specific AVP Code of 258 with a Vendor-ID field of 2636 should be
used for experimental purposes.
The body of the Key-Confirmation AVP contains 32 octets of binary Key
Confirmation Data, computed as described in section 7.4.
6. Secure Completion
As defined in [EAP], the EAP-Success and EAP-Failure messages, which
indicate the result of an EAP authentication, are unprotected
messages sent by the EAP authenticator to the client and not
acknowledged by the client. Thus these messages can be changed in
transit.
In addition, while the TLS protocol provides a means to securely
terminate a conversation, [TTLSv0] does not utilize that mechanism,
leaving it vulnerable to possible truncation attack. For example, an
attacker might insert a counterfeit EAP-Success to the client prior
to completion of the TTLS exchange, or the attacker might contrive to
Hanna Expires March 24, 2008 [Page 11]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
substitute empty TTLS payloads for real ones to either client or TTLS
server in the final TTLS payloads. This substitution would go
undetected.
Whether such vulnerabilities could lead to real damage beyond denial
of service depends on the underlying inner protocols used within
TTLS. However, for maximum security it is advisable to use the Secure
Completion mechanism to thwart possible attacks.
In Secure Completion, the TTLS server issues a TTLS-Success or TTLS-
Failure AVP as the final AVP of its final TTLS message to the client.
The client responds with either a TTLS-Success or TTLS-Failure AVP as
the final AVP of its final TTLS message to the TTLS server. Once the
TTLS server receives the client's final TTLS message, the unprotected
EAP-Success or EAP-Failure (as appropriate) is sent to the client to
complete the EAP exchange.
Note that other AVPs may appear in the same TTLS message as TTLS-
Success or TTLS-Failure, provided they appear earlier in the message.
The TTLS server, for example, could piggyback a TTLS-Success at the
end of a final inner EAP-Request message.
The client MUST respond to a TTLS-Success from the TTLS server with
either a TTLS-Success or TTLS-Failure. The client MUST respond to a
TTLS-Failure from the TTLS server with a TTLS-Failure. If the client
fails to include such a value as the final AVP in its final EAP-
Response or if the client sends a TTLS-Failure AVP in its final EAP-
Response, the server SHOULD send an EAP-Failure. The server SHOULD
NOT send an EAP-Failure if both the server and client have just sent
TTLS-Success messages since an untrusted intermediary could easily
change this EAP-Failure to an EAP-Success without the client
detecting that change. In any case, the server SHOULD send only one
TTLS-Success or TTLS-Failure message during a particular EAP-TTLSv0
handshake.
When session resumption is employed with EAP-TTLS and secure
completion had been negotiated in the prior session, the TTLS server
and client MUST still send TTLS-Success or TTLS-Failure AVPs to each
other as their last AVPs. This will often result in an additional
round trip but the client and server have previously negotiated
secure completion and this is the price to be paid for that extra
measure of security.
The client MAY issue a Secure-Completion-Option AVP in its first
phase 2 TTLS message to the TTLS server, listing one or both of the
following Secure Completion Option values (defined in section 6.1
below):
Hanna Expires March 24, 2008 [Page 12]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
- Disabled
- Enabled
By listing both Disabled and Enabled options, the client can indicate
that it is willing to proceed with or without Secure Completion. If
this is the case, the client should set the M bit for the Secure-
Completion-Option AVP to 0 so that servers that do not support this
AVP can be supported. If, on the other hand, the client requires
Secure Completion to be used, it may set the M bit for the Secure-
Completion-Option AVP to 1 so that servers that do not support this
AVP will fail the authentication.
The Secure-Completion-Option AVP MUST appear in the client's first
phase 2 TTLS message to the TTLS server if it appears at all. Absence
of the Secure-Completion-Option AVP is equivalent to selecting the
"Disabled" option.
If the client transmits a Secure-Completion-Option AVP that includes
an option acceptable to the TTLS server, the TTLS server MUST respond
with a Secure-Completion-Option AVP in its first phase 2 TTLS message
to the client indicating its selection (Enabled or Disabled). If the
TTLS server is unwilling to accommodate the client's Secure
Completion preferences, it MUST fail the authentication.
6.1. Secure-Completion-Option AVP
The basic format of the Secure-Completion-Option AVP is defined in
section 3 above. This section only describes aspects that are
specific to the Secure-Completion-Option AVP.
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 (when V bit is 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Completion Option Value 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP Code for the Secure-Completion-Option AVP will be assigned by
IANA when this document moves to RFC status. In the mean time, a
Hanna Expires March 24, 2008 [Page 13]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
vendor-specific AVP Code of 259 with a Vendor-ID field of 2636 should
be used for experimental purposes.
The body of the Secure-Completion-Option AVP contains one or more 32-
bit Secure Completion Option Values. To enable extensibility, each
value contains a vendor-id in the first (high order) 24 bits and a
selector in the last (low order) 8 bits. Standard values (defined in
this or future IETF specifications) use a vendor-id of 0. Vendors
MUST use the vendor's IANA-assigned Private Enterprise Number [PEN].
The following standard Secure Completion Option values are defined:
- 0 Disabled (default behavior of [TTLSv0])
- 1 Enabled
The client MAY list multiple Secure Completion Option values, in
order from most to least preferred. The server MUST list only one
value.
6.2. TTLS-Success AVP
The basic format of the TTLS-Success AVP is defined in section 3
above. This section only describes aspects that are specific to the
TTLS-Success AVP.
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 (when V bit is 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP Code for the TTLS-Success AVP will be assigned by IANA when
this document moves to RFC status. In the mean time, a vendor-
specific AVP Code of 260 with a Vendor-ID field of 2636 should be
used for experimental purposes.
The body of the TTLS-Success AVP is empty (zero length).
Hanna Expires March 24, 2008 [Page 14]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
6.3. TTLS-Failure AVP
The basic format of the TTLS-Failure AVP is defined in section 3
above. This section only describes aspects that are specific to the
TTLS-Failure AVP.
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 (when V bit is 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP Code for the TTLS-Failure AVP will be assigned by IANA when
this document moves to RFC status. In the mean time, a vendor-
specific AVP Code of 261 with a Vendor-ID field of 2636 should be
used for experimental purposes.
The body of the TTLS-Failure AVP is empty (zero length).
7. Cryptographic Computations
7.1. Use of TLS PRF
All of the cryptographic mechanisms described in this section use the
PRF function used in the TLS handshake negotiation that initiates the
TTLS exchange. In many cases, this will be the standard PRF function
defined in TLS 1.1 [TLS]; however, it is expected that future
versions of or extensions to the TLS protocol will permit alternative
PRF functions to be negotiated. If an alternative PRF function has
been negotiated during the TLS handshake negotiation, then these
mechanisms use that alternative PRF function instead of the TLS 1.1
PRF. This provides algorithm agility since these mechanisms are not
tied to the MD5 and SHA-1 hashes used in the TLS 1.1 PRF.
The TLS PRF function used for cryptography described in this
specification is denoted as follows:
TLS-PRF-nn(secret, label, seed)
where:
nn is the number of generated octets
Hanna Expires March 24, 2008 [Page 15]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
secret is a secret key
label is a string (without null-terminator)
seed is a binary sequence.
The same PRF function that is used in the TLS handshake MUST be used
for all cryptographic operations described in this manner.
The TLS 1.1 PRF has invariant output regardless of how many octets
are generated. However, it is possible that alternative PRF functions
will include the size of the output sequence as input to the PRF
function; this means generating 32 octets and generating 64 octets
from the same input parameters will no longer result in the first 32
octets being identical. For this reason, the PRF is always specified
with an "nn", indicating the number of generated octets.
7.2. Composite Key Computation
The Composite Key is a 40-octet secret derived by cryptographically
mixing the TLS master secret and all inner MSKs. It is used as a
basis for computing the MSK and/or EMSK when the "Mixed" computation
mechanism has been negotiated, as well as for computing Key
Confirmation values.
Note that when an intermediate Key Confirmation is performed, an
intermediate Composite Key must be computed using only those inner
MSKs whose values are available at the time that the TTLS server
issues the intermediate Key Confirmation. A subsequent Key
Confirmation exchange or MSK/EMSK computation using the "Mixed"
mechanism will require a new Composite Key computation, as one or
more additional inner MSKs will have become available.
Composite Key = TLS-PRF-40(master_secret,
"ttls composite key",
client_random +
server_random +
inner_session_keys)
master_secret, client_random and server_random are security
parameters from the TLS handshake.
inner_session_keys is the concatenation of all session keys produced
by inner authentication methods. This value is calculated as follows.
Treating each session key as an unsigned big-endian binary numeric
value (perhaps a rather long number), sort this set of session keys
from lowest numeric value to highest. Prefix each session key with a
Hanna Expires March 24, 2008 [Page 16]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
2-octet big-endian value indicating the length of that session key in
octets. Then concatenate the length-prefixed session keys in the
determined (sorted) order. Finally, append two octets of zero to
terminate the sequence.
If there are no inner authentication methods that produce a session
key, inner_session_keys will consist only of two octets of zero.
The session keys are ordered by value rather than by the sequence in
which they are produced in order to avoid imposing any restrictions
against multiple concurrent inner authentications, which might result
in ambiguous orderings.
7.3. MSK/EMSK computation using the "Mixed" mechanism
The "Mixed" mechanism for computing the MSK and EMSK uses the
following formula:
Keying Material = TLS-PRF-128(composite_key,
"ttls mixed keying material",
<null>)
MSK = Keying Material [0..63]
EMSK = Keying Material [64..127]
where <null> indicates that the seed value is of zero-length.
7.4. Key Confirmation computation
The Key Confirmation value transmitted by the client is computed
according to the following formula:
client_key_confirmation = TLS-PRF-32(composite_key,
"ttls client key confirmation",
<null>)
The Key Confirmation value transmitted by the TTLS server is computed
according to the following formula:
server_key_confirmation = TLS-PRF-32(composite_key,
"ttls server key confirmation",
<null>)
Hanna Expires March 24, 2008 [Page 17]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
8. Security Considerations
The EAP-TTLSv0 extensions defined in this document supplement the
security protection provided by EAP-TTLSv0 by adding algorithm
agility, cryptographic binding of inner authentications to the outer
tunnel, and protected results. These additional security features
provide protection against failures in cryptographic algorithms,
protection against particular kinds of MITM attacks, protection
against truncation attacks, and protection against forged results.
The following sections show how this protection is provided.
8.1. Cryptographic Algorithm Agility
EAP-TTLS uses cryptographic algorithms in several places. First, it
is based on EAP-TLS [EAPTLS] which is based on TLS which uses
asymmetric and symmetric encryption algorithms and hash algorithms.
Some algorithm agility is provided by the ciphersuite negotiation
included in TLS 1.1 but the TLS PRF always uses MD5 and SHA1.
Fortunately, TLS 1.2 [TLS12] can be used with EAP-TTLS to provide
algorithm agility for the TLS PRF. This can be negotiated with the
standard TLS version negotiation mechanism.
However, the original design of EAP-TTLSv0 always uses the TLS 1.1
PRF to calculate the Master Session Key (MSK) and Extended Master
Session Key (EMSK). This leaves the system open to attacks based on
weaknesses in MD5 and SHA1. The MSK-Computation AVP allows the PRF
negotiated during the TLS handshake to be used for calculating MSK
and EMSK values, thus allowing a smooth transition to other
cryptographic algorithms if MD5 and SHA1 are judged to be inadequate.
8.2. Protection Against MITM Attacks
As described in [MITM], if a malicious EAP server can convince a
client to authenticate using a particular EAP authentication method
and then pass this method through a standard tunneled EAP method, the
malicious party can typically gain access as if it had performed the
authentication itself. Several countermeasures are possible, such as
ensuring that clients only authenticate with trusted servers. But one
good way to solve the problem is to modify tunneled EAP methods to
verify that the same client is terminating both the inner and the
outer authentication method.
The MSK-Computation AVP allows the client and/or server to require
that the MSK and EMSK is computed using a mixture of the TLS master
secret and the MSKs exported from inner methods. If the MSK and EMSK
are used to derive keys necessary for later access (as with 802.1X
[8021X]), this will ensure that the attack described above will fail
Hanna Expires March 24, 2008 [Page 18]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
since the attacker will not know the MSKs exported from the inner
methods. The KeyConfirmation AVPs provide even stronger protection
against this attack, allowing the TTLS server and TTLS client each to
verify that the other party knows the MSKs from all inner methods and
the TLS master secret before the authentication terminates. When
intermediate key confirmation is used, the TTLS server can verify
this at any point in the authentication process. If a MITM attack is
detected, the TTLS server can terminate authentication promptly to
prevent the later authentication steps from taking place. This can
avoid revealing sensitive information to the attacker, such as one-
time passwords or biometric data.
8.3. Protection Against Truncation Attacks
By truncating an EAP-TTLSv0 session, an attacker could cause the
client to believe that the session completed successfully when in
fact it was unsuccessful or incomplete. The implications of such an
attack depend on the particular inner methods in use and the
circumstances of the deployment but they could perhaps result in the
client using the wrong keying material for later communications, for
example. The Secure-Completion-Option, TTLS-Success, and TTLS-Failure
AVPs allow the client to require or request that the server and
client securely confirm the results of the authentication to each
other before the authentication is considered complete. Thus, any
truncation can easily be detected.
8.4. Protection Against Forged Results
EAP results (EAP-Success and EAP-Failure) are not generally protected
in transit from the server to the client. This means that the client
can be led to believe that an authentication failed when it actually
succeeded or vice versa. The Secure-Completion, TTLS-Success, and
TTLS-Failure AVPs allow the client to securely determine the results
of the authentication, thus foiling any attempt to forge or modify
the results of the authentication.
9. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this
specification, in accordance with [IANA]. The term "IETF Consensus"
is used in this section with the meaning defined in [IANA].
9.1. Allocation of AVP Codes
This specification requires the allocation and assignment of six AVP
Codes to identify new AVPs identified in this specification. As
Hanna Expires March 24, 2008 [Page 19]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
described in RFC 3588, release of blocks of AVPs requires IETF
Consensus.
Once this document is approved as an RFC, the IANA is requested to
allocate and assign unique AVP Codes for the following six AVPs
defined in this specification: MSK-Computation, Key-Confirmation-
Option, Key-Confirmation, Secure-Completion-Option, TTLS-Success, and
TTLS-Failure.
Once these allocations and assignments have been made, they should be
added to this specification. For each AVP Code, there is a paragraph
like this one:
The AVP Code for the MSK-Computation AVP will be assigned by IANA
when this document moves to RFC status. In the mean time, a vendor-
specific AVP Code of 256 with a Vendor-ID field of 2636 should be
used for experimental purposes.
Once the AVP Code for the MSK-Computation AVP has been assigned, this
paragraph should be changed to read:
The AVP Code for the MSK-Computation AVP is [Assigned-AVP-Code]. In
order to allow implementation of this specification before assignment
of that code, a vendor-specific AVP Code of 256 with a Vendor-ID
field of 2636 has been used for experimental purposes.
Implementations of this RFC MUST accept the new standard AVP Code for
the MSK-Computation AVP, MAY accept the vendor-specific AVP Code, and
SHOULD only send the standard AVP Code.
This subsection (subsection 9.1) of the IANA Considerations section
may be removed once the AVP Codes have been assigned and the document
is ready to move to RFC status.
9.2. Creation of New Registries
This specification requires the creation of three new registries to
be managed by IANA: MSK Computation Methods, Key Confirmation
Options, and Secure Completion Options.
Each of these registries should be composed of numeric values in the
range 0 to 255. Each value should also have a name. Because of the
limited number of values available in each of these registries,
values should only be added to these registries if they achieve IETF
Consensus as defined in [IANA].
A vendor extension mechanism has been defined to allow vendors to
define their own values similar in function to the IANA-reserved
Hanna Expires March 24, 2008 [Page 20]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
values in these registries. This vendor extension mechanism is
described earlier in this specification. Such vendor-specific values
are not to be tracked or managed by IANA.
Certain values defined in this specification should be prepopulated
into these registries. The next three paragraphs enumerate those
values.
For the MSK Computation Methods registry, the values to be
prepopulated are 0 (with a name of "Default computation as defined in
RFC XXXX") and 1 (with a name of "Mixed computation mechanism as
defined in RFC YYYY"), where XXXX is replaced by the RFC number
assigned to [TTLSv0] and YYYY is replaced by the RFC number assigned
to this specification.
For the Key Confirmation Options registry, the values to be
prepopulated are 0 (with a name of "Disabled") and 1 (with a name of
"Enabled").
For the Secure Completion Options registry, the values to be
prepopulated are 0 (with a name of "Disabled") and 1 (with a name of
"Enabled").
When this document is ready to become an RFC, this paragraph and the
preceding four paragraphs can be deleted.
10. References
10.1. Normative References
[KEYWORDS]S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TTLSv0] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol Version 0", Internet Draft (work in
progress), draft-funk-eap-ttls-v0-01.txt, April 2007.
10.2. Informative References
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
Hanna Expires March 24, 2008 [Page 21]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
[EAPTLS] Simon, D. and B. Aboba, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in
Tunnelled Authentication Protocols", Cryptology ePrint
Archive, Report 2002/163, http://eprint.iacr.org, 2002.
[PEN] IANA Private Enterprise Numbers,
http://www.iana.org/assignments/enterprise-numbers.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", Internet Draft (work in
progress), draft-ietf-tls-rfc4346bis-04.txt, July 2007.
[8021X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
Authors' Addresses
Steve Hanna
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
Email: shanna@juniper.net
Paul Funk
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
Email: pfunk@juniper.net
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
Hanna Expires March 24, 2008 [Page 22]
Internet-Draft draft-hanna-eap-ttls-agility-00.txt September 2007
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hanna Expires March 24, 2008 [Page 23]
