draft-ietf-emu-eap-gpsk-10.txt   draft-ietf-emu-eap-gpsk-11.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: January 6, 2009 Nokia Siemens Networks Expires: January 30, 2009 Nokia Siemens Networks
July 5, 2008 July 29, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) Method EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-10 draft-ietf-emu-eap-gpsk-11
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 January 6, 2009. This Internet-Draft will expire on January 30, 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 method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method
is a lightweight shared-key authentication protocol supporting mutual is a lightweight shared-key authentication protocol supporting mutual
authentication and key derivation. authentication and key derivation.
Table of Contents Table of Contents
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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)
From this it should be noted that EAP-GSPK assumes the cipher key From this it should be noted that EAP-GSPK assumes the cipher key
input length is equal to the MAC output length. This is generally input length is equal to the MAC output length. This is generally
true of many ciphersuites, but would prevent the definition of a true of many ciphersuites, but would prevent the definition of a
ciphersuite that used a one input key length and a different output ciphersuite that used a one input key length and a different output
MAC length. MAC length. The value for PL is encoded as a 2-octet integer in
network byte order.
Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires
the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID.
These values are defined as: These 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
skipping to change at page 11, line 46 skipping to change at page 11, line 46
Figure 2: EAP-GPSK Key Derivation Figure 2: EAP-GPSK Key Derivation
5. Key Management 5. Key Management
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 a octet-wise comparison. Thus PSK. Validation of these values is by an octet-wise comparison. The
the management interface SHOULD support non-ASCII to allow entering management interface SHOULD support entering non-ASCII octets for the
values for the ID_Peer and ID_Server as ASCII strings up to 254 ID_Peer and ID_Server up to 254 octets in length. For more
octets in length. For more information the reader is adviced to read information the reader is adviced to read Section 2.4 of RFC 4282
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 25, line 13 skipping to change at page 25, line 13
Failure" and discard the received packet. Failure" and discard the received packet.
A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in
response to a GPSK-2 message MUST replay the received GPSK-Fail / response to a GPSK-2 message MUST replay the received GPSK-Fail /
GPSK-Protected-Fail message. Then, the EAP server returns an EAP- GPSK-Protected-Fail message. Then, the EAP server returns an EAP-
Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message
to correctly finish the EAP conversation. If MAC validation on a to correctly finish the EAP conversation. If MAC validation on a
GPSK-Protected-Fail packet fails, then the received packet MUST be GPSK-Protected-Fail packet fails, then the received packet MUST be
silently discarded. silently discarded.
For GPSK-3, a peer MUST silently discard messages where the For GPSK-3, a peer MUST silently discard messages where the RAND_Peer
RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those field does match the value transmitted in GPSK-2. An EAP peer MUST
transmitted in GPSK-2. An EAP peer MUST silently discard any packet silently discard any packet whose MAC fails.
whose MAC fails.
For GPSK-4, a server MUST silently discard any packet whose MAC fails For GPSK-4, a server MUST silently discard any packet whose MAC fails
validation. validation.
If a decryption failure of a protected payload is detected, the If a decryption failure of a protected payload is detected, the
recipient MUST silently discard the GPSK packet. recipient MUST silently discard the GPSK packet.
11. Example Message Exchanges 11. Example Message Exchanges
This section shows a couple of example message flows. This section shows a couple of example message flows.
skipping to change at page 34, line 24 skipping to change at page 34, line 24
implement cryptographic binding. implement cryptographic binding.
13. IANA Considerations 13. IANA Considerations
This document requires IANA to allocate a new EAP Type for EAP-GPSK. This document requires IANA to allocate a new EAP Type for EAP-GPSK.
This document requires IANA to create a new registry for This document requires IANA to create a new registry for
ciphersuites, protected data types, failure codes and op-codes. IANA ciphersuites, protected data types, failure codes and op-codes. IANA
is furthermore instructed to add the specified ciphersuites, is furthermore instructed to add the specified ciphersuites,
protected data types, failure codes and op-codes to these registries protected data types, failure codes and op-codes to these registries
as defined below. Values can be added or modified per IETF CONSENSUS as defined below. Values can be added or modified per IETF REVIEW
[RFC5226] defining either block-based or hash-based ciphersuites, [RFC5226] defining either block-based or hash-based ciphersuites,
protected data payloads, failure codes and op-codes. Each protected data payloads, failure codes and op-codes. Each
ciphersuite needs to provide processing rules and needs to specify ciphersuite needs to provide processing rules and needs to specify
how the following algorithms are instantiated: encryption, integrity, how the following algorithms are instantiated: encryption, integrity,
key derivation and key length. key derivation and key length.
Figure 3 represents the initial ciphersuite CSuite/Specifier registry Figure 3 represents the initial ciphersuite CSuite/Specifier registry
setup. The CSuite/Specifier field is 16 bits long. All other values setup. The CSuite/Specifier field is 16 bits long. All other values
are available via IANA registration. This registry should be named are available via IANA registration. This registry should be named
"EAP-GPSK Ciphersuites". "EAP-GPSK Ciphersuites".
 End of changes. 7 change blocks. 
15 lines changed or deleted 15 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/