Hi Pasi,
thanks for the new round of comments.
[EMAIL PROTECTED] wrote:
Charles Clancy wrote:
See comments inline. An updated draft will be released shortly.
Also note that the new draft addresses Dan's comments about
resistance to dictionary attack.
Thanks for the update! I have some additional comments (see below),
but they should be easy to address.
S4, "EAP_Method_Type refers to the integer value of the IANA
allocated EAP Type code", "...to the EAP type code (1 byte),
specified in Section XX"?
I don't think it's ever been clear how to reference the IANA
allocated EAP type code in an I-D before it's been allocated. These
are things that would be fixed by the RFC Editor or in AUTH48, once
IANA has allocated the type code.
For clarity, I'd still suggest adding the "(1 octet)" part (although
someone reading RFC 3748 will of course figure out that it's 1 octet).
Does this sound better:
"
EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code value.
"
S6 and elsewhere: Several places in the document assume that KS
(key size of the ciphersuite) is always the same as the MAC output
length. This would make it difficult to define ciphersuites based
on e.g. AES-CMAC-256. If this restriction is intentional (and WG
is happy with it), at the very least it needs to be emphasized
much more.
I'm not sure what AES-CMAC-256 means. RFC 4493 defines CMAC
specifically for 128 length AES, so if you wanted to something
involving 256, you'd need to define exactly what AES-CMAC-256 was,
and I imagine it would have a 256-bit input and a 256-bit output.
Regardless, I added a statement in the key derivation section saying
the input and output lengths of your ciphersuite must be equal.
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.
S5 and S8.2 are not consistent about ciphersuite formatting (is
enterprise number 3 or 4 octets; if you're not sure, suggest
doing what RFC3748 did)
Fixed (should be 4).
Figure 3 in S6 still assumes it's 3.
Fixed the figure.
+------------+----+-------------+--------------+----------------+
| CSuite/ | KS | Encryption | Integrity / | Key Derivation |
| Specifier | | | KDF MAC | Function |
+------------+----+-------------+--------------+----------------+
| 0x00000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF |
+------------+----+-------------+--------------+----------------+
| 0x00000002 | 32 | NULL | HMAC-SHA256 | GKDF |
+------------+----+-------------+--------------+----------------+
S8.4, text and bit diagram are not consistent about whether
enterprise code is 3 or 4 bytes
Text consistent with length 4 enterprise code.
The 1st figure (now in S9.4) still shows 3 octets; so does the text
at end of S9.4, and IANA considerations text for PData/Specifier.
Done.
S9, "If the MAC validation fails, the server MUST transmit a
GPSK-Fail message specifying "Authentication Failure" and discard
the received packet." Not quite sure what "discard the received
packet" here exactly means in the context of EAP state machine (If
the server sends a reply, it's not discarding the packet as such).
Fixed.
It seems this text was not changed at all?
Done.
Interoperability requires the ability to enter same PSK in
both client and server. See e.g. RFC4306 S2.15 and RFC4279 S5.4
for examples of management interface requirements.
Added.
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.
Addtional comments:
S2, "PL": would help reading if it said PL must be >= KS (it's said
in S6, but this assumption is already needed in S4).
Done.
S3, should also mention GPSK-Fail and GPSK-Protected-Fail messages
for completeness (in additino to GPSK-1...4).
Ok.
S4, how is PL encoded when input to KDF? (1 octet, 2 octets?)
2 octets.
S9.3, "from the ID_Client length" -> "from the ID_Peer length"
OK
S11, GPSK-3 and GPSK-Fail are distinct message Op-Codes, so showing
e.g. "EAP-Request/GPSK-3 (GPSK-Fail (PSK Not Found or Authentication
Failure))" is confusing. Should be just "EAP-Request/GPSK-Fail ...".
OK
S12.1, the references to sections 11.* should be to 12.* (and some
of the subsection numbers don't match; e.g. channel binding is .13,
not .12).
Fixed.
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.
>From idnits:
Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
Ok.
I am going to ship an update to make sure that we capture the previously
discussed aspects.
Ciao
Hannes
Best regards,
Pasi
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
