Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)

Pasi,

This state-minimization approach was proposed by the Stanford security 
review.  In earlier versions of the draft, CSuite_Sel and RAND_Server 
were not included in GPSK-3, and were not verified.  I'm not sure why 
the language you referenced below got updated after they were added to 
GPSK-3.

All -- Does anyone in the WG object to this change?

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Pasi.Eronen@nokia.com wrote:
> Charles,
> 
> Thanks for the update! There's one change I'm slightly worried 
> about:
> 
> Version -10:
>    For GPSK-3, a peer MUST silently discard messages where the
>    RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match 
>    those transmitted in GPSK-2.
> 
> Version -11:
>    For GPSK-3, a peer MUST silently discard messages where the 
>    RAND_Peer field does match the value transmitted in GPSK-2. 
> 
> I guess the security analysis of GPSK was performed assuming
> the peer does check RAND_Server and CSuite_Sel? 
> 
> While I can't come up with any attack even if this check is
> omitted (e.g., RAND_Server and CSuite_Sel are still included 
> in MK derivation), is the whole WG comfortable with this change?
> (I didn't see any discussion about this topic yet.)
> 
> Best regards,
> Pasi
> 
>> -----Original Message-----
>> From: ext Charles Clancy [mailto:tcc@umd.edu] 
>> Sent: 29 July, 2008 14:42
>> To: Eronen Pasi (Nokia-NRC/Helsinki)
>> Cc: Hannes.Tschofenig@gmx.net; clancy@cs.umd.edu; emu@ietf.org
>> Subject: Re: Review of draft-ietf-emu-eap-gpsk-08 (1st round 
>> of comments)
>>
>> Pasi,
>>
>> I've submitted an update that addresses the ASCII text garbling, PL 
>> encoding, packet validation inconsistencies, and IANA policies.  All 
>> that remains is the key/MAC-length issue.
>>
>> --
>> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
>> electrical & computer engineering, university of maryland
>>
>>
>> Pasi.Eronen@nokia.com wrote:
>>> Hannes Tschofenig wrote:
>>>
>>>>> As Dan Harkins already pointed out, NIST 800-38B does define CMAC 
>>>>> for 256-bit AES, with 256-bit key and 128-bit output.
>>>>>
>>>>> So hardcoding this assumption in EAP-GPSK seems to limit 
>> the future
>>>>> algorithm agility somewhat -- is the WG sure this is an acceptable
>>>>> limitation?
>>>>>
>>>>> (If this limitation is kept, I'd suggest mentioning in Section 2
>>>>> that "KS" is not only the key size, but also MAC output length.)
>>>> This seems to require a separate discussion on the list.
>>> Ok -- please let me know once you think the discussion has
>>> concluded.
>>>
>>>>> The text (Section 5) should probably say something about non-ASCII
>>>>> characters, especially since NAIs can contain them (and IETF
>>>>> policies usually require dealing with non-ASCII in strings handled
>>>>> by ordinary users -- RFC4306/4279 are probably mostly for admins).
>>>>>
>>>>> Maybe "SHOULD support non-ASCII", with pointer to detailed 
>>>>> instructions in Section 2.4 of RFC 4282?
>>>> Fixed.
>>> It seems this update got garbled somehow -- at least I have some
>>> difficulties in parsing the new text:
>>>
>>>    Thus the management interface SHOULD support non-ASCII to allow
>>>    entering values for the ID_Peer and ID_Server as ASCII strings up
>>>    to 254 octets in length.
>>>
>>>>> S4, how is PL encoded when input to KDF? (1 octet, 2 octets?)
>>>>    
>>>> 2 octets.
>>> The text in Section 4 should say so.
>>>
>>>>> S12.9: the text about minimal state (only RAND_Peer) seems
>>>>> inconsistent with S10, which requires discarding GPSK-3 if the
>>>>> RAND_Server and CSuite_Sel fields are not the same as in GPSK-2.  
>>>>> To make that comparison, it seems you need to store the 
>> values after
>>>>> sending GPSK-2?
>>>>   
>>>> I added text on this issue. I am not fully sure whether it resolves
>>>> the aspect entirely though.
>>> Not really -- the text in Section 12.9 seems to say that doing
>>> the comparison (of RAND_Server and CSuite_Sel) can be omitted,
>>> but it's a MUST in Section 10. These two sections need to be
>>> consistent.
>>>  
>>>>> >From idnits: 
>>>>> Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
>>>> Ok.
>>> The names of the pre-defined IANA policies were also 
>> slightly changed,
>>> so Section 13 needs some small updates.
>>>
>>> Best regards,
>>> Pasi
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu