eap Mailing List: RE: my Issue A12 - state machines - server side

[henry.haverinen (henry.haverinen]

Michael,

I think we should not duplicate anything that
is covered by rfc2284bis or the EAP state machine
(draft-vollbrecht-eap-state) in the EAP method drafts.
They specify, among other things, the processing of 
EAP notifications, EAP identity, EAP Success, EAP Failure,
how the Identifier field is used, and how the EAP exchange
proceeds in general.

Certainly we have to specify the processing of
EAP/SIM packets, also in any error and corner
cases, such as unexpected Subtype, or unexpected
attributes included. In the current version, the default action
in error cases is Silent Discard and that is specified for
these cases too. However, we're planning to change the drafts 
according to Glen's comments. In the next versions, if an error 
occurs in the server, the server generally issues EAP Failure. 
If an error occurs on the client, the client sends a Client Error
packet (a new EAP/SIM subtype), and the server is expected
to respond with EAP Failure.

I agree the specification in general needs some re-structuring
and clarification, but I'm inclined to think we don't
need to add state machines to the documents.
They are after all quite simple request/response protocols,
and the operation in various cases can be described 
unambiguously without state machnies. 
However state machnies can be very useful in the discussions,
even if we did not make them part of the document.

Regards,
Henry


> -----Original Message-----
> From: ext Michael Richardson [mailto:mcr [at] sandelman.ottawa.on.ca]
> Sent: 15 September, 2003 22:59
> To: eap
> Subject: [eap] my Issue A12 - state machines - server side
> 
> 
> 
> *** PGP Signature Status: unknown
> *** Signer: Unknown, Key ID = 0xE99DD5FD
> *** Signed: 15.09.2003 10:58:26 PM
> *** Verified: 16.09.2003 11:08:00 AM
> *** BEGIN PGP VERIFIED MESSAGE ***
> 
> 
> >>>>> "Michael" == Michael Richardson 
> <mcr [at] sandelman.ottawa.on.ca> writes:
>     Michael> A12)     section 5.1, 5.2 and 5.3 should have 
> *NO* mention of
>     Michael>  re-authentication. Please describe the base 
> protocol first,
>     Michael>  (including state machines), and then give the 
> version that 
>     Michael>  supports re-authentication.
> 
>   I have implemented basic authentication so far. As such, my 
> state machines
> are incomplete, but even so, there are a number of holes and 
> questions that
> are not easily determined from reading the document.
> 
>   In particular, as I'm writing this, I realize that the EAP-business
> of dealing with retransmits in IDs is probably best made explicit in
> new states.
> 
>   Obviously, I have not taken into account any notifications.
> 
>   I suggest text based upon what I write here. I.e. in this style.
>   I can write similar text for the client.
> 
>   The server seems to have three states in my implementation:
>       1) START
>       2) CHALLENGE
>       3) SUCCESS
> 
>   0) 
> 
>   Upon recognizing the user as an EAP-SIM, the server transitions into
>   the START state. This is done upon receipt of an 
> EAP/Identity message
>   detailing a user who should be using EAP-SIM.
>   (EAP may have other state that it goes through to get here)
> 
>   1) START
> 
>   The transition into the START state will result in transmitting an 
>   EAP-Request/Sim/Start message. 
> 
>   When in state "Start", the following messages may be received:
>        a) An EAP-Response/Sim/Start.   
>         i) Verify selected version is compatible and presence 
> of NONCE_MT,
>            and transition to 2) CHALLENGE.
>         
> ****    ii) upon failure to verify - ????
> 
>        b) An EAP/Identity message. Transition to 1) START.
> 
> ****   c) OTHER MESSAGES - unsure. Transition to 1) START ????
> 
>   2) CHALLENGE
> 
>   The transition into the CHALLENGE state will result in an
>   EAP-Request/Sim/Challenge message being sent. 
>   {Existing RAND challenges should be used if this user has not
>    completed the state yet. The EAP ID should not be updated}
> 
>   When in state "Challenge", the following messages may be received:
>        a) an EAP-Response/Sim/Start 
>         i) Verify selected version is compatible and presence 
> of NONCE_MT,
>            and transition to 2) CHALLENGE.
>         
> ****    ii) upon failure to verify - ????
> 
>        b) an EAP-Response/Sim/Challenge
>         i) verify AT-MAC. If valid, transition to 3) SUCCESS.
> ****    ii) If AT-MAC failes then ????
> 
> ****   c) an EAP/Identity message. Transition to 1) START ????
> 
>        d) OTHER MESSAGES - unsure. Drop?
> 
>   3) SUCCESS
> 
>   The transition into the SUCCESS state will result in an EAP-Success
>   message being sent.
> 
>   When in state SUCCESS, receipt of any message results in a 
> transition
>   back to (0).
> 
> ]      Out and about in Ottawa.    hmmm... beer.              
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON  
>   |net architect[
> ] mcr [at] sandelman.ottawa.on.ca 
> http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another Debian/notebook using, kernel hacking, 
> security guy");  [
> 
> 
>   
> 
> 
> 
> 
> *** END PGP VERIFIED MESSAGE ***
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
> 
>