< draft-otto-emu-eap-tls-psk-00.txt   draft-otto-emu-eap-tls-psk-01.txt >
EMU Working Group T. Otto EMU Working Group T. Otto
Internet-Draft H. Tschofenig Internet-Draft
Expires: October 21, 2006 Siemens AG Intended status: Standards Track H. Tschofenig
April 19, 2006 Expires: April 26, 2007 Siemens Networks GmbH & Co KG
October 23, 2006
The EAP-TLS-PSK Authentication Protocol The EAP-TLS-PSK Authentication Protocol
draft-otto-emu-eap-tls-psk-00 draft-otto-emu-eap-tls-psk-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 21, 2006. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, is The Extensible Authentication Protocol (EAP), defined in RFC 3748, is
a network access authentication framework which provides support for a network access authentication framework which provides support for
multiple authentication methods. One proposal is EAP-TLS, which multiple authentication methods. One proposal is EAP-TLS, which
relies on the Transport Layer Security (TLS) protocol and allows for relies on the Transport Layer Security (TLS) protocol and allows for
certificate-based authentication. This document specifies EAP-TLS- certificate-based authentication. This document specifies EAP-TLS-
PSK, which also relies on TLS, but allows for shared secret-based PSK, which also relies on TLS, but allows for shared secret-based
authentication. EAP-TLS-PSK supports the pre-shared key ciphersuites authentication. EAP-TLS-PSK supports the pre-shared key ciphersuites
specified in RFC 4279. specified in RFC 4279.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview about pre-shared key TLS ciphersuites . . . . . . 3 1.1. Overview about pre-shared key TLS ciphersuites . . . . . . 4
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Overview of the EAP-TLS-PSK Conversation . . . . . . . . . 6 2.1. Overview of the EAP-TLS-PSK Conversation . . . . . . . . . 7
2.2. Retry Behavior . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Retry Behavior . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Identity Verification . . . . . . . . . . . . . . . . . . 12 2.4. Identity Verification . . . . . . . . . . . . . . . . . . 13
2.5. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Ciphersuite and Compression Negotiation . . . . . . . . . 13 2.6. Ciphersuite and Compression Negotiation . . . . . . . . . 15
3. EAP-TLS-PSK Packet Format . . . . . . . . . . . . . . . . . . 15 3. EAP-TLS-PSK Packet Format . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 18 5.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 19
5.2. Protected Result Indications . . . . . . . . . . . . . . . 18 5.2. Protected Result Indications . . . . . . . . . . . . . . . 19
5.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 18 5.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 19
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 18 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 19
5.5. Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 18 5.5. Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 19
5.6. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 19 5.6. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 20
5.7. Session Independence . . . . . . . . . . . . . . . . . . . 19 5.7. Session Independence . . . . . . . . . . . . . . . . . . . 20
5.8. Exposition of the PSK . . . . . . . . . . . . . . . . . . 19 5.8. Exposition of the PSK . . . . . . . . . . . . . . . . . . 20
5.9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 20 5.9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21
5.10. Channel Binding . . . . . . . . . . . . . . . . . . . . . 20 5.10. Channel Binding . . . . . . . . . . . . . . . . . . . . . 21
5.11. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 20 5.11. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 21
5.12. Identity Protection . . . . . . . . . . . . . . . . . . . 20 5.12. Identity Protection . . . . . . . . . . . . . . . . . . . 21
5.13. Protected Ciphersuite Negotiation . . . . . . . . . . . . 20 5.13. Protected Ciphersuite Negotiation . . . . . . . . . . . . 21
5.14. Confidentiality . . . . . . . . . . . . . . . . . . . . . 20 5.14. Confidentiality . . . . . . . . . . . . . . . . . . . . . 21
5.15. Cryptographic Binding . . . . . . . . . . . . . . . . . . 21 5.15. Cryptographic Binding . . . . . . . . . . . . . . . . . . 22
5.16. Security Claims . . . . . . . . . . . . . . . . . . . . . 21 5.16. Security Claims . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), described in [RFC3748], The Extensible Authentication Protocol (EAP), described in [RFC3748],
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. Through the use of EAP, support for a number of methods. Through the use of EAP, support for a number of
authentication schemes may be added, including smart cards, Kerberos, authentication schemes may be added, including smart cards, Kerberos,
Public Key, One Time Passwords, and others. Public Key, One Time Passwords, and others.
In 1998, EAP-TLS ([RFC2716]) was published. It performs mutual In 1998, EAP-TLS ([RFC2716]) was published. It performs mutual
skipping to change at page 6, line 28 skipping to change at page 7, line 28
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=EAP-TLS-PSK EAP-Type=EAP-TLS-PSK
(TLS Start) (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS-PSK EAP-Type=EAP-TLS-PSK
(TLS client_hello)-> (TLS client_hello)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=EAP-TLS-PSK EAP-Type=EAP-TLS-PSK
(TLS server_hello, (TLS server_hello,
[TLS certificate,]
[TLS server_key_exchange,] [TLS server_key_exchange,]
TLS server_hello_done) TLS server_hello_done)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS-PSK EAP-Type=EAP-TLS-PSK
(TLS client_key_exchange, (TLS client_key_exchange,
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=EAP-TLS-PSK EAP-Type=EAP-TLS-PSK
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS-PSK -> EAP-Type=EAP-TLS-PSK ->
<- EAP-Success <- EAP-Success
Figure 1: EAP-TLS-PSK message flow Figure 1: EAP-TLS-PSK message flow
As described in [RFC3748], the EAP-TLS-PSK conversation will As described in [RFC3748], the EAP-TLS-PSK conversation will
typically begin with the authenticator and the peer negotiating EAP. typically begin with the authenticator and the peer negotiating EAP.
The authenticator will then typically send an EAP-Request/Identity The authenticator will then typically send an EAP-Request/Identity
packet to the peer, and the peer will respond with an EAP-Response/ packet to the peer, and the peer will respond with an EAP-Response/
Identity packet to the authenticator, containing the peer's userId. Identity packet to the authenticator, containing the peer's userId.
From this point forward, while nominally the EAP conversation occurs From this point forward, while nominally the EAP conversation occurs
between the EAP authenticator and the peer, the authenticator MAY act between the EAP authenticator and the peer, the authenticator MAY act
as a passthrough device, with the EAP packets received from the peer as a passthrough device, with the EAP packets received from the peer
skipping to change at page 8, line 43 skipping to change at page 9, line 43
In case of a RSA_PSK ciphersuite, the server sends a certificate In case of a RSA_PSK ciphersuite, the server sends a certificate
message. This message MUST contain the server's public key. In message. This message MUST contain the server's public key. In
accordance to EAP-TLS, the certificate message contains a public key accordance to EAP-TLS, the certificate message contains a public key
certificate chain for either a key exchange public key (such as an certificate chain for either a key exchange public key (such as an
RSA or Diffie-Hellman key exchange public key) or a signature public RSA or Diffie-Hellman key exchange public key) or a signature public
key (such as an RSA or DSS signature public key). In the latter key (such as an RSA or DSS signature public key). In the latter
case, a TLS server_key_exchange handshake message MUST also be case, a TLS server_key_exchange handshake message MUST also be
included to allow the key exchange to take place. included to allow the key exchange to take place.
In an EAP-TLS-PSK message exchange, the client will never send a In an EAP-TLS-PSK message exchange, there will never the client will
certificate message and certificate_verify message, and the server never send a certificate and certificate_verify message, and the
will never send a certificate_request message. server will never send a certificate_request message.
The peer MUST respond to the EAP-Request with an EAP-Response packet The peer MUST respond to the EAP-Request with an EAP-Response packet
of EAP-Type=EAP-TLS-PSK. The data field of this packet will of EAP-Type=EAP-TLS-PSK. The data field of this packet will
encapsulate one or more TLS records containing a TLS encapsulate one or more TLS records containing a TLS
client_key_exchange, change_cipher_spec and and finished handshake client_key_exchange, change_cipher_spec and and finished handshake
message. message.
If the preceding server_hello message sent by the EAP server in the If the preceding server_hello message sent by the EAP server in the
preceding EAP-Request packet indicated the resumption of a previous preceding EAP-Request packet indicated the resumption of a previous
session, then the peer MUST send only the change_cipher_spec and session, then the peer MUST send only the change_cipher_spec and
skipping to change at page 13, line 14 skipping to change at page 14, line 14
2.5. Key Hierarchy 2.5. Key Hierarchy
In EAP-TLS-PSK, the MSK, EMSK and IV are derived from the TLS master In EAP-TLS-PSK, the MSK, EMSK and IV are derived from the TLS master
secret via a one-way function. This ensures that the TLS master secret via a one-way function. This ensures that the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) is broken. Since the MSK is derived from the the function (TLS PRF) is broken. Since the MSK is derived from the the
TLS master secret, if the TLS master secret is compromised then the TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised. MSK is also compromised.
The notation X[A..B] means byte A to B of X. The notation TLS-PRF-X The MSK is divided into two halves, corresponding to the "Peer to
means that the TLS-PRF is iterated as long as possible to generate X Authenticator Encryption Key" (Enc- RECV-Key, 32 octets) and
byte output. "Authenticator to Peer Encryption Key" (Enc- SEND-Key, 32 octets).
Having this, the EAP-TLS-PSK key derivation procedure looks as The EMSK is also divided into two halves, corresponding to the "Peer
follows: to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that is a known value; octets
0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
The key derivation scheme is as follows. The notation X[A..B] means
byte A to B of X. The notation TLS-PRF-X means that the TLS-PRF is
iterated as long as possible to generate X byte output.
MSK = TLS-PRF-128 (master_secret, "client EAP encryption", MSK = TLS-PRF-128 (master_secret, "client EAP encryption",
client.random || server.random)[0..63] client.random || server.random)[0..63]
EMSK = TLS-PRF-128 (master_secret, "client EAP encryption", EMSK = TLS-PRF-128 (master_secret, "client EAP encryption",
client.random || server.random)[64..127] client.random || server.random)[64..127]
IV = TLS-PRF-64 ("", "client EAP encryption", IV = TLS-PRF-64 ("", "client EAP encryption",
client.random || server.random)[0..63] client.random || server.random)[0..63]
The TLS-negotiated ciphersuite is used to set up a protected channel The TLS-negotiated ciphersuite is used to set up a protected channel
for use in protecting the EAP conversation, keyed by the derived for use in protecting the EAP conversation, keyed by the derived
TEKs. The TEK derivation proceeds as follows: TEKs. The TEK derivation proceeds as follows:
master_secret = TLS-PRF-48 (pre_master_secret, "master secret", master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random) client.random || server.random)
TEK = TLS-PRF-X (master_secret, "key expansion", TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random) server.random || client.random)
To meet the requirements of [I-D.ietf-eap-keying], EAP-TLS-PSK To meet the requirements of [I-D.ietf-eap-keying] EAP-TLS-PSK defines
defines a Method-ID, which is used for computing the Session-ID and a Method-ID, which is used for computing a session-ID and key names.
key names. In the current version, the Method-ID is set to the In the current version, the Method-ID is set to the concatenation of
concatenation of the server and client Finished messages. The the server and client Finished messages. The Method-ID uniquely
Method-ID uniquely identifies an EAP-TLS-PSK session, because the identifies an EAP-TLS-PSK session, because the Hashes in the Finished
hashes in the Finished message contain the random values exchanged message contain the random values exchanged with the ClientHello- and
with the ClientHello- and ServerHello messages as well as the ServerHello messages as well as the identities of client and EAP
identities of client and EAP server. server.
2.6. Ciphersuite and Compression Negotiation 2.6. Ciphersuite and Compression Negotiation
Since TLS supports ciphersuite negotiation, peers completing the TLS Since TLS supports ciphersuite negotiation, peers completing the TLS
negotiation will also have selected a ciphersuite, which includes negotiation will also have selected a ciphersuite, which includes
encryption and hashing methods. Since the ciphersuite negotiated encryption and hashing methods. Since the ciphersuite negotiated
within EAP-TLS-PSK applies only to the EAP conversation, TLS within EAP-TLS-PSK applies only to the EAP conversation, TLS
ciphersuite negotiation SHOULD NOT be used to negotiate the ciphersuite negotiation SHOULD NOT be used to negotiate the
ciphersuites used to secure data. ciphersuites used to secure data.
skipping to change at page 15, line 20 skipping to change at page 16, line 20
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | TLS Message Length | Type | Flags | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data... | TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EAP-TLS-PSK packet format Figure 3: EAP-TLS-PSK packet format
Code Code
1 - EAP-TLS-PSK Request (short: Request) 1 - EAP-TLS-PSK Request (short: Request)
2 - EAP-TLS-PSK Response (short: Response) 2 - EAP-TLS-PSK Response (short: Response)
Identifier Identifier
The identifier field is one octet and aids in matching responses The identifier field is one octet and aids in matching responses
with requests. If the message is of type Response, then the with requests. If the message is of type Response, then the
skipping to change at page 18, line 48 skipping to change at page 19, line 48
5.5. Dictionary Attacks 5.5. Dictionary Attacks
For PSK and DHE_PSK, mutual authentication is based on a shared For PSK and DHE_PSK, mutual authentication is based on a shared
secret. While [RFC4279] does not specify the length of this pre- secret. While [RFC4279] does not specify the length of this pre-
shared key, EAP-TLS-PSK does so. The pre-shared key MUST be at least shared key, EAP-TLS-PSK does so. The pre-shared key MUST be at least
16 byte long and have full entropy. For these two modes, it is 16 byte long and have full entropy. For these two modes, it is
highly discouraged having derived the pre-shared key from low entropy highly discouraged having derived the pre-shared key from low entropy
source, e.g. a password. source, e.g. a password.
For RSA_PSK, the pre-shared key SHOULD also be at least 16 byte long. For RSA_PSK, the shared secret must also be at least 16 byte long.
In contrast to PSK and DHE_PSK, the pre-shared key may also be In contrast to PSK and DHE_PSK modes, the shared secret may be also
derived from a low entropy source, e.g. a password. This becomes derived from a low entropy source, e.g. a password. This becomes
possible because the EAP server authenticates himself through public possible because the server authentications with public-key
key techniques and prior than the client. techniques first.
In this version of EAP-TLS-PSK, however, the pre-shared key MUST BE In this draft version, however, the following assertion is made. If
at least 16 byte long and MUST HAVE full entropy. Then, EAP-TLS-PSK the shared secret is at least 16 byte long and has full entropy, EAP-
is not susceptible for dictionary attacks. TLS-PSK is not susceptible for dictionary attacks.
5.6. Key Derivation 5.6. Key Derivation
EAP-TLS-PSK supports key derivation according to [RFC3748] and EAP-TLS-PSK supports key derivation according to [RFC3748] and [I.D.-
[I-D.ietf-eap-keying]. Keying].
EAP-TLS-PSK exports keys, namely a 64-byte MSK, a 64-byte EMSK and a EAP-TLS-PSK exports keys, namely a 64-byte MSK, a 64-byte EMSK and a
64-byte IV. 64-byte IV.
Some remarks regarding the key strength of EAP-TLS-PSK. In case of Some remarks regarding the key strength. In case of RSA_PSK
RSA_PSK, the server's private key size should be chosen accordingly ciphersuites, the server's private key size should be chosen
to the length of the pre-shared key. Section 5 in [RFC3766] accordingly to the length of the pre-shared key. Section 5 in
contrasts symmetric key sizes with their public key counterparts, to [RFC3766] contrasts symmetric key sizes with their public key
obtain roughly the same overall key strength. Based on the table counterparts, to obtain roughly the same overall key strength. Based
below, a 3072-bit RSA key is required to provide 128-bit equivalent on the table below, a 3072-bit RSA key is required to provide 128-bit
key strength. equivalent key strength.
Attack Resistance RSA or DH Modulus DSA subgroup Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits) (bits) size (bits) size (bits)
----------------- ----------------- ------------ ----------------- ----------------- ------------
70 947 128 70 947 128
80 1228 145 80 1228 145
90 1553 153 90 1553 153
100 1926 184 100 1926 184
150 4575 279 150 4575 279
200 8719 373 200 8719 373
skipping to change at page 20, line 5 skipping to change at page 21, line 5
EMSKs. The assumption that the random numbers of the TLS EMSKs. The assumption that the random numbers of the TLS
client_hello and server_hello messages are random is central for the client_hello and server_hello messages are random is central for the
security of EAP-TLS-PSK in general and session independance in security of EAP-TLS-PSK in general and session independance in
particular. particular.
5.8. Exposition of the PSK 5.8. Exposition of the PSK
EAP-TLS-PSK specifies three sets of ciphersuites, which distinguish EAP-TLS-PSK specifies three sets of ciphersuites, which distinguish
in the underlying key derivation mechanism. in the underlying key derivation mechanism.
o The PSK and RSA_PSK ciphersuites do not provide perfect forward o The PSK and RSA_PSK ciphersuites does not provide perfect forward
secrecy. Compromise of the pre-shared key or the pre-shared key secrecy. Compromise of the pre-shared key or the pre-shared key
and the server's private key (in case of RSA_PSK) leads to and the server's private key (in case of RSA_PSK) leads to
compromise of recorded past sessions. compromise of recorded past sessions.
o DHE_PSK ciphersuites provide perfect forward secrecy, if a fresh o DHE_PSK ciphersuites provide perfect forward secrecy, if a fresh
Diffie-Hellman private key is generated for each handshake. Diffie-Hellman private key is generated for each handshake.
5.9. Fragmentation 5.9. Fragmentation
EAP-TLS-PSK supports fragmentation and reassembly. The mechanism is EAP-TLS-PSK supports fragmentation and reassembly. The mechanism is
skipping to change at page 21, line 13 skipping to change at page 22, line 13
'identity protection', which is also not addressed by EAP-TLS-PSK. 'identity protection', which is also not addressed by EAP-TLS-PSK.
5.15. Cryptographic Binding 5.15. Cryptographic Binding
This feature is not applicable for EAP-TLS-PSK. This feature is not applicable for EAP-TLS-PSK.
5.16. Security Claims 5.16. Security Claims
This section provides the security claims required by [RFC3748]. This section provides the security claims required by [RFC3748].
[a] Mechanism. [a] Mechanism.
* For PSK and DHE_PSK: Pre-shared key. * For PSK and DHE_PSK: Pre-shared key.
* For RSA_PSK: Server via Public key, Peer via Pre-shared key. * For RSA_PSK: Server via Public key, Peer via Pre-shared key.
[b] Security claims. EAP-TLS-PSK provides: [b] Security claims. EAP-TLS-PSK provides:
* Mutual authentication (see Section 5.1) * Mutual authentication (see Section 5.1)
* Integrity protection (see Section 5.3) * Integrity protection (see Section 5.3)
* Replay protection (see Section 5.4) * Replay protection (see Section 5.4)
* Key derivation (see Section 5.6) * Key derivation (see Section 5.6)
* Dictionary attack resistance (see Section 5.5) * Dictionary attack resistance (see Section 5.5)
* Session independence (see section Section 5.5) * Session independence (see section Section 5.5)
* Fast reconnect (see Section 5.11) * Fast reconnect (see Section 5.11)
* Fragmentation (see Section 5.9) * Fragmentation (see Section 5.9)
* Protected cipher suite negotiation (see Section 5.13) * Protected cipher suite negotiation (see Section 5.13)
* Perfect Forward Secrecy (at least partially; see Section 5.6) * Perfect Forward Secrecy (at least partially; see Section 5.6)
[c] Key strength. EAP-TLS-PSK provides at least a 16-byte effective [c] Key strength. EAP-TLS-PSK provides at least a 16-byte effective
key strength. key strength.
[d] Indication of vulnerabilities. EAP-TLS-PSK does not provide: [d] Indication of vulnerabilities. EAP-TLS-PSK does not provide:
* Identity protection (see Section 5.12) * Identity protection (see Section 5.12)
* Confidentiality (see Section 5.14) * Confidentiality (see Section 5.14)
* Cryptographic binding (see Section 5.15) * Cryptographic binding (see Section 5.15)
* Key agreement: the session key is chosen by the peer (see * Key agreement: the session key is chosen by the peer (see
Section 5.6) Section 5.6)
* Channel binding (see Section 5.10) * Channel binding (see Section 5.10)
6. Acknowledgments 6. Acknowledgments
The EAP-TLS-PSK specification lends parts of both the EAP-TLS and The authors would like to thank Bernard Aboba and Dan Simon for
EAP-PSK specifications. The authors would like to thank Bernard adopting parts of their EAP-TLS specification, and Florent Bersani
Aboba and Dan Simon and Florent Bersani for their challenging work. for lending parts of the EAP-PSK specification.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
skipping to change at page 24, line 30 skipping to change at page 25, line 30
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
7.2. Informative References 7.2. Informative References
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-12 (work in Management Framework", draft-ietf-eap-keying-14 (work in
progress), April 2006. progress), June 2006.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Standard for Telecommunications and Information Exchange "Standard for Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 11: Between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 1999. Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[IEEE-802.11i] [IEEE-802.11i]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
skipping to change at page 27, line 8 skipping to change at page 28, line 8
Fang-Chun Kuo, Hannes Tschofenig, Fabian Meyer, and Fang-Chun Kuo, Hannes Tschofenig, Fabian Meyer, and
Xiaoming Fu, "Comparison Studies between Pre-Shared Key Xiaoming Fu, "Comparison Studies between Pre-Shared Key
and Public Key Exchange Mechanisms for Transport Layer and Public Key Exchange Mechanisms for Transport Layer
Security (TLS)", IFI-TB-2006-01 URL: http:// Security (TLS)", IFI-TB-2006-01 URL: http://
user.informatik.uni-goettingen.de/~fkuo/publications/ user.informatik.uni-goettingen.de/~fkuo/publications/
ptls-ifi-tb-2006-01.pdf, January 2006. ptls-ifi-tb-2006-01.pdf, January 2006.
Authors' Addresses Authors' Addresses
Thomas Otto Thomas Otto
Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
Email: thomas.g.otto@googlemail.com Email: thomas.g.otto@googlemail.com
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich 81739 Munich 81739
Germany Germany
Email: hannes.tschofenig@siemens.com Email: hannes.tschofenig@siemens.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 28, line 29 skipping to change at page 29, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (2006). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 46 change blocks. 
129 lines changed or deleted 133 lines changed or added

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