Subject: [eap] EAP state machine

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Nov 2003 08:48:16 -0500

-----BEGIN PGP SIGNED MESSAGE-----

I read the EAP state machine draft this morning in the airport.

I had printed it, since reading diagrams on the computer is not very
pleasant. My comments:

1) presentation. 

a) Please make the diagrams use non-zero-width lines in the boxes. Zero-width
   lines do not always render perfectly with all tools/printers. True, it is
   bugs in some tools, and in some printers and some printer drivers.  But
   it is not always fixable.

   Specifically, I experience that some sides of the boxes are not being
   drawn. The PDF is fine, btw. The Postscript is not. I am not certain where
   the problem originates, or where the postscript was generated. 

   (I recall that diagrams that I did with other tools with zero-width
   lines did not import into MS-Office 2000 either)

b) please write the conditionals, with one condition per line.
	  i.e.	A &&
		B &&
		C || 
		D
		
   rather than	A && B &&
		C || D.

   You may even want to use a somewhat unorthodox, but often more clear 
   format of:
	  A
	  && B
	  && C
	  || D

  (FreeS/WAN's pluto uses this style for its C code. It weirded me out at
  first, but I've come to appreciate it a bit)

2) authority

>3.3 Document authority
>
>   Should a  conflict  exist  between  the  interpretation  of  a  state
>   diagram and  either  the  corresponding  global transition  tables
>   or the  textual  description  associated  with  the  state  machine,
>   the state  diagram  takes precedence. When a discrepancy occurs
>   between any part of this document (text or diagram) and any of the
>   related documents ([I-D.ietf-eap-rfc2284bis], [RFC3579], etc.) the
>   latter (the other document) is considered authoritative and takes
>   precedence.

  I am concerned that the diagram, which can't easily be quoted, displayed
or edited is considered authoritative. In addition, while 2223 is slightly
vague about which version is considered authoritative,
draft-rfceditor-editor-rfc2223bis-07 is pretty clear: 
    
      The ASCII plain text version (and its .txt.pdf facsimile) is
      always the official specification, and it must adequately and
      completely define the technical content.  (A very few exceptions
      have been made over the 30 year history of RFCs, allowing a
      definitive PostScript (.ps) version with no .txt version.)  The
      primacy of the ASCII version typically requires that the critical
      diagrams and packet formats be rendered as "ASCII art" in the .txt
      version.

  The above text would seem to contradict this.

  I am also concerned that this document is not authoritative vs the other
documents. 

  I believe that each state in the diagram should have a paragraph explaining
it, its entry conditions and exit conditions.

3) Standalone authenticator State machine - retransmit state

There is no text for me to quote to discuss this, so I can't really 
point at anything, nor can I offer "alternative text" either.

There is a major problem with this state. It can not be implemented in some
transports. The major one is radius. A radius server (which would be the EAP
Requestor) does not initiate new messages on its own. 

It also does not retransmit ever. Rather, it relies on the client to resend
its request, and it will retransmit the reply. EAP does not easily fit into
this, and this state machine shows nothing.

One might say that this is radius' problem. Perhaps. But, it needs to be
documented, and I believe that it has effects on the client (peer) state
machine as well. 

So, I do not agree that this document is ready for last call.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 Nov 2003 11:49:41 -0800

Hi,

> Requestor) does not initiate new messages on its own. 

Standalone authenticator does not use any AAA protocol (RADIUS,
Diameter, etc.), So I don't undersand why RADIUS comes into the
picture here.

Yoshihiro Ohba

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBP6+W+YqHRg3pndX9AQH8gQP/WP6hDumYvv4RRGTv2sJeisvO6xCcLsI9
> +qfcmxTBqp6vXUeGGOZ4bSKitMOtaOmUf1m10P2jHsOSZBauovuc9kQzU1UiwMwi
> iKEFTjxfdcwRPyVxzzgGGlcgjM1HzGXy6ddaB1LaChbAvgdNDdWW3Hi/tt9w31oW
> +ZpHY87F648=
> =7Jky
> -----END PGP SIGNATURE-----

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Nov 2003 14:48:21 -0600

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:
    Yoshihiro> On Mon, Nov 10, 2003 at 08:48:16AM -0500, Michael Richardson
    Yoshihiro> wrote:
    >> There is a major problem with this state. It can not be implemented in
    >> some transports. The major one is radius. A radius server (which would
    >> be the EAP Requestor) does not initiate new messages on its own.

    Yoshihiro> Standalone authenticator does not use any AAA protocol
    Yoshihiro> (RADIUS, Diameter, etc.), So I don't undersand why RADIUS
    Yoshihiro> comes into the picture here.

  Uh, what?

  EAP doesn't live on a wire. It lives in other protocols.

  For instance, this is a "standalone" server - it doesn't talk to any
"backend"

         |-------------------------EAP------------------|

      supplicant              AP--------radius--------server 
	 +-------- 802x ------+

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 Nov 2003 14:29:13 -0800

>       supplicant              AP--------radius--------server 

When we use the word "standalone", it points to EAP authenticator 
that shows a basic, non-passthrough authenticator's behavior, as described 
in section 2 of the state machines draft.  

In the above example, AP acts as a passthrough authenticator, and 
the RADIUS server is a "backend" server to the passthough authenticator, 
not a "standalone" authenticator.  (AP is talking to the backend server).

Yoshihiro Ohba

