All,
We've put together an update to the GPSK draft to address the last call
comments. Below is a list of the identified issues and their solutions.
For a variety of issues we recommended no change with a brief
description. If more detail is desired, we can certainly discuss them
further on the list.
You can find the latest version here, pending the I-D editor's release:
http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-04.txt
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
-----------
TECHNICAL
-----------
Issue: why not use EAP-TLS-PSK instead (narayanan)
Resolution: no change -- WG consensus was to do GPSK
Issue: MAC does not cover the EAP or GPSK header (Dondeti, Narayanan)
Resolution: no change -- protecting the EAP header is pointless, since
the EAP engine would not be able to validate the MAC. The
GPSK header only includes an op-code, which can be
implicitly checked by validating the MAC on the rest of the
packet contents.
Issue: use of SHA-1 (Aboba)
Resolution: switched AES ciphersuite to use SHA256
Issue: KDFs do not appear compliant with draft-dange-nistkdf-01 (Aboba)
Resolution: no change, NIST reviewed our KDF, and the current one is
based specifically on their recommendations
Issue: Why doesn't the MK derviation use the PSK as it's keying input,
instead of all zeros? (Dondeti)
Resolution: no change -- The PSK can be of arbitrary length, and
therefore may not be the correct length to use as the KDF
input key.
Issue: revert to previous KDF based on MACs (Dondeti, Narayanan)
Resolution: no change -- the KDF changes from MAC to Hash were
proposed by NIST
Issue: Use of CTR instead of CBC to avoid implementing AES decryption
code (Dondeti)
Resolution: no change -- we discussed this at length, CTR does its
own integrity protection, which would be redundant, hence
the decision to use CBC instead
Issue: dropping nonparsable packets is EAP behavior (Narayanan)
Resolution: changed to talk about parsing EAP-GPSK packets, rather than
EAP packets
Issue: derive keys individually rather than deriving a big block
and then split it up (Narayanan)
Resolution: no change -- places fewer restrictions on the KDF, and
guarantees cryptographic independence
Issue: derivation of PK when not using an encryption Ciphersuite
(Narayanan)
Resolution: removed PK from hash ciphersuite discussion, added other
comments indicating it's lack of necessity for
non-encrypting ciphersuites
-----------
EDITORIAL
-----------
Issue: citing old drafts (Malinen)
Resolution: moot, as references were removed
Issue: s/needs to instantiated/needs to be instantiated/ (Malinen)
Resolution: text edited
Issue: discussion of other protocols and deficiencies (Aboba)
Resolution: section removed
Issue: quick availability as a design goal (Aboba)
Resolution: text edited
Issue: design goal s/Wide Applicability/Security Model/ (Aboba)
Resolution: text edited
Issue: efficiency design goal, mention round trips (Aboba)
Resolution: text edited
Issue: efficiency design goal, mention Privacy not supported (Aboba)
Resolution: no change -- privacy supported if AES ciphersuite is used
Issue: define peer/server/session-ID (Aboba)
Resolution: defined
Issue: ambiguous definition of KS with respect to hashes (Dondeti)
Resolution: removed ambiguous text
Issue: erronious references to multiple protected payload blocks (Dondeti)
Resolution: fixed some references -- others referred to them as plural
as you can have a total 3 in the entire protocol exchange
Issue: order of key definitions in terminology section (Dondeti)
Resolution: changed the order to be alphabetical -- not quite what was
proposed, but logical IMHO
Issue: precision of some of the protocol specification (Dondeti)
Resolution: made some minor edits
Issue: GPSK-4 is needed only as a filler, specify that (Dondeti)
Resolution: no change, GPSK-4 can contain a PD_Payload_Block
Issue: Text involving validation of keys after GPSK-4 (Dondeti)
Resolution: text revised
Issue: discussion of MACs in KDF section (Dondeti)
Resolution: text replaced
Issue: instead of length(Csuites_List) use NumberOf_CSuites to save
one byte (Dondeti)
Resolution: no change -- using a 2-byte length makes parsing code
consistent across all length-prefixed data blocks
Issue: EAP terminology renamed (Narayanan)
Resolution: s/client/peer/g
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
