Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

From: "M. Vanderveen" <[email-masked]>
Date: Tue, 3 Apr 2007 11:30:58 -0700 (PDT)

Regarding carrying data on the EAP-Success. Let's not forget that the previous EAP RFC2284 allowed carrying data in the EAP Success. Consequently methods deployed between 1998 and 2004 could have very well already carried data in it. In fact there is relatively wide deployment in Europe of an EAP method that does just that.

If I recall correctly the reason for banning data in the EAP-Success was because it should be protected, and we did not have a method-independent way to do that. 

An important point I would like to make regards implementation/deployment:
Folks with experience implementing and maintaining servers (not NASes/BSs) claim that it would be much easier to modify EAP behavior by adding data onto the EAP-Success than by adding new Codes.  That is because adding new methods is something that is WELL-UNDERSTOOD and done frequently. Adding something under the EAP method layer is not.  They fear a lot of implementation complexity and ongoing test efforts with the addition of EAP-ER onto existing EAP server implementations. 

Michaela

----- Original Message ----
From: Avi Lior <[email-masked]>
To: Lakshminath Dondeti <[email-masked]>; Madjid Nakhjiri <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, April 3, 2007 6:47:43 AM
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol

I for one thinks we should look at allowing us to carry data in EAP success.  In fact, it would be a good idea if we allowed EAP to carry data which is not part of the method in all exchanges. 

Clearly there is a need to communicate with the Peer before and just after authentication.  There is no other path to the Peer.  EAP should have addressed this.
 
We already see this happening in the Request Identity (as in Network Selection and other such usage), in the Repsonse Identity and now in the Success phase.
 
We can continue to "hack" EAP but we can also fix it.
 
I am not saying EAP-ER is a hack but it is not efficient because it works around the existing EAP semantics but hopefully we could do better.
 
Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183

From: Lakshminath Dondeti
Sent: Mon 4/2/2007 11:13 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Many of the active WG contributors were present at the interim meeting
and there was a presentation and discussion on how reauthentication
might work with new EAP types or codes.  The consensus was that
code-based approach works best and that consensus was subsequently
verified on the list.

Well, here we are.  I am also looking forward to seeing your analysis on
this topic.  Changing the structure of the EAP Success message and also
the transmission rules for EAP Success are quite drastic changes.  If
EAP Success needs to be reliably transmitted, authenticator behavior
would have to change.  Consider the following rules on EAP Success messages:

"The peer
    MAY, in the event that an EAP Success is not received, conclude that
    the EAP Success packet was lost and that authentication concluded
    successfully."

"Success and Failure packets MUST NOT
    contain additional data."

"Because the Success and Failure packets are not
    acknowledged, they are not retransmitted by the authenticator, and
    may be potentially lost.  A peer MUST allow for this circumstance as
    described in this note. "

Anyway, I still want to see your analysis of this.

thanks,
Lakshminath

PS:  I understand your concern about EAP Identity Request and we can
work on other alternatives for it where terminating the EAP state
machine at the Authenticator and spawning an EAP-ER state machine is
considered burdensome (there are other ways of looking at this and that
is written in vidya-eap-er-02).

