Subject: [eap] Issue 7: Ability to authenticate with multiple methods not specified

From: [email-masked] (Bernard Aboba)
Date: Sun, 6 Oct 2002 08:35:39 -0700 (PDT)

Issue 7: Ability to authenticate with multiple methods one after another
not specified
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 2, 2002
Reference:
Document: RFC2284bis-01
Comment type: T
Priority: S
Section: 2

Rationale/Explanation of issue:

RFC 2284 does not explain how to authenticate with multiple authentication
methods one after another.

Resolution:

Add the following text to Section 2:

"An Authenticator MAY authenticate the Peer using a sequence of methods.
A common example of this is an Identity request followed by an EAP
authentication method such as MD5-Challenge.

To accomplish this, the Authenticator and Peer first complete an EAP
exchange involving the initial method, with a matching EAP type field
included in both Request and Response packets.

If the initial authentication method completes unsuccessfully, then the
Authenticator sends a Failure packet to the peer. If it completes
successfully, and additional authentication methods are required, the
Authenticator will send a Request packet for a subsequent
authentication method. The Peer will then respond with a Response packet
containing a type field matching the Request.

The sequence of authentication methods proceeds until either an
authentication method fails (in which case the Authenticator sends a
Failure packet to the peer) or the final authentication method completes
successfully, in which case the Authenticator sends a Success packet to
the peer."

Comment by Bryan Payne:

> > The state machine allows the authenticator to send a new ID request
before
> > each Auth request if it wants to. This is because each auth request
may
> > be associated with a different identity.
>
> Only if the Type code changes, right?

Ahh yes, I'm glad that you brought this up. I can't find anything about
this in the RFC. The closest thing that I can find is in "step 1" of
section 2 (2284bis-03) where it is giving an overview of the protocol.

So the answer to your question is "I don't know". There is no mention of
the ID request only being allowed at this point in time. As I read the
RFC, the authenticator could send identity requests over and over. Yes,
this would be pointless...and that's why Nick and I drew the state machine
to at least require ID, Auth, ID, Auth requests or Auth, Auth, ID, Auth,
etc (because ID, ID, ID just doesn't make sense). Basically, I think that
it makes sense to say that all ID requests will be followed by an auth
request...and that ID requests are not required. I feel that this is
captured in the state machine pretty well.

Perhaps the RFC should be more specific in dealing with this issue?

-bryan

Notes from Bernard Aboba:

Yet another question has arisen as to what happens when, in
the middle of one EAP method, a Peer receives a Request for
a completely different EAP method. Does it silently discard
the packet? Call the new EAP method while leaving the
old one suspended? Nak the new method with the Type of
the previous one? Is this illegal?

Also, are there some methods which must be the last method
in a sequence? For example, what if the last packet sent
within a method is not an EAP Success/Failure, but an
EAP Request (say, encapsulating an encrypted Success/Failure).
How can another method come after that one, since there will
be no EAP Response to continue the conversation? And how
can a final EAP Success/Failure ever be sent?