Subject: [eap] Comments on EAP state machine v4

From: Florent Bersani <[email-masked]>
Date: Wed, 09 Jun 2004 11:26:55 +0200

Hi all,

Below are some comments that came to my mind while reading the latest 
version of EAP state machine I am aware of 
(http://www.cs.umd.edu/~npetroni/EAP/drafts/ietf-eap-statemachine/04/draft-ietf-eap-statemachine-strawman-04.pdf).

I know that these comments may:
* Come much too late (since IETF last call has ended 2004-05-13 so it 
shouldn't be the time IINM to propose any "real" changes to this document)
* Be completely naive or off the rocket
* Echo some comments that have already been made (although I tried my 
best to reread - and understand ;-) - the EAP state machine issues 
tracked by Bernard

I just felt like making them:
* Because the probability that they be of some help somehow is - I hope 
- non-zero
* Because the probability that someone kindly replies to educate me, is 
- I hope - non-zero
* For the record

So here they go.

Comment #1 - Editorial

In section 3.2 state machine symbols, we can read:
"+ Arithmetic addition operator.
- Arithmetic subtraction operator."

I find these definitions useless (IINM we never see the notation + in 
the state machines and the notation ++ which is perhaps why this was 
included should either be defined directly or assumed understandable as 
it is said in section 3.1 "The interpretation of the special symbols and 
operators used in the state diagrams is as defined in Section 3.2; these 
symbols and operators are derived from the notation of the C++ 
programming language, ISO/IEC 14882.") BTW, I cannot find any use of - 
or -- in the document. And anyway, I think that in case + and - are 
however necessary for the comprehension of the document, it should be 
stated on which space they operate (N, Z/2**16Z, Z/2**32Z...)

Comment #2 - Editorial

This is about portEnabled and eapRestart.

This discussion for what regards portEnabled is a follow-up on issues 
198 and 203. I do still find the name of this variable too .1X centric 
and, in the light of the recent debates on corner cases on EAP starts 
and restarts, I'd prefer a more explicit name (like Yoshi had proposed 
for instance). Also I'd like the current definition (e.g. in section 
4.1.1 "portEnabled (boolean) Indicates that the EAP peer state machine 
should be ready for communication. This is set to TRUE
when the EAP conversation is started by the lower layer. If at any point 
the communication port or session is not available, portEnabled is set 
to FALSE and the state machine transitions to DISABLED.") clarified (and 
why not - two - example instantiations given, one .1x and one IKEv2 for 
instance) to take the "new"? problems into account (e.g. section 7.12 of 
RFC 3748b "In IEEE 802.11, a "link down" indication is an unreliable 
indication of link failure, since wireless signal strength can come and 
go and may be influenced by radio frequency interference generated by an 
attacker. To avoid unnecessary resets, it is advisable to damp these 
indications, rather than passing them directly to the EAP. Since EAP 
supports retransmission, it is robust against transient connectivity 
losses. " )

For eapRestart, my problem is much the same, two concrete examples (.1X, 
PPP or IKEv2 for instance) would considerably help understand what this 
variable stands for.

Comment #3 - Editorial

This is about the initialization of lastID which is not done in the EAP 
peer state machine. This had been pointed out in issue 229 but 
apparently not taken into account.
Also specify, e.g. in section 4.3.1 that lastId may take the value "NONE"

Comment #4 - Editorial

This is about idleWhile. From my understanding, this timer steadily 
decreases and when it reaches 0, the peer may time out. Clearly, knowing 
the initial value of this timer, by a simple subtraction, one can get to 
know how long the peer has been waiting.
So, contrary to the definition in section 4.1.1 ("idleWhile (integer) 
Outside timer used to indicate how long the peer has waited for a new 
(valid) request."), I'd rather say that this timer indicates how long 
remains before the peer may time out.

Comment #5 - Technical

That's just a triviality about for instance the peer state machine: 
thanks to EAP idleWhile, the method does not have to set timers (EAP 
cares for it). However, in case the method wants to implement a "bad 
packet received" counter (e.g. it is waiting for a packet and to provide 
DoS resilience it wants to allow receiving a limited number of "bad 
packets" before the right one - instead of going automatically to 
failure), it has to do so by itself (and typically will use altReject if 
it wants to fail before the timeout. This is not an issue but perhaps it 
could be worth discussing the usefulness of such a behavior for EAP 
methods (see e..G g. RFC 3748 section 7.5 "Whether a MIC validation 
failure is considered a fatal error or not is determined by the EAP 
method specification") and that it can indeed be implemented in the EAP 
state machines (with a little disymmetry between the timer implemented 
within EAP and the "bad packet received" counter implemented within the 
method. I guess this comment is a way for me to express that I 
wholeheartedly agree with the point .3 Joe made in issue 203 (in other 
words the imbrication of EAP and EAP methods confine to layer violation).

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? 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.

Comment #7 - Editorial

I do not find any definition of m.buildResp (that is used in Figure 3 
EAP peer state machine) in section 4.4 Peer state machine procedures). 
Moreover, i would find it clearer if m.buildresp somehow indicated that 
it does not only depend on ReqId but also on some internal method state 
that has been calculated by m.process.

Comment #8 - Editorial

Although in section 4.4, it is said parseEapReq() "checks that the 
lengthfield is not longer than the received packet", I do not find it 
completely straightforward from Figure 3 what the peer does in case 
there is a parse error due to the length (or an invalid code type or...).

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).

Comment #10 - Technical

Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state?

Comment #11 - Editorial

eapTimeout does not seem to be defined in the text.

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

Comment #13 - Editorial

Why call section 5 "standalone authenticator"? I bet this is the old 
story of the glass half full or half empty, because I'd rather have 
standalone EAP server.

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.

Comment #15 - Editorial

The title of Section 6 is "EAP Backend Authenticator" which I find quite 
strange. I'd rather suggest "backend authentication server".

Comment #16 - Editorial

In section 6.2 we find: "The only difference is that some methods on the 
backend may support "picking up" a conversation started by the 
pass-through. That is, the EAP Request packet was sent by the 
pass-through, but the backend must process the corresponding EAP 
Response. Usually only the Identity method supports this, but others are 
possible"
Would it be possible to explain whether this possibility is explicitly 
left open by some document (in this case, which one) or is implicitly 
allowed (and in this case, whether there are yet 
settings/implementations which use such a possibility).

Comment #17 - Technical

I fail to understand the transition in Figure 7 from 
INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that 
AAA_IDLE sets aaaEapResp=TRUE

Comment #18 - Editorial

If the purpose of aaaIdentity is to allow encapsulation of the peer's 
identity in e.g. RADIUS User-Name attribute, I'd rather have aaaIdentity 
be directly the identity of the peer than a whole EAP packet

Comment #19 - General

Just a late and useless remark, I tend to dislike EAP being too much 
802.1X centric: EAP is (or at least should be) media independent. 
Therefore, the problems implied by splitting the server side into an 
authenticator and an authentication server do probably not belong 
(originally) to EAP.
Thus, for the sake of clarity, I would rather have had two separate 
documents: one for the EAP state machine (peer and standalone server) 
and for the  EAP state machines in case the server side is split (the 
split case is however also evoked in RFC 3748 - which I would also have 
avoided)...

Florent, at least you know the reactions of naive reader while reading 
the EAP state machine ;-)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Thu, 24 Jun 2004 08:27:57 -0400 (EDT)

Florent,
Sorry for the delayed response, some comments are inline. I will respond
to the other issues and hope to hear back from others on these.

Thanks,
nick

> best to reread - and understand ;-) - the EAP state machine issues
It's fine, I think the document should be the best it can be. Thanks for
taking the time.

> stated on which space they operate (N, Z/2**16Z, Z/2**32Z...)
That description was taken from IEEE 802.1X-REV and the notation
was chosen so that both documents could be easily read together. It is
true that the current version of SM document does not use "+" or "-", but
I can assure you that at certain points during the document's lifecycle it
did. Now that things are basically stable in the document I would be fine
removing these, but if it requires outside approval (and if that process
is overly difficult) I would just as soon
leave them for the sake of expediency. IMHO they are not *that* confusing,
even on the issue of space of operation, to most implementers.

Since you brough up the issue of operators, I also noticed that '>=' is
not used but is defined, while '<=' is used but is not defined. Perhaps we
should clean up all of these at one time and just identify symbols that
are used? Are we missing any others?

> and restarts, I'd prefer a more explicit name (like Yoshi had proposed
I have no opinion on the name, whatever the group agrees on is fine with
me. I think it was indecision that left us with portEnabled last time, but
I could be remembering incorrectly.

> supports retransmission, it is robust against transient connectivity
IMHO, this is not an EAP issue nor a problem with the state machine. I
think it is up to the lower layer to wisely use our interface. From my
point of view the lower layer can determine when "the communication port
or session is not available" and if it wants to be fault tolerant that's
great. Perhaps we could reword it to say "If at any point the lower layer
decides communication is no longer available..." ?

> PPP or IKEv2 for instance) would considerably help understand what this
You are asking to include these examples in the definition? Personally, I
think the definition is fine, but I could be missing something. From my
POV, the definition is describing some functionality that EAP provides to
the lower layer, namely restarting, when eapRestart is set. Any decision
process for setting that variable is up to the lower layer.

