Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4

From: Nick Petroni <[email-masked]>
Date: Thu, 15 Jul 2004 02:59:02 -0400 (EDT)

Florent and all,

As Monday 7/19 is the cut-off for document submission, I would like to ask
for help in resolving as much of the remaining issues as possible in the
state machine document. Here is a list of necessary changes as I see them
for Issue 248. Please let me know how these look in principle and
contribute text if possible. I also will attempt to contribute text over
the next couple of days.

Thanks,
nick

Comment #5 - Technical
  No changes.

Comment #6 - Technical
  Request text to clarify the use the methodState variable in section
  4.2.

Comment #9 - Technical
  Request text amendments for policy functions to clarify that
  multiple authentication methods are not expected or propose
  alternate solution.

Comment #10 - Technical
  - change the text of TIMEOUT_FAILURE in section 5.5 and
    TIMEOUT_FAILURE2 in section 7.5 to the following:
  "A final state indicating failure because no response has been
   received. Because no response was received, no new message
   (including failure) should be sent to the peer."

Comment #12 - Technical
  Supersede by the resolution of Issue 251 (TBD).

Comment #14 - Technical
  Request text to describe the possible DoS issues and possible
  mitigation techniques. Specific changes to the SM necessary to
  achieve such mitigations would be great.

Comment #17 - Technical
  Request text for section 7 and/or section 8 to
  describe expected behavior when aaaEapRespData is NONE.

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

---

From: Nick Petroni <[email-masked]>
Date: Thu, 15 Jul 2004 08:00:20 -0400 (EDT)

A proposal from Pasi... Looks good to me.

>   describe expected behavior when aaaEapRespData is NONE.

Here's also some text related to issue 248 comment #17:

  In Sections 6.1.1 and 7.1.2 change

  "aaaEapResp ... Indicates an EAP response is available for
  processing by the AAA server.

  aaaEapRespData ... The EAP packet to be processed."

  to

  "aaaEapResp ... Usually indicates that an EAP response, stored in
  aaaEapRespData, is available for processing by the AAA server.
  If aaaEapRespData is set to NONE, indicates that the AAA server
  should send the initial EAP request.

  aaaEapRespData ... The EAP packet to be processed or NONE."

---

From: Florent Bersani <[email-masked]>
Date: Fri, 16 Jul 2004 07:15:11 +0200

>A proposal from Pasi... Looks good to me.
So does it for me :-)

---

From: Florent Bersani <[email-masked]>
Date: Fri, 16 Jul 2004 17:20:20 +0200

Nick, all

I looked again at my comment #6 and the current text in the draft.

I guess that my original comment was twofold:
1) Since among the 9 theoretically possible (methodState,decision) 
pairs, only 6 were allowed (namely (CONT,FAIL), (MAY_CONT,COND_SUCC), 
(MAY_CONT, FAIL), (DONE, COND_SUCC), (DONE, UNCOND_SUCC) and 
(DONE,FAIL), I took this as a hint that there might be simpler way to 
implement things...
1) While thinking on simpler ways, I came to question the usefulness of 
COND_SUCC: to me this decision value is harmful from a security POV. An 
attacker has no problem whatsoever to make the peer believe anything 
(i.e. success or failure) as soon as the peer has set COND_SUCC. So my 
comment was about: do we want to keep COND_SUCC? (same comment applies 
to MAY_CONT: I fail to see why we have (MAY_CONT,FAIL) - it could be 
replaced by (CONT,FAIL), couldn't it?)

This reflexion led me to the mechanism EAP-PSK currently uses to (try 
to) end properly its dialog, see 
http://perso.rd.francetelecom.fr/bersani/EAP_PSK/draft-bersani-eap-psk-03-d.html#rflag 
for a presentation of this mechanism (sorry for this rude ad on EAP-PSK 
but I think that what's in there could clarify my comment... and 
possibly get me some feedback ;-)).

After rereading the state machine draft , I believe that the text of 
section 4.2 is pretty clear (congratulations ;-)). My only remaining 
unanswered question is: do we want to keep COND_SUCC?

I am in favor of deleting it (as a legacy venue for irritating - though 
perhaps not very important - security trouble)...

