Subject: [eap] Issue 76: Multiple methods in sequence

From: [email-masked] (Bernard Aboba)
Date: Tue, 4 Feb 2003 16:12:14 -0800 (PST)

I would like to recommend against this change. RFC 2284bis is not a
greenfield protocol, and so an important consideration is backward
compatibility with existing implementations. To my knowledge, there
are no existing EAP implementations that support sequences.

In discussion it was noted that some implementations would have
fundamental problems in supporting sequences. Also James Carlson noted
that for his implementation, he interpreted the original RFC 2284
language as discouraging sequences:

   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.

In terms of the suggested language here are some issues:

"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. Another example
is an authentication method followed by a method that negotiates QoS
parameters with the user. In both cases only one authentication Method
is used."

[BA] -- RFC 2284bis is focused on clarifying the existing specification
and addressing interoperability issues, not adding major new functionality
such as QoS negotiation.

[Note: it is not considered good practice to allow the peer to
"negotiate down" the EAP methods that do authentication. That is,
trying a different authentication method after failing a method SHOULD
not be allowed.]

[BA] - this would introduce indeterminacy in the state machine, I think.

Sequences are driven by the authenticator end of the EAP connection.
The authenticator proposes a method by sending an EAP request for that
Method. The Peer can accept the method by responding to the request or
refuse the method by responding with a NAK.

On completion of one method the authenticator may attempt to initiate
another method or may signal completion by sending either a Success or
Failure message. Success or Failure messages indicate to the peer that
the sequence is complete and that the authenticator believes the
sequence has succeeded or failed.

Note that each end of the EAP connection may independently decide whether
to activate the connection, and in particular the peer may decide not to
activate the connection based on the results of its EAP methods,
regardless of the Success or Failure from the authenticator. This is
what allow mutual authentication to work.

[BA] This seems like it would create interoperability problems, and
potentially add some security vulnerabilities as well.

Interactions between authenticator and peer in cases where messages are
lost and retransmitted, where unexpected NAKs or timeouts occur are
described in section (xxx or rfc xxx state machine)."

[BA] RFC 2284bis is designed to be a standalone document and should not
depend on the state machine document.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 04 Feb 2003 22:35:33 -0500

> are no existing EAP implementations that support sequences.
[JohnV]I am not sure what the comment about greenfield is meant to imply. 
I don'at think the intent of this is to only define what someone has 
implemented.  If that was the case then a lot of what we have been 
discussing would be moot.  I believe we are to clarify the wording to make 
interoperation possible.  If you do not think sequences should be part of 
this then why have we been discussing them?  Implementations should not be 
required to implement sequences, but they should be allowed.

>    each of which identifies exactly one authentication method.
[JohnV] We have had this discussionon the list.  we agree that negotiating 
down authentication methods is a bad idea.  We apparently don't agree that 
other methods should  be allowed.  I know that there are designs which 
expect to use eap method sequences, and prohibiting them would limit what 
can be done within the scope of the original rfc.

> and addressing interoperability issues, not adding major new functionality
[JohnV] Nothing here is adding QoS functionality.  The intent was to 
indicate that sequences are legal.  If QoS is a bad example then we should 
find another.
> [BA] - this would introduce indeterminacy in the state machine, I think.
[JohnV] - I don't think so -- the state machines are designed to handle 
exactly this.
> potentially add some security vulnerabilities as well.
[JohnV] I don't see why -- can you be more specific about the problems and 
vulnerabilities?

> depend on the state machine document.
[JohnV] I agree that it should be stand alone.  That is why I suggested 
section xxx.  Some of the text for section xxx might be driven off the 
state machine, and I am beginning to think the state machine would be a 
good appendix.  Without it there will confusion about how EAP should 
actually work.
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 4 Feb 2003 20:13:08 -0800 (PST)

> If you do not think sequences should be part of

There's no language in RFC 2284 suggesting that sequences are a MUST NOT,
nor has anyone so far suggested that they be forbidden.

On the other hand, we have had input from implementors that say that their
implementations would not react well to sequences, can't implement sequences,
or interpret RFC 2284 as discouraging use of sequences.

Also, there have been questions about whether sequences open up new
security vulnerabilities (draft-puthenkulam-eap-binding-01.txt).

Given all of this, it's hard to make a case that RFC 2284bis can
be neutral on the subject. The suggestion from James (and others) was to
interpret the RFC 2284 admonitions as applying to sequences. Given all the
evidence, this seems like a reasonable thing to do.

> can be done within the scope of the original rfc.

It's hard to argue that RFC 2284bis is imposing a limitation when
implementors seem to be assuming that the limitation was part of
RFC 2284.

