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

From: [email-masked]
Date: Wed, 18 Oct 2006 15:50:02 -0400

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-00.txt
	Pages		: 29
	Date		: 2006-10-18
	
   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-00.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-00.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-00.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: Sat, 21 Oct 2006 10:43:26 -0700

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

While updating my implementation to the new draft, I noticed couple of
conflicts in how the key derivation is defined. Chapter 4 uses
KDF_Zero-String(PL || PSK | ...) to derive MK whereas 6.1.8 and 6.2.8
use GKDF-#(PSK, ...). I would assume that the version in 6.1.8 and 6.2.8
is the correct one and chapter 4 should be updated to match with this.

Another difference is in whether CSuite_Sel is to be included in the
GKDF data field. Chapter 4 seems to include it (just before
inputString), but 6.1.8 and 6.2.8 do not. Should it be there or not?

The new draft is trying to fix the GKDF-X n (number of output blocks)
calculation, but that seems to have a typo of some sort.

Now:  n = int( X / size - 1 ) + 1;

That doesn't make any sense since -1 and +1 are are cancelling eachother
and we are left with n = int( X / size ).

I would assume that this was supposed to be taken into account rounding
up (ceiling) by using n = int( (X + size - 1) / size ) which could be
written as n = int( (X - 1) / size ) + 1.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: "Charles Clancy" <[email-masked]>
Date: Thu, 26 Oct 2006 14:04:58 -0400 (EDT)

Jouni,

Actually, the descriptions in chapter 6 are incorrect, and need be fixed
to reflect the changes in chapter 4.

The KDF in chapter 4 was changed to allow PSKs of variable length and
entropy.  Using the PSK to directly key the KDF to generate the MK has
problems because most KDFs have fixed-length inputs for keys.  Imagine
someone who uses a 50-character passphrase (English text has around 2.5
bits of entropy per character, so that's roughly a 128-bit secure key). 
If we follow what's currently in chapter 6, we truncate that to 16 bytes,
which would only be 40 bits of security.  Not a good thing.

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

---

From: Jouni Malinen <[email-masked]>
Date: Sat, 28 Oct 2006 09:27:59 -0700

> to reflect the changes in chapter 4.

OK.

> which would only be 40 bits of security.  Not a good thing.

Only with Ciphersuite 1.. Ciphersuite 2, i.e., HMAC-SHA256, should be
able to handle arbitrary length keys.

Does the following change match with your understanding?

In 6.1.3, replace

   MK = GKDF-16 (PSK[0..15], RAND_Client || ID_Client || RAND_Server ||
   ID_Server)

with

   MK = GKDF-16 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client ||
   ID_Client || RAND_Server || ID_Server)

(I did not find definition for how PL is to be represented here. Is it
enough to limit to PSKs of up to 255 octets and define PL to be one
octet?)

In 6.2.3, replace

   MK = GKDF-32 (PSK, RAND_Client || ID_Client || RAND_Server ||
   ID_Server)

with

   MK = GKDF-32 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client ||
   ID_Client || RAND_Server || ID_Server)

(Same comment about PL)

As an alternative, this could be

   MK = GKDF-32 (PSK, CSuite_Sel || RAND_Client || ID_Client ||
   RAND_Server || ID_Server)

since HMAC-SHA256 should have no problems with variable length PSK.

By the way, is the definition of Zero-String (KS octets of 0x00) really
suitable for Ciphersuite 2? Why bother generating a sequence of 32
octets of 0x00 for HMAC-SHA256 key (which could as well be zero-length).