Subject: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues

From: <[email-masked]>
Date: Wed, 19 Nov 2003 11:52:44 +0200

Proposed resolution to issue 198: Other EAP Peer SM issues

- Remove all references to EapTunnelled (it does not adequately
  define behavior of existing tunneled methods, and we don't even
  need to describe their behavior in this document).

- Change in Section 4.1.1 (portEnabled) from:

  "Indicates that there is a valid port to use for the
  communication.  If at any point the port is not available,
  portEnabled is set to FALSE and the state machine transitions
  to DISABLED (or BACKEND_DISABLED)."

  to

  "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."
      
- Change in Section 5.1.1 (portEnabled) from

  "Indicates that there is a valid port to use for the
  communication.  If at any point the port is not available,
  portEnabled is set to FALSE and the state machine transitions
  to DISABLED."
 
  to 

  "Indicates that the EAP authenticator 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."

- Change in Section 4.1.3 (ClientTimeout) from:

  "Configurable amount of time to wait for a valid request
  before aborting."
  
  to

  "Configurable amount of time to wait for a valid request
  before aborting, initialized by implementation-specific 
  means (e.g. a configuration setting)."

- Change in Section 4.2 from

  "methodState=DONE: The method always continues at this point,
  (or the peer sees no point in continuing it)."

  to

  "methodState=DONE: The method never continues at this point
  (or the peer sees no point in continuing it)."

- Add to Section 8 (implementation considerations):

  "Implementations may define an additional interfaces to pass
  method-specific information between methods and lower layers.
  These interfaces are beyond the scope of this document."

Best regards,
Pasi
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Wed, 19 Nov 2003 14:40:10 -0500 (EST)

I agree with the proposed changes.

nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 20 Nov 2003 15:09:27 -0500

>   need to describe their behavior in this document).
I like all the changes except the removing of EapTunnelled.  It is set if 
EAP is running in tunnelled mode and hence allowed to do method sequencing. 
I think this is a marker that says that sequences are not allowed on 
unprotected connections, but are (or are not forbidden) in protected 
connections.  I see no reason to take this out.  EAP is not constrained to 
run in an unprotected mode, and this indicates that everything should be 
the same in protected mode, except that method sequences are possible.