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
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
Sent: 29 July, 2008 14:42
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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
[EMAIL PROTECTED] 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