> [JohnV] I don't see why -- can you be more specific about the problems and

Bill Arbaugh's group has written about attacks by rogue APs where the
rogue can convince the peer that it has connected to a legitimate network.
This occurs because the peer accepts an EAP Success in the middle of an
EAP method. The solution to that was addressed in Section 4.2.1 --
potentially to drop unexpected Success/Failure messages.

There is also some text relating to protected/unprotected EAP
Success/Failure. However, the problem is that these indications apply only
to methods, not to the EAP conversation as a whole. So the client can't
just say "I'm authenticated" because it succeeded within a method --
because the EAP authentication might not be complete. However, it can say
"I've failed or the authenticator has failed" and disconnect if any method
fails.

> good appendix.  Without it there will confusion about how EAP should

The problem is that the state machine document is likely to take quite a
bit longer to complete (after all, it's not even a WG work item yet) and
there are hard deadlines for completion of RFC 2284bis.

Pushing out RFC 2284bis is likely to cause references to it to be removed
in other documents, and will also delay followon work requested by IEEE
802.11i and 3GPP.

---

From: [email-masked] (Jari Arkko)
Date: Wed, 05 Feb 2003 15:52:50 +0200

> implementors seem to be assuming that the limitation was part of

John, when you say "there are designs" -- do you mean existing implementations
that use sequences for something, or planned implementations that use sequences
for some new task? Do you have specific knowledge of deployment which
uses sequences?

I agree with Bernard in that sequences seem to bring a number of
troublesome issues for us. If people seem to believe that they were
forbidden in the original RFC (even if the text is unclear), it
might make sense to disallow sequences. However, if the use of
sequences is already widespread I wouldn't feel too good about
making them illegal.

> in other documents, and will also delay followon work requested by IEEE

This is important. We need to get 2284bis out as soon as possible.
It is OK if the state machine comes out slightly later.

Question: where are we now in terms of the relationship of the
two documents? Are we expecting to be able to produce 2284bis without
a normative reference to the state machine document?

Jari

---

From: [email-masked] (James Carlson)
Date: Wed, 5 Feb 2003 09:05:23 -0500

> sequences is already widespread I wouldn't feel too good about

Just to clarify (or perhaps muddy the water even further): I read the
text in 2284 as indicating that it was a "bad idea" to use sequences.
I therefore support arbitrary sequences (including switching methods
midstream) fully in the authenticatee (client) side, but provide no
means of configuring any multiple authentication method sequence on
the authenticator (server) side.  The authenticator issues Identity
(if it does not have a preconfigured peer identity), and then tries
configured authentication methods until it finds one that isn't Nak'd
(or gives up).  Once that one agreed-on method is complete, it sends
Success/Failure, and it's done.

> a normative reference to the state machine document?

I would be opposed to normative references to a state machine
document.  That is one *possible* implementation, but I see no reason
to require it as the only implementation.  If published as a separate
document, I'd expect a state machine description to be on
Informational track, and RFC 2026 says:

   Note: Standards track specifications normally must not depend on
   other standards track specifications which are at a lower maturity
   level or on non standards track specifications other than referenced
   specifications from other standards bodies.  (See Section 7.)

2284 needs to be complete on its own.

-- 
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: Wed, 05 Feb 2003 09:32:55 -0500

--On Tuesday, February 4, 2003 8:13 PM -0800 Bernard Aboba 
<[email-masked]> wrote:

> > this then why have we been discussing them?  Implementations should not
> > be required to implement sequences, but they should be allowed.
>
So this means they are ok if used properly, right?

> implementations would not react well to sequences, can't implement
> sequences, or interpret RFC 2284 as discouraging use of sequences.
>
Others have not interpreted it this way.  Allowing it does not require it.

> security vulnerabilities (draft-puthenkulam-eap-binding-01.txt).
but not if the other methods are not authentication methods.

> evidence, this seems like a reasonable thing to do.
I think the existing wording is way too strong and implies that sequences 
are not allowed.  I think the same warning about multiple authentication 
methods can be included without implying that sequences with methods for 
other purposes can be included.

> > [JohnV] We have had this discussionon the list.  we agree that
> > negotiating down authentication methods is a bad idea.  We apparently
> > don't agree that other methods should  be allowed.  I know that there
> > are designs which expect to use eap method sequences, and prohibiting
> > them would limit what can be done within the scope of the original rfc.
>
not all implementors

> > > Note that each end of the EAP connection may independently decide
> > > whether to activate the connection, and in particular the peer may
> > > decide not to activate the connection based on the results of its EAP
> > > methods, regardless of the Success or Failure from the authenticator.
> > > This is what allow mutual authentication to work.
> > >
> > [JohnV] I don't see why -- can you be more specific about the problems
> > and vulnerabilities?
>
the language I suggest did not contradict this.

> "I've failed or the authenticator has failed" and disconnect if any method
yes - the language about protected/unprotected success and failure is 
confusing.  I think we should do something about it, but I don't think it 
impacts the sequence issue.

> > > [BA] RFC 2284bis is designed to be a standalone document and should
> > > not depend on the state machine document.
> > >
Actually I think the state machine is closer to being done than the rest of 
the document.  Nick has a new set of diagrams, and we have worked out the 
interactions with 802.1x.  We are planning to work with 802.11 to sort that 
out.

> in other documents, and will also delay followon work requested by IEEE
I understand.  I think having a section on how retransmisssion, duplicate 
detection, handling of success and failure, naks, DOS would be useful and 
speed things up rather than slow them down.

---

From: [email-masked] (Nick Petroni)
Date: Wed, 5 Feb 2003 09:43:41 -0500 (EST)

[ sorry for changing the subject, but I think the previous
  message had two ].

I am an IETF newbie, so forgive my ignorance. I am sure the following text
is not as limiting as it reads, but what are our actual options for not
referencing/including the state machine in 2284bis? Since the words are
"intended to be covered", does that mean it could be left out completely?

This is from the EAP WG page:

<begin quote>
1. IANA considerations for EAP. 2. Type space extension to support an
expanded Type space. 3. EAP usage model. 4. Threat model and security
requirements. 5. EAP state machine. 6. Documentation of interaction
between EAP and other layers. 7. Resolution of interoperability issues. 8.
EAP keying problem description and requirements.

Items 1-7 are intended to be covered within RFC 2284bis, the revision to
the EAP specification. Item 8 will be covered within a separate document
<end quote>

---

From: [email-masked] (James Carlson)
Date: Wed, 5 Feb 2003 10:07:28 -0500

Nick Petroni writes:
> referencing/including the state machine in 2284bis?

So-called "informative references" (cases where the reader might want
to refer to the state machine document, but is not required to) are
fine.  "Normative references" (cases where the reader _must_ refer to
the state machine document in order to understand the material
completely) are bad, assuming that the state machine document is at a
lower level than the base document.

---

From: [email-masked] (Jari Arkko)
Date: Wed, 05 Feb 2003 17:39:36 +0200

There appears to be two issues here:

1. Getting RFC 2284 bis published in the next few weeks or in the next IETF
    without waiting for the state machines to be fully approved at the same
    time. If we are to do this, we can't refer to normative references that
    aren't done yet.

2. The type of the state machine document, standards track mandatory-to-support
    or informational?

My desire is to make no 1 above happen somehow. Perhaps we can omit any
reference to the state machine or have it in the non-normative references
part. Also, we can't contradict anything that will eventually be in the
state machine document when its approved. Hopefully we have a good
idea about that already.

On no 2 above... why do you James think that it should be only an
informational? Do you believe there is something that would not
apply to all implementations? Or do you think that the rules in
2284 bis are sufficient and the state machine is just an illustration
of them in a state machine form? Or do you think the implementations
shouldn't require to implement the state machine just as described,
only the results should be the same? I certainly hope we don't
describe any behaviour in the state machine document that isn't
followed by all implementations!

Jari

---

From: [email-masked] (Nick Petroni)
Date: Wed, 5 Feb 2003 10:50:08 -0500 (EST)

A previous mail I sent (possibly just to eap-design) inquired about
whether MUSTs only should be in the state machine, or SHOULDs as well. I
assume not all implementations will do SHOULDs, so how does that play out?
I believe a popular opinion at that point was to include as much of the
document as possible.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 5 Feb 2003 06:44:52 -0800 (PST)

> So this means they are ok if used properly, right?

I think that it's more along the lines of "this is discouraged, so think
carefully before you do this." But there is no prohibition.

> Others have not interpreted it this way.

Can you give an example of who those "others" are? Are these deployed
implementations? Implementations in progress? EAP peers? Authenticators?

> but not if the other methods are not authentication methods.

Unless the additional methods are somehow protected by keys that are sent
earlier, it would seem like a vulnerability would be created, since the
additional "method" would be unprotected. And since the [RFC2548] keying
attributes can only be sent in an Access-Accept, it isn't clear how
existing implementations could accomplish that.

> other purposes can be included.

Can you cite the text that says that sequences MUST NOT be used? This is
probably more like a SHOULD NOT.

---

From: [email-masked] (James Carlson)
Date: Wed, 5 Feb 2003 10:59:51 -0500

Jari Arkko writes:
> informational?

Because it doesn't actually document the bits on the wire, but rather
documents one possible way to achieve those bits.  Anything that
achieves the right interoperable result (including -- yecch! -- an O-O
decomposition or -- double yecch! -- hard-coded message processing or
-- unspeakable -- internal message passing) is acceptable.

> Do you believe there is something that would not
> only the results should be the same?

As far as IETF documents go, interoperability is all that really
matters, and it's the only goal.  Standards-track documents generally
don't talk about how to implement the protocol, but rather only how
the protocol behaves.  This is the tradition -- protocols last a long
time, but design methods and computing systems don't.

So, yes, it's that I see no requirement that anyone actually implement
the state machine as documented.  As long as the implementation is
interoperable and the observed behavior on the wire conforms with what
other EAP implementations and RFC 2284 require, I don't see how an
outside observer (lacking access to the source code) could actually
"know" whether the internal implementation details included an
explicit state machine or something rather different.

Since there's no way to tell the difference, it seems rather vacuous
to "require" that as part of an implementation.

> I certainly hope we don't

That's exactly the point.  If the state machine somehow documents
something that is *NOT* documented by 2284, and that behavior is
actually required for interoperability, then I think you have a
problem.

If the behavior of the state machine itself is the normative reference
for how the protocol is supposed to behave, then I think it needs to
be part of 2284, and I have a hard time seeing how they could live
independently.

---

From: [email-masked] (Jari Arkko)
Date: Wed, 05 Feb 2003 19:10:22 +0200

> I believe a popular opinion at that point was to include as much of the

I think the right answer is that the state machine transitions
should somehow indicate the "keyword strength" involved. I'm sure
some are MUST, some are weaker such as SHOULD or MAY. Can you
make the MUST arrows black, SHOULD arrows red, and MAY arrows
green ;-) ?