> Also specify, e.g. in section 4.3.1 that lastId may take the value "NONE"
Sorry, I guess this was an oversight. I agree this should be changed.

> remains before the peer may time out.
I agree that by simple subtraction you can arrive at the definition, but
changing it to yours seems more correct.

> that has been calculated by m.process.
I agree that the definition should be added.

As for method state, IMHO it is clear that the method is using internal
state in addition to the information provided from the EAP layer. I think
we have just chosen to show what is explicitly provided to the method by
EAP. There have been a number of debates on the best way to show the
method/EAP separation and how much to model the method itself. I would
prefer to leave it as is, but of course am open to more conversation on
the matter.

> there is a parse error due to the length (or an invalid code type or...).
I think the "else" transition catches this condition, but the text could
be better. Anyone want to suggest something? I think the idea is that
rxReq, rxSuccess, and rxFailure would all be FALSE, thereby catching
"else".

> eapTimeout does not seem to be defined in the text.
yes! that's true. good catch. I would say the definition goes in the
sections for "EAP to lower layer". Thoughts?

> story of the glass half full or half empty, because I'd rather have
Since EAP is based on the 2-party "peer" and "authenticator" it seems a
little odd to me to only have a "peer" and an "EAP server" in the
2-party case.

> strange. I'd rather suggest "backend authentication server".
This diagram is meant to show the backend of the state machine (the
authenticator portion), which is implemented on the AAA server. "backend
authentication server" to me would describe the entire AAA server
including protocols outside of EAP. Anyway, I think the text describing
what this entity does is fine, even if the name is not ;). Are there
others out there who feel strongly on this issue?

> settings/implementations which use such a possibility).
I think this is explicitly left open by the fact that the protocol is not
dependent on implementation- you can put any piece of it anywhere you
want, as long as it looks like EAP to the other end. I don't think it's
necessary to say any more, but I could be wrong.

> be directly the identity of the peer than a whole EAP packet
I am not a AAA expert, but I think this may have something to do with
parsing the actual packet at the AAA server instead of at the AP. Is this
not correct?

---

From: Nick Petroni <[email-masked]>
Date: Thu, 24 Jun 2004 10:28:55 -0400 (EDT)

Florent,

I very much appreciate your opinion on this, I tended to be an EAP
"purist" as well. However, given the widespread deployment of this
particular architecture, as well as the informational nature of this
document, I would like to propose we reject this issue. Furthermore, the
document is so late in its lifecycle I don't think it would be wise (or
possible?) to make such major changes.

Thanks for all of your comments, I am confident they will lead to a better
document.

nick

---

From: Nick Petroni <[email-masked]>
Date: Thu, 24 Jun 2004 10:19:19 -0400 (EDT)

Here are some comments on Issue 248.

Thanks,
nick

> words the imbrication of EAP and EAP methods confine to layer violation).
I'm sorry, I don't quite understand how you would like to resolve this
issue. I *think* you want more guidelines for how a method could implement
certain types of error processing for things like possible DoS attacks
etc. Is this correct?

> independent. Here again, giving an example why COND_SUCC was introduced
This seems mostly editorial, but perhaps not- you are asking for more text
to describe these state, right? I can see why this might be of some use
for someone without the context of the EAP WG discussions (i.e. the
typical reader of this document).

> CONT && decision == FAIL" may occur.
This is the condition where a so-called "alternate indication" of success
is received, but the method *might* be done and has not yet concluded it
succeeded on its own. There are three competing issues here:
  1. We received an outside "alternate" indication that EAP is finished
     (e.g. DHCP request or similar)
  2. The method has not explicitly claimed it is still continuing, so it
     is either "possbily done" (methodState == MAY_CONT) or it is
     definitely done (methodState == DONE). Either way, it is possible tha
     the method could be finished so we can't just ignore the indication
  3. we have no indication from the method of success. EAP should never go
     to the SUCCESS state without getting notification that the method
     succeeded (or otherwise is willing to accept the connection)

> shouldn't it? Indeed while IIRC RFC 3748 mandates (in section 4.2 "The
No, I think there are two things being confused here. altAccept is NOT to
be used by methods. altAccept corresponds to so-called "alternate
indications" found in RFC2284 (and now RFC3748). (a) is meant to show the
case where IN THE METHOD the peer has been made aware that the
authenticator is happy with the state of authentication and will allow
access. Previously, it was possible to hijack EAP sessions by sending an
EAP Success before the authentication was complete or DoS by sending EAP
Failure. Now, the method has a way to say "I know we succeeded, so
any Failure packet is false" or "if you don't get a Success, it's still
ok."

> out (that the policy MUST forbid this behavior).
I agree, this is not correct explicitly. I see a couple ways of handling
this as well. I think the simplest is to add a statement in the definition
of some policy functions, but if others feel the SM should be updated I
would go along with it.

> Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state?
This is because the symptom is that a requeste has been sent, but no
response received. My recollection is that it was discussed and determined
that EAP should not send a Failure in response to this symptom, it should
simply stop trying.

> some problem with eapReqData = buildFailure(currentId) since currentId=NONE
This is a problem with Canned Success/Failure in general since only
Requests modify the Identifier field. IEEE 802-1X-REV states the following
in 8.2.4.1.3:
  txCannedFail. An EAPOL frame of type EAP-Packet, containing an EAP
                Failure packet constructed by the Authenticator, is
                transmitted to the Supplicant. In the case that
                no EAP communication was taking place on the port, then
                any value of Id may be used in the identifier field of the
                EAP frame. In the case that there was an EAP communication
                taking place on the port, then the value of the Identifier
                field in the EAP packet is set to a value that is different
                from the last delivered EAPOL frame of type EAP-Packet.

We could add similar text if you like.

> method has already been received) which is not our case here.
Using forged Naks as a DoS is a known attack against EAP AFAIK. The DoS
attack is mitigated by the case you mention (not allowing after non-Nak
response has been received), but the attack remains nonetheless.

> AAA_IDLE sets aaaEapResp=TRUE
I think the point here is that aaaEapResp is telling the lower layer that
it's time for that layer to do something. In this case, no packets have
been sent from anyone so the lower layer will see aaaEapRespData is NONE
and know to start. At least I *think* this is what's going on. Others may
be able to correct me.

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 15:23:33 +0200

Hi Nick,

Many thanks for your answer.
See some more in-line.

BR,
Florent

Nick Petroni wrote:

> ...
>>I find these definitions useless ...
>>    
>>
>leave them for the sake of expediency.
>
I agree, #1 is really minor

> IMHO they are not *that* confusing,
I agree though some precision would do no harm ;-)

>not used but is defined, while '<=' is used but is not defined.
>
Good catch. Similarly < is defined but is not used

> Perhaps we
I'll try and make another pass on the document to check this (BTW, I 
agree it is more important to check that all symbols that are used are 
defined rather than remove the symbols that are defined but unused)

>I could be remembering incorrectly.

Well this time, I'm decided ;-) and I vote in favor either of Yoshi's 
proposal (simply "Start" instead of portEnabled) or something like 
"LowerLayerEnabled"

