Subject: [HOKEY] consensus call: ERX transport

From: Charles Clancy <[email-masked]>
Date: Mon, 23 Jul 2007 13:41:40 -0400

During our email discussions, the idea of defining these general-purpose 
packets to carry ERX payloads was discussed.  These included 
EAP-Identity-v2/Request, EAP-Identity-v2/Response, and EAP-Success-v2. 
There seemed to be vague non-hatred of this idea as a compromise among 
several different approaches.

Our AD has strongly encouraged us to not pursue this route as it's 
beyond our current charter's scope.  As a result, the current course of 
action is to leave the current ERX transport as-is.  If there is any 
strong opposition to this direction, please comment by August 2.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc
adjunct professor, electrical engineering, university of maryland

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Jul 2007 17:29:38 -0400

I am probably misunderstanding, but I don't understand why
EAP-Identity-v2/Request, EAP-Identity-v2/Response, and EAP-Success-v2
(or we could rename the messages differently to look better) are
beyond our current charter while the current ERX transport is within
the charter.  There is no difference in that both schemes require new
EAP Code assignment and requires modifications to EAP.

I am not arguing against the current ERX transport, but just needs
more clarification on AD's opinion.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Jul 2007 18:42:05 -0400

Tim,

Thank you for the clarification.

With regard to modification to state machine, ERX also requires
modification to EAP state machine, Section 5.2 of
draft-ietf-hokey-erx-03.txt says:

"
   Notes on authenticator state machine:

   The authenticator state machine needs to be modified to consider the
   EAP Re-authentication exchange as a "response" to the EAP Request
   Identity and transfer the state machine to follow the EAP Re-
   authentication exchange and determine Success or Failure of the
   exchange based on whether the EAP Finish Re-auth message is a Success
   or Failure.  The authenticator MUST consider that it has received a
   response to the EAP Request Identity and cancel the corresponding
   retransmission timer.
"

I am wondering if ERX is acceptable from the viewpoint of EAP
participants.

Best Regards,
Yoshihiro Ohba

On Tue, Jul 24, 2007 at 05:22:39PM -0500, Tim Polk wrote:
> Yoshi,
> 
> I am basing my analysis on section 4, "HOKEY Re-Auth Protocol  
> Document", of
> draft-clancy-hokey-plan-00.txt.  While this is not an official WG  
> document, I understand
> that it documents WG consensus established since Prague.  The  
> important excerpt is:
> 
> >   EAP-ER shall be adopted as a working group document to satisfy the
> >   HOKEY Re-Auth Protocol requirement, subject to a variety of  
> >caveats:
> >
> >   [extra stuff deleted...]
> >   o  The EAP-Initiate/Reauth packet shall be converted into a "new"
> >      version of the EAP-Response/Identity.
> >   o  The EAP-Finish/Reauth packet shall be converted into a "new"
> >      version of the EAP-Success.
> >
> >   These "new" packet codes shall be designed in a generic fashion,  
> >such
> >   that they could be used by future EAP extensions.  For example, the
> >   Identity codes could natively include network selection  
> >information,
> >   rather than embedding them into the prompt and client NAI fields.
> >   The "new" EAP-Success could include native support for protected
> >   results indication.
> >
> 
> I conferred with other ADs, and we interpret these actions as changes  
> to the base EAP
> messages and state machine.  That, in my opinion and several others,  
> exceeds your
> scope.  Hokey isn't chartered to revise EAP, it is chartered to  
> extend the EAP framework
> to facilitate inter-authenticator handover and roaming.
> 
> Yes, I understand that the ERX protocol as currently specified will  
> exchange the same
> information regardless of whether these are Hokey-specific reauth  
> messages, or changes
> to the EAP Identity/Request and Success messages.   However,  
> modifications to the EAP
> messages and state machine are clearly unacceptable from the  
> viewpoint of the EAP
> participants.  That is a non-starter, and I hate to see the WG devote  
> a lot of time and energy
> to a document I can't progress!
> 
> The EAP folks still have some questions about the implications of  
> ERX, so I still
> have a lot of coordination to do.   However, I have confidence that  
> the ERX mechanism
> (as currently specified) can be progressed.
> 
> Hope that helps.
> 
> Tim Polk
> 
> On Jul 24, 2007, at 4:29 PM, Yoshihiro Ohba wrote:
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 25 Jul 2007 10:06:05 +0200

