Comments on Section 1.2 of draft-ietf-eap-keying-18.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: Comments on Section 1.2 of draft-ietf-eap-keying-18.txt

I apologize for the tardiness of these comments: I planned to send this email over a week ago but I experienced some computer issues ;-).

The definitions of both "authenticator" and "peer" refer to these as 'end of the link'; this seems just a bit too vague to me (after all, what's at the "end of a link" is usually a transceiver, right, which is generally neither an authenticator nor a peer ;-): I would prefer to see them referred to at least as entities. For example:

"authenticator
     The entity initiating EAP authentication…"
&
"peer
     The entity that responds to the authenticator."

Although this change clarifies slightly the nature of the EAP peer and authenticator, it may require the rethinking of some other definitions.  For example, see the definition of "Secure Association Protocol" later in this section: only if "peer" & "authenticator" are defined in the original (vague) manner can this definition be accurate, since the entities involved in the 802.11i 4-way handshake are, I think, quite different from the EAP entities.  In general, the consumers/users of the keys that may be generated as a side-effect of EAP authentication are not identical to the EAP entities, however, a fact that seems to be if not lost then at least glossed over in this document.  Further  examples can be found in the definitions of "Transient EAP Keys (TEKs)", where the EAP peers are presumed to continue sending & receiving encrypted data after authentication is complete(!) and "Transient Session Keys (TSKs)", where the EAP peers negotiate a ciphersuite for this purpose.  Although I don't think it's prohibited for EAP methods to negotiate ciphersuites for subsequent use _by other protocols_ (such as 802.11i, etc.), I don't know of any that do & I don't think that that is what is meant in this definition: it is only the rather IMHO sloppy use of the terms "authenticator" and "peer" to mean, basically, "whatever is hanging off the ends of the wire" that allows this usage.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]