Jari

---

From: [email-masked] (Jari Arkko)
Date: Wed, 05 Feb 2003 19:27:00 +0200

> -- unspeakable -- internal message passing) is acceptable.

First, I agree with your yecch-classification of implementation
techniques ;-)

But I actually think the state machine is not about the
internal way to achieve bits. It may seem that way because
it describes a picture which you might not exactly follow
in your implementation if you used one of the yecchy techniques.

However, what I think matters is the set of legal message
sequences defined by the state machine. You could think
of it as a the BNF description of what the protocol message
sequences can be. Like an implementation of an RFC containing
some BNF, we don't actually require you to use this specific
technique (BNF) but we do require you to follow the language
defined by it.

The distinction should be made clear in the state machine
draft. For instance: "All EAP implementations MUST follow
the legal sequences of events defined by the state machine,
regardless of whether the used implementation technique
actually provides a state machine or not."

> time, but design methods and computing systems don't.

I agree, but I see a state machine as a specification rather
than an implemetnation.

> interoperable and the observed behavior on the wire conforms with what

Exactly.

> to "require" that as part of an implementation.

I think one could see a difference. For instance, the peer state
machine doesn't allow any sequence of EAP messages to be sent.
As an example, it would surely be against the state machine to
send a response without receiving a request. If your implementation
sends a response without me sending a request to it, I would
have been able to tell that your implementation doesn't follow
the RFC.

