draft-ietf-emu-eap-gpsk-12.txt   draft-ietf-emu-eap-gpsk-13.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 4, 2009 Nokia Siemens Networks Expires: April 18, 2009 Nokia Siemens Networks
October 1, 2008 October 15, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) Method EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-12 draft-ietf-emu-eap-gpsk-13
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 4, 2009. This Internet-Draft will expire on April 18, 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 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 RAND_Peer The client has to keep state information after receiving the GPSK-1
field does match the value transmitted in GPSK-2. An EAP peer MUST message. To prevent a replay attack, all the client needs to do is
silently discard any packet whose MAC fails. to ensure that the value of RAND_Peer is consistent between GPSK-2
and GPSK-3. Message GPSK-3 contains all the material required to re-
compute the keying material. Thus, if a client chooses to implement
this client-side DoS protection mechanism it may manage RAND_Peer and
CSuite_Sel on a per-server basis for servers it knows instead of on a
per-message basis.
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.
 End of changes. 4 change blocks. 
7 lines changed or deleted 12 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/