Subject: [eap] Proposed resolution to Issue 87

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 05:00:59 -0800 (PST)

I would like to propose that Issue 87 be resolved as follows:

Change the text of Section 2.1 to the following:

"An EAP conversation MAY utilize a sequence of methods. A common example
of this is an Identity request followed by a single EAP authentication
method such as an MD5-Challenge. However, within or associated with each
EAP server, a particular named peer SHOULD NOT utilize multiple
authentication methods (Type 4 or greater), either by
supporting a choice of methods or by using multiple methods in sequence.
This would make the peer vulnerable to attacks that negotiate the least
secure method from among a set (negotiation attacks, described in
Section 7.8) or man-in-the-middle attacks (described in Section 7.4).
Instead, for each named peer there SHOULD be an indication of exactly
one method used to authenticate that peer name. If a peer 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.

If additional authentication methods are required beyond the initial
one, the authenticator MAY send a Request packet for a subsequent
authentication method, or it MAY send another Identity request. If the
peer does not support additional methods, it SHOULD respond with a Nak,
indicating no acceptable alternative, as described in Section 5.3.
However, peer implementations MAY not respond at all, in which case a
timeout will result and authentication will fail. Since the
authenticator presumably requires successful completion of the sequence
in order to grant access, authentication failure is the correct result.
Therefore, it is not necessary for the authenticator to determine that
the peer supports sequences prior to sending a Request for a subsequent
authentication method.

The above prescription also applies in the situation where an
authenticator sends a message of a different Type prior to completion of
the final round of a given method. If the peer wishes to continue
authenticating with the method in progress, it SHOULD send a Nak in
response to such a Request, indicating the Type in progress as the
alternative. Otherwise it MAY send a Response with the same Type as the
Request. Since an EAP packet with a different Type may be sent by an
attacker, an authenticator receiving a Nak including a preference for
the Type in progress SHOULD log the event, but otherwise not take any
action.

Once a peer has sent a Response of the same Type as a Request, some
existing peer implementations might expect the method to run to
completion. As a result, these implementations silently discard EAP
Requests of a Type different from the method in progress, despite the
requirement for a Response in section 4.1. For this reason, EAP
authenticators that must interoperate with these peers are discouraged
from switching methods before the final round of a given method has
completed."

---

From: [email-masked] (Jari Arkko)
Date: Thu, 06 Mar 2003 23:54:43 +0200

> exactly one authentication method.

I support this. The protocol is simpler, smaller likelihood of
interoperability problems, well in line with original RFC 2284, etc.

> one, the authenticator MAY send a Request packet for a subsequent

Is this MAY against the SHOULD NOT? If yes, you could just use a
"may" and avoid the dueling keywords...

> from switching methods before the final round of a given method has

The same may apply in some of the above as well.

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 14:34:35 -0800 (PST)

OK. How about this?

EAP server, a particular named peer SHOULD NOT
utilize multiple authentication methods (Type 4 or greater), either by

If additional authentication methods are required beyond the initial
one, the authenticator may send a Request packet for a subsequent
authentication method, or it MAY send another Identity request. If the
peer does not support additional methods, it SHOULD respond with a Nak,
indicating no acceptable alternative, as described in Section 5.3.
However, peer implementations MAY NOT respond at all, in which case a
timeout will result and authentication will fail. As a result,
use of sequences is likely to result in interoperability
problems.

Once a peer has sent a Response of the same Type as a Request, some
existing peer implementations might expect the method to run to
completion. As a result, these implementations silently discard EAP
Requests of a Type different from the method in progress, despite the
requirement for a Response in section 4.1. For this reason, EAP
authenticators SHOULD NOT switch methods before the final
round of a given method has completed."

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 06 Mar 2003 21:53:58 -0500

I believe that much of the discussion of appropriate use of methods belongs 
in the security considerations section of the document, not here.  Here we 
should describe the behaviour of the protocol.  Having a SHOULD NOT at this 
point and winking under the table that it is not a MUST NOT so and 
implementer could do something else is something of an end run.  This 
paragraph implies that additional methods that support QoS or other non 
authentication methods are inappropriate.  I feel pretty strongly that they 
are appropriate, and so find this wording in the main description of how 
the protocol works limiting.  The same wording in the security 
considerations (with reference to the different types of methods, both 
authentication and non authentication methods) would be appropriate and 
would serve the same purpose.

--On Thursday, March 6, 2003 2:34 PM -0800 Bernard Aboba 
<[email-masked]> wrote:

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

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 17:46:47 -0800 (PST)

