Subject: [eap] Proposed Resolution to Issue 397: Comments

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 06 May 2007 13:55:27 -0700

The text of Issue 397 is enclosed below.

The proposed resolution is as follows:

In Section 1.2, change:

"authenticator
     The end of the link initiating EAP authentication.  The term
     Authenticator is used in [IEEE-802.1X], and authenticator has the
     same meaning in this document."

To:

"authenticator
     The entity initiating EAP authentication."

Change:

"peer
The end of the link that responds to the authenticator."

To:

"peer
The entity that responds to the authenticator."

-------------------------------
Issue 397: Comments
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date Submitted:  March 4, 2007
Reference: http://lists.frascone.com/pipermail/eap/msg04621.html
Document: KEYING-18
Comment type: Technical
Priority: S
Section: 1.2
Rationale/Explanation of issue:

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.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 07 May 2007 08:19:02 -0700

Given that these definitions are also used in RFC 3748, I think that if this 
proposed change is accepted that "Updates: 3748" probably needs to be added.

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked]
>Subject: [eap] Proposed Resolution to Issue 397: Comments
>Date: Sun, 06 May 2007 13:55:27 -0700
>
>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
>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.
>
>