>think it is up to the lower layer to wisely use our interface. 
>
Right but you probably want to give some hints to the lower layer on how 
to wisely use your interface, don't you?

>From my
I like your proposed addition: let me back it up and expand it with sth 
like: "to avoid unnecessary resets, the lower layer may damp link down 
indications when it believes that the link is only temporarily down and 
that it will soon be back up (see RFC 3748, section 7.12). In this case, 
the LowerLayerEnabled [or whatever the name we choose] may not always be 
equal to the the LinkUp flag of the lower layer"

>process for setting that variable is up to the lower layer.
I am asking to give possible instantiations of the variables chosen by 
the EAP state machine (and I would like instantiations with two 
different lower layers, i.e. not only a .1X one but also an IKEv2 or a 
PPP one for example).

I believe this is important to help understand how the state machine 
really works! Otherwise, since no implementation I know of conforms to 
this state machine (perhaps I'm wrong and there are some that do, like 
Yoshi's?) and since knowledge of the layers  that may be below or above 
EAP is not trivial, I fear that this document will remain too 
theoretical and, worse, that it will not help as much as it could, from 
a theoretical POV, to understand how EAP relates to the upper and lower 
layers.

I'd be more than happy to contribute to such instantiations but my 
problem are

1) that I hardly know anything about the lower layers above which EAP 
may be run (e.g. .1X, PPP and IKEv2)

2) second, that even if I dive into these lower layers, understand them 
and come back with correct instantiations, it will probably be too late 
for the EAP state machine document (perhaps it could be a new WG 
document, what do the others think?)

3) I am not even sure that someone apart from myself is interested in 
such instantiations :-(

>prefer to leave it as is, but of course am open to more conversation on
Well a simple suggestion: just include what you've mentioned at the 
beginning of the procedures section (section 4.4, 5.4 and 6.4), namely 
sth like: "in the procedures, the method uses its internal state in 
addition to the information provided by the EAP layer. The only 
arguments that are explicitly shown as inputs to the procedures are 
those provided to the method by EAP, the ones provided by the method 
internal state remain implicit"

BTW, it is a bit sad that the procedures do not precisely define their 
output! For instance, m.check(), in addition to possible internal 
outputs, outputs a boolean. Do we want to clarify this? If yes, I volunteer.

>rxReq, rxSuccess, and rxFailure would all be FALSE, thereby catching
Here again, i think that being more explicit could help. Instead of only 
sticking to the current lapidary definition of parseEapReq(), why not 
make it more explicit, sth like "In case of a parsing error (e.g.the 
length field is longer than the received packet), parseEapReq() outputs 
(FALSE, FALSE, FALSE, NONE, NONE)" - BTW reqMethod should then be 
allowed to take the value NONE.

I agree that being too detailed may
1) Lead to being less clear (too much verbose text, the reader gets lost 
and bored)
2) Not be useful (some things may be assumed to be easily understandable 
without needing to explicit them)

My opinion here is however that we could be a little bit more precise 
but I am OK with people disagreeing.

>sections for "EAP to lower layer". Thoughts?
I agree

>little odd to me to only have a "peer" and an "EAP server" in the
Here it gets funny: while I agree that RFC 2284 used the terms "peer" 
and "authenticator", I believe that the latter has been borrowed by .1X 
with a different meaning and that is the .1X meaning that prevails. 
Thus, RFC 3748 has introduced the term "EAP server"... and after 
rereading RFC 3748, I find that its usage of "authenticator" in some 
places and "EAP server" in others is confusing, despite the note at the 
bottom of page 3.

Anyway, it's a minor comment so I want keep bothering you with it (this 
also applies to comment #15).

>necessary to say any more, but I could be wrong.
Well, just add what you said, i.e.  "(while there currently no other 
methods than identity that do this, this behavior is possible as long as 
the packets sent between the authenticator and the peer comply to RFC 3748)"

>parsing the actual packet at the AAA server instead of at the AP. Is this
Neither am I a AAA expert, but I assume this is the hook provided to 
comply to RFC 3579, section 2.1, page 7:
"In order to permit non-EAP aware RADIUS proxies to forward the
Access-Request packet, if the NAS initially sends an
EAP-Request/Identity message to the peer, the NAS MUST copy the
contents of the Type-Data field of the EAP-Response/Identity received
from the peer into the User-Name attribute and MUST include the
Type-Data field of the EAP-Response/Identity in the User-Name
attribute in every subsequent Access-Request. Since RADIUS proxies
are assumed to act as a pass-through, they cannot be expected to
parse an EAP-Response/Identity encapsulated within EAP-Message
attribute(s). If the NAS initially sends an EAP-Request for an
authentication method, and the peer identity cannot be determined
from the EAP-Response, then the User-Name attribute SHOULD be
determined by another means. As noted in [RFC2865] Section 5.6, it
is recommended that Access-Requests use the value of the
Calling-Station-Id as the value of the User-Name attribute."

I believe that your interpretation ("parsing the actual packet at the 
AAA server instead of at the AP. Is this not correct?") is therefore 
IMHO not correct (indeed, in addition to the RFC 3579 possible 
interpretation quoted above, an AP=authenticator MUST parse the EAP 
packets per RFC 3748 and the state machine document - e.g. figure 6 - 
the AP=authenticator checks for instance the identifier of the response 
it gets...). Others?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 15:23:46 +0200

I unfortunately agree with this rejection for obvious pragmatic reasons

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 09:43:03 -0400 (EDT)

Florent,

Thanks for the quick reply. I will reply in a sort of ad-hoc fashion to
some of these issues and hope that others chime in with their opinions as
well.

Best Regards,
nick

> comply to RFC 3579, section 2.1, page 7:
I would caution that AAA != RADIUS. There are other possibilities.

> the AP=authenticator checks for instance the identifier of the response
You are correct, I wrote hastily and imprecisely. I agree the AP must
parse some amount of the response, possibly even all of it since it did
send  the initial request. However, If you look at the AAA-EAP draft
http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt
you will see on pages 4 and 5 some discussion of this topic. My guess is
it is *this* text that was the motivation for the passing of the entire
packet.

A quick highlight of the text:

   A preferred approach is for the access device to issue the
   EAP-Request/Identity message to the EAP client, and forward the
   EAP-Response/Identity packet, encapsulated within the EAP-Payload
   AVP, as a Diameter-EAP-Request to the Diameter server (see the
   diagram below).  This alternative reduces the number of Diameter
   message round trips.  When the EAP-Request/Identity message is issued
   by the access device, it SHOULD interpret the EAP-Response/Identity
   packet returned by the authenticating peer, and copy its value to a
   User-Name AVP in Diameter-EAP-Request.  This is useful in roaming
   environments, since the Destination-Realm is needed for routing
   purposes.  Note that this alternative cannot be universally employed,
   as there are circumstances where a user's identity is not needed
   (such as when authorization occurs based on a calling or called phone
   number).

   User                             NAS                           Server
    |                                |                                |
    |        (initiate EAP)          |                                |
    |<------------------------------>|                                |
    |                                |                                |
    |          EAP Request(Identity) |                                |
    |<-------------------------------|                                |
    |                                |                                |
    | EAP Response(Identity)         |                                |
    |------------------------------->|                                |
    |                                | Diameter-EAP-Request           |
    |                                | EAP-Payload(EAP Response)      |
    |                                |------------------------------->|
    :                                :                                :
    :                        ...continues...                          :

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 17:09:40 +0200

Some more thoughts on these issues in-line.

Many thanks for taking the time to read them and to write a detailed answer!

Florent, who agrees that some issues are uninteresting (at least for me) 
and too meticulous (but when specifying a state machine, it seems to me 
a good idea, isn't it ;-))

>certain types of error processing for things like possible DoS attacks
To clarify what I meant, this is related to comment #6 of this thread 
and comment #1 of my mail on EAP (see 
http://mail.frascone.com/pipermail/public/eap/2004-June/002531.html).

In short, since altAccept and altReject are set by the lower layer and 
not by the EAP method (*), there is no way for the method to fail more 
quickly than a time out IINM.

Indeed, suppose we are in a method exchange (any resemblance to EAP-PSK 
is purely incidental ;-)) where the peer waits for the server to 
authenticate to it, that is the peer waits for a MAC=MIC produced by the 
server. The peer receives request #1 containing such a MAC=MIC. As this 
MAC=MIC is invalid, the peer discards thanks to m.check and waits for 
another request.

The question was: in case the peer considered this reception of an 
invalid MAC as a critical failure and wants to fail immediately i.e. 
without processing any other packet (despite the DoS issues associated 
with this behavior), how does he(***) do? My answer from the EAP state 
machine figure 3 of the strawman4 version is that he can't! To avoid 
processing any new requests, he updates his m.check function to answer 
TRUE whatever the input (or sets methodstate to DONE) and waits for the 
time out, that's his best option (this comes from the examination of the 
transition conditions that lead to the SUCCESS or FAILURE state). This 
comes from an examination of the transition conditions that lead to 
SUCCESS or FAILURE and the fact that the method does not control 
portEnabled or eapRestart (the lower layer does). I think that not 
allowing the method to quickly transition to SUCCESS or FAILURE is a bad 
restriction. What do you think?

