Subject: [eap] Issue #3: No state machine

From: [email-masked] (Bernard Aboba)
Date: Mon, 25 Mar 2002 09:34:50 -0800 (PST)

Issue 3: No state machine
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 25, 2002
Reference:
Document: RFC2284bis-02
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:
RFC 2284bis does not include a state machine description. This makes it
difficult to understand how the protocol works. 
Change:
Incorporate the state machine described in 
http://www.cs.umd.edu/~bdpayne/papers/eap-state-machine.pdf
(Text requested)

---

From: [email-masked] (Bryan D. Payne)
Date: Wed, 27 Mar 2002 16:15:52 -0500 (EST)

> http://www.cs.umd.edu/~bdpayne/papers/eap-state-machine.pdf

Text is now available at...

http://www.cs.umd.edu/~bdpayne/papers/eap.txt

Please note the version number when viewing this file.  Currently, this is
just a text version of the pdf, but it will most likely need updates to
address issues with the state machines.  We will only be updating the txt
file from here on out.

-bryan

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Mar 2002 12:53:20 -0800 (PST)

Thanks for the paper. 

Some comments:

EAP Peer state machine

1. Assuming that the fix to Issue #2 is accepted, then I think EAP will no
longer have the notion of "Out of Band Failure" and "Out of Band
Success". This is a good thing, I think because the out of band
indications were never well defined and they are obviously problematic
from a security point of view. 

2. The resolution to Issue #7 was to add text that enables multiple
methods to be run one after another. So I think this needs to be reflected
in the state machine. 

3. I'd be interested in understanding how the proposed resolution to Issue
#10 (Acknowledged Termination) would address your issue about states
between client and server getting out of sync. Any opinions? 

EAP authenticator state machine

4. RFC 2284 doesn't state that the Identifier is to be initialized to 0 or
that it is to be incremented on each new Request, although many
implementations do this. It only requires that the Identifier be different
for each new Request and that the Identifier not repeat during a
conversation. Of course, running a counter is a good way to accomplish
this. 

5. The state diagram seems to imply that sending an Identity-Request is
mandatory. It isn't, and indeed some of the cryptographically protected
methods may not do this. 

6. The diagram seems to imply that if a NAK is received, then the
Identity-Request is sent again. Actually, the Authenticator will
just choose another method. 

7. There is nothing in the authenticator state diagram to cover
retransmissions. 

8. Again, I'd be interested in how an Acknowledged Termination would
affect the state machine.

---

From: [email-masked] (Bryan D. Payne)
Date: Wed, 27 Mar 2002 17:27:05 -0500 (EST)

> Thanks for the paper.

no problem

> from a security point of view.

agreed, we can update that...

> methods to be run one after another. So I think this needs to be reflected

This is reflected in the state machine.  The policy would determine if the
state machine performs multiple auth methods or not.  Note the transition
from the the "auth method" to "unauthenticated".

> between client and server getting out of sync. Any opinions?

Issue #10 doesn't indicate what happens if the peer replies with a failed
outcome message.  What state does this leave the authenticator in?  And,
if it just restarts the process, then what guarentees that we don't just
cycle through over and over?

> conversation. Of course, running a counter is a good way to accomplish

I'm not completely sure what you're asking for here.  Are you saying that
there should be an Identifier counter in the state machine?  Or ???

> mandatory. It isn't, and indeed some of the cryptographically protected

The diagram actually allows for the authenticator to make this decision.
It can choose to send an ID request or an Auth request from the
unauthenticated state.

> just choose another method.

The state machine allows the authenticator to send a new ID request before
each Auth request if it wants to.  This is because each auth request may
be associated with a different identity.

> 7. There is nothing in the authenticator state diagram to cover

Basically the authenticator just retransmits if too much time has passed
and there is no reply.  This retransmission doesn't affect the state at
all.  We could show this in the state machine with a timer loop on each
state, but it will get very messy.  It may be best to just mention it as
we have already mentioned the handling of invalid messages and notify
messages.

> affect the state machine.

I think that, as currently stated, it is unclear exactly how it would
affect the state machine.  But I'm sure that it will affect the state
machine in some way.  It just depends on how the authenticator and peer
should react to these messages...and this isn't clearly defined in issue
#10.

-bryan

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Mar 2002 13:50:19 -0800 (PST)

> cycle through over and over?

Well, since you raised the issue at the EAP BOF, do you want to hazard a
guess about what should happen? 

> there should be an Identifier counter in the state machine?  Or ???

I've added an issue about explicitly adding a counter to the
specification. 

> be associated with a different identity.

Only if the Type code changes, right?

---

From: [email-masked] (Bryan D. Payne)
Date: Thu, 28 Mar 2002 00:48:13 -0500 (EST)

> guess about what should happen?

Ok, a couple of comments on that:

