draft-ietf-emu-eap-gpsk-15.txt   draft-ietf-emu-eap-gpsk-16.txt 
EMU Working Group T. Clancy EMU Working Group T. Clancy
Internet-Draft LTS Internet-Draft LTS
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 19, 2009 Nokia Siemens Networks Expires: May 1, 2009 Nokia Siemens Networks
October 16, 2008 October 28, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) Method EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-15 draft-ietf-emu-eap-gpsk-16
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 35 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 April 19, 2009. This Internet-Draft will expire on May 1, 2009.
Abstract Abstract
This Internet Draft defines an Extensible Authentication Protocol This Internet Draft defines an Extensible Authentication Protocol
method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This
is a lightweight shared-key authentication protocol supporting mutual method is a lightweight shared-key authentication protocol supporting
authentication and key derivation. mutual authentication and key derivation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 4, line 30 skipping to change at page 4, line 30
Security Model: Security Model:
EAP-GPSK has been designed in a threat model where the attacker EAP-GPSK has been designed in a threat model where the attacker
has full control over the communication channel. This is the EAP has full control over the communication channel. This is the EAP
threat model that is presented in Section 7.1 of [RFC3748]. threat model that is presented in Section 7.1 of [RFC3748].
Efficiency: Efficiency:
EAP-GPSK does not make use of public key cryptography and fully EAP-GPSK does not make use of public key cryptography and fully
relies of symmetric cryptography. The restriction on symmetric relies of symmetric cryptography. The restriction of symmetric
cryptographic computations allows for low computational overhead. cryptographic computations allows for low computational overhead.
Hence, EAP-GPSK is lightweight and well suited for any type of Hence, EAP-GPSK is lightweight and well suited for any type of
device, especially those with processing power, memory and battery device, especially those with processing power, memory and battery
constraints. Additionally it seeks to minimize the number of constraints. Additionally it seeks to minimize the number of
round trips. round trips.
Flexibility: Flexibility:
EAP-GPSK offers cryptographic flexibility. At the beginning, the EAP-GPSK offers cryptographic flexibility. At the beginning, the
EAP server proposes a list of ciphersuites. The client then EAP server proposes a list of ciphersuites. The client then
selects one. The current version of EAP-GPSK comprises two selects one. The current version of EAP-GPSK includes two
ciphersuites, but additional ones can be easily added. ciphersuites, but additional ones can be easily added.
Extensibility: Extensibility:
The design of EAP-GPSK allows to securely exchange information The design of EAP-GPSK allows to securely exchange information
between the EAP peer and the EAP server using protected data between the EAP peer and the EAP server using protected data
fields. These fields might, for example, be used to exchange fields. These fields might, for example, be used to exchange
channel binding information or to provide support for identity channel binding information or to provide support for identity
confidentiality. confidentiality.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
SK: Session key generated from the MK and used during protocol SK: Session key generated from the MK and used during protocol
exchange to demonstrate knowledge of the PSK (KS octets) exchange to demonstrate knowledge of the PSK (KS octets)
3. Overview 3. Overview
The EAP framework (see Section 1.3 of [RFC3748]) defines three basic The EAP framework (see Section 1.3 of [RFC3748]) defines three basic
steps that occur during the execution of an EAP conversation between steps that occur during the execution of an EAP conversation between
the EAP peer, the Authenticator and the EAP server. the EAP peer, the Authenticator and the EAP server.
1. The first phase, discovery, is handled by the underlying 1. The first phase, discovery, is handled by the underlying protocol
protocol. (e.g. IEEE 802.1X as utilized by IEEE 802.11i).
2. The EAP authentication phase with EAP-GPSK is defined in this 2. The EAP authentication phase with EAP-GPSK is defined in this
document. document.
3. The secure association distribution and secure association phases 3. The secure association distribution and secure association phases
are handled differently depending on the underlying protocol. are handled differently depending on the underlying protocol.
EAP-GPSK performs mutual authentication between EAP peer ("Peer") and EAP-GPSK performs mutual authentication between EAP peer ("Peer") and
EAP server ("Server") based on a pre-shared key (PSK). The protocol EAP server ("Server") based on a pre-shared key (PSK). The protocol
consists of the message exchanges (GPSK-1, ..., GPSK-4), in which consists of the message exchanges (GPSK-1, ..., GPSK-4), in which
both sides exchange nonces and their identities, compute and exchange both sides exchange nonces and their identities, compute and exchange
a Message Authentication Code (MAC) over the previously exchanged a Message Authentication Code (MAC) over the previously exchanged
skipping to change at page 9, line 35 skipping to change at page 9, line 35
verification is successful, GPSK-4 is prepared. This message can verification is successful, GPSK-4 is prepared. This message can
optionally contain the peer's protected data parameters. optionally contain the peer's protected data parameters.
Upon receipt of GPSK-4, the server processes any included Upon receipt of GPSK-4, the server processes any included
PD_Payload_Block. Then, the EAP server sends an EAP Success message PD_Payload_Block. Then, the EAP server sends an EAP Success message
to indicate the successful outcome of the authentication. to indicate the successful outcome of the authentication.
4. Key Derivation 4. Key Derivation
EAP-GPSK provides key derivation in compliance to the requirements of EAP-GPSK provides key derivation in compliance to the requirements of
[RFC3748] and [I-D.ietf-eap-keying]. Note that this section provides [RFC3748] and [RFC5247]. Note that this section provides an abstract
an abstract description for the key derivation procedure that needs description for the key derivation procedure that needs to be
to be instantiated with a specific ciphersuite. instantiated with a specific ciphersuite.
The long-term credential shared between EAP peer and EAP server The long-term credential shared between EAP peer and EAP server
SHOULD be a strong pre-shared key PSK of at least 16 octets, though SHOULD be a strong pre-shared key PSK of at least 16 octets, though
its length and entropy is variable. While it is possible to use a its length and entropy is variable. While it is possible to use a
password or passphrase, doing so is NOT RECOMMENDED as it would make password or passphrase, doing so is NOT RECOMMENDED as it would make
EAP-GPSK vulnerable to dictionary attacks. EAP-GPSK vulnerable to dictionary attacks.
During an EAP-GPSK authentication, a Master Key MK, a Session Key SK During an EAP-GPSK authentication, a Master Key MK, a Session Key SK
and a Protected Data Encryption Key PK (if using an encrypting and a Protected Data Encryption Key PK (if using an encrypting
ciphersuite) are derived using the ciphersuite-specified KDF and data ciphersuite) are derived using the ciphersuite-specified KDF and data
skipping to change at page 10, line 30 skipping to change at page 10, line 30
inputString)[0..KS-1] inputString)[0..KS-1]
o MSK = KDF-{128+2*KS}(MK, inputString)[0..63] o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127] o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS] o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using
an encrypting ciphersuite) an encrypting ciphersuite)
The value for PL is encoded as a 2-octet integer in network byte The value for PL is encoded as a 2-octet integer in network byte
order. order.
Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires Additionally, the EAP keying framework [RFC5247] requires the
the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These
These values are defined as: values are defined as:
o zero = 0x00 || 0x00 || ... || 0x00 (KS times) o zero = 0x00 || 0x00 || ... || 0x00 (KS times)
o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type || o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString)[0..15] CSuite_Sel || inputString)[0..15]
o Session-ID = Type_Code || Method_ID o Session-ID = Type_Code || Method_ID
o Peer-ID = ID_Peer o Peer-ID = ID_Peer
o Server-ID = ID_Server o Server-ID = ID_Server
EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code
value. value.
skipping to change at page 11, line 49 skipping to change at page 11, line 49
In order to be interoperable, PSKs must be entered in the same way on In order to be interoperable, PSKs must be entered in the same way on
both the peer and server. The management interface for entering PSKs both the peer and server. The management interface for entering PSKs
MUST support entering PSKs up to 64 octets in length as ASCII strings MUST support entering PSKs up to 64 octets in length as ASCII strings
and in hexadecimal encoding. and in hexadecimal encoding.
Additionally, the ID_Peer and ID_Server MUST be provisioned with the Additionally, the ID_Peer and ID_Server MUST be provisioned with the
PSK. Validation of these values is by an octet-wise comparison. The PSK. Validation of these values is by an octet-wise comparison. The
management interface SHOULD support entering non-ASCII octets for the management interface SHOULD support entering non-ASCII octets for the
ID_Peer and ID_Server up to 254 octets in length. For more ID_Peer and ID_Server up to 254 octets in length. For more
information the reader is adviced to read Section 2.4 of RFC 4282 information the reader is advised to read Section 2.4 of RFC 4282
[RFC4282]. [RFC4282].
6. Ciphersuites 6. Ciphersuites
The design of EAP-GPSK allows cryptographic algorithms and key sizes, The design of EAP-GPSK allows cryptographic algorithms and key sizes,
called ciphersuites, to be negotiated during the protocol run. The called ciphersuites, to be negotiated during the protocol run. The
ability to specify block-based and hash-based ciphersuites is ability to specify block-based and hash-based ciphersuites is
offered. Extensibility is provided with the introduction of new offered. Extensibility is provided with the introduction of new
ciphersuites; this document specifies an initial set. The CSuite/ ciphersuites; this document specifies an initial set. The CSuite/
Specifier column in Figure 3 uniquely identifies a ciphersuite. Specifier column in Figure 3 uniquely identifies a ciphersuite.
skipping to change at page 36, line 22 skipping to change at page 36, line 22
ML on the 12th July 2006). ML on the 12th July 2006).
o Based on a review requested from NIST Quynh Dang suggested changes o Based on a review requested from NIST Quynh Dang suggested changes
to the GKDF function (December 2006). to the GKDF function (December 2006).
o Jouni Malinen and Victor Fajardo for their review in January 2007. o Jouni Malinen and Victor Fajardo for their review in January 2007.
o Jouni Malinen for his suggestions regarding the examples and the o Jouni Malinen for his suggestions regarding the examples and the
key derivation function in February 2007. key derivation function in February 2007.
o Bernard Aboba and Jouni Malinen for their review in February 2007. o Bernard Aboba and Jouni Malinen for their review in February 2007.
o Vidya Narayanan for her review in March 2007. o Vidya Narayanan for her review in March 2007.
o Pasi Eronen for his IESG review in March and July 2008. o Pasi Eronen for his IESG review in March and July 2008.
o Dan Harkins for his review in June 2008. o Dan Harkins for his review in June 2008.
o
o Joe Salowey, the EMU working group chair, provided a document o Joe Salowey, the EMU working group chair, provided a document
review in April 2007. Jouni Malinen also reviewed the document review in April 2007. Jouni Malinen also reviewed the document
during the same month. during the same month.
o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov
and Prof. John C. Mitchell for their analysis of EAP-GPSK and for and Prof. John C. Mitchell for their analysis of EAP-GPSK and for
pointing us to a client-side DoS attack, a downgrading attack and pointing us to a client-side DoS attack, a downgrading attack and
their input to the key derivation function. Based on their input their input to the key derivation function. Based on their input
the key derivation function has been modified and the text in the the key derivation function has been modified and the text in the
security consideration section has been updated. security consideration section has been updated.
o Finally, we would like to thank our working group chair, Joe o Finally, we would like to thank our working group chair, Joe
Salowey, for his support and for the time he spend on discussing Salowey, for his support and for the time he spend on discussing
open issues with us. open issues with us.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006. (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
(AES)", Federal Information Processing Standards (AES)", Federal Information Processing Standards
(FIPS) 197, November 2001. (FIPS) 197, November 2001.
[CMAC] National Institute of Standards and Technology, [CMAC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: The "Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication", Special Publication CMAC Mode for Authentication", Special Publication
(SP) 800-38B, May 2005. (SP) 800-38B, May 2005.
 End of changes. 14 change blocks. 
29 lines changed or deleted 26 lines changed or added

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