Actually, the question was originally formulated in a slightly different 
scenario: the peer receives request #1 with a bogus MAC=MIC but he is 
disposed to allow reception of 3 bogus MAC=MIC before failing. He 
ignores it thanks to m.check() and increments its BadPacketCounter that 
is internal to the method. He receives request #2 with a bogus MAC=MIC. 
He ignores it thanks to m.check() and increments its BadPacketCounter. 
He receives request #3 with a bogus MAC=MIC and wants then to fail 
quickly, what does he do? In fact, I was also complaining that the 
BadPacketCounter lies within the method internal state, while the 
Timeout timer is handled by EAP (this is probably a matter of taste... 
and such issues arise when one does not adopt a neat black box interface 
between layers, which is IMO the case for EAP and EAP methods, hence the 
reference to Joe and Issue 203.

To keep on expanding my thoughts on the problem, the only parameter the 
method has IINM to influence the success or failure of EAP is the 
methodstate (****) and decision variables (*****). It is a pity that 
decision is always associated to idlewhile in the transitions to SUCCESS 
or FAILURE, don't you think? This has surely to do with the choice to 
keep the EAP success or failure packets although they are useless - 
(expect for backwards compatibility - which however could certainly be 
provided without endangering the new generation) and worse, harmful.
 
(*) Here there is a possible confusion between alternate result 
indications - a possibly unprotected indication given by the lower layer 
that the data link went down or up (**) - and protected result 
indications - cryptographically protected result indications given by 
the method. At least, it confused me ;-)

(**) BTW do we have an example of indication of the data link that it is 
up? (I see examples of link down, e.g. a dial-up NAS hangs up)
I do not think that your DHCP example works as it is, IIRC, the peer 
that first sends the DHCP request. So to understand that the 
authentication succeeded from this, the peer would have to keep trying 
sending DHCP requests while authenticating and understand it has 
succeeded when it gets a response. Am I right? Perhaps, sth around DNA?

(***) BTW, would a native English speaker or an educated foreigner tell 
me what is the correct pronoun to use when talking of the peer: it or he 
or both?

(****) BTW, I think I have two other issues here:
1) allowMethod is not defined in the document IINM but is used in figure 3
2) I did not find a place in RFC 3748 saying that it is forbidden to 
have multiple round trips of the Identity method. If this is the case, 
the state machine reflects this... sadly, this leads to an unnecessary 
(& stupid & not dramatic) DoS attack: the attacker keeps sending EAP 
Identity request and the peer may keep replying to these requests (and 
discarding the valid requests of the server). I thought about this when 
talking about the methodstate variable and noticing that there was a 
difference between Identity/Notification (which are from a theoretical 
POV two methods) and the other methods. Namely, while the identity and 
notification methods do not impact the methodstate variable nor the 
decision one...
I'll post these issues in a separate mail for those who won't have read 
this lengthy one (I very much understand them ;-))

(*****) BTW, the only way the protected result indication is IINM the 
decision variable (see also comment #6):
1) if the peer has a protected success indication, he sets decision to 
UNCOND_SUCC provided he wants to use the access he has been granted
2) if the peer has a protected failure indication, he sets decision to FAIL
3) if the peer hasn't any protected result indication and is willing to 
use the access if he is granted it, he sets decision to COND_SUCC

>typical reader of this document).
Not only text to describe these variables but some hints to the reason 
why these variables were chosen.

>     succeeded (or otherwise is willing to accept the connection)
Although I disagree stricto sensu with this example (the peer will not 
receive a DHCP request, IINM, it will send one), I essentially agree 
with you: I confused alternate lower layer indications and protected 
method indications.

>any Failure packet is false" or "if you don't get a Success, it's still
I agree: I confused alternate lower layer indications and protected 
method indications. Thanks for your very pedagogical correction :-)

>that EAP should not send a Failure in response to this symptom, it should
Thx for the explanation (and sorry I missed it in the archives). Why not 
include it in the document?

>We could add similar text if you like.
It is not stricto sensu a canned success/failure IMO.

It's just that although RFC 3748 prevents IMHO a stupid server to 
directly start an authentication by sending a failure (not very 
explicitly, perhaps see the beginning of section 2 of RFC 3748 but it 
doesn't sound very normative or section 4.2 of RFC 3748), figure 4 
relies on the policy (policy.getdecision) to avoid this behavior... and 
I think this is worse stating that the authenticator's policy must 
comply to this!

I have problems to understand the .1X text: does it authorize a valid 
authenticator to send directly a failure message ("in the case that no 
EAP communication was taking place on the port, then any value of Id may 
be used in the identifier field of the EAP frame") could you please 
clarify it for my poor brain?

>response has been received)
>
This is not the case I mention!!
I precisely mention the case, when the server has sent his initial 
request and an attacker replies with a NAKs before the peer replies with 
the correct response. In this scenario, IINM, although the server may be 
sure that a valid peer won't NAK (a policy decision), figure 4 mandates 
that it processes the NAK. I find it an unnecessary open a door to a 
stupid & useless & inefficient DoS (and when one cans close such doors 
without much trouble, then I recommend closing them although the DoS 
attack is not dramatic). So my proposed resolution is to allow the 
policy to set methodstate directly to CONTINUE (while still authorizing 
it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do 
you think?

>and know to start. At least I *think* this is what's going on. Others may
well, according to the definition of aaaEapResp (section 7.1.1 "Set to 
TRUE in lower layer, FALSE in authenticator state machine. Indicates an 
EAP response is available for processing."), aaaEapResp is *not* a vague 
flag to say to the lower layer to do to do something but a precise flag 
to say to it that it has a  response available for processing.
So I still hold onto this issue. It arises when an authenticator boots 
and decides directly that it will be pass-through whatever the id of the 
peer (this behavior appears to be allowed by the state machine). I think 
it needs a fix.
Perhaps I'm off the rocket but then I would like to be enlightened (if 
somebody thinks I am able to understand the explanation ;-))
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 17:20:47 +0200

A few ad-hoc thoughts in-line ;-)

Nick Petroni wrote:

>hope that others chime in with their opinions as
>well.
>
So do I ;-)

I agree

>I agree the AP must
I believe that your text backs my point: since the authenticator already 
sends the whole EAP packet to the AS in aaaEapRespData, I do not yet see 
the point in passing the whole EAP packet to aaaIdentity (and not only 
the identity). The behavior I described with RADIUS is the one quoted in 
your text with DIAMETER.

However, as "the one who does more can do less", there is no critical 
technical reason to prevent aaaIdentity from being the whole packet and 
not only the identity field. This issue is *editorial* and I won't fight 
for it.

It's just that
1) to the average reader I am, when I read the actions of the 
AAA_REQUEST state in figure 7, namely aaaIdentity = eapRespData ; 
aaaEapRespData = eapRespData, I find it weird to instantiate two 
variables that take the same value
2) from an interface perspective, if you set aaaIdentity to a whole EAP 
packet, then the AAA layer has to parse the EAP packet to recover the 
identity wherehas if you set it aaaIdentity to identity, the AAA layer 
has no parsing to do, just encapsulation. I find the latter cleaner.

