Subject: [Pana] [issue28] PaC and PAA state machines

From: [email-masked]
Date: Fri, 19 Sep 2003 12:46:29 +0300

New submission from Dan Forsberg <[email-masked]>:

Initial version (v0.1) of PAA state machine.
See file: PAA_State_Machine_v0.1.jpg
- Does not contain error handling
- Does not contain timer handling

----------
status: No Discussion -> Pending
________________________________________________
PANA Issues <[email-masked]>
http://danforsberg.info:8080/pana-issues/issue28
________________________________________________

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 23 Sep 2003 21:27:28 -0700

Hello Dan,

> - Does not contain timer handling

Thank you very much for working on the state machine.
Please find my comments on the state machine.

-------
Comments on PANA State Machine v0.1

1. General comments

o The proposed PANA state machine represents the basic PANA protocol
  behavior comprehensively and I think we should include the state
  machine in the PANA specification to improve interoperability of the
  protocol.  On the other hand, there are several places where further
  improvement or correctness can be expected.

o It might improve readability if verbs such as Tx (transmit) and Rx
  (receive) are added to the strings that represent events and
  actions. (It looks that underlined strings represent events and
  non-underlined strings associated with arrows represent actions.)

o Both PaC and PAA state machines seems to assume that PANA
  authentication immediately fails if the first EAP authentication
  fails.  However, this is not always true according to the PANA
  specification.  When two EAP authentications are performed in a
  single PANA authentication, it is possible that the 2nd EAP
  authentication is performed even after the 1st EAP authentication
  fails.

2. Specific comments on the PaC state machine

o I think we need a variable that stores whether the 2ND_EAP state has
  been visited in order to avoid the state machine to visit the
  2ND_EAP state twice or more.

o In the transition from WAIT_REAUTH_ANS state to SESS_TERM state, I
  think the event "PANA-Reauth-Answer(Failure)" is not an appropriate
  event to make this transition if the event means that the received
  PANA-Reauth-Answer message does not contain a valid MAC AVP.  If the
  PAA changes its state when receiving a PANA-Reauth-Answer with an
  invalid MAC AVP, an attacker can launch a DoS attack of sending
  bogus messages to make the reauthentication easily fail.  A robust
  design should silently discard the received message without
  changing the state, and the transition from WAIT_REAUTH_ANS state to
  SESS_TERM state should be made only when a session timeout event
  occurs.

o I think it is possible that a PaC in OPEN state can trigger EAP
  reauthentication by sending a PANA-PAA-Discover message to its PAA
  when it wants to reauthenticate the PAA.  We can add a transition
  from OPEN state to DISC state with event "SIGNAL: EAP Reauth" and
  action "Tx PANA-PAA-Discover".

2. Specific comments on the PAA state machine

o Since PAA is designed to be stateless for handling PANA-PAA-Discover
  messages sent from unknown PaCs, the transition from OFFLINE state
  to DISC state should not occur when receiving a PANA-PAA-Discover
  message and thus the state should stay in OFFLINE when receiving a
  PANA-PAA-Discover message.  For the same reason, direct transitions
  from OFFLINE to WAIT_REAUTH_ANS and WAIT_AUTH_ANS should be made
  when the PAA in OFFLINE state receives a PANA-Start-Answer message,
  and DISC state should be removed.

o With regard to the transition from WAIT_EAP state to AUTH_FAILED
  state, when there is 2nd EAP authentication, the 1st EAP
  authentication failure should not change the state to the
  AUTH_FAILED state (as mentioned in the general comments.)
  Similarly, with regard to the transition from WAIT_EAP state to OPEN
  state, when the 2nd EAP authentication as well as the 1st EAP
  authentication fails, the transition from from WAIT_EAP state to
  OPEN state should not occur.

o The same comment as the 2nd comment on the PaC state machine also
  applies to the PAA state machine.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 23 Sep 2003 21:27:28 -0700

Hello Dan,

-------

1. General comments