Of course, this particular rule is also in 2284bis. Are all
rules in 2284bis? In exactly the same form? If yes, then we
may have a state machine that is used more for illustrative
purposes, another representation of the *same* rules that
you have to follow anyway. In that case it may not be _necessary_
to make the state machine RFC mandatory. (But this is still
different from saying that we don't have to follow the state
machine.)

Where does all this leave us? I guess we are finding out that
whatever we do, 2284bis and the state machine need to be in
good sync... We do have some options as to the RFC status
of the state machine document. And I think we can agree that
in any case the state machines should not be viewed as implementation
requirements but rather as specifications defining rules the
implementations must follow.

Jari

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 5 Feb 2003 13:04:10 -0500

> for some new task? Do you have specific knowledge of deployment which

Actually, there is a DSL scenario in PANA that might use sequences, in
which one method is used for NAP (network access provider) to
authenticate the client, and the other method is used for ISP to
authenticate the client.  The client would use different identities
for each method.  By this way, the NAP can provide NAP-specific
network access services independent of what the ISP provides.  (Note
that the assumption is both NAP and ISP shares the same NAS for
authenticating the client.)

To be fair, it is also possible to run multiple set of EAP
conversations in a single PANA conversation, where each EAP
conversation contains one authentication method (besides Identity).

Yoshihiro Ohba