BTW, I haven't yet read the draft you pointed me to. So I'll read it 
this WE and come back with perhaps more educated thoughts.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 11:23:31 -0400 (EDT)

> the identity). The behavior I described with RADIUS is the one quoted in
Ok, I'm sorry. I misread the original comment. I think you are correct,
the aaaIdentity probably makes more sense as just that portion of the
response. Any others have opinions?

> this WE and come back with perhaps more educated thoughts.
Don't bother, I misread the comment.

thanks,
nick

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 11:39:13 -0400 (EDT)

> with you: I confused alternate lower layer indications and protected
Typically, no, it would not receive a DHCP request. However, you are
thinking of a particular scenario (Roaming client == EAP Peer). I know of no
strict mapping that this must occur. There can certainly be cases, at
least theoretically, where the entity playing the role of EAP Peer
provides some sort of network service. The authenticator's use of that
service could serve as an "alternate indication of success." That
service COULD be DHCP, although I don't know why it would be. Anyway, as
you say, it's not important to the conversation. We both understand.

> include it in the document?
We could. I see no reason why this can't be added.

> This is not the case I mention!!
I know it isn't. My point is, that this DoS is known and well understood.
Furthermore, the ONLY mitigation of Nak DoS is the one both you and I
described.

> the correct response. In this scenario, IINM, although the server may be
However, the server has no way to know the Peer was not a valid peer.
Think about a new person trying to use the network or simply someone using
the wrong configuration file for their peer software. Even legacy
software that doesn't support the deployed method could be an issue. If
they send a Nak and get NO RESPONSE this would make for difficult
debugging. Sending a Nak at this point is valid and they should at least
receive a Failure to indicate that their proposal was rejected.

> it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do
I think this is not a useful mitigation. The reason is simple- an attacker
can still spoof a Failure packet in the opposite direction at almost any
point for just as easy a DoS. Even if you are using a smart method, there
will be a window when the attacker can sneak in a Failure in most
environments. I think the general rule of "it's no worse than a DoS that
we know we can't mitigate so why mitigate this one." Furthermore, IMHO the
protocol issue discussed above is all the more reason not to disallow
Naks at this point. Some implementations may do so, but I don't see the
value of mitigating this particular attack in the SM.

> peer (this behavior appears to be allowed by the state machine). I think
What is the issue precisely? The problem as I see it is if you DON'T set
aaaEapResp in AAA_IDLE then you will just hang waiting for the lower layer
when it doesn't know that it's its turn.

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 11:48:11 -0400 (EDT)

> It is not stricto sensu a canned success/failure IMO.
It's not? I definitely do not understand then. I define canned failure as
without any previous packets the authenticator decids failure will be sent
and sends it without any other EAP conversation.

> I think this is worse stating that the authenticator's policy must
I don't see the RFC as denying the use of immediate failure. The behavior
is valid IMHO.

> clarify it for my poor brain?
The Failure or Success messages in EAP use the last valid Identifier value
from the EAP conversation. However, this text is referring to the case
where no EAP conversation took place, you are just sending a Failure. This
is termed a canned failure, and I think this is the case you were
describing. The 802.1X-REV document states that ANY Identifier is valid
for Failure in that case (and similarly for canned success). Perhaps you
can distinguish your case from the "canned" case for a slow person like
myself? Sorry I'm not getting it yet.

Regards,
nick

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 12:19:35 -0400 (EDT)

> quickly than a time out IINM.
Why is there not? Can't the method just not "ignore" the packet and
instead return FAIL? I think I am missing something.

> machine figure 3 of the strawman4 version is that he can't! To avoid
I see. The peer is inherently powerless in EAP. What he CAN do is to end
this conversation and start a new one. To end the current conversation,
the peer can simply not "ignore" the packet, make decision == FAIL, and
methodSate == DONE.

> time out, that's his best option (this comes from the examination of the
why does he wait for the timeout? There is a direct transition from METHOD
to FAILURE with no condition for timeout. No? I am referring to the
rightmost transition in the diagram.

> restriction. What do you think?
Is that the case? I don't see it that way. Maybe I am looking at the wrong
diagram?? I am looking at Figure 3.

> or FAILURE, don't you think? This has surely to do with the choice to
I am REALLY lost here. There are a number of transitions to both FAILURE
and SUCCESS that do NOT depend on idleWhile. The method shouldn't need
more than to say whether or not it's done and what its decision was. Why
it failed is of no concern to the EAP layer.

> succeeded when it gets a response. Am I right? Perhaps, sth around DNA?
I remember some discussion about examples of alternate indications. I
don't recall them all, but I know EAPoL Key packets are possible examples
of data link up. There are a number of possible data indications here, or
even specific link-layer indications.

> me what is the correct pronoun to use when talking of the peer: it or he
My opinion is it's a matter of style. The peer is strictly an 'it', but
there is generally some idea that a 'he' or a 'she' is operating the
machine ;).

> 1) allowMethod is not defined in the document IINM but is used in figure 3
yes. another good catch.

> this lengthy one (I very much understand them ;-))
As I said before, if you are looking for DoS mitigation from stray
messages, EAP is not the place for you. My understanding is that you can
repeat Identity requests within the protocol, yes. But at this point you
could have just sent a Failure and ended the conversation anyway, so an
attacker is not much helped by this fact IMHO.

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 18:33:25 +0200

Some more in-line

Nick Petroni wrote:

> There can certainly be cases, at
>provides some sort of network service. 
>  
>
Thx here is the alternate success indication I was looking for :-)

>receive a Failure to indicate that their proposal was rejected.
I was talking here of a specific (though probably widespread) case: a 
corporation BigCo providing wireless access to its employees.
Since BigCo is a great corporation, it knows that all its employees use 
EAP-TLS: so whoever tries to connect, if it is a valid employee, it will 
use EAP-TLS

>I think this is not a useful mitigation. 
>
I disagree

>The reason is simple- an attacker
>point for just as easy a DoS. 
>
Right but this is a different problem that has a different mitigation 
(namely the protected result indication by the method and/or the 
decision/methodstate variable that allows to silently discard the bogus 
failure/success message)

>Even if you are using a smart method, there
>environments. 
I strongly disagree here: are you talking about protocols (then I'd like 
more precisions because I think it will be hard to demonstrate what you 
say ;-)) or about implementations (then I think this is out of scope 
since our main focus is not what people do or how they do it but rather 
what they should do, isn't it?)

>I think the general rule of "it's no worse than a DoS that
>we know we can't mitigate so why mitigate this one." 
>
I won't engage in a big fight either here. I think this is a minor issue 
and that it is easy to solve. If people don't want to solve it (because 
they think the resolution costs more than the issue), I respect that 
although i disagree

>Furthermore, IMHO the
>Naks at this point. 
I didn't say that we should disallow them but allow them to be 
disallowed (i.e. silently discarded) according to a policy!

