eap Mailing List: Re: [Issue 247] Comments on EAP state machine v4

Hi Nick,
Many thanks for your answer.
See some more in-line.
BR,
Florent
Nick Petroni wrote:
...
Comment #1 - Editorial
In section 3.2 state machine symbols, we can read:
"+ Arithmetic addition operator.
- Arithmetic subtraction operator."
I find these definitions useless ...

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.
I agree, #1 is really minor
IMHO they are not *that* confusing,

even on the issue of space of operation, to most implementers.

I agree though some precision would do no harm ;-)
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.
Good catch. Similarly < is defined but is not used
Perhaps we

should clean up all of these at one time and just identify symbols that

are used? Are we missing any others?

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)

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

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.

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

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

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

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

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.

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 :-(
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.

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.

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

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

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.
Comment #11 - Editorial
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?

I agree
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.

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.

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

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.

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

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

Re: [Issue 247] Comments on EAP state machine v4	<– Date –> <– Thread –>
From: Florent Bersani (florent.bersanird.francetelecom.fr)
Date: Fri, 25 Jun 2004 09:06:18 -0400 (EDT)

eap Mailing List
View Index by: Date - Thread - Author