... but I understand that I am probably *unfortunately* the only one to 
have this position and that it is probably too late to change this 
direction (don't worry, I am not going at this point  to try and reopen 
issues like #26 
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2026 or others by 
saying that the current EAP-Success/Failure packet is not only useless 
but harmful ;-))

As a fall-back solution, I would recommend inserting something like the 
following text advising that COND_SUCC may be dangerous:

"In case the peer reaches the decision COND_SUCC, please note that the 
peer is vulnerable to an active attacker that may easily lead him to 
believe that the authenticator has reached any decision the attacker 
chooses. In situations where security is a concern, it is RECOMMENDED to 
avoid using the value COND_SUCC of the decision variable"

What do you think?

Florent, so tired he does not doubt that he may well again be totally 
off the rocket :-(

Nick Petroni wrote:

>...
Florent Bersani wrote:

> Comment #6 - Technical
>
> This is about DONE, CONT and MAY_CONT/UNCOND_SUCC, COND_SUCC and FAIL.
>
> While I do not doubt that there are could technical reasons to use 
> these variables (rather than simply CONT and DONE) and that the EAP 
> state machine does not claim to be THE way to implement EAP (in its 
> introduction "The State Machine and associated model are informative 
> only. Implementations may achieve the same results using different 
> methods"), I think that giving briefly the rationales behind this 
> choice (which is not explicit in section 4.2 IMHO) would help the 
> reader. In particular, giving an example of MAY_CONT's usefulness.
>
> About the decision variable, here also an explanation of the design 
> (maybe with an example) could help. Indeed, it seems to me that not 
> all pairs (state, decision) are acceptable so state/decision are not 
> totally independent. Here again, giving an example why COND_SUCC was 
> introduced could help.
>
> I think this concern is also related to the conditions in the state 
> machine that allow the peer to transition to success or failure. They 
> do not appear to be either trivial or symmetric. The newbie I 
> unfortunately am, needs much more time to (fully) understand them than 
> any other transition condition in the state machine. Bernard for 
> instance questioned about these Success/Failure transitions in Issue 
> 229. For instance, I am wondering, how the condition "altAccept && 
> methodState != CONT && decision == FAIL" may occur.
>
> Also in section 4.2 I tend to feel dizzy with some text in the 
> paragraph methodState=DONE: "If both (a) the server has informed us 
> that it will allow access and the next packet will be EAP Success,and 
> (b) we're willing to use this access, set decision=UNCOND SUCC." I 
> guess that condition (a) should rather be formulated in terms of 
> altAccept, shouldn't it?

As a reminder, this has been clarified. I was totally wrong and 
confused. altAccept referred to lower layer indications and not method 
protected result indication. altAccept has been relaebeled 
lowerLayerAccept (or something like this IINM).

> Indeed while IIRC RFC 3748 mandates (in section 4.2 "The authenticator 
> MUST transmit an EAP packet with the Code field set to 3 (Success)"  
> that a success packet be sent, this does not guarantee that the peer 
> will ever receive it.

---

From: Florent Bersani <[email-masked]>
Date: Fri, 16 Jul 2004 17:30:02 +0200

Nick, all

Here is some proposed text:

Add to the definition of Policy.getNextMethod (section 5.4 page 20 of 
the .pdf):
"Policy.getNextMethod MUST comply to RFC 3748 that forbids, in its 
Section 2.1, the use of sequences of authentication methods within an 
EAP conversation. Hence, if an authentication method has already been 
executed within an EAP dialog, Policy.getNextMethod MUST NOT propose 
another authentication method within the same EAP dialog"

What do you think of it?

Florent

Florent Bersani wrote:

> Comment #9 - Technical
>
> Apparently Figure 4 (EAP Standalone Authenticator State Machine) 
> leaves the door open to a sequence of EAP authentication methods 
> (which is explicitly forbidden by RFC 3748 section 2.1 "However, the 
> peer and authenticator MUST utilize only one authentication method 
> (Type 4 or greater) within an EAP conversation"). This behavior may be 
> prevented thanks to Policy.getDecision or PolicygetNextMethod... but I 
> do not find this is exactly a matter of policy and at least, this 
> should be pointed out (that the policy MUST forbid this behavior).

---

From: Florent Bersani <[email-masked]>
Date: Fri, 16 Jul 2004 17:43:00 +0200

Nick all,

see in-line

Florent, who won't fight on wordsmithing ;-)

>   (including failure) should be sent to the peer."
Great!
Perhaps even a little bit that text by appending: "this is why this 
state needs to be distinct of the FAILURE state"

Florent Bersani wrote:

> Comment #10 - Technical
>
> Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE 
> state?

---

From: Florent Bersani <[email-masked]>
Date: Fri, 16 Jul 2004 17:46:12 +0200

>  Supersede by the resolution of Issue 251 (TBD).
It would be great if some luminaries could enlighten us on this!!!!

Florent, who hates to spend time to educate others but loves being 
educated ;-)

> Comment #12 - Technical
>
> This one is stupid but what happens, according to Figure 4, when the 
> standalone authenticator fails directly, i.e. starts by INITIALIZE, 
> transitions to SELECT_ACTION where Policy.getDecision replies FAILURE 
> and thus transitions to FAILURE - in the FAILURE state, I bet there is 
> some problem with eapReqData = buildFailure(currentId) since 
> currentId=NONE

---

From: Florent Bersani <[email-masked]>
Date: Fri, 16 Jul 2004 17:52:15 +0200

Nick, all

>  achieve such mitigations would be great.
I am reluctant to provide text and modifications to the SM for this one 
(*although I already did in some of my previous mails*) because my 
understanding was that the group had not reached consensus on whether 
this issue has to be handled and how this has to be done...

If the group is (apart from silent) against this issue (and the stupid 
DoS ones in general) which seems to be the case IINM, then I might want 
to save my text/modifications for some other purposes... ;-)

Florent

Florent Bersani wrote:

> Comment #14  - Technical
>
> I am totally novice to DoS (I found a lot of papers on the subject, 
> for instance related to IKE - I plan to read them soon :-)) so this 
> point is probably not very important (my understanding is that one of 
> the difficulties with DoS is to understand what is really relevant and 
> what rather belongs to the .11 microwave oven attack, another one 
> could be set the trade off between DoS resilience and "efficiency").
>
> It just seems to me that Figure 4 prevents the standalone 
> authenticator from ignoring (bogus) NAKs. Indeed, let us consider a 
> corporate WLAN deployment where exactly one EAP method is allowed - so 
> that no valid user will ever NAK. In this setting, there is no point 
> in processing the NAK, possibly loosing the valid user's response if 
> the attacker's NAK arrived first and starting all over. I did not find 
> text on this in RFC 3748 (the text I found was about preventing NAKs 
> when a response to a method has already been received) which is not 
> our case here.

---

From: Nick Petroni <[email-masked]>
Date: Fri, 16 Jul 2004 12:09:15 -0400 (EDT)

> this issue has to be handled and how this has to be done...
Sorry, I should have been more clear on this. I think we are agreed that
no changes should take place to the SM itself. However, some of the
possible protocol changes pointed out by yourself and John Vollbrecht, and
discussed on this list, could be described at least in terms of the
vulnerabilities themselves. Jari mentioned that such a description might
be fitting:
http://mail.frascone.com/pipermail/eap/2004-June/002580.html

"As a result, I would recommend documenting the specific
vulnerabilities to accepting NAKs and Failures. I think
RFC 3748 already has some general text about this, but it
would be OK for the state machine document to talk about
specific issues related to specific state transitions.
I am a bit uneasy about changing the actual diagram or
behaviour, however. "

This seems the most prudent to me and it was the text I was requesting.

> to save my text/modifications for some other purposes... ;-)
I agree modifications would not be the consensus of the group, but I think
everyone recognizes these attacks are feasible.

