Subject: [HOKEY] WGLC comments for erx-05

From: <[email-masked]>
Date: Mon, 29 Oct 2007 14:57:01 +0200

Some comments about draft-ietf-hokey-erx-05 (disclaimer: I haven't
followed this spec recently, so some of these might be just
things I didn't understand):

S4.1.1, "S = rRK Label + "\0" + NULL + length". Is this
intentionally two nulls?

S4.1.1/4.1.3: does "prf-64" mean first 64 bits of "prf(K,S)" 
or the first 64 bits of "prf+(K,S)"?

Terminology: the term "rIKname" is used to refer to two separate 
(but related) data elements. suggest using two different
names instead (e.g. "rIKname" and "rIKname-NAI").

S5.3.1, "The computed rIKname itself serves as the username part 
of the NAI".  The computed rIKname may contain octets that are
invalid/troublesome in a NAI. Hexadecimal or Base64 encoding,
perhaps?

S5.3.2, Why does the EAP Finish Re-auth packet contain the peer's 
NAI? Or should it contain Server-ID instead?

S5: What is the relationship between the rIKname sent in the Initiate
message, and the one received in the Finish message?  (Are they
supposed to be the same? Is the peer expected to use the latter one
when sending the next Initiate message? Or something else?)

S5.3.1, "This field contains the integrity checksum over the ERP
packet." This should be more specific about what data is covered
(e.g. "The ERP packet" could mean the whole packet, including the
Authentication Tag?)

S6, The list of requirements here does not match exactly the list in
RFC 4962; the differences should be at least explained.

S6, "Authenticate all parties": The local ER server and the ER
Authenticator are also parties that should be considered.

S6, Peer-ID privacy: the security considerations section should
note that ERX exposes the Peer-ID over the wire.

General: The document should explain what is the relationship (if any)
between the ERX peer-ID and the Peer-ID exported by the EAP method
(and likewise for Server-ID).

S7, suggest adding slightly more information to help IANA (see
e.g. "What To Put In Documents That Create A Registry" section 
of draft-narten-iana-considerations-rfc2434bis).

General: The document does not seem to specify how DSRKs are derived;
this looks like a missing normative reference (+ missing details
on what particular data item from ERX messages is used and how).

General: What's the reason for specifying three different variants 
of HMAC-SHA256 with different authentication tag lengths? (Just
saving a couple of bytes in packet size, or something else?)

General: The document uses terms such as "EAP Session-ID" without
citing a document that defines them (i.e., eap-keying draft).

Best regards,
Pasi

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey