Subject: [eap] Issue 66: Mandatory for who?

From: [email-masked] (Bernard Aboba)
Date: Wed, 8 Jan 2003 18:31:15 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 8, 2003
Document:
Comment type: T
Priority: S
Section: 3.4
Rationale/Explanation of issue:

RFC 2284, Section 3.4 states:

"All EAP implementations MUST support the MD5-Challenge mechanism."

Does this obligation extend to NASes operating in passthrough mode?
For example, MUST they be able to authenticate a local user via
EAP MD5?

Going further, do obligations of authenticators (such as dropping
duplicate Requests) extend to NASes operating in passthrough? Who
is the authenticator in this case? The NAS? The AAA server?
Both?

---

From: [email-masked] (Jari Arkko)
Date: Thu, 09 Jan 2003 09:59:06 +0200

> For example, MUST they be able to authenticate a local user via

I'd say no.

 > is the authenticator in this case? The NAS? The AAA server?

This specific issue is related to the discussion on ordering. I
don't have an opinion yet on that. However, I believe it would
be very useful indicate for each requirement for which node it
applies, and treat AAA servers, passthroughs, and peers separately.

Hmm.. Do we talk about passthroughs here or in 2869bis? Would
it be sufficient for us to define authenticator == AAA server in
case EAP is not directly terminated in the NAS?

Anyway, here's a my check of all the MUSTs in the spec:

o Section 1.2 (terms): General MUSTs which appear OK.
o Section 2 (intro): Two MUSTs for passthrough NASes.
o Section 2.1 (mux): One peer MUST, one general MUST which appears OK.
o Section 3.2 (PPP): One general MUST which appears OK because it is for PPP peers
                      and therefore unambiguous.
o Section 3.4 (ll inds): Two general MUSTs, appears OK.
o Section 4 (format): One general MUST, explicitly says applies to authenticators and
                       peers. Ok.
o Section 4.1 (r&r): - One authenticator MUST, one peer MUST for who sends requests.
                        Is it unclear whether the passthrough should check something
                        here? I guess the passthrough does not know whether we are running
                        EAP in two directions. Hence, it MUST allow both requests and
                        responses from both directions. Should this be stated somewhere?
                      - Two MUSTs on additional requests. From the context this is
                        the authenticator sending them, but this isn't explicitly
                        stated. Maybe we should do that.
                      - One MUST on peer's response behaviour. Ok.
                      - Two MUSTs on general response-request matching; this would
                        benefit from explicitly stating who does what.
                      - Three MUSTs for authenticators.
o Section 4.1 (id) - Two general MUSTs for retransmissions; should explictly say
                      these are for the authenticator?
                    - Two peer MUSTs for duplicates: OK.
o Section 4.1 (type): - One general MUST, apparently OK (?)
o Section 4.2 (succ): - Two authenticator MUSTs.
                       - One general MUST, OK.
                       - One MUST which states that the Id for a Succ/Fail
                         must be unique over the *whole* conversation. I
                         fail to see how this can be implemented... what if
                         you already cycled through all the numbers?! Or are
                         we reserving one (or more?) Id numbers for
o Section 4.2.1 (prot): - One peer MUST.
                         - One authenticator MUST.
                         - One peer MUST
                         - Two general MUSTs in bullet item e, but
                           since they talk about discarding Failures
                           and Successes, isn't this for the peer?
o Section 5 (types): - 4 general MUSTs, I guess these are OK.
o Section 5.1 (identity): - 2 general MUSTs, hmm.. maybe OK.
                           - 1 authenticator MUST
                           - 1 general MUST, OK.
o Section 5.2 (notif): - 3 peer MUSTs.
                        - 2 general MUSTs. Hmm... I think
                          we said earlier somewhere that the
                          authenticator must discard requests.
                          Maybe it would make sense to change
                          the 2 requirements here to apply for
                          peers only, otherwise there's a
                          contradiction since they say MUST
                          respond.
o Section 5.3 (nak): - One general MUST. Ok.
                      - One general MUST dealing with sending this;
                        I guess this should be for peer only?
                      - Two general MUSTs, Ok.
o Section 5.4 (md5): - One general MUST but again this should
                        hold for authenticators only?
                      - One general MUST, Ok.
o Section 5.5 (otp): - Two general MUSTs. The first should be
                        again for peer only?
o Section 5.6 (gtc): - One general MUST, again for peer only?
                        Also, all the other sections explain
                        carefully that you can either respond
                        with the Response or Nak; 5.6 does not!
o Section 5.7 (vend): - One general MUST, Ok.
                       - One peer MUST.

There's some potential things to fix in the following sections:
   - 4.1 (4 times)
   - 4.2.1 (1 time)
   - 5.2 (1 time)
   - 5.3 (1 time)
   - 5.4 (1 time)
   - 5.5 (1 time)
   - 5.6 (1 time)

And a potential new issues to file from Section 4.2
and from Section 5.6.

Jari
----
P.S. In bis-09, change
    is implemented within the EAP layer. peers MUST respond to an EAP
to
    is implemented within the EAP layer. Peers MUST respond to an EAP

---

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

>  > For example, MUST they be able to authenticate a local user via

I'd also say no -- but that it forms a part of the requirements for
choosing a backend service when doing any sort of pass-through.  If
the backend service cannot support MD5-Challenge, then it cannot be a
backend for EAP, because it would make the EAP Authenticator
incompatible with RFC 2284.

> applies, and treat AAA servers, passthroughs, and peers separately.

I think an EAP implementation in the Authenticator role must appear to
be the same from the EAP Authenticatee's point of view no matter what
sort of backend its using.  That's sort of the point of having a
standard here.

If you want to have a separate text to describe how you might
accomplish that within the EAP Authenticator implementation using a
pass-through mechanism, that sounds like reasonable implementation
advice, but I'd question whether it even belongs here.  I think it
should probably go in a separate Informational "using EAP with AAA"
document.

Clearly, AAA servers and the protocols used to talk to AAA clients
(such as EAP Authenticators) need to be in separate documents.
Duplicating RADIUS or DIAMETER work here would be a bad thing.

> case EAP is not directly terminated in the NAS?

No, I don't think that definition is good.  I think we need clearly
separate terms for the EAP-speaking peer that is in the Authenticator
role (the "NAS" in many architectures) and the EAP-capable system that
is in the ultimate authentication role (the "AAA server").  The two
are clearly quite different.  In particular, the fact that, if you're
doing pass-through, the AAA server sees EAP messages does *NOT* mean
that the AAA server itself speaks EAP.  In particular, it doesn't do
the Identifier-related blood-and-chicken dances.  It's using EAP
message formats to convey authentication data, not EAP the
authentication transport protocol.

>     is implemented within the EAP layer. Peers MUST respond to an EAP

Personally, and I might be in the minority here, I find the usage of
capitalization to delimit a term d'art to be quite baroque, especially
as it's applied in this document.  In particular, the term "peer" has
well-known usage in IETF circles.  Does EAP need its own private
definition to survive?

-- 
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: Thu, 9 Jan 2003 09:25:21 -0500

> Does this obligation extend to NASes operating in passthrough mode?

In a sense, yes.  The EAP Authenticator *plus* the backend server
together have to arrange to support MD5-Challenge in order for the EAP
Authenticator to pass RFC 2284 muster.  How this actually takes place
really isn't our problem -- it's the problem of the definition of the
AAA linkage.

If the AAA service to be used supports MD5-Challenge, then that'd be
great.  If it doesn't, then other arrangements will have to be made.
None of that affects what's on the wire for EAP -- the EAP
implementation must be able to support this authentication mechanism.

Another way to document it is that from the EAP Authenticatee's point
of view, there's no way to distinguish between what the EAP
Authenticator implements, and what some backend service implements.
It's a null issue.  From the Authenticatee's point of view,
MD5-Challenge must be supported.

> duplicate Requests)

Authenticators do not drop duplicate Requests.  Authenticatees do.

> extend to NASes operating in passthrough? Who

As before, I'd argue that the entity that generates the duplicate
Requests should also have responsibility to discard invalid Responses.
If, in a given AAA scenario, the NAS is responsible for
retransmitting, then it should eliminate the bad responses (which
would include, but not be limited to, duplicates).  If it's not
retransmitting, then the NAS wouldn't be eliminating bad responses.

We can possibly give guidance here, but I don't think it's wise for
the EAP working group to do the work of the AAA working group.  The
boundary is at the implementation level: there's a description of what
has to appear on the wire between two EAP speakers, which is this
working group's job, and there's a description of what has to appear
on the wire between a AAA client (i.e., EAP Authenticator) and AAA
server, and that's the AAA's responsibility.  The impedance matching
between those to is mostly an implementation issue.

