Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure?

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 11:16:20 -0800 (PST)

> If I understand this comment, you are saying that one could fail a method
> and not send a failure? Maybe this has changed, but I thought prior
> conversations ruled this out. I have searched through the esteem doc and
> the EAP issues, but I am having trouble finding the resolution.

I've opened Issue 59 to deal with this.

Issue 59: Failed authentication and EAP Failure
Submitter name: Nick Petroni
Submitter email address: [email-masked]
Date first submitted: January 7, 2003
Document: RFC2284bis-08
Comment type: T
Priority: S
Section: 2
Rationale/Explanation of issue:

Section 2 says:

[6] The sequence of authentication methods proceeds until either an
authentication method fails (in which case the Authenticator sends
an EAP Failure packet to the Peer) or the final authentication
method completes successfully, in which case the Authenticator
sends an EAP Success packet to the Peer.

Is this always true? Is it possible for a failed authentication to result
in a Success? Maybe this has changed, but I thought prior
conversations ruled this out. I have searched through the esteem doc and
the EAP issues, but I am having trouble finding the resolution.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 11:22:42 -0800 (PST)

Here's what RFC 2284 has to say about this:

Section 2.2.2

      If the authenticator cannot authenticate the peer (unacceptable
      Responses to one or more Requests) then the implementation MUST
      transmit an EAP packet with the Code field set to 4 (Failure). An
      authenticator MAY wish to issue multiple Requests before sending a
      Failure response in order to allow for human typing mistakes.

So while multiple Requests are possible, if the authenticator cannot
authenticate the Peer, RFC 2284 doesn't leave much room for interpretation
-- a Failure MUST be sent.

---

From: [email-masked] (James Carlson)
Date: Tue, 7 Jan 2003 15:35:14 -0500

> the EAP issues, but I am having trouble finding the resolution.

Wouldn't this be an internal implementation detail?  Whether the
authentication method itself has "failed" or not is known only to the
authenticator; the only information that the authenticatee has is
whether it has gotten the EAP Success or EAP Failure message.

I don't think the document really needs to describe internal
implementation details.  The most obvious implementation is one in
which each method must succeed ("logical AND") in order for the
authenticator to send a Success message, but since this is entirely
determined by the implementation itself, I don't see why other
possible choices should be excluded.

To the extent that there's a state machine document, I think it ought
to restrict itself to the items necessary to produce the messages on
the wire, and not those that are quirks of policy.

One possible way out of the problem would be to define four outputs
from the method:

	- "Continue to next method, if any.  Fail if no next method."
	- "Continue to next method, if any.  Succeed if none left."
	- "Fail now."
	- "Succeed now."

Obviously, this could get arbitrarily complex ...

-- 
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

---

From: [email-masked] (James Carlson)
Date: Tue, 7 Jan 2003 15:37:31 -0500

> -- a Failure MUST be sent.

The RFC (rightly, in my opinion) doesn't distinguish between a single
method returning failure and the *authenticator* itself returning
failure.  The two are not necessarily the same.  Once the
authenticator has determined that there is failure, I agree that it
must send the Failure message.  The question of how it determines
"failure" (whether that's the failure of some crucial method, the
joint failure of multiple methods, or even the success of a "bad"
method) is not specified.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 11:44:38 -0800 (PST)

How about this:

[6] The sequence of authentication methods proceeds until the
authenticator cannot authenticate the peer (unacceptable
Responses to one or more Requests), in which case the
implementation MUST transmit an EAP packet with the Code field
set to 4 (Failure). Alternatively, the authentication sequence
can continue until the authenticator determines
that successful authentication has occurred, in which case the
authenticator MUST transmit an EAP packet with the
Code field set to 3 (Success).

---

From: [email-masked] (James Carlson)
Date: Tue, 7 Jan 2003 16:01:55 -0500

> Code field set to 3 (Success).

That looks good to me.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 7 Jan 2003 16:02:56 -0500

I agree with James.  I also have an impression that text [6] 
is specifying too much, while one important purpose of EAP is to 
provide flexibility in authentication.  

Yoshihiro Ohba

On Tue, Jan 07, 2003 at 03:35:14PM -0500, James Carlson wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Hao Zhou)
Date: Tue, 7 Jan 2003 16:46:46 -0500

I agree.

The current 2284bis doesn't distinguish FAILURE and SUCCESS from individual
method and the final one from Authenticator, which makes it hard to support
sequence of EAP methods.