Hi all,
> but I don't understand why
> the charter.
I have to confess that me neither. At this point, I don't know why "ERX
as-is" is a better option.

On the other hand, not sure whether ERX is a pure transport since the
signature affects the own ERX packets. As far as I conceived it (maybe
I'm wrong but), EAP-Identity-v2/Response, and EAP-Success-v2... (or
whatever name you may better want to choose) can convey cryptographic
information (like a token) but it does not mean that cryptographic
information is applied to the EAP packet itself (at least i implemented
it in that way :) )
>   There is no difference in that both schemes require new
Agree.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 25 Jul 2007 08:20:06 -0700

All,
A couple of clarifications: 

- The current notes on the authenticator state machine describe how to
transition from the EAP to ERX state machine.  If there is no
transition, the EAP state machine can time out, but, I believe that
would not be ideal. 

- With the proposed EAP Initiate/Re-auth Start message (the optional
authenticator-initiated ERX message that Charles proposed), there won't
be a need for this transition; this has just been discussed and is not
yet reflected in the draft. 

Thanks,
Vidya

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 3:42 PM
> To: Tim Polk
> Cc: [email-masked]
> Subject: Re: [HOKEY] consensus call: ERX transport
> 
> Tim,
> 
> With regard to modification to state machine, ERX also 
> requires modification to EAP state machine, Section 5.2 of 
> > Document", of draft-clancy-hokey-plan-00.txt.  While this is not an 
> > official WG document, I understand that it documents WG consensus 
> > established since Prague.  The important excerpt is:
> > 
> > to the base EAP messages and state machine.  That, in my 
> opinion and 
> > several others, exceeds your scope.  Hokey isn't chartered 
> to revise 
> > EAP, it is chartered to extend the EAP framework to facilitate 
> > inter-authenticator handover and roaming.
> > 
> > exchange the same information regardless of whether these are 
> > Hokey-specific reauth messages, or changes
> > messages and state machine are clearly unacceptable from 
> the viewpoint 
> > of the EAP participants.  That is a non-starter, and I hate 
> to see the 
> > WG devote a lot of time and energy to a document I can't progress!
> > 
> > The EAP folks still have some questions about the 
> implications of ERX, 
> > so I still
> > >>During our email discussions, the idea of defining these general- 
> > >>purpose packets to carry ERX payloads was discussed.  
> These included 
> > >>EAP-Identity-v2/Request, EAP-Identity-v2/Response, and 
> EAP-Success- 
> > >>v2.
> > >>There seemed to be vague non-hatred of this idea as a compromise 
> > >>among several different approaches.
> > >>
> > >>beyond our current charter's scope.  As a result, the 
> current course 
> > >>of action is to leave the current ERX transport as-is.  
> If there is 
> > >>any strong opposition to this direction, please comment 
> by August 2.
> > >>
> > >>--

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 25 Jul 2007 09:05:18 -0700 (PDT)

Hi Vidya,

On Wed, July 25, 2007 8:20 am, Narayanan, Vidya wrote:
> transition from the EAP to ERX state machine.

A transition between state machines? It's an EAP packet. It's being
received by the EAP layer. It's being processed by a chunk of EAP code.
The state machine to handle requires a change.

>                                                If there is no

