draft-ietf-emu-eap-gpsk-13.txt   draft-ietf-emu-eap-gpsk-14.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 18, 2009 Nokia Siemens Networks Expires: April 19, 2009 Nokia Siemens Networks
October 15, 2008 October 16, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) Method EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-13 draft-ietf-emu-eap-gpsk-14
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 18, 2009. This Internet-Draft will expire on April 19, 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 3, line 4 skipping to change at page 3, line 4
12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30 12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30
12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30 12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30 12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30
12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30 12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30
12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 31 12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 31
12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31 12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31
12.10. Session Independence . . . . . . . . . . . . . . . . . . 31 12.10. Session Independence . . . . . . . . . . . . . . . . . . 31
12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32 12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32
12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32 12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32
12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32
12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 32 12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 33
12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33 12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33
12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33 12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33
12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33 12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 34
12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34 12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 36
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.
The client has to keep state information after receiving the GPSK-1 For GPSK-3, a peer MUST silently discard messages where the RAND_Peer
message. To prevent a replay attack, all the client needs to do is field does match the value transmitted in GPSK-2. An EAP peer MUST
to ensure that the value of RAND_Peer is consistent between GPSK-2 silently discard any packet whose MAC fails.
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.
skipping to change at page 31, line 36 skipping to change at page 31, line 36
number of EAP-GPSK communication attempts. An EAP server may number of EAP-GPSK communication attempts. An EAP server may
therefore ensure that established state times out after a relatively therefore ensure that established state times out after a relatively
short period of time when no further messages are received. This short period of time when no further messages are received. This
enables a sort of garbage collection. enables a sort of garbage collection.
The client has to keep state information after receiving the GPSK-1 The client has to keep state information after receiving the GPSK-1
message. To prevent a replay attack, all the client needs to do is message. To prevent a replay attack, all the client needs to do is
to ensure that the value of RAND_Peer is consistent between GPSK-2 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- and GPSK-3. Message GPSK-3 contains all the material required to re-
compute the keying material. Thus, if a client chooses to implement compute the keying material. Thus, if a client chooses to implement
this client-side DoS protection mechanism it only needs to maintain this client-side DoS protection mechanism it may manage RAND_Peer and
minimal state (RAND_Peer) between GPSK-2 and GPSK-3. CSuite_Sel on a per-server basis for servers it knows instead of on a
per-message basis.
Attacks that disrupt communication between the peer and server are Attacks that disrupt communication between the peer and server are
mitigated by silently discarding messages with invalid MACs. Attacks mitigated by silently discarding messages with invalid MACs. Attacks
against computational resources are mitigated by having very light- against computational resources are mitigated by having very light-
weight cryptographic operations required during each protocol round. weight cryptographic operations required during each protocol round.
The security considerations of EAP itself, see Section 5.2 and The security considerations of EAP itself, see Section 5.2 and
Section 7 of RFC 3748 [RFC3748], are also applicable to this Section 7 of RFC 3748 [RFC3748], are also applicable to this
specification (e.g., for example concerning EAP-based notifications). specification (e.g., for example concerning EAP-based notifications).
 End of changes. 7 change blocks. 
16 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/