Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.txt

From: [email-masked]
Date: Mon, 08 Jan 2007 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the EAP Method Update Working Group of the IETF.

	Title		: EAP Generalized Pre-Shared Key (EAP-GPSK)
	Author(s)	: C. Clancy, H. Tschofenig
	Filename	: draft-ietf-emu-eap-gpsk-02.txt
	Pages		: 30
	Date		: 2007-1-8
	
This Internet Draft defines an Extensible Authentication Protocol
   method called EAP Generalized Pre-Shared Key (EAP-GPSK).  This method
   is a lightweight shared-key authentication protocol supporting mutual
   authentication and key derivation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-emu-eap-gpsk-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-emu-eap-gpsk-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 8 Jan 2007 19:39:06 -0800

> 	Filename	: draft-ietf-emu-eap-gpsk-02.txt

Some comments..

General

- How long are the random values? 16 octets? 32 octets?
  * I assumed they were 32 octets (256 bits), but the draft is in
    conflict with itself..
  * 2. Terminology: 16 octets (this was 256 bits in -00)
  * 7.3. Payload Formatting: 32 octets
  * 9.4. Replay Protection: 16 octets
  * 9.8. Denial of Service Resistance: 16 octets

2.  Terminology

- MSK and EMSK were changed from 512 bits (64 octets) to 32 octets
  * Why?
  * Other EAP methods use 64 octet MSK and EMSK, so I hope this was
    just an accident and the purpose was only to move from bits to
    octets:  s/32 octets/64 octets/
  * Similar change in 4.  Key Derivation (though, that section is also
    using 64 octets.. only Figure 2 is incorrect; s/32-octet/64-octet/)

3.  Overview

- Order of CSuite_Sel and CSuite_List in GPSK-2 was reversed
  * Why?
  * 7.3.  Payload Formatting is still using the previous order, i.e.,
    CSuite_List before CSuite_Sel; in other words, there is now conflict
    between sections 3 and 7.3 on the order of these fields

5.  Ciphersuites

- definitions of GKDF-X(Y, Z) was changed, but some cleanup missing
  * 'X' is not used anymore as an input to hash function and because
    of this, there is no need to say that it is repredsented as a
    2-octet value in network byte order:
    s/'i' and 'X' in M_i are represented as 2-octet values/
      'i' is represented as 2-octet value/

6.1.1.  Encryption

- CBC is mentioned to require an IV
  * However, there is no definition on where this IV is coming from or
    how it is to be transmitted to the other party
  * How exactly is this supposed to work?

8.  Packet Processing Rules

- typo: s/receving/receiving/

- "(i.e. an EAP client receiving GPSK-3 before receving GPSK-1 or before
   transmitting GPSK-2)"
  * isn't that more of an example (e.g.) than the only possible case
    (i.e.)?
  * s/i.e./e.g./

- "GPSK-1 contains no MAC protection, so provided it properly parses, it
  MUST be accepted by the client."
  * MUST??
  * What if CSuite_List in GPSK-1 does not include any supported
    cipher?

- s/EAP-NACK/EAP-Nak/ to match with "Nak" spelling in RFC 3748

- "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in
  response to a GPSK-2 message MUST either transmit an EAP-Failure
  message and end the session"
  * Success and Failure messages are sent by authenticator, not
    peer
  * This should probably be changed to say that client (peer) is sending
    back GPSK-Fail / GPSK-Protected-Fail, not EAP-Failure, to
    acknowledge failure; this will be followed by the authenticator
    sending EAP-Failure

- "For GPSK-3, a client MUST silently discard any packet containing
  whose RAND_Client, RAND_Server, or CSuite_Sel fields do match those
  transmitted in GPSK-2."
  * There's something wrong with this sentence..
    s/whose //
    s/do match/that do not match/

9.4. Replay Protection

- typo: s/RAND_P/RAND_Client/

9.8. Denial of Service Resistance

- typo: s/RAND_S/RAND_Server/

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 8 Jan 2007 20:09:13 -0800

> > 	Filename	: draft-ietf-emu-eap-gpsk-02.txt

And one more..

5.  Ciphersuites

GKDF-X(Y, Z) was modified to use "Hash-Function" instead of MAC_Y.
However, there does not seem to be any definition on which hash function
is used here.. SHA-1 is mentioned as a required function and "SHAs" are
recommended (whatever that means; SHA-256 and friends?), but the
ciphersuite does not include information on which hash function is to be
used here. Previously, this was covered by the "Integrity" column of
Figure 3. Should the ciphersuite table be extended to define the hash
function for GKDF now?

In addition, this "SHA-1" here is the only need use of SHA-1 for
EAP-GPSK. Do we really need it? Was this done because of possible NIST
issues with the use of AES-CMAC for KDF?

---

From: Charles Clancy <[email-masked]>
Date: Tue, 09 Jan 2007 07:19:31 -0500

Jouni,

In the last draft I tried to make all the terminology consistent by 
using octets for everything instead of bits and bytes.  Apparently I 
can't properly divide by 8, and introduced a bunch of inconsistencies.

Thanks for all your additional comments.  We'll try to get them all 
resolved ASAP.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy