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

[Jouni Malinen <jkmaline at cc.hut.fi>]

On Mon, Jan 08, 2007 at 03:50:02PM -0500, Internet-Drafts at ietf.org 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?
  * 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

_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu