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

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 Feb 2007 13:36:42 -0500

Hi Jouni,

I am currently working on the draft update. A few short responses below:

Jouni Malinen wrote:
> On Mon, Jan 08, 2007 at 03:50:02PM -0500, [email-masked] wrote:
>
>   
>> 	Title		: EAP Generalized Pre-Shared Key (EAP-GPSK)
>> 	Author(s)	: C. Clancy, H. Tschofenig
>> 	Filename	: draft-ietf-emu-eap-gpsk-02.txt
>>     
>
> Some comments..
>
> General
>
> - How long are the random values? 16 octets? 32 octets?
>   
As indicated by Charlesthis is a bug.

>   * 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)
>   
changed to 32 octets

>   * 7.3. Payload Formatting: 32 octets
>   
Untouched.

>   * 9.4. Replay Protection: 16 octets
>   
changed to 32 octets
>   * 9.8. Denial of Service Resistance: 16 octets
>   
changed to 32 octets
> changed to 32 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/
>   

Changed to 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/)
>
>   
Changed figure.

> 3.  Overview
>
> - Order of CSuite_Sel and CSuite_List in GPSK-2 was reversed
>   * Why?
>   
No clue.

>   * 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
>
>   
Changed the order in Section 3.

> 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/
>
>   
Here is the definition of GKDF-X(Y, Z):

------------

GKDF-X (Y, Z) {

n = ceiling integer of ( X / hashlen );
   /* determine number of output blocks */

M_0 = "";
result = "";

for i = 1 to n {
  M_i = Hash-Function (i || y || Z);
  result = result || M_i;
}

return truncate (result; X)
}

------------

The value of X is used to compute n. 

I suggest not to change anything. 

> 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?
>
>
>   
That's a good point. More text is indeed needed.

> 8.  Packet Processing Rules
>
> - typo: s/receving/receiving/
>
>   
Fixed.

> - "(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./
>   

You are right. This is an example.

> - "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?
>   
The mandatory-to-implement ciphersuite will always have to be included.

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

> - "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
>   
Fixed.
Victor made the same comment.

> - "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/
>   
Fixed.

>
> 9.4. Replay Protection
>
> - typo: s/RAND_P/RAND_Client/
>
>   
Fixed.

> 9.8. Denial of Service Resistance
>
> - typo: s/RAND_S/RAND_Server/
>
>   
Fixed.

Ciao
Hannes

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu