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

[Michael Richardson (mcr]

-----BEGIN PGP SIGNED 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");  [


  



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP2YZ4oqHRg3pndX9AQGRtwP/fjIjpcpnRKHpNwpaoDgfwpDc1FaokGur
3PmJfoK5ht1NB0NZFl5Kk91eLlN1Eu0DHeLennuvFD455IbCzmY8VA/24OnuE19T
nqw9IQ+LBewpfH4rKOSjT3uUjH+QhMpKNCuP2T0dE1oov4OuSoUqclDG62CWIKun
CINaaIPOzQs=
=X4EW
-----END PGP SIGNATURE-----