Subject: [eap] Re: Issue 52: Identity requery

From: [email-masked] (Bernard Aboba)
Date: Thu, 2 Jan 2003 10:18:07 -0800 (PST)

Question: Are you also asserting that a new method can be started prior to
completion of a previous method? I think that the state machine
document assumes that this is not possible (which lead to the restriction
on Identity, too).

Issue 52: Identity requery
Submitter name: James Carlson
Submitter email address: [email-masked].
Date first submitted: January 2, 2003
Document: RFC2284bis
Comment type: T
Priority: 1
Section: 5.1
Rationale/Explanation of issue:

The restriction doesn't appear to be warranted. There's no visible
difference between, for example, an authenticator suddenly deciding to
start authentication over because the current method cannot proceed
(which should be allowed), and sending an Identity message in the
"middle" of a method (which has been proscribed). Since there's no
distinction, the requirements can't be different.

Requested change:

from:

The Identity Type is used to query the identity of the Peer. The
Authenticator will typically issue this as the initial Request;
however, an Identity Request MAY also be sent multiple times within a
sequence of methods. An Identity Request MUST NOT be sent in the
middle of another method conversation.

to:

The Identity Type is used to query the identity of the Peer. The
Authenticator will typically issue this as the initial Request;
however, an Identity Request MAY be sent at any time.

---

From: [email-masked] (James Carlson)
Date: Thu, 2 Jan 2003 14:55:27 -0500

> document assumes that this is not possible (which lead to the restriction

I'm saying that stating this as a restriction on the authenticator
doesn't make sense to me.  Suppose the authenticator wants to give up
on the currently running method (due, perhaps, to compatibility
problems with the peer) and decides to try an alternative method.
Does the authenticator need to provide any notification to the
authenticatee that it wants to start over?  Would that notification
need to be anything more than a Request message with a new Type value?

Or is the authenticator "forced" to continue with the current method,
even if continuation is infeasible?

I'm not saying that it makes sense to have multiple concurrent methods
running at one time.  But it also doesn't make sense to me to say that
the authenticator needs to be limited in any way in its choice of
Request messages to send.  The original EAP model seemed much simpler
to me: the authenticator is the master, and the authenticatee is a
slave.  The authenticatee must respond to requests it gets at best it
can, and can't be in the business of predicting the future.

If there's some concern about fully documenting how to *implement* an
authenticatee (though I don't think there should be), then language
like this might work:

	Other than Type 2 (Notification), which is unrelated to the
	operation of any authentication method, and Type 3 (Nak),
	which is used in a session operating in the opposite
	direction, an authenticatee receiving any Type number that
	differs from the previous Type number may assume (e.g., for
	purposes of allocating transient storage) that the method
	indicated by any previous Type number received has concluded.

I don't think this is actually required for proper operation, though.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677