No, that would not be ideal. Which brings up a question that has been
nagging me for a while. How is a peer to know whether the server
is HOKEY-enabled or not? It could respond to the ID request with this
new ERX packet which the authenticator will...well, I guess drop on the
floor. Then is the peer just supposed to wait some period of time before
assuming that a fast handover is just not gonna happen and had he just
responded with his identity he'd be authenticated by now.

Doesn't this require a giant flag day for deployment?

  Dan.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 25 Jul 2007 09:20:52 -0700

Yoshi,

Back in April we had a long and extensive debate on use of new EAP codes,
versus loading EAP success. 
Many people with extensive EAP experience talked about problems with new EAP
codes. Examples (picked one per author during the "consensus call for EAP-ER
as a HOKEY protocol):

http://www1.ietf.org/mail-archive/web/hokey/current/msg00454.html
http://www1.ietf.org/mail-archive/web/hokey/current/msg00453.html
http://www1.ietf.org/mail-archive/web/hokey/current/msg00456.html

Not claiming to have extensive EAP experience, personally made an attempt at
showing how EAP methods with existing EAP messaging framework can be used to
solve the problem (EAP-HR solution). 

How the consensus call with such an extensive debate and oppositions against
it led to where we are today, I am still at awe. May be we need a
Clancy-plan-01 :)

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 3:42 PM
To: Tim Polk
Cc: [email-masked]
Subject: Re: [HOKEY] consensus call: ERX transport

Tim,

"

Best Regards,
Yoshihiro Ohba

On Tue, Jul 24, 2007 at 05:22:39PM -0500, Tim Polk wrote:
> >>purpose

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 25 Jul 2007 10:04:53 -0700

Hao brought up some of the issues related to backward compatibility in a 
face to face discussion after the meeting on Monday morning.

Let's see if we can walk through them here:

Case 1.  legacy peer, ERX-capable authenticator:

The authenticator sends EAP Initiate/Reauth-Start (as per Charles's 
proposal).

So the peer receives a message with a new EAP code it doesn't 
understand, it sends the equivalent of EAPoL-Start and the authenticator 
can take it from there.

If the peer's message, EAPoL-Start comes first, that'll also work.

If the authenticator sends both EAP Request/Identity and EAP 
Initiate/Reauth-Start, there may be a need for a hook between the 
"additions" to the state machine and the current state machine.

Case 2.  ERX-capable peer, legacy authenticator

The peer send EAP Initiate/Reauth message, but receives an EAP 
Request/Identity (it would expect EAP Initiate/Reauth-Start from an ERX 
authenticator).  It responds with EAP Response/Identity and kills the 
EAP Initiate/Reauth message (no further retransmissions).

I am not claiming that this is fully thought through :).  I am looking 
for others' input.

thanks,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 25 Jul 2007 12:02:11 -0700 (PDT)

Hi Lakshminath,

  It was case #2 I was thinking about. So it's your view that a peer
will know whether an authenticator is HOKEY-aware or not by whether it
gets an Initiate/Reauth-Start or an identity request? In the ERX draft
the authenticator sends an identity request and gets a Initiate/Reauth
in response.

  Also, EAPOL-Start is not required. Typically 802.1x begins with a