Madjid Nakhjiri wrote:
> Hi,
>
> I like to seek a clarification here first.
> Have we put the discussion of use of EAP code versus EAP types to bed,
> completely satisfied that EAP types will absolutely not solve the problems?
>
> Given that the Russ only first gave the few of us present in San Jose the
> green light to change EAP, I feel that we did not quite discuss the impact
> of adding new EAP codes versus other changes to an end.  A simple analysis
> shows (I have confirmed this with several EAP experts) that using a new EAP
> type and adding some payload to EAP success you can easily achieve near 1
> roundtrip exchanges. I can forward that analysis in a separate email.
>
> It is not clear whether adding data to EAP success is more severe than the
> changes that EAP-ER is suggesting, to name a few:
>
> 1) adding new codes even though 3748 mandates a discard code>4
> 2) change of authenticator state machine to treat EAP ER Request as a
> response to EAP Identity request. This seems a lot more intrusive on the
> massive scale of existing authenticators, than adding data to EAP success
> intended for the peer.
>
> It seems that before fully deciding the EAP code versus EAP type options, it
> is hard to make a judgement on a solution that is based on EAP code. After
> that, there are issues such as identity exchanges that are needed for key
> derivation according to the EMSK draft and it seems that EAP-ER is
> considering those out of band or requires explicit additional signaling.
>
> Finally the other clarification I am seeking is regarding the second
> document, don't we want to specify how the per-authenticator keys are
> derived? It seems that it should be included in the second spec as well.
>
> R,
>
> Madjid
>
> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]]
> Sent: Saturday, March 31, 2007 11:58 AM
> To: [email-masked]
> Subject: [HOKEY] consensus call: EAP-ER as HOKEY protocol
>
> HOKEY WG,
>
> The chairs are making a second consensus call request to adopt EAP-ER as
> a WG document to satisfy our re-auth and hand-off deliverables.  It
> would serve as a starting point for development of the HOKEY protocol.
>
> Note that if accepted, it may be split into two WG documents, separating
> the EAP-ER-Bootstrap into a second set of messages that could be
> transported by any service to obtain a USRK or DSUSRK.
>
> Please respond by Friday, April 13.
>

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

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

____________________________________________________________________________________
Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 03 Apr 2007 11:52:14 -0700

Thanks for offlist clarification Michaela, the relevant note is from 
Appendix A of 3748 and it says

"In Section 4.2, it has been clarified that Success and Failure
       packets must not contain additional data, and the implementation
       note has been expanded.  A subsection giving requirements on
       processing of success and failure packets has been added."

The keyword being clarified.  It was never allowed.

2284 just as 3748 says EAP Success is of length 4.  What part of that is 
unclear really?

Lakshminath

M. Vanderveen wrote:
> Regarding carrying data on the EAP-Success. Let's not forget that the 
> previous EAP RFC2284 allowed carrying data in the EAP Success. 
> Consequently methods deployed between 1998 and 2004 could have very well 
> already carried data in it. In fact there is relatively wide deployment 
> in Europe of an EAP method that does just that.
>  
> If I recall correctly the reason for banning data in the EAP-Success was 
> because it should be protected, and we did not have a method-independent 
> way to do that.
>  
> Folks with experience implementing and maintaining servers (not 
> NASes/BSs) claim that it would be much easier to modify EAP behavior by 
> adding data onto the EAP-Success than by adding new Codes.  That is 
> because adding new methods is something that is WELL-UNDERSTOOD and done 
> frequently. Adding something under the EAP method layer is not.  They 
> fear a lot of implementation complexity and ongoing test efforts with 
> the addition of EAP-ER onto existing EAP server implementations.
>  
>  
>  
> Michaela
> 
> I for one thinks we should look at allowing us to carry data in EAP 
> success.  In fact, it would be a good idea if we allowed EAP to carry 
> data which is not part of the method in all exchanges. 
> 
> Clearly there is a need to communicate with the Peer before and just 
> after authentication.  There is no other path to the Peer.  EAP should 
> have addressed this.
>  
> We already see this happening in the Request Identity (as in Network 
> Selection and other such usage), in the Repsonse Identity and now in the 
> Success phase.
>  
> I am not saying EAP-ER is a hack but it is not efficient because it 
> works around the existing EAP semantics but hopefully we could do better.
>  
> ------------------------------------------------------------------------
> *From:* Lakshminath Dondeti
> *Sent:* Mon 4/2/2007 11:13 PM
> *To:* Madjid Nakhjiri
> *Cc:* [email-masked]
> *Subject:* Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol
> 
> ------------------------------------------------------------------------
> The fish are biting.
> Get more visitors 
> <http://us.rd.yahoo.com/evt=49679/*http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php?o=US2140&cmp=Yahoo&ctv=Q107Tagline&s=Y&s2=EM&b=50> 
> on your site using Yahoo! Search Marketing. < 
> http://us.rd.yahoo.com/evt=49679/*http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php?o=US2140&cmp=Yahoo&ctv=Q107Tagline&s=Y&s2=EM&b=50>