Subject: [eap] Re: EAP issues

From: [email-masked] (Bernard Aboba)
Date: Tue, 24 Sep 2002 12:23:56 -0700 (PDT)

> Issue A -
> In 2284bis-05 the Identity type is treated as a special method.  I think
> it is just another method, and while it may be required in some
> applications, it should not be special in the EAP spec.
>
> I would like references to it as a unique method removed.  It can be
> used as an example in sequencing methods.

Can you give examples of the changes that you'd like made? One way that
"Identity" is special is that it can be generated by the NAS when in
"passthrough" mode. That's largely because the NAI is needed in order to
decide where to route the authentication.

Question: can it be assumed that the results of the "Identity" exchange is
somehow made available to a subsequently selected EAP method? Or are the
"methods" independent?

Along the same vein, do you think that "Nak" or "Notification" are "just
another method" or do these reside at the EAP layer (sort of like the
relationship between ICMP and IP). I tend to think of Notification as a
service that can be used by any EAP method, and "Nak" as the equivalent of
an "ICMP port unreachable" -- operating above EAP, but really part of the
EAP layer.

> Issue B -
> Where and when Success and Failure messages are created and sent is not
> clear.  I think that Success and Failure messages should be generated by
> the EAP Mux, not by individual methods.  The alternative is to have
> methods send and EAP mux receive, but then all methods would need to
> send, and chaining methods might be difficult.
>
> This should be clarified so implementations of methods can work
> together.

Question: Can methods decide that they don't want to use EAP Success and
EAP Failure within their method? For example, can a method decide that it
wants to use its own (perhaps cryptographically secured) Success/Failure
indication? Note that in pass-through mode, the NAS is told the result via
AAA, and doesn't look at the encapsulated EAP packet (if any). So only the
EAP peer and authenticator care about this. If the method can indicate
when it has succeeded or failed on its own, without receiving a
(cleartext) EAP Success or EAP Failure, is this sufficient?

In other words, can a method declare that it is "done" (requesting the mux
to handle EAP Success/Failure) OR that it is "completely done"
(success/failure indication handled within the method, no need for help
from the mux).

> Issue C-
> If the authenticator starts an  EAP method but doesn't complete the
> whole method sequence, how does the client indicate that it is not
> finished?
>
> In this case the client EAP mux has been happily passing EAP messages to
> the appropriate method, then gets a different EAP type.  If it is going
> to complain it needs to know that the prior EAP method is not complete.
> This implies some signalling between the EAP method and the EAP Mux.

Yes. That signalling also seems needed to fix the problem described above.

> The interactions between the mux and methods needs to be spelled out
> more.  This may not be a protocol, but is part of what is required to
> understand what the protocol needs to support.

I think this also comes up in deciding whether an EAP Success or Failure
should be accepted (or silently discarded) at various stages of the
protocol. For example, one might argue that a cleartext success/failure
indication should be silently discarded if the method has not signalled
that authentication is complete.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 24 Sep 2002 18:02:13 -0400

> decide where to route the authentication.

in section 2 subparagraph [1] there is a section that starts "Typically
the Authenticator will send an initial Identity Request; ...."  All this
about Identity should be removed, in my opinion.

> an "ICMP port unreachable" -- operating above EAP, but really part of the
I think Notification is just another method.  I think NAK, although it
has a type, is really not a method, but a communication with the EAP
mux.  This is obviously open for discussion.

> (success/failure indication handled within the method, no need for help
see below -- I think the Success/Failure should always be sent from the
mux.

> > Issue C
Honestly, I am not completely sure what a success/failure should be used
for.  I do not think it should be generated from an EAP method.

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Nick Petroni)
Date: Tue, 24 Sep 2002 18:17:06 -0400 (EDT)

> mux.  This is obviously open for discussion.
this seems to make sense, but my understanding is that
Notifications cannot affect the outcome of the authentication in any way.
To this end they are sort of like NULL methods.

> see below -- I think the Success/Failure should always be sent from the
I think this seems right.
Since the protocol clearly states the ability to require multiple methods
before sending a success (bullet [4], section 2 just to point out 1), it
doesn't make sense for a particular method to ever send an EAP success. As
Bernard stated, a particular method may have its own
version of success/failure, but it seems the mux should be responsible for
the general purpose success/fail (if they have any use at all).

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 24 Sep 2002 17:30:37 -0700 (PDT)

> for.  I do not think it should be generated from an EAP method.

Well, that makes two of us :)

I agree that it should be generated from the mux, not an EAP method.

But I wonder whether it is even needed at all in some circumstances, or
whether the "alternative indications" text of RFC 2284 should be retained,
and perhaps clarified.

For example, if an EAP method has its own protected indications of success
and failure, then it isn't clear to me why an EAP Success or Failure is
needed at all (it just creates an opportunity for DoS attacks and adds an
unnecessary roundtrip), except perhaps as a way of ending an EAP
conversation involving multiple methods.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 24 Sep 2002 17:40:09 -0700 (PDT)

> To this end they are sort of like NULL methods.

Yes. Notification is *not* an error indication.

> the general purpose success/fail (if they have any use at all).

The question is when the mux is triggered to send it, and how, and when
the client is willing to accept these indications.

1. Is this based on an indication from the method? For example,
the method residing on the EAP server asserting "client authentication
successful", causing the mux to send the indication?

2. Can the mux choose *not* to send the indication?
(e.g. if there is more than one method operating in succession).

3. Must a server-based EAP method always indicate completion *after*
receipt of an EAP Response, so as to allow for multiple methods to be
used in succession? Or can the final message be an EAP Request?

4. Does the EAP client agree to accept EAP Success messaged based on an
indication from the client method, asserting "server authentication successful"?
For example, does the mux silently discard EAP Success messages received
in advance of receipt of that indication from the active method?