> iQCVAwUBP6/5lIqHRg3pndX9AQEZowP+Kwg5/LB1qZk30+Zz32kfACMIs2lnsYux
> ZGgFFwL77R+9rqGS2/BWUwlTrr66TdFbpgR0smxUlgYbpEy8z5ftY/Snuc09xNo4
> rzu40sLKebFji9L5QETQqyL67tUdlJA7cdOy6KlsnSEOgBwetonHU7p/5cqTtibT
> mvZPEl5KEq0=
> =djIQ

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Nov 2003 00:34:52 +0200

Michael Richardson wrote:
> a) Please make the diagrams use non-zero-width lines in the boxes.

Agree, but I'm not even sure we need postscript versions.

> b) please write the conditionals, with one condition per line.

Agree.
  		
>    You may even want to use a somewhat unorthodox, but often more clear 

Uh.

>       diagrams and packet formats be rendered as "ASCII art" in the .txt

We are working with the RFC editor to figure out what to do in our
particular case. Our statemachines aren't easily representable in
ASCII art, so we do have a problem. Or should we publish state
*tables* in ASCII, and an associated PDF version.

But *if* we can figure out a way to do this in ASCII, then I
would agree with you that it should be the authorative one.
Just don't know if its possible in this case.

> it, its entry conditions and exit conditions.

Hmm... I think most of the explanations of why things are done in a certain
way are in 2284bis. We had some explanations in earlier versions of the state
machine document too, but it was hard to get them synchronized with the diagrams.
Personally, I find it easies to grasp the semantics from the diagram. Additional
text does not help, it hurts.

> documented, and I believe that it has effects on the client (peer) state

Well, the functionality split in the passthrough case is non-trivial.
When the authenticator is standalone, all of EAP is terminated in the
same node. However, with a passthrough some parts of the termination
(such as retransmission) are done in the passthrough and the rest
in the backend authenticator.

So I would agree with Yoshi that you shouldn't apply the standalone
authenticator diagram in the case of radius. Then you should apply
the Figure 7 diagram in the passsthrough and the backend auth diagram
in the RADIUS server.

> So, I do not agree that this document is ready for last call.

Hey, we got you reading it, didn't we ;-)

--Jari

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Nov 2003 16:56:30 -0600

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:
    Jari> But *if* we can figure out a way to do this in ASCII, then I
    Jari> would agree with you that it should be the authorative one.
    Jari> Just don't know if its possible in this case.

  My opinion is that each state needs to have text explaining it.
  It should explain how you enter the state, and the conditions to exit it.
Instead, this document seems to spend a lot of space explaining a lot of
variables, but doesn't seem to shed any light on the problem.
  
  Is this document modeled after some IEEE document format?

    >> documented, and I believe that it has effects on the client (peer) state

    Jari> Well, the functionality split in the passthrough case is non-trivial.
    Jari> When the authenticator is standalone, all of EAP is terminated in the
    Jari> same node. However, with a passthrough some parts of the termination
    Jari> (such as retransmission) are done in the passthrough and the rest
    Jari> in the backend authenticator.

  No. You don't understand radius then.
  A radius server, which is where the EAP would be terminated CAN NOT
RETRANSMIT. It can only respond to retransmissions from the client.

    Jari> So I would agree with Yoshi that you shouldn't apply the standalone
    Jari> authenticator diagram in the case of radius. Then you should apply
    Jari> the Figure 7 diagram in the passsthrough and the backend auth diagram
    Jari> in the RADIUS server.

  I don't understand why. The EAP is inside the Radius server.

    Jari> Hey, we got you reading it, didn't we ;-)

  Actually, it got printed before the last call got issued. 
  I have to be at IPSP as well, so I won't be there at some point.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Nov 2003 17:06:57 -0600

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:
    Yoshihiro> When we use the word "standalone", it points to EAP
    Yoshihiro> authenticator that shows a basic, non-passthrough
    Yoshihiro> authenticator's behavior, as described in section 2 of the
    Yoshihiro> state machines draft.   

    Yoshihiro> In the above example, AP acts as a passthrough authenticator,
    Yoshihiro> and the RADIUS server is a "backend" server to the passthough
    Yoshihiro> authenticator, not a "standalone" authenticator.  (AP is
    Yoshihiro> talking to the backend server). 

  okay.   I understand the terminology now. 

  I don't see anything in the backend state machine to accomplish
retransmission. It says that the radius server retransmits... but so what?

  When it retransmits, it will be sending a response to the previous EAP
request, NOT the current one, so the IDs won't match, etc.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 Nov 2003 15:18:58 -0800

>   okay.   I understand the terminology now. 

OK.

> retransmission. It says that the radius server retransmits... but so what?

In Figure 5 (EAP Backend Authenticator State Machine), there is no 
"RETRANSMIT" state unlike standalone authenticator.  So the diagram indicates 
that the backend authenticator does not perform timer-based retransmission.
(i.e., we actually understand the RADIUS behavior.)

Yoshihiro Ohba

> iQCVAwUBP7AaD4qHRg3pndX9AQGkIgP9HZAMG800CjVA9pT7WY/nyiRBIHgCgUdI
> XDiHOJy6xvmR1VVI/auR7L14KydgGhvmhiL0JIlZM2BgZOHdfwLLqs6fgAPSqZ7B
> UWQp0riJem6VIwyqXvhkiVULBifQeexLWJ7dmtGYzmUvixq/AVVDcgLaMpEpFkTT
> Qv31hFJPLMs=
> =5juS