I assume it is preferred that the existing EAP methods will require no
change to be supported for sequences. They currently send out EAP-SUCCESS
and EAP-FAILURE by themselves. On the other end, authenticator sometimes
send out "canned " SUCCESS and FAILURE messages after receiving
Accept/Reject from the server [IEEE8021X]. Obviously, we need to distinguish
those two types of success and failure to continue the sequence.

I wonder if extending the EAP-SUCCESS and EAP-FAILURE message to include a
EAP method type would solve this.

There would be two types of EAP-SUCCESS and FAILURE:
1. The current EAP-SUCCESS and EAP-FAILURE with no data to indicate final
success and failure;
2. The extended EAP-SUCCESS and EAP-FAILURE include extra eap method type to
indicate individual eap method success and failure. Without requiring
changes in the existing individual methods to be used in the sequence, they
would keep sending out EAP-SUCCESS and EAP-FAILURE messages. The EAP layer
would append the EAP type to the success and failure packets if the
individual methods are chained. Otherwise, send the message out without
modifying it, which indicates final success and failure.

In addition to above, an acknowledgment of receiving the success and failure
message might be needed to support sequence. For example, after EAP method 1
received EAP-SUCCESS, it sends out acknowledge to the backend server, so
backend server can start EAP method 2. This is due to unreliable
transmission of lower layer, success or failure message might not reach the
client. Server should not start method 2 until peer acknowledges that it
finishes with method 1.

----- Original Message -----
From: "James Carlson" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 07, 2003 3:37 PM
Subject: Re: [eap] Re: [Issue 59] Does failed authentication required a
Failure?

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 12:48:54 -0800 (PST)

Filed as Issue 61: Support for EAP Sequences.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 13:03:26 -0800 (PST)

> method and the final one from Authenticator, which makes it hard to support

I think it's fair to say that RFC 2284 didn't anticipate use of sequences
at all, other than Identity followed by a method.

> and EAP-FAILURE by themselves.

This appears to be implementation specific. In some implementations they
are sent by the EAP layer, not by the method (Windows is an example).

> On the other end, authenticator sometimes
> Accept/Reject from the server [IEEE8021X].

Support for "canned" Success and Failure messages has been removed from
IEEE 802.1aa, for the most part.

> Obviously, we need to distinguish

Are you saying that the current RFC 2284bis text would break an existing
implementation? One of the mandates of the EAP WG is to retain backwards
compatibility if at all possible, particularly if the change doesn't
represent a "grey area" of RFC 2284.

> modifying it, which indicates final success and failure.

How are the new messages to be sent? As new codes? A new EAP type? How
will backwards compatibility be maintained?

---

From: [email-masked] (James Carlson)
Date: Tue, 7 Jan 2003 17:26:58 -0500

> at all, other than Identity followed by a method.

That's only roughly fair.  RFC 2284 did anticipate the use, but said
that it probably wasn't a good idea on the balance:

   In practice, within or associated with each PPP server, it is not
   anticipated that a particular named user would be authenticated by
   multiple methods.  This would make the user vulnerable to attacks
   which negotiate the least secure method from among a set (such as PAP
   rather than EAP).  Instead, for each named user there should be an
   indication of exactly one method used to authenticate that user name.
   If a user needs to make use of different authentication methods under
   different circumstances, then distinct identities SHOULD be employed,
   each of which identifies exactly one authentication method.

Is suspect that fear need not be true for an implementation that was
exceedingly careful (that is, one that ran each authentication method
regardless of the intermediate result of each, and then sent Success
after *all* had been run only if all had passed).  But given the
tendency for mistakes, and the likely uselessness of the "feature," it
seems reasonable to suggest that it's not a good idea.

> are sent by the EAP layer, not by the method (Windows is an example).

As long as the EAP implementation sends out EAP Success or EAP Failure
when it has completely finished its authentication (rather than part
way through), it doesn't matter how it's implemented internally.

> represent a "grey area" of RFC 2284.

Why is it obvious that this is needed at all?

What would the authenticatee do if told the equivalent of "you've
passed two hurdles; now just one more to go?"  If nothing else, this
"method success" message would clearly present serious security
problems, since it would allow divide and conquer.  It also doesn't
seem to help in the slightest because nobody has identified a use for
them, other than perhaps as signaling *entirely* internal to an
implementation with a particular EAP+method architecture.