>What is the issue precisely?
>
you say to AAA that you have a response to send (aaaEspResp=TRUE) when 
you don't (aaaRespData=NONE).
Apart from this IMHO unsatisfactory behavior, I think this is leaving 
the door open to buggy implementations (think of somebody who will send 
sth as soon as aaaEspResp=TRUE with encapsulated whatever garbage was in 
memory for aaaRespData (i.e. missing that aaaRespData=NONE)

> The problem as I see it is if you DON'T set
I agree : my problem is not with the state but the transition from 
INITIALIZE_PASSTHROUGH to AAA_IDLE with currentid==NONE

Did I clarify?

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 18:42:37 +0200

Some more in-line

>and sends it without any other EAP conversation.
OK I defined canned success/failure as a success/failure maliciously 
inserted by an attacker; According to my definition, we were not talking 
of canned success since it was a valid authenticator that sent the failure

>I don't see the RFC as denying the use of immediate failure. The behavior
To be honest, I started the mail you replied to by lamenting that this 
was not mandated by EAP (which you tend to think) but after rereading 
RFC 3748 (I stumbled across some wording like "The EAP authentication 
exchange proceeds as follows: [1] The authenticator sends a Request to 
authenticate the peer." RFC 3748 page 7).

So, although it didn't seem like very normative text, I changed my mind 
and now think that EAP mandates that a dialog begins with a request.

 I'd really like others' opinion on this, Bernard, Jari?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 12:50:59 -0400 (EDT)

> EAP-TLS: so whoever tries to connect, if it is a valid employee, it will
I get it. I always have. You don't have to convince me of the scenario.
I think I am just saying there is an equally devastating attack
of sending a Failure to the peer instead of a Nak to the Authenticator.

> decision/methodstate variable that allows to silently discard the bogus
Protected result indications are METHOD SPECIFIC. you have not started the
method at the point when your 'invalid Nak insertion' attack takes place.
You will notice on the Peer that the methodState variable is initialized
to NONE. Therefore, if immediately after (or before) an Identity exchange
the attacker forges a Failure the Peer MUST accept it.

> what they should do, isn't it?)
No, this is a protocol issue. There is a window of opportunity at the
beginning where a Failure can be spoofed, just like there is the window
you describe where a Nak can be. The only protection from injected
Failures is methodState == CONT, which it does NOT start out as. Some
methods DO NOT indicate when they are done, and in fact the peer may not
even be able to know if they are.

> disallowed (i.e. silently discarded) according to a policy!
I know. I think we can agree to disagree and let others weigh in.

[Comment 17]
> you don't (aaaRespData=NONE).
No, you do not. YOu have a respnse *received*. This makes all the
difference in the world. Authenticators *receive* responses and *send*
requests. Requests are generated by the lower layer. If you do not tell
the lower layer that it's time to go, you will hang forever.

> memory for aaaRespData (i.e. missing that aaaRespData=NONE)
send what? Eap Responses are PROCESSED by the lower layer, not SENT. if
the data is NONE then there will be nothing to process. eapRespData is
properly initialized, so your argument that there's garbage there is a bad
one. We can't account for people ignoring variables IMHO.

> Did I clarify?
Did I?

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 12:52:56 -0400 (EDT)

> of canned success since it was a valid authenticator that sent the failure
Can we agree on my terminology and call your version a "forged" one? I
think mine is much closer to common usage, if not dead on for the word
"canned".

Regards,
nick

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 18:59:31 +0200

Some more in-line to clarify: I had missed the transition :-((

>rightmost transition in the diagram.
Ooooooooooooops, sorry I had missed that one :-(

All my apologies, sorry for the time i made you loose :-( and many 
thanks for your patience and clarity

But my point could still apply to a peer that would like to transition 
quickly to success. Here, the difference is probably that the expected 
behavior of the peer is to wait for a success and if it doesn't receive 
one, then if it has had a protected result indication transition to 
success. So I don't think my point is very interesting in this case :-(

>attacker is not much helped by this fact IMHO.
Hummm
I had understood that EAP left many doors open for abuses... and I agree 
it is probably too late to try and fix them (and probably not worth it)
But I deeply regret that

So here is another stupid scenario:
1) The valid server sends EAPrequest identity
2) The valid peer replies with EAP response identity
3) The attacker sends Failure to the peer

In this scenario, for now, whatever the protection of the method the 
peer wants to use, he fails :-( (again in some scenarios - typically 
corporate or domestic - this is sth which we could want to avoid)

It does not harm much (cf. the easier micro-wave oven attack) but it 
would not have been that hard to avoid, wouldn'it?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 19:05:56 +0200

More in-line

>the attacker forges a Failure the Peer MUST accept it.
Right I just came to this unfortunate conclusion in a mail I've just 
sent you :-(

>No, you do not. YOu have a respnse *received*. 
>
No you don't IINM

I'm talking of Figures 6 and 7: you start in INITIALIZE move with UCT to 
SELECT_ACTION, take decision PASSTHROUGH, transition to 
INITIALIZE_PASSTHROUGH, take the transition currentId==NONE and end in 
AAA_IDLE

I don't see the response you have... but I might well be confused as it 
was the case with the transition I forgot in Figure 3 :-( & ;-)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 19:06:39 +0200

>think mine is much closer to common usage, if not dead on for the word
OK

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 13:09:27 -0400 (EDT)

No worries! I do that kind of stuff all the time.

Some more comments...

> success. So I don't think my point is very interesting in this case :-(
The peer should not go to success unless he receives notice from the
authenticator. I will note that there are conditions into SUCCESS that do
not have timers on them, e.g.
(rxSuccess && (reqId == lastId) && (decision != FAIL)) and
(altAccept && decision != FAIL)

The peer cannot spontaneously decide to succeed. Timeout, Success, and
altSuccess are it.

> would not have been that hard to avoid, wouldn'it?
It is hard to avoid. The peer has to accept certain things based on the
protocol at certain times. Perhaps we could have rewritten EAP so that it
didn't have to fit the old protocol, but ultimately there would be new
places for DoS abuse even in the new version. The peer has no way to
authenticate immediate failures since some implementations really do send
immediate failures. Think of the case where you mistyped your username.
It's likely you would immediately get a Failure, but if you didn't accept
it you would just keep trying and never get any further. Furthermore, it
would take you a lot longer to determine the Authenticator really doesn't
want to authenticate you since you would have to wait for a timeout. It's
impossible to distinguish this case from the forged case.

Regards,
nick

---

From: Nick Petroni <[email-masked]>
Date: Fri, 25 Jun 2004 13:22:30 -0400 (EDT)

> was the case with the transition I forgot in Figure 3 :-( & ;-)
OK, again making me be precise ;). No, you did NOT receive a response. The
point is, the aaaEapResp variable is meant to tell the lower layer that
you have received one. Technically, you have not, but in the case of a
brand new connection that has had no packets but ends up in teh AAA_IDLE
state you STILL WANT TO SET aaaEAPResp so that the lower layer can build a
new request. It will know there was not a response based on the
aaaEapRespData. The point I am making is bad implementations cannot just
send garbage because they are required to PROCESS the data, not just send
it off.

The way it works (in very shorthand, please don't make me be more
precise) is:

Time    EAP Layer                            Lower Layer
====    =========                            ===========
 |     Transition to AAA_IDLE
 |     Set aaaEapResp = TRUE
 |                                        Sees aaaEapResp == TRUE
 |                                        Sees aaaEapRespData == NONE
 |                                        Build the first EAP Request
 |                                        set aaaEapReq
 |     Sees aaaEapReq
 |     sends the request
 |     waits for a response
 |     set aaaEapResp = TRUE
 |                                        Sees aaaEapResp == TRUE
 |                                        sees aaaEapRespData is filled
 |                                        Parses aaaEapRespData
 |                                        decides whether to send another
 |                                          request, sets aaaEapReq or
 |                                          aaaEapNoReq
 |
 V

Think of it as a handshake between the lower layer and the EAP layer. The
lower layer builds requests and waits for responses. the upper layer ships
the requests and waits for responses to pass down. Setting aaaEapResp
only transitions control to the lower layer so that it can do its thing.

Hope this helps. If not, maybe someone else can say it better than me or
show me I'm wrong :).

Regards,
nick

---

From: Florent Bersani <[email-masked]>
Date: Sat, 26 Jun 2004 11:09:03 +0200

Nick

I have a terrible fear I might be missing again sth and annoying you and 
the list with stupidities :-(

Thanks your for your detailed response. However, I am still not 
satisfied and think we are still misunderstanding each other, please see 
in-line.

However, as I've said, there's the possibility that you have perfectly 
understood what I meant, that my points are stupid and that you are 
spending much time to educate me. I hope and believe this is not the 
case (only the latter is true IMHO ;-))

BR,
Florent

Nick Petroni wrote:

>new request.
My problem zero is this: if you use a variable in a different way than 
you define it, this should be fixed. aaaEapResp is not defined as a 
variable to indicate the AAA layer that it has sth to do: it indicates 
to the AAA layer that its has an EAP response to encapsulate and send to 
the AS, doesn't it?

> It will know there was not a response based on the
>aaaEapRespData. 
>
Problem zero: this assumption should at least be made explicit, 
shouldn't it? (this is the proposed solution if we want to fix problem zero)

>The point I am making is bad implementations cannot just
Here is my point:

IINM the setting we are talking about is the following
Peer <----->   Authenticator <------------>  Authentication server

We are looking at the authenticator, in case it behaves as pass-through

Theoretically, if it is really the authenticator, then per RFC 3748 (see 
terminology section 1.2) it is it which initiates the EAP conversation 
(typically with an EAP request identity)

However, it appears to me that figure 6 and 7 allow an authenticator to 
select pass-through without having done anything to initiate EAP - 
that's the following hand trace start in INITIALIZE move with UCT to 
SELECT_ACTION, take decision PASSTHROUGH, transition to 
INITIALIZE_PASSTHROUGH, take the transition currentId==NONE and end in 
AAA_IDLE (first problem, proposed solution : say the authenticator 
cannot select pass-through with policy.getdecision when it hasn't sent 
any EAP request and received the corresponding response)

Second problem, if the authenticator adopts this IMO bad behavior, I 
still have a concern with aaaResp being set to TRUE
Indeed, the authenticator is interfaced with the AAA layer (what you 
call lower layer in your mail), e.g. RADIUS or DIAMETER

This how IINM things work:
1) when the authenticator sets aaaEapResp to TRUE, the AAA layer (e.g. 
RADIUS) takes aaaEapRespData and encapsulate it in the relevant AVP 
(EAP-Message) *without any other processing by the AAA layer* and the 
AAA layer of the authenticator sends it to the AAA layer of the AS server
2) the authenticator waits in the AAA_IDLE state after having sent this 
response of the peer to the AS
3) and then it can get a request that the AS sent to it through their 
AAA link and....

So, to me, when you set aaaEapResp to TRUE on the authenticator, you 
indicate to the AAA layer (e.g. RADIUS) that you have an EAP Response 
received from the peer that you want to transfer to the AS. And this is 
not the case in the scenario I describe. Hence, to me, if the 
implementation is very dumb and logical, when aaaEapResp is set to TRUE, 
the AAA layer should take whatever is located at aaaEAPRespData and 
encapsulate in the AAA AVP (e.g. EAP message) and send it to the AS. Did 
I clarify what I meant? Is this completely nonsense?

Proposed solution to problem 2: either adopt problem 1 proposed 
resolution (which would remove the transition of figure 7 from 
INITIALIZE_PASSTHROUGH to AAA_IDLE with currentId==NONE, BTW could you 
tell me why or how this transition appeared?) or make the AAA layer 
behavior explicit (e.g. it is able to understand that aaaEapResp==NONE 
and if so signals "sth"  via the AAA layer to the AS... and this "sth" 
should/could be defined)

>Time    EAP Layer                            Lower Layer
I disagree with this, the AAA layer does not have to understand that 
EapRespData == NONE, to me the AAA layer is only responsible for 
encapsulation of the data it is handed over. To me the behavior you 
describe is layer violation of what the AAA layer does

> |                                        sees aaaEapRespData is filled
It is not the AAA layer of the authenticator that parses EapRespData 
(some checks have however been done by the authenticator in its EAP 
layer, namely in RECEIVED2)

---

From: Nick Petroni <[email-masked]>
Date: Sat, 26 Jun 2004 09:12:44 -0400 (EDT)

Florent,

Thanks for the reply. Some comments below. This is my last reply for about
a week as I will be in the woods without email or phone ;)