* Making the Acknowledged Termination simply another type of
request/response will make it very difficult to depict properly in the
state machine.  I feel that this implies some ambiguity that should be
avoided.  For this reason, I suggest that we create an additional EAP
packet type (in Section 4 of 2284bis-03) for these ackknowledged
terminations...

* Assuming the above, when the authenticator sends an acknowledged
termination packet it can move into a success or failure state in
accordance with the data in it's packet.

* If the peer's reply agrees with the authenticator, then all is well.
The peer moves into the appropriate state and the authenticator stays
where it was.

* If the peer's reply does not agree with the authenticator, then everyone
should move back to the unauthenticated state (I propose this instead of
initialization state b/c the policy should not be re-initialized at this
point).  The authenticator and peer should then try to complete the
protocol from there.

The main problem with the above (that I see right now) is that the server
an authenticator could have policies that would never result in an
authentication that both parties are happy with (e.g., the authenticator
uses a "canned success" and the peer wants mutual auth).  For this reason,
we will need a counter to ensure that the peer and authenticator don't
loop forever.  If the counter expires, then everyone should return to the
initialization state.

I'm open to ideas / changes / etc.  This is just my first thoughts on this
matter...

> I've added an issue about explicitly adding a counter to the

To be honest, I'm still kind of confused about this.  I see an issue with
my name by it...but don't agree with what it says entirely ;-)

The issue states...

"The state machine sets the initial Identifier to zero and increments it
on each subsequent new Request. Shouldn't RFC 2284bis-03 mandate this
behavior?"

...however, the state machine does not do anything with the initial
Identifier.  Furthermore, I'm indifferent on this topic.  It seems like
more of an implementation issue than a state machine issue.  If there's a
reason that the identifier should be included in the state machine, please
let me know and we can discuss it.

> Only if the Type code changes, right?

Ahh yes, I'm glad that you brought this up.  I can't find anything about
this in the RFC.  The closest thing that I can find is in "step 1" of
section 2 (2284bis-03) where it is giving an overview of the protocol.

So the answer to your question is "I don't know".  There is no mention of
the ID request only being allowed at this point in time.  As I read the
RFC, the authenticator could send identity requests over and over.  Yes,
this would be pointless...and that's why Nick and I drew the state machine
to at least require ID, Auth, ID, Auth requests or Auth, Auth, ID, Auth,
etc (because ID, ID, ID just doesn't make sense).  Basically, I think that
it makes sense to say that all ID requests will be followed by an auth
request...and that ID requests are not required.  I feel that this is
captured in the state machine pretty well.

Perhaps the RFC should be more specific in dealing with this issue?

-bryan

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Mar 2002 22:24:03 -0800 (PST)

> state machine.  

Can you explain this? NAK and Notification are already special types,
aren't they?

> I feel that this implies some ambiguity that should be

The problem with new packet types is that they will be discarded by *all*
existing implementations, whereas a new method can be NAK'd by those that
don't understand it, enabling backwards compatibility. 

> accordance with the data in it's packet.

Sure. 

> The peer moves into the appropriate state and the authenticator stays

I think that's right. 

> point).  The authenticator and peer should then try to complete the

Yes, that seems right. 

> loop forever.  If the counter expires, then everyone should return to the

Sure.

---

From: [email-masked] (Bryan D. Payne)
Date: Thu, 28 Mar 2002 08:54:25 -0500 (EST)

> Can you explain this? NAK and Notification are already special types,

There are currently 4 types defined in Section 4 of 2284bis-03: request,
response, success and failure.  I was refering to adding another type at
this level, not as "subtypes" of request / response.

> don't understand it, enabling backwards compatibility.

I agree.  This is the classic situation.  We can preserve backwards
compatibility and add a somewhat ambiguous feature, or we can (possibly --
see next paragraph) break backwards compatibility and add the feature in a
manner that causes the fewest problems for the future.

Saying that this idea (adding a new type) will break backwards
compatibility is perhaps questionable.  What do peers currently do if
they receive a packet with an unknown type (i.e., an EAP packet with the
code field set to something other than 1, 2, 3 or 4)?  I would guess that
the message is dropped.  In this case, the authenticator could simply time
out and send a success / failure message.  If the peer does something
other than drop unknown packets, then perhaps there's a problem with it's
implementation (i.e., it could break if there's a network error)?

-bryan

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 29 Mar 2002 06:45:24 -0800 (PST)

> the message is dropped.  

That's probably correct. 

> In this case, the authenticator could simply time
> out and send a success / failure message.  

If no response is received, a timeout will occur -- but the behavior of
existing implementations would be to drop the connection. Sending another
packet isn't possible because RADIUS servers don't retransmit. Since the
NAS hasn't received a response, it can't send an Access-Request to the
RADIUS server, and therefore the connection will stall. 

> If the peer does something

I think the issue is not with silent discard, but in the fact the
retransmission behavior.