> Having a SHOULD NOT at this
> implementer could do something else is something of an end run.

If you're arguing that the SHOULD NOT should be changed to MUST NOT, I
would agree. Authentication sequences introduce considerable extra
complexity and interoperability issues to the protocol that I would just
as soon be rid of.

---

From: [email-masked] (Joseph Salowey)
Date: Thu, 6 Mar 2003 20:06:11 -0800

Is the main reason why were are limiting this based on security
considerations or is it that it will truly break the protocol state
machine?

If it is due to security considerations then I agree with John that it
should be discussed in the security considerations section and not
mandated in this section.  There are ways to mitigate the risks of
chaining (PEAP for example).    

If it is going to break the protocol state machine then SHOULD NOT is
appropriate.  I think chaining will happen in some cases.  It looks like
it will be required in PEAP and it probably will happen elsewhere.  MUST
NOT is too prohibitive in this case.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Thursday, March 06, 2003 5:47 PM
> To: John Vollbrecht
> Cc: Jari Arkko; [email-masked]
> Subject: Re: [eap] Proposed resolution to Issue 87
> 
> 
> If you're arguing that the SHOULD NOT should be changed to 
> MUST NOT, I would agree. Authentication sequences introduce 
> considerable extra complexity and interoperability issues to 
> the protocol that I would just as soon be rid of.
> 
>

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 20:24:30 -0800 (PST)

> considerations or is it that it will truly break the protocol state

Both, I think. The implementation survey shows no current implementations
that support this, so that interoperability would be compromised. Also,
introducing sequences complicates the state machine, and adds security
vulnerabilities. Plus, the reasons that have been given for this
"extension" (e.g. QoS negotiation) all seem to be out of scope of the EAP
WG charter. Since the scope of RFC 2284bis is largely to *fix*
interoperability problems, not to create them, it's hard to justify.

> NOT is too prohibitive in this case.

Why would this be required in PEAP? From the perspective of the EAP state
machine, PEAP is a single EAP method.

---

From: [email-masked] (Joseph Salowey)
Date: Thu, 6 Mar 2003 21:50:24 -0800

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2003 8:25 PM
> To: Joseph Salowey
> Cc: [email-masked]
> Subject: RE: [eap] Proposed resolution to Issue 87
> 
> 
> Both, I think. The implementation survey shows no current 
> implementations that support this, so that interoperability 
> would be compromised. Also, introducing sequences complicates 
> the state machine, and adds security vulnerabilities. Plus, 
> the reasons that have been given for this "extension" (e.g. 
> QoS negotiation) all seem to be out of scope of the EAP WG 
> charter. Since the scope of RFC 2284bis is largely to *fix* 
> > it will be required in PEAP and it probably will happen elsewhere.  
> > MUST NOT is too prohibitive in this case.
> 
> Why would this be required in PEAP? From the perspective of 
> the EAP state machine, PEAP is a single EAP method.\]

Yes, but EAP also runs within PEAP.

---

From: [email-masked] (Jari Arkko)
Date: Fri, 07 Mar 2003 08:17:18 +0200

> Yes, but EAP also runs within PEAP.  

EAP runs both inside and outside PEAP. But I would
expect these runs to be "independent" instantiations
of the EAP state machine. Or do you actually perform
one EAP run on the outside for PEAP, and then *multiple*
methods inside, one after another?

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 04:40:38 -0800 (PST)

> The same may apply in this case as well.

OK. How about this?

If additional authentication methods are required beyond the initial
one, the authenticator may send a Request packet for a subsequent
authentication method, or it MAY send another Identity request. If the
peer does not support additional methods, it SHOULD respond with a Nak,
indicating no acceptable alternative, as described in Section 5.3.
However, peer implementations may not respond, in which case a
timeout will result and authentication will fail. As a result,
use of authentication sequences is likely to result in interoperability
problems.

Once a peer has sent a Response of the same Type as a Request, some
existing peer implementations may expect the method to run to
completion. These implementations silently discard EAP
Requests of a Type different from the method in progress, despite the
requirement for a Response in section 4.1. For this reason, EAP
authenticators SHOULD NOT switch methods before the final
round of a given method has completed."

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 06:45:18 -0800 (PST)

> NOT is too prohibitive in this case.

The case where chaining occurs within a tunneled method is also somewhat
different in that there is a way of insuring backward compatibility -- an
implementation that doesn't support that method also won't support
sequences within it, and can Nak.

If tunneling is the only application for sequences, then perhaps it really
is appropriate to make sequences a MUST NOT, indicating tunneling as the
exception, since backward compatibility is possible.

