Subject: [eap] mapping between the state machine and 2284bis

From: [email-masked] (Jari Arkko)
Date: Wed, 14 May 2003 16:29:14 +0300

Hi,

I'm trying to go through and check the state machine against the
2284bis document, to see if they are consistent and that neither
one lacks anything. Below I'll treat each individual state in the
peer state machine and discuss whether the corresponding
funtionality exists in 2284bis. The summary is that there
specifications are pretty well in sync, but a few issues
may need to be worked on.

DISABLED: OK -- not covered in 2284bis

INITIALIZE: OK -- more detail in sm
   - I think this is inline with Section 2.1,
     though 2284bis does not explicitly talk
     about this

DISCARD: OK (with a nit) -- 2284bis has more detail
   - Section 4 has a silent discard for other Code values
   - I also recently sent e-mail about whether Length >=
     received PDU should
     cause a silent discard. This too might be something
     that parseEapReq does, though it isn't specified in
     detail.
   - Perhaps there should be a "logEvent" call, as is
     required in 2284bis in the silent discard definition?

RETRANSMIT: OK (but one open issue) -- same level of detail
   - Section 4:
       If a peer receives a valid duplicate Request for which it has
       already sent a Response, it MUST resend its original Response.
   - But note the open issue listed in the sm document about
     multiple responses to the same retransmitted request while
     waiting for user input

NOTIFICATION: OK -- same level of detail
    - I think the state machine is in line with Section 2.1

SEND_RESPONSE: OK -- this is just an abstraction in the sm

GET_METHOD: NOT OK -- same level of detail, one nit and one problem
    - Incoming arrow valid according to Section 2.1 and Section 4
    - First if branch valid according to Section 2.1
    - Second if branch valid, but note that it would be imho
      clearer if setting the methodState to NORMAL in METHOD
      would also result in setting currentMethod to NONE.
      Then we could remove "resetCurrentMethod"? On the other
      hand, you appear to rely on currentMethod to stay intact
      for forbidding sequences... right?
    - The third if branch appears unclear or perhaps incorrect. Section 2.1:
       "A peer MUST NOT send a Nak (legacy or expanded) in reply to a
        Request, after an initial non-Nak Response has been sent. Since
        spoofed EAP Request packets may be sent by an attacker, an an
        authenticator receiving an unexpected Nak SHOULD silently discard it
        and log the event."
       And here we send a Nak (even if we were in the middle of
       another method). The spec talks about it being invalid for
       the authenticator to send other types while already doing
       one authentication method. We also talk about the strict
       mode, where such requests would be silently discarded.
       But I didn't find a place that says what we should do
       outside the strict mode for such requests. So should we
       respond with a Nak, as the sm does? Or silent discard?
       If silent discard, we need to split the third if branch
       into two, one dealing with currentmethod = NONE and
       one with the other case.

METHOD: NOT OK -- one nit and one small error
    - Aligned with A.1 in general, but:
    - Perhaps there should be a call to logEvent, to show the
      SHOULD requirement in A.1?
    - A.1 allows MIC failure to be a fatal error. This does
      not appear to be handled by the sm.

The following MUST requirement from 2284bis don't appear to
be handled:

    Nak (Type 3) or
    Expanded Nak (Type 254) are valid only for Response packets, they
    MUST NOT be sent in a Request.

(I'm assuming this can be interpreted on the peer side as silent
discard...)

I didn't look at FAILURE and SUCCESS, because alternative indications
were being discussed on the list. Also, the other state machines
remain to be checked...

--Jari