Thanks,
nick

---

From: Nick Petroni <[email-masked]>
Date: Fri, 16 Jul 2004 12:10:47 -0400 (EDT)

> state needs to be distinct of the FAILURE state"
Sure, it's fine with me. I think it could be determined by reading the
states themselves, but this text is by no means excessive.

nick

---

From: Nick Petroni <[email-masked]>
Date: Fri, 16 Jul 2004 12:22:23 -0400 (EDT)

> unanswered question is: do we want to keep COND_SUCC?
I think the answer is we have to. Some methods simply will not know
whether or not they are complete and actually must wait for Success or
Failure or another request to be received. We cannot exclude (for
legacy purposes) methods that cannot say for certain that they are not
complete or do not know the success of the method itself. COND_SUCC is
the only way to handle methods like MD5 where you have no idea if you
authenticated correctly or not. you have to wait for success or failure.

> saying that the current EAP-Success/Failure packet is not only useless
I don't think you could change it if you wanted to... I think the charter
is pretty clear that existing methods can't be made obsolete. I could be
wrong though.

> avoid using the value COND_SUCC of the decision variable"
This would be a good recommendation to method writers I think, but I am
not sure a general claim about setting that variable alone is enough. We
could add some guidelines for method authors in the Implementation
Considerations section or perhaps better somewhere else? IMHO, the
middle of the SM description is not the place to get into this.