As Pasi has been noting, this would potentially simplify the EAP
state machine.

---

From: [email-masked] (John Vollbrecht)
Date: Fri, 07 Mar 2003 11:16:17 -0500

> > The same may apply in this case as well.

I think this is fine except for the parenthetical (Type 4 or greater).  I 
think there may be EAP methods that are not authentication methods that get 
assigned numbers greater than 4.  If we agree that there may me methbods 
that are not auathentication methods and remove the parenthentical 
expression I think this would be good.

John

---

From: [email-masked] (Jari Arkko)
Date: Fri, 07 Mar 2003 22:29:01 +0200

John Vollbrecht wrote:
> I think this is fine except for the parenthetical (Type 4 or greater).  
> I think there may be EAP methods that are not authentication methods 
> that get assigned numbers greater than 4.  If we agree that there may me 
> methbods that are not auathentication methods and remove the 
> parenthentical expression I think this would be good.

What do you mean with non-authentication methods? Would these be

   (a) A new base EAP method, perhaps defined in bis of 2284bis
       at some point? Like a new, improved Identity?

   (b) Methods that don't authenticate but deliver some
       other information, maybe configuration information?

I think (b) is out of scope for EAP. But (a) can certainly happen
at some point. But if it does, wouldn't we update the statement
in the paranthesis at the same time? Also, if we don't have
the number 4 there, how would an implementation know whether
a method Type X is "authentication" or "non-authentication"?

Jari

---

From: [email-masked] (John Vollbrecht)
Date: Fri, 07 Mar 2003 16:31:35 -0500

--On Friday, March 7, 2003 10:29 PM +0200 Jari Arkko <[email-masked]> 
wrote:

> > that get assigned numbers greater than 4.  If we agree that there may
> > me  methbods that are not auathentication methods and remove the
I am thinking of b.  It is out of scope for 2284bis to define such a 
method, but since there is number space for a lot of new methods, some of 
them may be non authentication methods.

> a method Type X is "authentication" or "non-authentication"?
It would know by configuring its rules/policy.  For example, some instances 
might support only MD5, some might support either MD5 or LEAP, others might 
support PEAP/MD5 or TTLS/PAP, etc.  The configurer would have to know 
whether the method was an authentication method or not.  The method 
description should include whether it is an authentication method along 
with  other information about the method.

does this make sense?

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 15:03:21 -0800 (PST)

> a method Type X is "authentication" or "non-authentication"?

The major reason that "authentication" and Type >4 was put in as a
modifier was to allow a sequence involving Identity Request/Response and
an authentication method, or even Identity Request/Response, auth method
Request/Response and Notification Request/Response.

If an implementation can't at least handle an Identity Request/Response
and an auth method, it's pretty broken. I'm not sure about the last case
though. If Notification can be sent at any time, or Identity can be
requeried, then implementations need to be prepared to handle that.

I'm not sure that the proposed language is very clear about these cases.

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 15:10:38 -0800 (PST)

And while we're on the subject of issue 80, I have a basic question:

Are Notifications used with any of the EAP methods defined in RFC 2284?
I'm talking about EAP MD5-Challenge, OTP and GTC. RFC 2284 doesn't mention
use of Notifications in any of those protocols, but doesn't preclude it
either. The question came to mind because the concept of "strict
interpretation" described in Issue 80 is method-specific. So naturally the
question arose "Are the methods defined in RFC 2284 to be strictly
interpreted? If so, what does completion mean?"

Each of the RFC 2284-defined EAP methods is a Challenge/Response protocol,
so there is only one Request and one Response within the method. Since the
peer doesn't authenticate the authenticator, from it's point of view it is
"done" once it sends the Response, but it has no idea whether to expect
Success or Failure, so it will use either one.

The question is: what do these methods do if they receive a packet other
than a retransmission or Success or Failure after sending the Response?
Note that one must be careful not to interpret the filter concept as
prohibiting a response to a retransmitted Request. While it is possible to
install the filter on the authenticator after receiving the first
Response, I don't think that the filter can be installed on the peer after
sending the first Response. After all, it might not get to the
authenticator. So I think that there is a timing issue here --
installation on the peer probably has to wait until receipt of the Request
that is liberated by the first Response. Of course this can be spoofed,
sooo.....

Hmmm. This is not as simple as we thought, is it?

---

From: [email-masked] (John Vollbrecht)
Date: Fri, 07 Mar 2003 19:37:24 -0500

> than a retransmission or Success or Failure after sending the Response?