> will backwards compatibility be maintained?

And what would the peer do with them?  They seem to be the protocol
equivalent of having the peer say, "yes, yes, I see; do go on."

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 14:25:38 -0800 (PST)

>    each of which identifies exactly one authentication method.

The question has been whether this referred to sequences, or merely to
choices in the use of a single authentication method.

> seems reasonable to suggest that it's not a good idea.

So you're suggesting that sequences SHOULD NOT be used?

> way through), it doesn't matter how it's implemented internally.

Yes.

> Why is it obvious that this is needed at all?

It's not obvious to me :)

---

From: [email-masked] ([email-masked])
Date: Tue, 7 Jan 2003 19:18:44 -0500

> seems reasonable to suggest that it's not a good idea.
I think the idea of sequences is useful when doing something in addition to 
authentication.  E.g. a method that negotiates QOS.  Then the negotiation for 
authenication method can be done, and if that method succeeds, an attempt to do 
the QOS method can be made.  If the peer accepts the method, it will get to 
negotiate - if not it gets some default settings. 

This concept was at least part of the thinking at the time the initial EAP 
draft was written.

> way through), it doesn't matter how it's implemented internally.
seems true to me

> equivalent of having the peer say, "yes, yes, I see; do go on."

I agree again. I think a success or failure should end a sequence.  If methods 
are implemented to send success or failure, then these implementations can't do 
method sequences for the reasons that James Carlson suggests.

John Vollbrecht

---

From: [email-masked] (Hao Zhou)
Date: Wed, 8 Jan 2003 16:58:51 -0500

----- Original Message -----
From: <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "Hao Zhou" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, January 07, 2003 7:18 PM
Subject: Re: [eap] Re: [Issue 61] Support for EAP Sequences

> method sequences for the reasons that James Carlson suggests.

Are we saying there should be only one success or failure message in the
whole eap session, which should end the session? For methods that send out
success and failure message (or the equivalent of result code to EAP layer
signaling the same) to be used in a sequence, EAP layer should intercept
them and change them into something else (new code/or new EAP type, such as
EAP-TLV) to indicate to the peer the finishing of the first method. Peer
would also need send back same indication to the backend server to
acknowledge the receipt of the success so second method can start. Since
backward compatibility with existing RFC2284 is needed, then a new code is
not desirable.

RFC 2284bis states sequences of EAP methods is supported in Page 5 Section
2.0, [6]. But it doesn't get into detail how the sequences is supported and
what mechanism is used to link sequences of method together. Does this get
too much into implementation or is it still part of the EAP spec? I was
hoping a general mechanism or guidelines can be given to support the
sequences of eap methods.

Hao Zhou

---

From: [email-masked] (James Carlson)
Date: Wed, 8 Jan 2003 17:06:50 -0500

Hao Zhou writes:
> whole eap session, which should end the session?

Yes, precisely.  That's what RFC 2284 *requires*:

   3. The authenticator ends the authentication phase with a Success or
      Failure packet.

and also:

         Implementation Note: Because the Success and Failure packets
         are not acknowledged, they may be potentially lost.  A peer
         MUST allow for this circumstance.  The peer can use a Network
         Protocol packet as an alternative indication of Success.
         Likewise, the receipt of a LCP Terminate-Request can be taken
         as a Failure.

They're "not acknowledged" in part because when you get to this point,
EAP is done.

> For methods that send out

That's entirely an internal design issue.  The communication (if any!)
between methods and EAP within an implementation doesn't hit the
wire and thus can't be part of any Standards Track IETF document.

The only requirement is on what appears on the wire.  That has to look
like this:

	Zero or more Requests ->
	                      <- As many as one Response per Request
	Success or Failure ->

Those codes, if they indeed do exist for some reason, must not appear
on the wire.  Indeed, they need not appear on the wire -- there's
nothing sensible that an EAP peer could possibly do with a "partial
Success" message.  The authenticatee doesn't start anything -- he
doesn't start the current method and he cannot start the next method.
It's not his problem.

> sequences of eap methods.

It's implementation.  None of it appears on the wire between the two
EAP-speaking peers.

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 10:08:11 -0500

> negotiate - if not it gets some default settings. 

Despite the fact that I'm a little uncomfortable with putting
authorization negotiation (such as QoS) into the middle of an
authentication protocol, hat's a good example because it shows the
depth of the problem in trying to define *anything* about sequences in
a "generic" way in this draft.