Best regards,
nick

> to the AAA layer that its has an EAP response to encapsulate and send to
I agree, the text is in the least ambiguous. If it's being used the way I
think it is, the text could use some help.

> shouldn't it? (this is the proposed solution if we want to fix problem zero)
Yes, I think that seems wise, if I am correct.

> (typically with an EAP request identity)
The authenticator, when acting as passthrough, does NOT have to initiate
the conversation AFIAK. There are a number of indications of this in
RFC3748.  Here are a couple of examples:

 Section 1, introduction:
   One of the advantages of the EAP architecture is its flexibility.
   EAP is used to select a specific authentication mechanism, typically
   after the authenticator requests more information in order to
   determine the specific authentication method to be used.  Rather than
   requiring the authenticator to be updated to support each new
   authentication method, EAP permits the use of a backend
   authentication server, which may implement some or all authentication
   methods, with the authenticator acting as a pass-through for some or
   all methods and peers.

Since we know that Identity is optional, and it explicitly says ALL
methods may be on the backend, the only possibility when not using
Identity is that the backend starts the conversation.

another place is Section 2.3, third paragraph which again talks about an
authenticator that does not implement any methods.

Furthermore, if you look at draft-ietf-aaa-eap-08.txt, the first paragraph
of Section 2.2 states:
   The EAP conversation between the authenticating peer and the access
   device begins with the initiation of EAP within a link layer, such as
   PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i].  Once EAP has been
   initiated, the access device will typically send to the Diameter
   server a Diameter-EAP-Request message with an empty EAP-Payload AVP,
   signifying an EAP-Start.

This seems to support my conclusion that the lower layer knows to deal
with the empty packet.

> any EAP request and received the corresponding response)
I think it can. All indications are that you can go straight to
passthrough.

> call lower layer in your mail), e.g. RADIUS or DIAMETER
draft-ietf-aaa-eap-08.txt seems to indicated DIAMETER can handle the
case... IINM.

> (EAP-Message) *without any other processing by the AAA layer* and the
Be careful with the statement *without* any processing. In the LEAST it
will have to identify the length of the AVP before copying the data, since
EAP packets are variable length. The first one will just be 0 length as
indicated in draft-ietf-aaa-eap-08.txt.

> 3) and then it can get a request that the AS sent to it through their
right.

> not the case in the scenario I describe. Hence, to me, if the
well, it sort of its. THe packet format is the same, you just have an
empty AVP.

> I clarify what I meant? Is this completely nonsense?
Which is correct behavior I think, but there is still *some* processing.
You can't just copy the entire buffer length, you copy the amount you know
to be present in the buffer (in this case 0).

> layer, namely in RECEIVED2)
not parses, I should have written PROCESSES.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 26 Jun 2004 10:19:23 -0400

Hi Florent and Nick,

Let me comment on one specific issue.

On Sat, Jun 26, 2004 at 11:09:03AM +0200, Florent Bersani wrote:

(snip)

> I clarify what I meant? Is this completely nonsense?

Yes, the AAA layer should take whatever is located at aaaEapRespData
and encapsulate in the AAA message that defines some AVP or attribute
to carry EAP PDU.  But if aaaEapRespData is NONE, it locates
*nothing*.  It agree that the EAP state machine document is unclear on
what is the AAA layer's expected behavior when aaaEapRespData is NONE.
I believe that the expected behavor is creating an AVP or attribute to
carry EAP PDU but with empty data.  I think adding some clarification
on this in the EAP state machine draft (perhaps in Implementation
Considerations section) could be useful for implementors.

> describe is layer violation of what the AAA layer does

I think the AAA layer should at least check whether EapRespData is
NONE or not (see my comment above).

> layer, namely in RECEIVED2)

Right.  The AAA layer does not have to parse EapRespData.

Yoshihiro Ohba

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 28 Jun 2004 16:35:15 -0400

Some discussion below -

--On Friday, June 25, 2004 6:33 PM +0200 Florent Bersani 
<[email-masked]> wrote:

> >> request and an attacker replies with a NAKs before the peer replies
> >> with the correct response. In this scenario, IINM, although the server
> >> may be
> >>
> >>
> > Think about a new person trying to use the network or simply someone
> > using the wrong configuration file for their peer software. Even legacy
> corporation BigCo providing wireless access to its employees. Since BigCo
> is a great corporation, it knows that all its employees use EAP-TLS: so
> whoever tries to connect, if it is a valid employee, it will use EAP-TLS
>
> >
> >
> I didn't say that we should disallow them but allow them to be disallowed
> (i.e. silently discarded) according to a policy!
>

I am not sure I understand all the nuances of this conversation. From what 
I understand and have read, I think Florent has seen and described a 
possible DOS attack that could be mitigated.   My impression is that Nick 
is right, that this is not worse than other possible attacks, that the 
Failure attack on the peer is also possible -  and I am not sure how many 
cases it will help.