link-up event noticed by the authenticator who constructs an identity
request. An EAPOL-Start, if received, will reset the state machine
but it can, and usually does, proceed without ever getting that packet.
I think it might be problematic to depend on receipt of an EAPOL-Start
from a peer to inform an authenticator whether the peer is HOKEY-aware
or not (case #1).

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 25 Jul 2007 12:09:54 -0700

Hi Dan, 

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Wednesday, July 25, 2007 9:05 AM
> To: Narayanan, Vidya
> Cc: Yoshihiro Ohba; Tim Polk; [email-masked]
> Subject: RE: [HOKEY] consensus call: ERX transport
> 
> 
>   Hi Vidya,
> 
> A transition between state machines? It's an EAP packet. It's 
> being received by the EAP layer. It's being processed by a 
> chunk of EAP code.

I guess it depends on how it is implemented.  In any case, it is a new
chunk of state machine which is hooked on to the existing state machine.
It is that "hook" that is described in the current text. 

> No, that would not be ideal. Which brings up a question that 
> has been nagging me for a while. How is a peer to know 
> whether the server is HOKEY-enabled or not? It could respond 
> to the ID request with this new ERX packet which the 
> authenticator will...well, I guess drop on the floor. Then is 
> the peer just supposed to wait some period of time before 
> assuming that a fast handover is just not gonna happen and 
> had he just responded with his identity he'd be authenticated by now.
> 

Did you mean server isn't HOKEY-enabled or authenticator isn't
HOKEY-enabled or both?  In some lower layers, the ERX support will be
indicated by the lower layer and hence the peer will know about that.
In case the peer has no idea of whether the server supports ERX, it can
do an ERP bootstrapping exchange without waiting for a handoff (i.e.,
after finishing regular EAP through an authenticator) - it will not get
a response and can conclude that ERP isn't feasible. 

With the proposed change of having an ERP-specific initiation message
from authenticator, it will be clearer, since the authenticator will
only send the EAP Initiate/Re-auth-Start message if it supported ERP.
If it only sent EAP Request/ID, it doesn't indicate support for ERP. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 25 Jul 2007 12:14:47 -0700

Hi Dan, 

> Sent: Wednesday, July 25, 2007 12:02 PM
> To: Dondeti, Lakshminath
> Cc: Dan Harkins; Narayanan, Vidya; Tim Polk; [email-masked]
>   It was case #2 I was thinking about. So it's your view that 
> a peer will know whether an authenticator is HOKEY-aware or 
> not by whether it gets an Initiate/Reauth-Start or an 
> identity request? In the ERX draft the authenticator sends an 
> identity request and gets a Initiate/Reauth in response.
> 

The current draft hasn't been reflected to include the proposed
Initiate/Reauth-Start. It needs to be updated on that. 

>   Also, EAPOL-Start is not required. Typically 802.1x begins 
> with a link-up event noticed by the authenticator who 
> constructs an identity request. An EAPOL-Start, if received, 
> will reset the state machine but it can, and usually does, 
> proceed without ever getting that packet.
> I think it might be problematic to depend on receipt of an 
> EAPOL-Start from a peer to inform an authenticator whether 
> the peer is HOKEY-aware or not (case #1).
> 

I'm not sure that case #1 relies on the peer sending EAPoL-Start.  If
the peer sends it, it also works; but, I think an authenticator that has
no idea about the peer's capability of supporting ERX should send both
EAP Request/Identity and EAP Initiate/Re-auth-Start, so that the peer
can just continue with regular EAP. 

Vidya

> > Hao brought up some of the issues related to backward 
> compatibility in 
> > a face to face discussion after the meeting on Monday morning.
> >
> > understand, it sends the equivalent of EAPoL-Start and the 
> > authenticator can take it from there.
> >
> > Request/Identity (it would expect EAP Initiate/Reauth-Start from an 
> > ERX authenticator).  It responds with EAP Response/Identity 
> and kills 
> > the EAP Initiate/Reauth message (no further retransmissions).
> >
> >>> - The current notes on the authenticator state machine 
> describe how 
> >>> to transition from the EAP to ERX state machine.
> >>
> >> nagging me for a while. How is a peer to know whether the 
> server is 
> >> HOKEY-enabled or not? It could respond to the ID request with this 
> >> new ERX packet which the authenticator will...well, I 
> guess drop on 
> >> the floor. Then is the peer just supposed to wait some 
> period of time 
> >> before assuming that a fast handover is just not gonna 
> happen and had 
> >> he just responded with his identity he'd be authenticated by now.
> >>

---

From: Tim Polk <[email-masked]>
Date: Tue, 24 Jul 2007 17:22:39 -0500

Yoshi,

Hope that helps.

Tim Polk