Let's suppose you have a QoS negotiation, and the EAP Authenticatee
has never heard of it.  Is failure of the "QoS method" a problem?
Almost certainly not -- it just means that the peer gets a default QoS
treatment.  Does the unexpected method at the Authenticatee side pose
a problem?  No, the Authenticatee just sends back a suitable Nak, and
the Authenticator (and the designer of this new method) must be smart
enough to know what to do next.

While the concept is useful in implementation, and it's certainly
useful in designing particularly squirrelly methods, I don't see that
it has any place in the EAP specification itself.  The EAP
Authenticator holds its cards pretty closely; all it reveals is the
sequence of Request messages it sends.  More to the point, the EAP
Authenticatee cannot assume anything about method sequencing, because
it's not in control of the conversation.

So, since the Authenticator doesn't reveal its intentions except by
Request messages, and the Authenticatee, which is required to respond
to all requests, cannot care about those intentions, I think the issue
is irrelevant at this level.  Clearly, useful methods will likely have
to address issues here, but EAP itself doesn't.

(For instance, an EAP method should probably describe what, if
anything, a client must store between Requests, and what, if anything,
an intervening Request with a different Type might mean.  I think that
well-written methods would not change internal state based on the
activities of any other Types seen, but other method designers are
free to be strange.  Additionally, a method designer must describe
what, if anything special, an implementation is required to do on
seeing Success.  If the method includes mutual authentication, then
the definition of the method should say something like this: "the link
MUST be terminated if the peer sends EAP Success and the client method
state machine is not in final state AuthGood.")

What meanful generic requirements on EAP could be imposed with regard
to sequencing?  Since it's all so dependent on what the method does
and how, I'm at a loss to describe what that requirement must be.
Saying "MUST NOT send a Request with a new Type until the last method
is done" seems vacuous to me.  It only means something with a method
that has a state like that, and the general truth of it seems pretty
sketchy.

> method sequences for the reasons that James Carlson suggests.

Since "methods" are entirely internal to an EAP implementation, one
could imagine that the "Success" message is filtered out at the EAP
level and sent only when the "sequence" is complete.  Needless to say,
this is just an implementation strategy and has nothing to do with the
protocol on the wire.

---

From: [email-masked] ([email-masked])
Date: Thu, 9 Jan 2003 11:55:39 -0500

> this is just an implementation strategy and has nothing to do with the

I think of methods differently.  I think they are entities in themselves.  In 
order to do sequences of methods one needs know when they are done and whether 
they succeeded or failed.  This is different from whether a sequence of methods 
succeeded or failed.

For implementations to interoperate when sequences are possible, some set of 
rules must be agreed on what success for a sequence means, and who can decide.
My proposal, which is not the only possible solution, is that

1. the authenticator be the driver, and that it can select any sequence of 
methods it desires.
2. the peer can NAK any method(s)
3. Each end must have some criteria for a minimum set of methods that must be 
completed in order to succeed, and be able to indicate success or failure to 
the lower layer
4. the authenticator may request 'optional' methods which the peer may NAK.

There are probably some other rules needed.  The intent is to provide a set of 
rules for sequences which, if followed, will allow adding methods to existing 
sequences without breaking peer implementations that don't do sequences.  

I am interested in comments of whether people think this is a reasonable goal, 
and if so, whether the proposed set of rules would satisfy them.

John Vollbrecht

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 12:16:54 -0500

> they succeeded or failed.  This is different from whether a sequence of methods 

They may be distinct entities or may not; it doesn't matter for the
bits that end up on the wire.  The glue between methods and EAP (and,
perhaps, among methods) is an implementation artifact.

> rules must be agreed on what success for a sequence means, and who can decide.

Agreed.  The point I'm trying to make is that EAP itself is not a good
choice of places to define this.  The methods themselves would be a
much better place.

> 4. the authenticator may request 'optional' methods which the peer may NAK.

I agree with all of that.

However, none of that text actually constrains sequencing in any way.
For instance, suppose I have two methods, called "A" and "B".  "B" is
a single request-response method, such as MD5-Challenge.  "A" is a
more complex method that requires two separate exchanges; we'll call
them A1 and A2.  (Presumably, these are subtypes identified in the
payload itself; that's just a detail.)

The following sequence is compliant with your proposal:

	Authenticator            Authenticatee
	Request Type=A1    ->
	                   <-    Response Type=A1
	Request Type=B     ->
	                   <-    Response Type=B
	Request Type=A2    ->
	                   <-    Response Type=A2
	Success            ->

> and if so, whether the proposed set of rules would satisfy them.

I think this can be loosened to the point where no special sequencing
rules at all are necessary.

I *think* we can agree that the only real issue that arises is with
methods that use multiple rounds of messaging (such as "A" above).
Those that consist of single rounds (such as "B") cannot have any
problem, because there's no way to force anything in the middle.  (If
we can't agree on this, then please explain how a composition of
single-round methods requires a special rule.)

So, for those that require multiple rounds of Request messages, we
state that each method MUST keep its own internal, independent,
inter-Request state required to complete the method-specified
authentication process.  At a minimum, this consists of the next
expected message sub-type, and most such methods are expected to keep
far more state storage than that.  As an Authenticatee, the arrival of
a Request with a Type value that belongs to a different method MUST
still be processed, even if the previous Request invoked a multi-stage
method that is not yet complete, and MUST NOT affect any other method
that has not yet completed.

Finally, as an Authenticatee, if a Success message is received, and
any methods invoked are in a method-specific state such that making
the link available for network traffic is impossible (e.g., the method
employs mutual authentication, and the Authenticatee has not been able
to validate the Authenticator's identity), then the link MUST be
terminated.  The link MAY be terminated by the Authenticatee at any
time and for any reason.

With the above text, I think the whole sequencing issue goes away.  It
becomes a local policy matter.

(With the distinct benefit that the logic above is compatible with RFC
2284, while the logic necessary to enforce just about any sort of
sequencing among the Request messages would appear to impose stricter
requirements than appeared in the RFC and thus be incompatible.)

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 06:02:24 -0800 (PST)

> negotiate - if not it gets some default settings.

Why wouldn't this be negotiated at the lower layer? EAP doesn't have a
generic negotiation framework.

> This concept was at least part of the thinking at the time the initial EAP

Did it get removed later?

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 06:06:54 -0800 (PST)

>          Likewise, the receipt of a LCP Terminate-Request can be taken

The third sentence of this paragraph is quite scary -- the idea that the
EAP state machine can somehow enter into the SUCCESS state via receipt of
out-of-band exchanges. Lower layer failure indications need to be
processed, even if they are spoofable. It's the responsibility of the
lower layer to do something about this (such as protecting 802.11
Disassociate or Deauthenticate messages), but if it doesn't, there's
little EAP can do.

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 06:40:05 -0800 (PST)

> I suspect that fear need not be true for an implementation that was

The RFC 2284 text (below) was modified under the assumption that it
did not apply to sequences. However, given your concerns
and the recent work on man-in-the-middle attacks, that may not have been
appropriate.

This was the RFC 2284 text:

How about this:

In practice, within or associated with each EAP server, it is not
anticipated that a particular named user would be authenticated by
multiple methods, either in by offering a choice or by using multiple
methods in sequence. This would make the user vulnerable to attacks
which negotiate the least secure method from among a set (
negotiation attacks, described in Section 7.9) or man-in-the-middle
attacks (described in Section 7.5) Instead, for each named user there
SHOULD be an indication of exactly one method used to authenticate that user
name. If a user needs to make use of different authentication methods
under different circumstances, then distinct identities SHOULD be
employed, each of which identifies exactly one authentication method.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 14 Jan 2003 22:16:00 -0500

> > seems reasonable to suggest that it's not a good idea.
I don't think the feature is useless.  I think being able to have multiple 
methods talking between the AS and Client can be quite powerful.  The 
ability to negotiate with the user directly about the value of QoS features 
is an example.  There are others.

>    each of which identifies exactly one authentication method.

My understanding of this text is that only one authentication method should 
be supported by the Authenticator - negotiating MD5 rather than SIM is not 
allowed for example.  However I do not read it as saying that a sequence of 
methods with other purposes could not be run.

> SHOULD be an indication of exactly one method used to authenticate that
> user name. If a user needs to make use of different authentication methods

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 14 Jan 2003 20:07:26 -0800 (PST)

> is an example.  There are others.

EAP is supposed to be for authentication only. The link layer typically
has the negotiation facilities. So it's not clear to me why QoS signalling
is an important feature to enable in EAP.