Subject: [eap] Issue 37: EAP stack representation

From: [email-masked] (Bernard Aboba)
Date: Sun, 6 Oct 2002 03:06:56 -0700 (PDT)

Issue 37: EAP stack representation
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: 1
Section: 2.1
Rationale/Explanation of issue:

RFC 2284bis needs an explanation for how EAP multiplexing works.

Here is a proposal for material to be added to section 2.1:

"Within EAP, the Type field functions much like a port number in UDP or
TCP. With the exception of types handled by the EAP layer,
it is assumed that EAP implementations multiplex incoming
EAP packets according to their Type, and deliver them only to the EAP
method corresponding to that Type code. This includes the Identity Type,
which operates like any other EAP method.

The Nak method is utilized for the purposes of method negotiation,
and is implemented within the EAP layer. Peers MUST respond to an EAP
Request for an unsupported Type with a Nak Response. Authenticators
receiving an EAP Response with an unsupported Type MUST silently discard the Response.

While a Notification Request may be generated at the behest of an EAP
method, a Notification Response is generated automatically by
the peer EAP layer in response to it.

EAP packets with codes of Success or Failure do not include a Type, and
therefore are not delivered to an EAP method.

As a result, the Success, Failure, Nak and Notification messages
MUST NOT used to carry data destined for delivery to other EAP methods.
The architecture is illustrated in figure 1 on the next page.

(see ASCII art
at http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2037)

Figure 1. EAP Multiplexing Model

---

From: [email-masked] (Jari Arkko)
Date: Sun, 06 Oct 2002 15:22:37 +0300

Bernard,

I like your text, but I have a few discussion points below:

> Request for an unsupported Type with a Nak Response.

unsupported => unacceptable?

(What if I support the method but the password/config file/card is missing,
or if I'd rather not do this method even if I do support it. For instance,
Nakking an Identity request if I intend to do a tunneled TLS protected
EAP first before giving away my real identity?)

> Authenticators

Unsupported or unexpected? Even if I support FOO, I don't want a FOO
response if I just initiated BAR by sending its first message to the
peer.

Perhaps the following text would be more suitable: "Authenticators receiving
an EAP Response with a Type for which the authenticator has no outstanding
Request MUST silently discard the Response."

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 6 Oct 2002 04:40:26 -0700 (PDT)

> unsupported => unacceptable?

Done.

> Request MUST silently discard the Response."

Done.

---

From: [email-masked] (John Vollbrecht)
Date: Mon, 07 Oct 2002 15:06:12 -0400

I like this a lot.  

Have we determined that the notification method must be handled by the
MUX rather than as a "standard" method?  I thought the responses were
indeterminate about whether this is a requirement.

John

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

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 7 Oct 2002 13:13:41 -0700 (PDT)

> indeterminate about whether this is a requirement.

It appears that existing implementations handle generation of the
Notification Response automatically, within the EAP layer. I'm not as
clear from the Notification Request. You'll notice that the EAP
Notification Response is part of the EAP Layer in the ASCII-art figure,
but that the Notification Request is not -- it's in the method layer.

Also, existing implementations don't treat Notification Requests as data
-- it's not delivered to the running method, although it would appear that
methods can request that Notification Requests be sent.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 08 Oct 2002 13:09:42 -0400

> methods can request that Notification Requests be sent.

So my question is - would it be better to represent (in the formal state
machine) that the EAP methods signal a notification request be sent from
EAP or just have them originate and send it, or both.  

If we assume a sequence of methods might be defined somehow, and that
EAP is responsible for making the sequence happen, then it would seem
that Identity should be able to be treated as an "independent" method
called by EAP and not by another method.  Of course it could also be
called by another method, but then it is the only method called by
another method (I think - is that true?) and becomes a "special case".

I would like to have us define an API between EAP and methods before
deciding for sure how this should work.

-- John

---

From: [email-masked] (James Carlson)
Date: Tue, 8 Oct 2002 16:25:34 -0400

> EAP or just have them originate and send it, or both.  

That sounds like an implementation detail.  I don't see how it affects
the observable behavior of the system or the bits on the wire.

Is there any way for an outside observer to tell if the implementor
chose to create this abstraction in the "EAP layer" or if the method
itself just invokes Notification?  If there's no actual way to tell,
then I would argue that it does not belong in a document that comes
from the IETF.  (Certainly, other standards bodies have other
priorities.)

> deciding for sure how this should work.

If an API is needed at all, and I don't think it is, I would very much
prefer to see this done in a group that is equipped to handle the
intricacies of API design.  The IETF isn't that group.  Perhaps The
Open Group might be.