To reiterate the NAK case - If we disallow NAKs initially, then in an error 
situation where the peer is unable to do the requested method, the 
authenticator will receive a NAK, not accept it, and eventually timeout. 
If the peer is able to do the requested method then everything works as 
expected.  Disallowing the NAK eliminates the possibility that an attacker 
could send a bogus NAK and terminate the connection.

The question in my mind is whether there is ever a situation where a 
provider might decide that it would only deal with peers that do a 
particular method, and would be content to let the connection time out if 
the peer were unable to do the method.

My understanding is that Florent is suggesting that companies might desire 
to implement such a case, and setting the authenticator to ignore NAKs 
would eliminate a possible DOS attack.

Further, Florent has suggested that the authenticator be allowed to set the 
initial state "CONTINUE" rather than "PROPOSED" which will cause NAKs to be 
ignored as proposed.  I think this is possible, but I am not sure it is 
useful.

In particular, I am not sure how many companies would want to deploy a 
service which requires all peers to support the same method forever. 
Presumably at some point new methods might be introduced, and not all 
clients will have the methods installed at the same time.  There are ways 
around this, but I think allowing multiple methods makes this sort of 
transition much easier.

My proposed change would be to put some words in the description of the 
PROPOSE METHOD State that mentions that it is possible to set the initial 
state to CONTINUE, but it is not recommended.  This leaves the door open if 
there are future NAK attacks, but does not encourage inflexible 
implementation in normal situations.

--

I think the case of a Failure attack on the Peer is also interesting.  If a 
peer knows that it is going to do an identity and then method-X, then it 
can ignore everything that is not in that sequence.  I think this avoid the 
possibility of a Failure DOS attack - where an attacker sends a Failure 
when it sees an identity Response.

I am interested in whether I am missing something here.

If I am right, then some words in the peer could indicate this possibility. 
It does not fit the existing state machine well, so I don't think adding it 
would be a good idea, but mentioning it somewhere seems reasonable - 
perhaps in the implementation issues.

John

---

From: Florent Bersani <[email-masked]>
Date: Tue, 29 Jun 2004 09:57:48 +0200

Hi Nick,

Hope you had a nice time in the woods... and that it wasn't my numerous 
replies that prompted you to run far away from your emails ;-)

To close the discussion, I guess that, apart from the problem #0, on 
which it seems that we (You, Yoshihiro and I, at least) have an 
agreement to add clarifying text on the handling of aaaEapResp when it 
is equal to NONE, the other problems boil down to nothing as they came 
from my misunderstanding of the definition of an Authenticator.

Indeed, I only remembered the RFC 3748 definition of Authenticator in 
section 1.2: "The end of the link initiating EAP authentication." and I, 
erroneously as it appears, assumed that the Authenticator had to 
initiate EAP authentication "using EAP-Request/Response". After reading 
your detailed and clear explanations, it seems that the Authenticator 
can however initiate EAP authentication using an "empty EAP message" or 
whatever. I hope there won't be too many people that will misunderstand 
RFC 3748 on this point as I did ;-)

Thanks again for the clarification,
Florent

---

From: Florent Bersani <[email-masked]>
Date: Tue, 29 Jun 2004 10:38:31 +0200

Hi John,

I think you have captured the gist of the conversation and I tend to 
agree with your views.

Some more in-line.

Florent

John Vollbrecht wrote:

> I am not sure I understand all the nuances of this conversation. From 
> what I understand and have read, I think Florent has seen and 
> described a possible DOS attack that could be mitigated.   My 
> impression is that Nick is right, that this is not worse than other 
> possible attacks,

I agree: there are many little venues for annoying stupid DoS attacks in 
EAP :-(

I call these attacks annoying because, from a conceptual POV, their 
presence bugs me.

I call these attacks stupid because I don't think that they are very 
efficient and practical (e.g. compared to jamming the link layer) - the 
only advantage I potentially see for now is that they would improve the 
attacker's stealthiness, say, in a wireless setting compared to a 
microwave oven attack (where radiogoniometry can be of some help).

So I understand the "DoS-like" points I raise are well known and that 
there has been a consensus not to solve them, e.g., to preserve backward 
compatibility or to improve EAP behavior when errors occur. If this 
consensus is well-established, which it seems to be, my tentative is 
rather to have text added so that the reader's attention will be drawn 
on these points (and he will be able to understand why they exist). Of 
course, when it is possible to address some of these points, I am 
probably not against it ;-)

> that the Failure attack on the peer is also possible -  and I am not 
> sure how many cases it will help.
>
> To reiterate the NAK case - If we disallow NAKs initially, then in an 
> error situation where the peer is unable to do the requested method, 
> the authenticator will receive a NAK, not accept it, and eventually 
> timeout. If the peer is able to do the requested method then 
> everything works as expected.  Disallowing the NAK eliminates the 
> possibility that an attacker could send a bogus NAK and terminate the 
> connection.
>
> particular method, and would be content to let the connection time out 
> if the peer were unable to do the method.
>
> My understanding is that Florent is suggesting that companies might 
> desire to implement such a case, and setting the authenticator to 
> ignore NAKs would eliminate a possible DOS attack.

Right, I am talking of a corporate scenario in which a company wishes to 
provide wireless access to its employees.

>
> Further, Florent has suggested that the authenticator be allowed to 
> set the initial state "CONTINUE" rather than "PROPOSED" which will 
> cause NAKs to be ignored as proposed.  I think this is possible, but I 
> am not sure it is useful.
>
> clients will have the methods installed at the same time.  There are 
> ways around this, but I think allowing multiple methods makes this 
> sort of transition much easier.

I agree that:
1) I have no idea of the percentage of companies that will have their 
employees use only one method (although I know a good many that do)
2) There is the migration issue

It's just that for now, due to the lack of mature EAP methods, there are 
few alternatives for EAP methods... ;-)

>
> My proposed change would be to put some words in the description of 
> the PROPOSE METHOD State that mentions that it is possible to set the 
> initial state to CONTINUE, but it is not recommended.  This leaves the 
> door open if there are future NAK attacks, but does not encourage 
> inflexible implementation in normal situations.

Sounds great to me.
(however, if I am the only one in favor of this text, I won't fight for 
it and burden the nice state machine document with my metaphysical 
concerns).

>
> -- 
>
> I think the case of a Failure attack on the Peer is also interesting.  
> If a peer knows that it is going to do an identity and then method-X, 
> then it can ignore everything that is not in that sequence.  I think 
> this avoid the possibility of a Failure DOS attack - where an attacker 
> sends a Failure when it sees an identity Response.
>

I also concur

> It does not fit the existing state machine well, so I don't think 
> adding it would be a good idea, but mentioning it somewhere seems 
> reasonable - perhaps in the implementation issues.

I tend to agree.

FYI, the possibility I saw however to mitigate this attack in the peer 
state machine was to tweak the methodState initial value since it is
1) set to NONE in the INITIALIZE state
2) updated in the GET_METHOD and METHOD states if they are reached
3) and checked in the transition to FAILURE from RECEIVED (methodState 
!= CONT)

so setting it to CONT instead of NONE in INITIALIZE would work IINM...
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jun 2004 14:18:16 +0300

Florent, Nick -- thanks for discussing the state machine
issues in detail. I'll write my thoughts below about the
DoS-protection for NAKs & Failures part:

I agree that these attacks described by Florent and Nick
do exist. But it is indeed so that EAP was not originally
designed with denial-of-service in mind. While we could
do some things to improve its resilience, I do not
believe that we can make EAP and its current lower
layers bulletproof. A new set of protocols would be
needed for that. While this is a potentially interesting
issue for some of us (including myself), it is not in the
charter of the working group to redesign EAP or make it
incompatible with past implementations.

We are, however, chartered to document EAP behaviour and
security considerations in detail. This should include a
description of the various vulnerabilities we have talked
about here. In some cases we can also specify behaviour which
protects against a specific vulnerability, if interoperability
and other considerations allow this.

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 is not because of the general
EAP DoS situation, but rather the implications for
debugging, eventual transitions to new EAP methods, and
ability of the network side to fail for various reasons
such as suddenly running out of resources. It looks like
disallowing NAKs and early Failures could be made to
work, but I am just not sure the tradeoff is worth it.

--Jari