my suggestion is that strict interpretation only be set for the duration of 
the method.  So, if the method is "done" after one response, there would be 
no point in setting the "strict interpretation" indicator.

> authenticator.

presumable the retransmission rules are not affected by this since they are 
outside the method.  If it sends a message and then gets a Req for the same 
id it just resends the message it send before.

 So I think that there is a timing issue here --

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 15:34:34 -0800 (PST)

> no point in setting the "strict interpretation" indicator.

OK. So none of the methods defined in RFC 2284 support strict
interpretation, right?

---

From: [email-masked] (Jari Arkko)
Date: Sun, 09 Mar 2003 12:27:23 +0200

John Vollbrecht wrote:

> method, but since there is number space for a lot of new methods, some 
> of them may be non authentication methods.
> 
> 
> It would know by configuring its rules/policy.  For example, some 
> instances might support only MD5, some might support either MD5 or LEAP, 
> others might support PEAP/MD5 or TTLS/PAP, etc.  The configurer would 
> have to know whether the method was an authentication method or not.  
> The method description should include whether it is an authentication 
> method along with  other information about the method.

Yes. But regardless of the purpose of the methods, they suffer from
the same interoperability problems, right? What you are suggesting above
is a possible fix to the problem, but I worry about that fix because
it appears to depend on configuration. Furthermore, if I plug in a
non-authentication method to an EAP mux implementation using an API,
I have no control over the capabilities of the MUX; I suspect current
APIs would not have a flag telling the mux that the method is a
"non-authentication method", nor would current implementations
necessarily have support for dealing with the sequencing.

Perhaps we will have non-authentication methods some day. I'm not
fundamentally against them. I'm just saying that if we
adopted non-authentication methods we should carefully discuss
how to do them, in EAP or elsewhere, and if within EAP whether they
should be some sort of attributes within authentication methods
or individual methods.

And, in the interest of getting RFC 2284 bis out of the door as soon
as possible, let's not add new things, and let's try to keep the
protocol as "tight" as possible so that we will get better
interoperability.

Jari

---

From: [email-masked] (Jari Arkko)
Date: Sun, 09 Mar 2003 12:27:40 +0200

> I'm not sure that the proposed language is very clear about these cases.

You may be right about the text. How about changing

    An EAP conversation MAY utilize a sequence of methods. A common example
    of this is an Identity request followed by a single EAP authentication
    method such as an MD5-Challenge. However, <here's the MUST NOT / SHOULD
    NOT for multiple auth methods> ...

to

    An EAP conversation MAY utilize a sequence of methods. In addition to a
    single authentication method (Type 4 or greater), Identity requests and
    Notifications can be appear as discussed in Sections N.N and M.M. However,
    <here's the MUST NOT / SHOULD NOT for multiple auth methods> ...

Jari

---

From: [email-masked] (John Vollbrecht)
Date: Sun, 09 Mar 2003 21:28:37 -0500

--On Friday, March 7, 2003 3:34 PM -0800 Bernard Aboba 
<[email-masked]> wrote:

> > my suggestion is that strict interpretation only be set for the
> > duration of the method.  So, if the method is "done" after one
> > response, there would be no point in setting the "strict
> > interpretation" indicator.
>
yes - that is my take as well

---

From: [email-masked] (Jari Arkko)
Date: Sun, 09 Mar 2003 11:58:05 +0200

Jari

---

From: [email-masked] (Jari Arkko)
Date: Sun, 09 Mar 2003 12:11:11 +0200

to

Jari

---

From: [email-masked] (Joseph Salowey)
Date: Mon, 10 Mar 2003 09:50:48 -0800

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2003 10:17 PM
> To: Joseph Salowey
> Cc: 'Bernard Aboba'; [email-masked]
I would expect the runs inside and outside to be independent of one
another, but inside PEAP you may have multiple mechanisms.  For example

PEAP(EAP-Identity --> EAP-MSCHAPv2 --> EAP-TLV(results, key binding,...
) )

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 10 Mar 2003 09:42:21 -0800 (PST)

> PEAP(EAP-Identity --> EAP-MSCHAPv2 --> EAP-TLV(results, key binding,...

Sure. This case is a bit different than general support for sequences,
because:

a. Sequences are enabled *only* within a specific method -- so that
backward compatibility can be maintained. If a peer implementation doesn't
support the method (and sequences) it can Nak.

b. Presumably a solution will be offered to the man-in-the-middle problem
in this context. It's not clear to me yet whether such a solution is
possible in the general case. Without that, general support for sequences
would create security vulnerabilities with no known fix.