For that matter the state machine, as useful as it might be, can only
be advisory in nature, since there's no way to tell from the bits on
the wire whether the internal implementation details match that
particular realization.  I think it'd be much better to split this
portion off into an Informational track RFC describing known-good
implementation strategies.

-- 
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] (John Vollbrecht)
Date: Tue, 08 Oct 2002 17:49:00 -0400

> the observable behavior of the system or the bits on the wire.
I agree that from a protocol point of view it is an implementation
detail.

> implementation strategies.

One point of the state machine is to make it easier to describe what the
external behaviour is.  Without it one has to imagine all the ways
someone might interpret a set of words. 

A problem with describing it as a state-machine is that the state
machine often implies an implementation, and of course ietf describes
protocols not implementations.

I also am not sure this is the place to define an API.   However I do
think porting EAP methods accross a variety of platforms will be much
easier if there is such an API.

- John

---

From: [email-masked] (Joseph Salowey)
Date: Tue, 08 Oct 2002 15:47:37 -0700

>Bernard Aboba wrote:

<snip>

>another method (I think - is that true?) and becomes a "special case".

I like the idea of separating the Identity as a separate method invoked by 
"EAP".  I am uncertain about having Identity invoked from other 
methods.  The Identity messages do  not allow you to request a mechanism 
specific identity so how can a mechanism be sure it is going to get the 
right type of identity if it invokes the identity method?

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Oct 2002 17:28:20 -0700 (PDT)

> itself just invokes Notification?

If one implementation uses Notification to pass in-band data, and another
cannot handle that, then the two implementations won't interoperate. I
believe that this behavior has been observed in existing implementations.

> particular realization.

Unfortunately, that is not the case. There are known scenarios in which
some implementations will conclude that they have authenticated
successfully, and others will not. Again, this has been observed in the
field. The response of a peer to an EAP Success packet should not be a
mature of conjecture.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Oct 2002 22:14:21 -0700 (PDT)

> right type of identity if it invokes the identity method?

In reviewing RFC 2284bis, there are a number of places where Identity is
treated differently from other methods. For example, RFC 2284bis is clear
that an Identity Request MUST NOT be NAK'd (e.g. Identity is explicitly
excluded from the list of "authentication methods" which can be NAK'd).
So Identity isn't really "just like any other method".

It seems like you are arguing that Identity Request (unlike Notification
Request) doesn't appear to be invokable from other methods, nor can the
Identity Response data be assumed to be delivered to other methods,
correct?

It seems like the main function of Identity is message routing, but there
are circumstances (e.g. an AP used in a home) where there is no
message routing, and so the Identity would not be needed -- and in the
interest of better roaming performance, the less round-trips the better.

So it would seem that if a method needs the user identity, then
a method-specific identity exchange is probably the way to go,
particularly since this approach allows the method to be more
specific about what kind of identity information it wants
(e.g. a cert exchange payload).

---

From: [email-masked] (Jari Arkko)
Date: Wed, 09 Oct 2002 18:03:19 +0300

> (e.g. a cert exchange payload).

I'm pretty sure most methods require user identity. How would you
otherwise dig up the right password from the db to perform your
crypto on? Is the discussion about whether the methods can (a)
get the identity information which has already been provided,
(b) invoke Identity request when needed before their own execution,
or (c) invoke Identity request during their own execution?

I'm not sure we should limit identity requests just for
message routing purposes.

I agree though that in some cases (AP at home, cert
exchange) we don't need identity requests, and we should
allow the optimization to skip a roundtrip.

Jari

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 09 Oct 2002 08:05:45 -0700

>Identity Response data be assumed to be delivered to other methods,

Mostly. I think some methods require the information from the identity 
response. Perhaps this should be discouraged.

>(e.g. a cert exchange payload).

I agree with this.

Joe

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 9 Oct 2002 07:06:05 -0700 (PDT)

> or (c) invoke Identity request during their own execution?

I think that all three issues may be relevant to on-the-wire
interoperability.

> allow the optimization to skip a roundtrip.

The Identity Exchange is optional in RFC 2284 -- but is required in
802.1X. So that's a conflict that needs to be resolved.

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 09 Oct 2002 08:24:31 -0700

>or (c) invoke Identity request during their own execution?

I suggest that identity should be retrieved by the mechanism (in a 
mechanism specific fashion).  I realize that there are some existing 
mechanism that require identity exchange, but I think we should discourage 
methods from doing this.

>message routing purposes.

Perhaps not, but right now I think I would like to.