---

From: Nick Petroni <[email-masked]>
Date: Fri, 16 Jul 2004 12:22:51 -0400 (EDT)

Looks good to me. Thanks for all of the comments, suggestions, and text.

Best,
nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

---

From: Florent Bersani <[email-masked]>
Date: Fri, 16 Jul 2004 18:52:40 +0200

Nick,

see in-line

Florent

Nick Petroni wrote:

>complete or do not know the success of the method itself.
>
Aaaaaaaaaaaaaarghn the L word in a protocol that apparently is becoming 
pervasive for the future (invading IKEv2, IEEE 802.1X, IEEE 802.11, IEEE 
802.16e, and why not IEEE 802.20)!

I am aware of what you say but I respectfully and strongly disagree.: if 
EAP is going to be a protocol of the future why cripple it with problems 
of the past.

This being said (and I expected your answer), I won't keep bothering 
with old (and given the point where we are now, slightly unconstructive) 
remarks.

> COND_SUCC is
Again I wish that MD5-Challenge would disappear ;-)

>is pretty clear that existing methods can't be made obsolete. I could be
No, no I think you are right

>not sure a general claim about setting that variable alone is enough.
>
I think that you have seen only the aspect: "a good EAP method SHOULD 
provide protected result indications to avoid using COND_SUCC" but you 
have overlooked the aspect "EAP peer and server SHOULD use only good EAP 
methods" ;-)

I agree that the EAP state machine is probably not the best doc for his 
manifesto but since it is the State Machine that introduces COND_SUCC 
(which is not mandated by RFC 3748), then I'd recommend providing 
guidance on the usage of this "dangerous" variable.

> We
The IEEE 802 requirements probably have a word on protected result 
indications (I got to check that)... but I'd rather have IETF also state 
its opinion on EAP methods (while this could be done in a future IETF 
"how to design a good EAP method" document, I'd rather not count on the 
future and do what is possible now ;-)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Fri, 16 Jul 2004 14:54:06 -0400 (EDT)

Florent,

I certainly appreciate your opinion, but I hope you know that it is not
me with whom you are disagreeing. I am simply explaining what I understand
the constraints of this working group to be. I share your admonishment for
using bad methods, but it has been my understanding from the beginning
that these are our constraints. Sorry if this ruins your day :(. If I am
wrong, someone else can certainly correct me freely. It has certainly
happened on more than one occasion :).

Take care,
nick

Nick L. Petroni, Jr.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Jul 2004 22:18:42 +0300

Florent, Nick,

First: thanks for going through the remaining issues!

>>802.16e, and why not IEEE 802.20)!

Welcome to the real world :-(

>>EAP is going to be a protocol of the future why cripple it with problems
(snip)
>>Again I wish that MD5-Challenge would disappear ;-)

Fortunately or unfortunately, EAP is already deployed. We have
created this working group in the IETF to "fully document and
improve the interoperability of the existing EAP protocol" (quoting
our charter). I think we should adopt better alternatives
and designs whenever we can -- and I think we have often done
that when working with the details -- but not when it would affect
backwards compatibility. EAPv2 is also off-limits for our
working group, though of course individuals in the group
can pursue, say, next-gen network access protocol designs
in their research work.