So, at best, I think we should have a recommendation that says that if
you're using a back-end authentication service that is designed using
encapsulated EAP messages, then this working group believes that the
AAA protocol should be designed assuming that the NAS should
retransmit and eliminate duplicates.

Since the choice of whether to eliminate those duplicates or not does
*not* appear on the wire between the EAP peers, we should not (and I
would argue *cannot*) provide a normative specification for that part
of the behavior.

---

From: [email-masked] ([email-masked])
Date: Thu, 9 Jan 2003 09:58:58 -0500

> authentication transport protocol.

this is an interesting distinction.  could you expand on what you see the 
difference between doing EAP the transport protocol and using EAP message 
formats to convey authentication data?  I think there is a distinction here, 
but it seems to me the AAA server is in fact the one doing EAP protocol, and 
the AP initiates and provided the connection between Client and AAA.  

I think this is an area where the same vocabulary can have different meanings, 
and conversations go off in peculiar directions.  

Anyway, I think you raise an important point.  I think the "passthru" method 
might provide solution, where the passthru acts as Authenticator to the Client, 
and Client to the AAA.  Doing EAP in both connections. 

> well-known usage in IETF circles.  Does EAP need its own private

John Vollbrecht

---

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

[email-masked] writes:
> formats to convey authentication data?

The difference is in the way the protocols behave.  The AAA protocol
is a reliable transport -- it has its own retransmission behavior and
error recovery.  It would thus be senseless to implement any of EAP's
retransmission and duplicate handling strategy over a AAA protocol.
In fact, for DIAMETER and RADIUS, it would be strictly impossible
because there's no way to drive retransmission in that direction.
(The Requests come to the EAP Authenticator by way of AAA *RESPONSES*,
not commands.)

So, to put this in context, here's what I see:

	1.  NAS (EAP Authenticator) receives a new link (a "call").
	2.  NAS determines that this link uses EAP, and that DIAMETER
	    is needed for the backend.  (L2-specific and proprietary
	    policy mechanism here.)
	3.  NAS sends Diameter-EAP-Request with NULL EAP-Payload AVP
	    to DIAMETER server.
	4.  Server responds with Diameter-EAP-Answer containing EAP
	    message to send.
	5.  NAS sends EAP Request with the given payload.
	6.  NAS waits for Response from peer.  It retransmits the same
	    Request periodically based on its knowledge of the link
	    characteristics (RTT and so on).  It drops bad Response
	    messages (with Identifier not equal to the current one).
	7.  A valid Response is seen.  This is forwarded to the
	    DIAMETER server by encapsulating as EAP-Payload AVP in a
	    new Diameter-EAP-Request message.  The current stored
	    Identifier is "invalidated" so that we don't do this again
	    until the DIAMETER server responds.
	8.  The server responds with Diameter-EAP-Answer.  If this has
	    an EAP Response to send, go back to step (5).  If it has
	    EAP Success or Failure, send that, and quit.

Perhaps some feel that step (2) is vague.  That's intentional.  On
PPP, one uses LCP to tell if EAP is in use, and with ISDN one might
use the Calling Party Identification to determine what DIAMETER server
to use.  It's all local policy.  It might include an initial EAP
Identity to snag an NAI, as suggested in draft-ietf-aaa-eap-00.

The distinction I'm drawing, and I think it's quite valid, is between
EAP messages sent between EAP Authenticator and EAP Authenticatee, and
EAP messages that are carried as freight in the EAP-Payload AVP.

At step (7), the DIAMETER server *might* want to validate that the EAP
Identifier carried in the payload is indeed the same one that was sent
in the last answer to the NAS.  If not, then sending Failure would be
appropriate.  In any event, this sort of AAA message validation and
handling is NOT part of RFC 2284.  It's strictly a AAA linkage issue
and belongs in draft-ietf-aaa-eap-00.

Note particularly that *everything* about sequencing is controlled
*completely* on the DIAMETER server.  That, I think, is another clue
that sequencing is not really part of EAP itself but is rather a part
of the individual method and the overall deployment-specific
authentication policies.

>  I think there is a distinction here, 

Right.

> and conversations go off in peculiar directions.  

I agree.

> and Client to the AAA.  Doing EAP in both connections. 

