Proposed Resolution to Issue 397: Comments

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: gwzcisco.com
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

Proposed Resolution to Issue 397: Comments

Thread: Proposed Resolution to Issue 397: Comments