So, lets keep resolve the other stuff the best we can,
but not outlaw existing EAP methods. And as I have
said before, it would be good to have text to point
out specific vulnerabilities and issues in existing
EAP methods and the "L" part of the state machine.

I think RFC 3748 is our primary document regarding
the security properties of EAP (or lack thereof),
so I don't think we should hold the publication of the
state machine to develop such text. But if you already
have such text or you can clearly see what the implications
are, please send text so that Nick can put it in.

--Jari (the co-chair hat on)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Sat, 17 Jul 2004 19:20:24 +0200

Nick,

Please see in-line some answer to your email and Jari's... and some 
proposed text for the "DoS issues".

Hope this helps,

Florent

> are, please send text so that Nick can put it in.

What about the following text (alluding to the potential well-known 
vulnerabilities):

Add to section 8 "Implementation considerations" of the EAP state 
machine draft (or to section 9 "security considerations"):

"As noted in RFC 3748 there are some security concerns that arise 
because of the following EAP packets:

   1. EAP-Request/Response Identity
   2. EAP-Response/NAK
   3. EAP-Success/Failure

Since these packets are not cryptographically protected by themselves, 
an attacker can modify them without immediate detection by the peer or 
the server.

Following Figure 3 specification, an attacker may cause denial of 
service by:

    * Sending an EAP-Failure to the peer before the peer has started an
      EAP authentication method. Indeed, as long as the peer has not
      modified the methodState variable which is initialized to NONE,
      the peer MUST accept an EAP-Failure.
    * Forcing the peer to engage in endless EAP-Request/Response
      Identity exchanges before it has started an EAP authentication
      method. Indeed, as long as the peer has not modified the
      selectedMethod variable which is initialized to NONE, the peer
      MUST accept an EAP-Request/Identity and respond to it with an
      EAP-Response/Identity

Following Figure 4 specification, an attacker may cause denial of 
service by:

    * Sending a NAK to the server after the server first proposes an EAP
      authentication method to the peer. Indeed, as the methodState
      takes the value PROPOSED, the server is obliged to process a NAK
      that is included in response to its first packet of an EAP
      authentication method.

There MAY be some cases when it is desired to prevent such attacks. This 
can be done by modifying initial values of some variables of the EAP 
state machines. However, such modifications are NOT RECOMMENDED.

There is indeed a tradeofff between mitigating these denial of service 
attacks and being able to deal with EAP peers and servers in general. 
For instance, should the sending of a NAK to the server after it has 
just proposed an EAP authentication method to the peer be ignored, then 
a legitimate peer that is not able or willing to process the proposed 
EAP authentication method would fail without an opportunity to negotiate 
another EAP method."

What do you reckon?

> --Jari (the co-chair hat on)

Nice hat ;-)

Nick Petroni wrote:

>me with whom you are disagreeing.
>
I know that, don't worry.

> I am simply explaining what I understand
>the constraints of this working group to be.
>
It seemed like I just felt being reminded them by our beloved chairs ;-)

> I share your admonishment for
>wrong, someone else can certainly correct me freely.
>
I think (as Jari) that you are right :-))

> It has certainly

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 22 Jul 2004 14:48:16 -0400

looks good to me as well - John

--On Friday, July 16, 2004 12:22 PM -0400 Nick Petroni 
<[email-masked]> wrote:

> > > As Monday 7/19 is the cut-off for document submission, I would like
> > > to ask for help in resolving as much of the remaining issues as
> > > possible in the state machine document. Here is a list of necessary
> > > changes as I see them for Issue 248. Please let me know how these
> > > look in principle and contribute text if possible. I also will
> > > attempt to contribute text over the next couple of days.
> > >
> > > Thanks,
> > > nick
> > >
> > >
> > >
> > > Comment #9 - Technical

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 22 Jul 2004 14:52:08 -0400

.
.
.

> middle of the SM description is not the place to get into this.
I also think this would be a good recommendation, but not in the middle of 
the state machine.  Perhaps in a EAP methods document would be better.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 24 Jul 2004 12:50:43 +0300

Your text below looks good, Florent. Thanks. I see
that Nick already incorporated this to -04. Good.

--Jari