I'm almost with you.  EAP, including the retransmit mechanism, is
certainly there for the Authenticator to Authenticatee connection.
Those Identifier tricks are just not the same for the pass-through to
AAA connection, because that connnection is most certainly *not* EAP.
It has EAP messages encapsulated, but it's actually AAA, not EAP.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Thu, 9 Jan 2003 11:09:43 -0500

I agree.

> the AP initiates and provided the connection between Client and AAA.  

One distinction is EAP Success/Failre message is not necessarily
carried in AAA messages.

Another distinction is on Identifier management.  It is not always
possible for a NAS to completely "pass-through" EAP message "as it
is".  Suppose that method A and method B are performed in a sequence,
and method A is performed _without_ using AAA while method B is
performed _with_ using AAA.  If the NAS passes through method B EAP
Requests originated from the AAA server as it is, the last Identifier
in method A may conflict with the first Identifier in method B, and
coversation may fail.  So I think in this case the NAS need to
re-assign the Identifier.  On the other hand, if AAA provides ordered,
reliable transport, EAP Identifier might not be even necessarily
carried in AAA messages.

> and Client to the AAA.  Doing EAP in both connections. 

As one of persons who consider "pass-through" method, I think the
method should not be described in RFC228bis, according to the
consensus on having no distinction on operational modes in the
specification.  However, when definining a state machine of the
protocol (as an informational guideline for implementors), I believe 
"pass-through" method might help simplify the state machine
definition.

Yoshihiro Ohba

---

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

Yoshihiro Ohba writes:
> performed _with_ using AAA.

Or even (eek!) through different AAA services.

>  If the NAS passes through method B EAP

That's an interesting problem.  Since some methods (e.g., RFC 2284
MD5-Challenge) compute the Response value based on the Identifier, so
I think that Identifier remapping is impossible without some
additional help.

In any event, this is a problem for the definition of the AAA service,
not for EAP.

(One way around it might be to have the AAA protocol carry an
additional "EAP-NAS-Assigned-Identifier" AVP.  Since that probably has
interesting security issues, it's probably best left to the folks who
have to deal with that protocol.  Another way around it would be to
require the AAA server to choose an Identifier value for the first
message at random, and then have error handling code that restarts the
AAA session from scratch in the rare instance of a collision.)

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 9 Jan 2003 07:22:46 -0800 (PST)

> In a sense, yes.

The original text should have been unambiguous enough (an authenticator
implements EAP whether it is in passthrough mode or not), but
I would propose that we reword this to say:

"Peers, authenticators and backend authentication servers implementing
EAP MUST support the MD5-Challenge mechanism."

Also, to clarify other issues relating to authenticator responsibilities,
we can insert your suggested text:

"The EAP authenticator is responsible for retransmitting Request messages.
If the Request message is obtained from elsewhere (such as from a
backend authentication server), then the authenticator will need to
save a copy of the Request in order to accomplish this. The
authenticator is also responsible for discarding Response messages
with the wrong Identifier value before acting on them in any way,
including passing them on to the backend authentication server for
verification. Similarly, the peer is responsible for detecting and
handling duplicate Request messages before processing them in any
way, including passing them on to an outside party."

---

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

> I would propose that we reword this to say:

I think it still is unambiguous enough.  I'm a little wary of
documents that attempt to solve all conceivable interpretation
mistakes.

> EAP MUST support the MD5-Challenge mechanism."

I think that's too strict.  The restriction is that the EAP
Authenticator (which includes all of its internal implementation
details, such as authentication mechanisms invoked) MUST support
MD5-Challenge.  Whether that support is in the EAP Authenticator or in
the backend or in both is just not an issue here.  There's no way to
look at the messages on the wire between the Authenticator and
Authenticatee and somehow know if the messages are generated by the
Authenticator itself, or are being relayed from a secret backend
authenticator somewhere.

The reason that this requirement was added was for interoperability.
There needs to be at least one common authentication algorithm that
all are known to speak, or there will be cliques of implementations
that cannot interoperate.  So, the issue is that from the point of
view of the EAP Authenticatee, it must be *possible* for him to prove
his identity with MD5-Challenge.  (In a given deployment, that ability
might will be disabled for security reasons, but the implementations
themselves MUST allow it to be enabled in some manner.)

> way, including passing them on to an outside party."

OK, but I think it should be distinguished as an implementation note.