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

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 02 Apr 2007 16:16:12 -0700

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.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

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

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

---

From: Charles Clancy <[email-masked]>
Date: Mon, 02 Apr 2007 22:14:07 -0400

Madjid,

At the interim, we only discussed method vs code-based transport.  We 
did not discuss altering existing EAP messages.  If you have a 
comparative analysis of the options you think would be beneficial to the 
group, then please share it.

Regardless, I don't see this as a reason to not adopt EAP-ER.  We can 
change what packet codes it uses if there is WG consensus to do so.

---

From: Charles Clancy <[email-masked]>
Date: Mon, 02 Apr 2007 22:17:27 -0400

Madjid,

In response to your second question about the additional document -- the 
whole point is to separate out the part of HOKEY that would could be 
reused by another application to obtain a USRK.  The per-authenticator 
keying has nothing to do with other services or their ability to obtain 
a USRK, so I don't think it should be included in the second document.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 02 Apr 2007 20:13:28 -0700

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).

---

From: Avi Lior <[email-masked]>
Date: Tue, 3 Apr 2007 09:47:43 -0400

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

"The peer

thanks,
Lakshminath

---

From: "Charles Clancy" <[email-masked]>
Date: Tue, 3 Apr 2007 12:28:46 -0400 (EDT)

<all hats off>
I think adding stuff to the EAP Success without doing a 3748bis would be a
hack.  Until both approaches have been implemented and tested with a mix
legacy hardware, it's impossible to say which would be more likely to
partially work in a partially-upgraded environment.  I'd like to see how a
legacy NAS deals with a payload-ified EAP-Success and type codes > 4.
</all hats off>

On Tue, April 3, 2007 9:47 am, Avi Lior wrote:
> <HTML dir=ltr><HEAD><TITLE>Re: [HOKEY] consensus call: EAP-ER as HOKEY
> protocol</TITLE></HEAD>
> <BODY>
> <DIV id=idOWAReplyText95852 dir=ltr>
> <DIV dir=ltr><FONT face=Arial color=#000000 size=2>I for one thinks we
> should look at allowing us to carry data in EAP success.&nbsp; 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.&nbsp;</FONT></DIV>
> <DIV dir=ltr><FONT face=Arial size=2><BR>Clearly there is a need to
> communicate with the Peer before and just after authentication.&nbsp;
> There is no other path to the Peer.&nbsp; EAP should have addressed
> this.</FONT></DIV>
> <DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
> <DIV dir=ltr><FONT face="Times New Roman" size=3></FONT>&nbsp;</DIV>
> <DIV dir=ltr>We can continue to "hack" EAP but we can also fix it.</DIV>
> <DIV dir=ltr>&nbsp;</DIV>
> <DIV dir=ltr>I am not saying EAP-ER is a hack but it is not efficient
> because it works around the existing EAP&nbsp;semantics but
> hopefully&nbsp;we could do better.</DIV>
> <DIV dir=ltr><FONT face=Arial color=#000000
> size=2></FONT>&nbsp;</DIV></DIV>
> <DIV id=idSignature6710>
> <DIV RE>Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613
> 796-4183<PRE></PRE></DIV></DIV>
> <DIV dir=ltr><BR>
> <HR tabIndex=-1>
> <FONT face=Tahoma size=2><B>From:</B> Lakshminath Dondeti<BR><B>Sent:</B>
> Mon 4/2/2007 11:13 PM<BR><B>To:</B> Madjid Nakhjiri<BR><B>Cc:</B>
> [email-masked]<BR><B>Subject:</B> Re: [HOKEY] consensus call: EAP-ER as
> HOKEY protocol<BR></FONT><BR></DIV>
> <DIV>
> <P><FONT size=2>Many of the active WG contributors were present at the
> interim meeting<BR>and there was a presentation and discussion on how
> reauthentication<BR>might work with new EAP types or codes.&nbsp; The
> consensus was that<BR>code-based approach works best and that consensus
> was subsequently<BR>verified on the list.<BR><BR>Well, here we are.&nbsp;
> I am also looking forward to seeing your analysis on<BR>this topic.&nbsp;
> Changing the structure of the EAP Success message and also<BR>the
> transmission rules for EAP Success are quite drastic changes.&nbsp;
> If<BR>EAP Success needs to be reliably transmitted, authenticator
> behavior<BR>would have to change.&nbsp; Consider the following rules on
> EAP Success messages:<BR><BR>"The peer<BR>&nbsp;&nbsp;&nbsp; MAY, in the
> event that an EAP Success is not received, conclude
> that<BR>&nbsp;&nbsp;&nbsp; the EAP Success packet was lost and that
> authentication concluded<BR>&nbsp;&nbsp;&nbsp;
> successfully."<BR><BR>"Success and Failure packets MUST
> NOT<BR>&nbsp;&nbsp;&nbsp; contain additional data."<BR><BR>"Because the
> Success and Failure packets are not<BR>&nbsp;&nbsp;&nbsp; acknowledged,
> they are not retransmitted by the authenticator, and<BR>&nbsp;&nbsp;&nbsp;
> may be potentially lost.&nbsp; A peer MUST allow for this circumstance
> as<BR>&nbsp;&nbsp;&nbsp; described in this note. "<BR><BR>Anyway, I still
> want to see your analysis of
> this.<BR><BR>thanks,<BR>Lakshminath<BR><BR>PS:&nbsp; I understand your
> concern about EAP Identity Request and we can<BR>work on other
> alternatives for it where terminating the EAP state<BR>machine at the
> Authenticator and spawning an EAP-ER state machine is<BR>considered
> burdensome (there are other ways of looking at this and that<BR>is written
> in vidya-eap-er-02).<BR><BR>Madjid Nakhjiri wrote:<BR>&gt;
> Hi,<BR>&gt;<BR>&gt; I like to seek a clarification here first.<BR>&gt;
> Have we put the discussion of use of EAP code versus EAP types to
> bed,<BR>&gt; completely satisfied that EAP types will absolutely not solve
> the problems?<BR>&gt;<BR>&gt; Given that the Russ only first gave the few
> of us present in San Jose the<BR>&gt; green light to change EAP, I feel
> that we did not quite discuss the impact<BR>&gt; of adding new EAP codes
> versus other changes to an end.&nbsp; A simple analysis<BR>&gt; shows (I
> have confirmed this with several EAP experts) that using a new EAP<BR>&gt;
> type and adding some payload to EAP success you can easily achieve near
> 1<BR>&gt; roundtrip exchanges. I can forward that analysis in a separate
> email.<BR>&gt;<BR>&gt; It is not clear whether adding data to EAP success
> is more severe than the<BR>&gt; changes that EAP-ER is suggesting, to name
> a few:<BR>&gt;<BR>&gt; 1) adding new codes even though 3748 mandates a
> discard code&gt;4<BR>&gt; 2) change of authenticator state machine to
> treat EAP ER Request as a<BR>&gt; response to EAP Identity request. This
> seems a lot more intrusive on the<BR>&gt; massive scale of existing
> authenticators, than adding data to EAP success<BR>&gt; intended for the
> peer.<BR>&gt;<BR>&gt; It seems that before fully deciding the EAP code
> versus EAP type options, it<BR>&gt; is hard to make a judgement on a
> solution that is based on EAP code. After<BR>&gt; that, there are issues
> such as identity exchanges that are needed for key<BR>&gt; derivation
> according to the EMSK draft and it seems that EAP-ER is<BR>&gt;
> considering those out of band or requires explicit additional
> signaling.<BR>&gt;<BR>&gt; Finally the other clarification I am seeking is
> regarding the second<BR>&gt; document, don't we want to specify how the
> per-authenticator keys are<BR>&gt; derived? It seems that it should be
> included in the second spec as well.<BR>&gt;<BR>&gt; R,<BR>&gt;<BR>&gt;
> Madjid<BR>&gt;<BR>&gt; -----Original Message-----<BR>&gt; From: Charles
> Clancy [<A href="mailto:[email-masked]"
> target=_blank>mailto:[email-masked]</A>]<BR>&gt; Sent: Saturday, March
> 31, 2007 11:58 AM<BR>&gt; To: [email-masked]<BR>&gt; Subject: [HOKEY]
> consensus call: EAP-ER as HOKEY protocol<BR>&gt;<BR>&gt; HOKEY
> WG,<BR>&gt;<BR>&gt; The chairs are making a second consensus call request
> to adopt EAP-ER as<BR>&gt; a WG document to satisfy our re-auth and
> hand-off deliverables.&nbsp; It<BR>&gt; would serve as a starting point
> for development of the HOKEY protocol.<BR>&gt;<BR>&gt; Note that if
> accepted, it may be split into two WG documents, separating<BR>&gt; the
> EAP-ER-Bootstrap into a second set of messages that could be<BR>&gt;
> transported by any service to obtain a USRK or DSUSRK.<BR>&gt;<BR>&gt;
> Please respond by Friday, April
> 13.<BR>&gt;<BR><BR>_______________________________________________<BR>HOKEY
> mailing list<BR>[email-masked]<BR><A
> href="https://www1.ietf.org/mailman/listinfo/hokey"
> target=_blank>https://www1.ietf.org/mailman/listinfo/hokey</A><BR></FONT></P></DIV></BODY></HTML>
>

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 3 Apr 2007 13:02:10 -0400

I understand your concern.

If you were coding EAP verbatim then we should not be surprised to see a
legacy NAS puke when the length is greater then 4. 

I agree that we would have to go to a 3748bis unless we found another
clever way to do this.  A way of learning what the Peers, Authenticator
and Authentication-Server capabilities are.

So we could for instance come up with two solutions, one for the old
legacy deployments and one for the new deployments.

So here is a question, is HOKEY designed for old legacy deployments?  I
would argue that most likely not.  Therefore for example, in WiMAX and
3GPP2 we could insist that EAP-Success will be allowed to carry
additional payloads.

But I think that we would want to do this in the IETF.

There is lots of evidence now that we didn't get EAP right. And by the
way, there were proposals in the past for carrying additional attributes
in EAP but nobody could see into the future so the work was not done.

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 12:29 PM
To: Avi Lior
Cc: Lakshminath Dondeti; Madjid Nakhjiri; [email-masked]
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol

<all hats off>
I think adding stuff to the EAP Success without doing a 3748bis would be
a hack.  Until both approaches have been implemented and tested with a
mix legacy hardware, it's impossible to say which would be more likely
to partially work in a partially-upgraded environment.  I'd like to see
how a legacy NAS deals with a payload-ified EAP-Success and type codes >
4.
</all hats off>

--

> protocol</TITLE></HEAD> <BODY> <DIV id=idOWAReplyText95852 dir=ltr> 

> should look at allowing us to carry data in EAP success.&nbsp; 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.&nbsp;</FONT></DIV> <DIV 
> dir=ltr><FONT face=Arial size=2><BR>Clearly there is a need to 
> this.</FONT></DIV> <DIV dir=ltr><FONT face=Arial 
> size=2></FONT>&nbsp;</DIV> <DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV> <DIV dir=ltr><FONT face="Times New 
> Roman" size=3></FONT>&nbsp;</DIV> <DIV dir=ltr>We can continue to 
> "hack" EAP but we can also fix it.</DIV> <DIV dir=ltr>&nbsp;</DIV> 
> hopefully&nbsp;we could do better.</DIV> <DIV dir=ltr><FONT face=Arial

> color=#000000 size=2></FONT>&nbsp;</DIV></DIV> <DIV 
> id=idSignature6710> <DIV RE>Avi Lior Office: +1 613 591-9104 x 6417 
> Cell : +1 613 796-4183<PRE></PRE></DIV></DIV> <DIV dir=ltr><BR> <HR 
> tabIndex=-1> <FONT face=Tahoma size=2><B>From:</B> Lakshminath 
> Dondeti<BR><B>Sent:</B> Mon 4/2/2007 11:13 PM<BR><B>To:</B> Madjid 
> Nakhjiri<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> Re: [HOKEY] 
> consensus call: EAP-ER as HOKEY protocol<BR></FONT><BR></DIV> <DIV> 

> consensus was that<BR>code-based approach works best and that 
> consensus was subsequently<BR>verified on the list.<BR><BR>Well, here 
> we are.&nbsp; I am also looking forward to seeing your analysis 
> on<BR>this topic.&nbsp; Changing the structure of the EAP Success 
> message and also<BR>the transmission rules for EAP Success are quite 
> drastic changes.&nbsp; If<BR>EAP Success needs to be reliably 
> transmitted, authenticator behavior<BR>would have to change.&nbsp; 
> Consider the following rules on EAP Success messages:<BR><BR>"The 
> peer<BR>&nbsp;&nbsp;&nbsp; MAY, in the event that an EAP Success is 
> not received, conclude that<BR>&nbsp;&nbsp;&nbsp; the EAP Success 
> packet was lost and that authentication 
> concluded<BR>&nbsp;&nbsp;&nbsp; successfully."<BR><BR>"Success and 
> Failure packets MUST NOT<BR>&nbsp;&nbsp;&nbsp; contain additional 
> data."<BR><BR>"Because the Success and Failure packets are 
> not<BR>&nbsp;&nbsp;&nbsp; acknowledged, they are not retransmitted by 
> the authenticator, and<BR>&nbsp;&nbsp;&nbsp; may be potentially 
> lost.&nbsp; A peer MUST allow for this circumstance 
> as<BR>&nbsp;&nbsp;&nbsp; described in this note. "<BR><BR>Anyway, I 
> still want to see your analysis of 

> burdensome (there are other ways of looking at this and that<BR>is 
> written in vidya-eap-er-02).<BR><BR>Madjid Nakhjiri wrote:<BR>&gt; 

> bed,<BR>&gt; completely satisfied that EAP types will absolutely not 
> solve the problems?<BR>&gt;<BR>&gt; Given that the Russ only first 
> gave the few of us present in San Jose the<BR>&gt; green light to 
> change EAP, I feel that we did not quite discuss the impact<BR>&gt; of

> adding new EAP codes versus other changes to an end.&nbsp; A simple 
> analysis<BR>&gt; shows (I have confirmed this with several EAP 
> experts) that using a new EAP<BR>&gt; type and adding some payload to 
> EAP success you can easily achieve near 1<BR>&gt; roundtrip exchanges.

> I can forward that analysis in a separate email.<BR>&gt;<BR>&gt; It is

> not clear whether adding data to EAP success is more severe than 
> the<BR>&gt; changes that EAP-ER is suggesting, to name a 
> few:<BR>&gt;<BR>&gt; 1) adding new codes even though 3748 mandates a 
> treat EAP ER Request as a<BR>&gt; response to EAP Identity request. 
> This seems a lot more intrusive on the<BR>&gt; massive scale of 
> existing authenticators, than adding data to EAP success<BR>&gt; 
> intended for the peer.<BR>&gt;<BR>&gt; It seems that before fully 
> deciding the EAP code versus EAP type options, it<BR>&gt; is hard to 
> make a judgement on a solution that is based on EAP code. 
> After<BR>&gt; that, there are issues such as identity exchanges that 
> are needed for key<BR>&gt; derivation according to the EMSK draft and 
> it seems that EAP-ER is<BR>&gt; considering those out of band or 
> requires explicit additional signaling.<BR>&gt;<BR>&gt; Finally the 
> other clarification I am seeking is regarding the second<BR>&gt; 
> document, don't we want to specify how the per-authenticator keys 
> are<BR>&gt; derived? It seems that it should be included in the second
spec as well.<BR>&gt;<BR>&gt; R,<BR>&gt;<BR>&gt; Madjid<BR>&gt;<BR>&gt;
-----Original Message-----<BR>&gt; From: Charles Clancy [<A
href="mailto:[email-masked]"
> target=_blank>mailto:[email-masked]</A>]<BR>&gt; Sent: Saturday, 
> March 31, 2007 11:58 AM<BR>&gt; To: [email-masked]<BR>&gt; Subject: 
> [HOKEY] consensus call: EAP-ER as HOKEY protocol<BR>&gt;<BR>&gt; HOKEY

> WG,<BR>&gt;<BR>&gt; The chairs are making a second consensus call 
> request to adopt EAP-ER as<BR>&gt; a WG document to satisfy our 
> re-auth and hand-off deliverables.&nbsp; It<BR>&gt; would serve as a 
> starting point for development of the HOKEY protocol.<BR>&gt;<BR>&gt; 
> Note that if accepted, it may be split into two WG documents, 
> separating<BR>&gt; the EAP-ER-Bootstrap into a second set of messages 
> that could be<BR>&gt; transported by any service to obtain a USRK or 
> DSUSRK.<BR>&gt;<BR>&gt; Please respond by Friday, April

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 03 Apr 2007 10:06:43 -0700

Hi Avi,

I find some of your arguments counter-intuitive and so would like to 
understand your line of thinking on this topic.  Modifications to a 
protocol to my knowledge would be hacks and extensions are well, 
extensions.  For instance, the EAP Request/Identity message suspension 
in EAP-ER, as much as I would like to defend it, is somewhat of a hack. 
  It is the cleanest Vidya and I could come up with in the sense that 
the message itself is not modified, but we need something like it to 
make sure that the L2 connection is not closed if the retransmission 
time expires.  Perhaps the wider community might find a better approach.

Next, some notes on 4284 since that has come up here:

3748 says "Some EAP implementations piggy-back various options into the
       Identity Request after a NUL-character. "

4284 uses that provision.  In any event, 4284 is somewhat of a hack and 
is an informational RFC for the purposes of 3GPP's use.

Please see inline for some questions:

Avi Lior wrote:
> 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. 

If the data is not part of the method, which entity needs to send such 
data and how is it protected?

> 
> 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.

Again which entity needs to communicate with the Peer?

>  
> 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 lost here, so please help me out :).  The network selection 
solution of 4284 is a hack IMO.  If you are saying we should revise 
3748, I might agree with you in principle.  But, practically speaking 
that is not happening anytime soon.

Next, RFC 3748 has clear guidance on allocating new packet codes in 
Section 6.1.  Defining new codes is a natural way of extending EAP.  If 
the goal is backward compatibility, adding stuff to EAP Success doesn't 
help either.  As I have noted before, EAP Success packets are not 
retransmitted by authenticators and that would have to change if we add 
anything crucial to Success packets.

I appreciate any clarifications you might provide to help me understand 
your point of view here.  Thanks.

regards,
Lakshminath

>  
> 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
>

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 3 Apr 2007 13:56:51 -0400

I agree with everything you say.

So lets fix it so that we don't hack -- we are talking about good hacks
here (which are workarounds).

Or at least come up with a workaround that will solve problems in
general so we can apply it for other problems. 

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 1:07 PM
To: Avi Lior
Cc: Madjid Nakhjiri; [email-masked]
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Hi Avi,

[Avi] People get upset with hacks. Call it a workaround, and I am
suggesting to avoid future work around that we extend the protocol to
elliminate or incorporate the workaround into the protocol.

[Avi] Perhaps. And perhaps we can use this opportunity to fix other
problems as well.

[Avi] Okay. People feel it's a hack but why? 3748 allows for that and
the approach taken in 4284 accomodates future extensions by introducing
AVPs and delimeters.
The problem with 3748 was that it says you can put something after a
NULL but it stopped too short. It should have said, after the null you
can put AVP formatted in a certain way.

[Avi] As to which entity It's a good question, and I think we can work
out the details to this.   For 4284 who is the target entity?  It's not
for the EAP method.  It's for the entity that makes a decision on which
network to select and how to formulate the NAI that is delivered in the
EAP response identity.

[Avi]Not all data has to be protected, but where protection is needed we
can design for that.  There were proposals to do this in the past.
Certainly in the EAP success payload one could envision that some of
that payload could be protected betweent the EAP-AuthServer and the MS
using a key derived from EMSK and some attributes can be prtoected
between the Authentication and the MS using a key derived from the MSK.

Again which entity needs to communicate with the Peer?
[Avi]Again we can figure that out.

> the Success phase.

[Avi] Why not???  Or perhaps we can do something here without revising
3748 perhaps we can overlay something ontop.

[Avi] I understand this but it is not necessarily the best way to extend
-- and eventhough EAP does offer an extension mechanism it is not
sufficient as you pointed out by the workarounds  you had to do. And yes
if we are adding stuff to the EAP Success packets we would have to
address retransmission of that packet.

[Avi] I don't think I gave you the necessary clarifications.  I am not
trying to come up with a solution but rather point out that maybe we
need to address this in a more general way. And yes, maybe nothing will
happen and we will continue to hack EAP.  

[Avi] As with any twelve step program, the first step is to admit we
have a problem. So do we have a problem?

regards,
Lakshminath

> 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:
> considered burdensome (there are other ways of looking at this and 
> that is written in vidya-eap-er-02).
> 
> Madjid Nakhjiri wrote:
>  > Hi,
>  >
> 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  > 

> > 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.
>  > 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  

> separating  > the EAP-ER-Bootstrap into a second set of messages that 
> could be  > transported by any service to obtain a USRK or DSUSRK.
>  >

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Tue, 3 Apr 2007 15:06:16 -0400

I have been soliciting with a few others about the idea of using
existing EAP codes to do HOAKEY, instead of creating new EAP codes. The
idea is roughly like this:

1. NAS still sends out EAP-Identity request, with something in the
request to indicate HOAKEY support. Something similar to how network
selection RFC utilizing the space after NULL character. The extra data
would include HOAKEY capability, as well as any other information
needed, e.g., domain ID, etc.

2. Client send back normal EAP-Identity Response, piggybacking any
HOAKEY data needed, e.g., agreement to do HOAKEY and any HOAKEY keying
materials.

3. If the NAS determine that client wants to do HOAKEY, then it forwards
the HOAKEY data to the HOAKEY server. Otherwise, it starts the normal
full EAP authentication.

4. After HOAKEY server sends back the server data, NAS sends EAP-Success
with additional HOAKEY data, which allows the client to verify and
authenticate the NAS.

The benefits of using this approach are:

1. Maximum backward compatibility with legacy NAS and client. Existing
client should work with new HOAKEY NAS and existing NAS would work with
new HOAKEY capable client.
2. Less changes on the EAP lower layer on both the client and NAS. The
only change is to allow additional data to be piggy-backed on
EAP-Success, vs. current EAP-ER proposal of two new EAP codes.
3. HOAKEY capability negotiation and domain ID transmission is also
included this way, instead of being mandated to be added to lower layer.
The lower layer is probably harder to change.
4. I don't think the half round trip for EAP-Identity request and
response would hurt performance too much and critical, as it is local
between the client and NAS. Modifying the lower layer to allow client
initiating exchange might be too much for some lower layer. 
5. Even if piggybacking data on EAP-Success is determined to be
impossible and we need a new EAP code, we should still just create a
single new code for the EAP-Success with optional data, this way, only
the new HOAKEY capable NAS and client needs to understand and support
it. I would recommend still using the EAP-Identity request-response
exchange for the first part. The goal is to minimize changes to EAP flow
and state machine and EAP lower layer as little as possible. 

> Cc: [email-masked]; Madjid Nakhjiri
> I find some of your arguments counter-intuitive and so would 
> like to understand your line of thinking on this topic.  
> Modifications to a protocol to my knowledge would be hacks 
> and extensions are well, extensions.  For instance, the EAP 
> Request/Identity message suspension in EAP-ER, as much as I 
> would like to defend it, is somewhat of a hack. 
>   It is the cleanest Vidya and I could come up with in the 
> sense that the message itself is not modified, but we need 
> something like it to make sure that the L2 connection is not 
> closed if the retransmission time expires.  Perhaps the wider 
> community might find a better approach.
> 
> 4284 uses that provision.  In any event, 4284 is somewhat of 
> a hack and is an informational RFC for the purposes of 3GPP's use.
> 
> If the data is not part of the method, which entity needs to 
> send such data and how is it protected?
> 
> > 
> I am lost here, so please help me out :).  The network 
> selection solution of 4284 is a hack IMO.  If you are saying 
> we should revise 3748, I might agree with you in principle.  
> But, practically speaking that is not happening anytime soon.
> 
> Next, RFC 3748 has clear guidance on allocating new packet 
> codes in Section 6.1.  Defining new codes is a natural way of 
> extending EAP.  If the goal is backward compatibility, adding 
> stuff to EAP Success doesn't help either.  As I have noted 
> before, EAP Success packets are not retransmitted by 
> authenticators and that would have to change if we add 
> I appreciate any clarifications you might provide to help me 
> understand your point of view here.  Thanks.
> 
> regards,
> Lakshminath
> 
> >  
> > behavior would have to change.  Consider the following 
> rules on EAP Success messages:
> > 
> > "The peer
> > EAP-ER is  > considering those out of band or requires 
> explicit additional signaling.
> >  >
> > keys are  > derived? It seems that it should be included in 
> the second spec as well.
> >  >
> >  > R,
> >  >
> >  > Madjid
> >  >

---

From: <[email-masked]>
Date: Tue, 3 Apr 2007 15:15:08 -0500

-----Original Message-----
From: ext Hao Zhou (hzhou) [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 3:06 PM
To: Lakshminath Dondeti; Avi Lior
Cc: [email-masked]; Madjid Nakhjiri
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Snip...

>3. HOAKEY capability negotiation and domain ID transmission is also
included this way, instead of >being mandated to be added to lower
layer.
>The lower layer is probably harder to change.

Within IEEE 802.21 there is a mechanism to advertise information such as
network capabilities or domains either before or after authentication.
This method was adopted in 802.16g and is in process within 802.11 in
TGu.

Currently any information that is passed before authentication through
the point-of-attachment is unsecure.

Best Regards,
Michael

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 03 Apr 2007 13:56:48 -0700

Hi Hao,

Thanks for proposing the detailed solution.  On a first look, it might 
seem to offer the benefits you list, but a closer look reveals serious 
problems:

1. EAP-Request/Identity does have a provision to carry stuff after the 
NUL character.  There seems to be contention by various use cases for 
that space.  That is a problem.  More specifically, 4284 cannot be used 
with reauthentication.

2. EAP-Response/Identity does not have a provision to carry additional 
data.  That is a change to 3748's text.

3. EAP Success retransmission semantics need to change.  This means 
changes to the authenticator.  So, backward compatibility arguments are 
not applicable.

Bottomline is the authenticator behavior is going to be changed one way 
or another.  We reviewed all of this at the interim meeting.  As to one 
new code vs. two, one of the older versions of EAP-ER did have one code. 
  The current version is a result of the discussions at the interim 
meeting.  I think the minutes covered the reasoning.

As to minimizing lower layer changes and being able to signal HOKEY 
capability in EAP, let's talk about that separately.

My goals here are to minimize modifications to the EAP state machine. 
Additions are always better and cleaner than modifying the protocol 
behavior.  Suppose some other use case comes along in the future and 
modifies EAP in a different way.  What happens then?

thanks,
Lakshminath

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 3 Apr 2007 19:09:40 -0400

See inline: 

Snip...

[Avi] True but in reality the extra data is carried in the NAI.  That is
another hack that is commonly used.  This comes in all forms:
EAP-AKA uses it to signal fast-reauthentication; we see examples of this
for service selection; and the list goes on and on.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 03 Apr 2007 17:31:06 -0700

Avi Lior wrote:
> EAP-AKA uses it to signal fast-reauthentication; 

Are you referring to the fast re-authentication identity?  If so, that 
is not too different from the permanent identity or the pseudonym 
identity.  At least I don't count that as "extra" data.  It is the 
identity that allows for routing and identifying the re-auth 
"credential" (or state) and so serves the same purpose as the NAI.

>we see examples of this

Could you point me to this use case of service selection?  Is it 
additional data after the "identity"?  Which entity parses it and how?

thanks,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 3 Apr 2007 18:53:37 -0700

Hi Hao,
We had discussed an approach like you describe below with a few people
prior to writing the EAP-ER document and had run into a bunch of issues.
Many of the issues have been pointed out in Lakshminath's email. The
bottomline was that if this is not run with an EAP-method based
transport, there is really no backwards compatibility with
authenticators and modifying existing messages seems to be much more of
a hack than extending EAP with new codes. 

The discussion at the interim meeting focused on a code-based
method-based transport approach  and the consensus was on the code-based
approach. What you suggest below is still a code-based approach, except
it overloads the existing codes with new stuff. That seems like a
dangerous path to go down on, to me. Specifically, I see a number of
issues and no real backwards compatibility in that approach. The peer,
authenticator and the server - all have to be "HOKEY" capable to do
this. The only point for a method-based transport was that it could run
over legacy authenticators - but, due to the inefficiency in that
approach, it was dropped. 

In this case you outline below, what specific backwards compatibility do
you see? 

Vidya

> From: Hao Zhou (hzhou) [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 12:06 PM
> To: Dondeti, Lakshminath; Avi Lior
> I have been soliciting with a few others about the idea of 
> using existing EAP codes to do HOAKEY, instead of creating 
> new EAP codes. The idea is roughly like this:
> 
> 1. NAS still sends out EAP-Identity request, with something 
> in the request to indicate HOAKEY support. Something similar 
> to how network selection RFC utilizing the space after NULL 
> character. The extra data would include HOAKEY capability, as 
> well as any other information needed, e.g., domain ID, etc.
> 
> 2. Client send back normal EAP-Identity Response, 
> piggybacking any HOAKEY data needed, e.g., agreement to do 
> HOAKEY and any HOAKEY keying materials.
> 
> 3. If the NAS determine that client wants to do HOAKEY, then 
> it forwards the HOAKEY data to the HOAKEY server. Otherwise, 
> it starts the normal full EAP authentication.
> 
> 4. After HOAKEY server sends back the server data, NAS sends 
> EAP-Success with additional HOAKEY data, which allows the 
> client to verify and authenticate the NAS.
> 
> 1. Maximum backward compatibility with legacy NAS and client. 
> Existing client should work with new HOAKEY NAS and existing 
> NAS would work with new HOAKEY capable client.
> 2. Less changes on the EAP lower layer on both the client and 
> NAS. The only change is to allow additional data to be 
> piggy-backed on EAP-Success, vs. current EAP-ER proposal of 
> two new EAP codes.
> 3. HOAKEY capability negotiation and domain ID transmission 
> is also included this way, instead of being mandated to be 
> added to lower layer.
> 4. I don't think the half round trip for EAP-Identity request 
> and response would hurt performance too much and critical, as 
> it is local between the client and NAS. Modifying the lower 
> layer to allow client initiating exchange might be too much 
> for some lower layer. 
> 5. Even if piggybacking data on EAP-Success is determined to 
> be impossible and we need a new EAP code, we should still 
> just create a single new code for the EAP-Success with 
> optional data, this way, only the new HOAKEY capable NAS and 
> client needs to understand and support it. I would recommend 
> still using the EAP-Identity request-response exchange for 
> the first part. The goal is to minimize changes to EAP flow 
> > understand your line of thinking on this topic.
> > Modifications to a protocol to my knowledge would be hacks and 
> > extensions are well, extensions.  For instance, the EAP 
> sense that 
> > 4284 uses that provision.  In any event, 4284 is somewhat of a hack 
> > and is an informational RFC for the purposes of 3GPP's use.
> > 
> > 3748, I might agree with you in principle.
> > Section 6.1.  Defining new codes is a natural way of 
> extending EAP.  
> > If the goal is backward compatibility, adding stuff to EAP Success 
> > doesn't help either.  As I have noted before, EAP Success 
> packets are 
> > not retransmitted by authenticators and that would have to 
> change if 
> > we add anything crucial to Success packets.
> > 
> > > consensus call: EAP-ER as HOKEY protocol  >  > HOKEY WG,  
> >  > The

---

From: Charles Clancy <[email-masked]>
Date: Tue, 03 Apr 2007 22:08:09 -0400

Just to reiterate one of my earlier posts...

My concern is that the overloaded approach's backward compatibility 
seems to rely on legacy NASes having not properly followed the EAP spec. 
  It's only backward compatible if NASes don't drop EAP-Successes with 
length > 4.  EAP-ER is backward compatible if NASes don't check EAP code 
values.  It seems to me that neither can claim backward compatibility, 
so if backward compatibility is going to be used to decide which is 
better, someone should test legacy NASes and see how they behave.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Wed, 4 Apr 2007 11:03:12 -0400

Lakshminath:

Please see inline. 

> Sent: Tuesday, April 03, 2007 4:57 PM
> To: Hao Zhou (hzhou)
> Cc: Avi Lior; [email-masked]; Madjid Nakhjiri
> Thanks for proposing the detailed solution.  On a first look, 
> it might seem to offer the benefits you list, but a closer 
> look reveals serious
> problems:
> 
> 1. EAP-Request/Identity does have a provision to carry stuff 
> after the NUL character.  There seems to be contention by 
> various use cases for that space.  That is a problem.  More 
> specifically, 4284 cannot be used with reauthentication.
> 
[HZ] I don't see there is a contention, other than the size limitation.
RFC4284 defines it own syntax "NAIRealms=", for HOAKEY we can define our
own syntax. They can coexist. And we are not using RFC4284 (only using
idea similar to it) and thus not limited to initial authentication.

> 2. EAP-Response/Identity does not have a provision to carry 
> additional data.  That is a change to 3748's text.
> 
[HZ] I am talking about carry data inside the response, as part of the
response, like Avi pointed out. It doesn't conflict with RFC3748.

> 3. EAP Success retransmission semantics need to change.  This 
> means changes to the authenticator.  So, backward 
> compatibility arguments are not applicable.
>
[HZ] I guess you missed my point. Legacy authenticator and/or client
would never receive the EAP-Success with optional data, only the regular
EAP-Success, as HOAKEY will not happen for them and they will start a
normal EAP authentication. Only new client and NAS that are HOAKEY
capable will see this and know how to handle them. 
 
> Bottomline is the authenticator behavior is going to be 
> changed one way or another.  We reviewed all of this at the 
> interim meeting.  As to one new code vs. two, one of the 
> older versions of EAP-ER did have one code. 
>   The current version is a result of the discussions at the 
> interim meeting.  I think the minutes covered the reasoning.
> 
[HZ] Is your assumption that HOAKEY will only work on new EAP lower
layer, hence both client and authenticator will change and include
capability negotiation, and hence don't have to worry about legacy
client or authentication? My proposal works with legacy client and
authenticator. 

> As to minimizing lower layer changes and being able to signal 
> HOKEY capability in EAP, let's talk about that separately.
> 
[HZ] I don't see adding two new codes will minimize the modifications to
EAP state machine, vs. reusing the existing codes.

> Additions are always better and cleaner than modifying the 
> protocol behavior.  Suppose some other use case comes along 
> in the future and modifies EAP in a different way.  What happens then?
[HZ] If we really think of a solution to be more generic, then we
probably should look at extending the EAP packet, maybe allowing
carrying of other data, instead of creating two new codes just for
HOAKEY.

> > existing EAP codes to do HOAKEY, instead of creating new EAP codes. 
> > The idea is roughly like this:
> > 
> > 3. If the NAS determine that client wants to do HOAKEY, then it 
> > forwards the HOAKEY data to the HOAKEY server. Otherwise, it starts 
> > the normal full EAP authentication.
> > 
> > EAP-Success with additional HOAKEY data, which allows the client to 
> > verify and authenticate the NAS.
> > 
> > client should work with new HOAKEY NAS and existing NAS would work 
> > with new HOAKEY capable client.
> > exchange for the first part. The goal is to minimize changes to EAP 
> > flow and state machine and EAP lower layer as little as possible.
> > 
> >> Request/Identity message suspension in EAP-ER, as much as I would 
> >> like to defend it, is somewhat of a hack.
> >> 3748 says "Some EAP implementations piggy-back various 
> options into 
> >> the
> >> If the data is not part of the method, which entity needs to send 
> >> such data and how is it protected?
> >>
> codes in 
> ---------------------------------------------------------------------
> >> -
> >>> --

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 04 Apr 2007 09:40:28 -0700

Hao,

Thanks for your clarifications.  Please see inline (there is a disconnect):

> idea similar to it) and thus not limited to initial authentication.

There is of course contention for space :) .  As you note there is a 
size limitation and several different protocols may want to use that 
space; further, there is no clear format other than include text after 
the NUL character.  3748 documents some legacy uses (doesn't say what 
those are), there is the 4284 provision and now your proposal.  (Note 
draft-barany-eap-gee also considers the use of 4284 style hints).

All told, if there is a simple way of including HOKEY capability 
declaration in EAP Request/Identity messages, I am not opposed to that 
(at some point I may have even said that).  On the other hand, some 
lower layers have extensive capability negotiation; for those a simple 
maintenance extension for HOKEY is not out of the question.

> response, like Avi pointed out. It doesn't conflict with RFC3748.

I asked Avi for clarification.  His notes so far indicate that he is 
talking about overloading the NAI payload.  It is not the same thing as 
you are talking about.  Next, 3748-compliant implementations won't know 
what to do.  That automatically means that a revision to 3748 is needed 
if this were to be the path HOKEY chooses.  Do you agree?

> capable will see this and know how to handle them. 

Ok, let's see:

Case 1: Legacy client, HOKEY capable authenticator:

Piggybacking approach: Client receives an EAP Request/Identity with 
HOKEY capability.  It may not be able to parse the new stuff and if it 
were to be gracious in what it accepts, sends a 3748-compliant EAP 
Response/Identity.  Full authentication occurs.  If the client were not 
gracious it may crash or discard the Request message.

EAP-ER: Client negotiates full EAP only at the lower layer; or, if we 
use the piggybacking approach will behave more or less the same as above.

Case 2: HOKEY capable client, legacy authenticator:

Piggybacking approach: Client receives an EAP Request/Identity without 
HOKEY capability.  There are at least two cases: in the first, 4284 
hints and other stuff has filled up the EAP Request/Identity packet 
capacity and the client has no way of knowing whether the authenticator 
supports HOKEY capability or not.  In the second, the client knows that 
the authenticator does or doesn't support HOKEY and carries out 
reauthentication or full authentication.

EAP-ER: Client knows based on lower layer negotiation whether EAP-ER is 
supported and proceeds to use reauthentication or full authentication.

It may be plausible to introduce an EAP-ER trigger: one such possibility 
is to use what you propose, i.e., send EAP Request/Identity with HOKEY 
capability.  The considerations I elaborated above apply.

So, I see the whole backward compatibility thing as a non issue.

> client or authentication? My proposal works with legacy client and

Please see above.  Sure I appreciate the notion of adding 4284 style 
hints (my recollection is that it was mentioned before, but I am happy 
to call it your proposal), but there are limitations to it.  4284 itself 
was a semi-solution (that RFC says that much) or a semi-hack depending 
on how one looks at it.

> EAP state machine, vs. reusing the existing codes.

That sentence was constructed with some care: note the words 
"modifications" and "EAP state machine".  Put another way, the idea is 
to "add" a new "EAP-ER state machine."

Consider the complexity in making EAP Success reliable.  Suppose the 
HOKEY-capable peer doesn't receive the Success message with the 
additional data; what does it do?

> carrying of other data, instead of creating two new codes just for

Like I said before, if the hangup is two vs. one, that can be discussed 
as part of WG proceedings.  We had that discussion once before.

Again, extensions to EAP packets have limitations and introduce serious 
complexity; we have at least two examples: on Request/Identity there is 
a space contention.  The other thing is extending Success is a can of 
worms.  One reason is the retransmission complexity and the other thing 
is other protocols may want to add stuff to that message.  Protected 
result indications via EAP come to mind.

Finally, we have space for 252 new codes.  Why is using 2 new codes for 
as important an application as HOKEY a big deal?  After all, the IETF 
chartered a whole new WG to do that work!

Many thanks for elaborating the ideas behind the piggybacking exchange. 
  It has been helpful to me to understand fully what it entails (I must 
say Vidya and I have debated about this in the past and ruled out this 
direction; for instance, one of the long and painful debates was on how 
one might make EAP success reliable.  Can it be done?  Yes.  But, it 
requires serious changes to 3748 behavior and I strongly think that 
those changes are not worthwhile.  The code based approach is definitely 
cleaner!)

regards,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 04 Apr 2007 16:41:51 -0700

Well, I guess I am sort of fuzzy on the _whole point_ of the separation
then:) we have an EMSK hierarchy draft that will show/shows USRK and USDSRK
derivation, but is not supposed to go into any specific usage, and leaves
that to other SDOs.

Then we need to have a spec that deals with HOKEY as a usage and shows HRK
and its child keys. Per-authenticator keys are part of that. I am not
talking about non-HOKEY usages, but when it comes to HOKEY, we need to
specify the whole hierarchy, no?

Am I missing something?

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Monday, April 02, 2007 7:17 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Madjid,

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 04 Apr 2007 16:50:49 -0700

IETF has specific rules about the Interims and consensus and those are
public so I am going to simply refer you to those.

I don't know the meaning of "drastic" as it is indicated here. 

Everybody agrees that a major problem with EAP is that it does not provide
much protection for result indication. So here we are claiming we are
overhauling EAP, but don't want to deal with lost result indication?

Today the SDOs are struggling to carry the information indicated by the AAA
server to the authenticator, further to the EAP peer. AAA services are
getting more and more ubiquitous usage and hinging lots of this stuff to the
initial EAP process is as ubiquitious, so adding information to EAP success
is a very good thing to end a network access control process.

Adding data to EAP success has almost no effect on the authenticators, much
less than requiring the authenticators to treat responses as requests as the
code based method is suggesting.

I will send the analysis, but it seems that Hao has already sent a similar
one.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Monday, April 02, 2007 8:13 PM
To: Madjid Nakhjiri
Cc: 'Charles Clancy'; [email-masked]
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

"The peer

thanks,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 04 Apr 2007 17:02:35 -0700

As I once said less metaphorically, working in another SDO, we flipped the
EAP-keying steak everywhere we could and hit bones and that is why we
started HOKEY, now we are hitting the same issues with EAP 3748. Either it
is ok to change EAP or it is not, so why do we point 3748 sentences to each
other? 

3748 was written for authentication not for key distribution, or for
carrying network authorization data for the peer.

So as you are saying it is really the implementations that matter, not the
sentences in EAP 3748.

But currently, we are discussing a solution that requires the authenticator
to sends an EAP Identity request, but receives an EAP code>4 and treats that
as an EAP response. Plus what about a peer that uses MSK with the first
authenticator but MDMSK (I called the per-authenticator key, mobility domain
MSK) with the following ones.
I wonder if that is more severe than having EAP success to carry some data
(which is btw for the peer not for the authenticator).

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 9:29 AM
To: Avi Lior
Cc: Lakshminath Dondeti; Madjid Nakhjiri; [email-masked]
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol

<all hats off>

> href="https://www1.ietf.org/mailman/listinfo/hokey"
target=_blank>https://www1.ietf.org/mailman/listinfo/hokey</A><BR></FONT></P
></DIV></BODY></HTML>

---

From: Charles Clancy <[email-masked]>
Date: Wed, 04 Apr 2007 20:33:36 -0500

Indeed HOKEY is a specific usage.  As a part of that, it needs to define 
a protocol to get a USRK=HRK to the HOKEY server (in EAP-ER this is the 
bootstrap phase).  I was hoping that we could define a generic protocol 
that other services could use too, after defining their own transport 
for the protocol.  This way we could enforce certain security properties.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 04 Apr 2007 17:38:06 -0700

> public so I am going to simply refer you to those.

Yes, and my interpretation of those rules as applied to this situation 
is that we have consensus on Code vs. Type.  The rule is that consensus 
is to be verified on the list and it was.

The rest of your message is completely off-topic.

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 04 Apr 2007 18:00:44 -0700

Madjid,

"> So as you are saying it is really the implementations that matter, 
not the
 > sentences in EAP 3748."

Did you really mean that?  We simply have a fundamental disagreement 
then!  I will disregard any of your opinions that are based on that 
principle of yours.

We write specifications at the IETF and expect that implementations 
comply so we have interoperability.  If the specifications got it wrong, 
the specification is to be revised (which is a serious process since we 
don't want to penalize people who actually complied with the 
specification).  If implementors were lazy and used hacks (I am guilty 
of that for example, but I will fix my implementation rather than 
demanding that we revise the relevant RFCs), well that is their problem. 
  It is also a slippery slope since there is no representative 
population of the implementors on this list or any list in the IETF.

Next, there are at least two ways protocols are "changed" at the IETF.

We revise them: e.g., RFC 2284 --> draft 2284bis --> RFC 3748 (some 
behavior has actually changed)

We extend/update them: e.g, RFC 3830;  RFC 4738, Updates RFC 3830. 
(3830 behavior itself is still fine)

So, no we cannot say that "changing" EAP is the same thing in all cases. 
  There are instances where protocols are indeed revised/changed and 
there are cases where they are simply extended.

regards,
Lakshminath

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Thu, 5 Apr 2007 11:26:52 -0400

Lakshminath:

Please see inline. 

> Sent: Wednesday, April 04, 2007 12:40 PM
> To: Hao Zhou (hzhou)
> >> Thanks for proposing the detailed solution.  On a first look, it 
> >> might seem to offer the benefits you list, but a closer 
> look reveals 
> >> serious
> >> problems:
> >>
> >> 1. EAP-Request/Identity does have a provision to carry stuff after 
> >> the NUL character.  There seems to be contention by 
> various use cases 
> >> for that space.  That is a problem.  More specifically, 
> 4284 cannot 
> >> be used with reauthentication.
> >>
> > RFC4284 defines it own syntax "NAIRealms=", for HOAKEY we 
> can define 
> > our own syntax. They can coexist. And we are not using 
> RFC4284 (only 
> > using idea similar to it) and thus not limited to initial 
> authentication.
> 
> There is of course contention for space :) .  As you note 
> there is a size limitation and several different protocols 
> may want to use that space; further, there is no clear format 
> other than include text after the NUL character.  3748 
> documents some legacy uses (doesn't say what those are), 
> there is the 4284 provision and now your proposal.  (Note 
> All told, if there is a simple way of including HOKEY 
> capability declaration in EAP Request/Identity messages, I am 
> not opposed to that (at some point I may have even said 
> that).  On the other hand, some lower layers have extensive 
> capability negotiation; for those a simple maintenance 
> extension for HOKEY is not out of the question.
> 
> 
> > 
> I asked Avi for clarification.  His notes so far indicate 
> that he is talking about overloading the NAI payload.  It is 
> not the same thing as you are talking about.  Next, 
> 3748-compliant implementations won't know what to do.  That 
> automatically means that a revision to 3748 is needed if this 
> were to be the path HOKEY chooses.  Do you agree?
> 
[HZ] I think I am talking about overloading the response identity as
well. I don't think 3748 compliant implementation has any problem with
it, it just forwards it to AAA. 

> >> changes to the authenticator.  So, backward compatibility 
> arguments 
> >> are not applicable.
> >>
> > would never receive the EAP-Success with optional data, only the 
> > regular EAP-Success, as HOAKEY will not happen for them and 
> they will 
> > start a normal EAP authentication. Only new client and NAS that are 
> > HOAKEY capable will see this and know how to handle them.
> 
> Ok, let's see:
> 
> Piggybacking approach: Client receives an EAP 
> Request/Identity with HOKEY capability.  It may not be able 
> to parse the new stuff and if it were to be gracious in what 
> it accepts, sends a 3748-compliant EAP Response/Identity.  
> Full authentication occurs.  If the client were not gracious 
> it may crash or discard the Request message.
> 
[HZ] Why would the client crash? If it doesn't behave well with data
after NULL, it would crash with RFC 4284 as well. Most clients I know
don't care about the data in the request at all.

> EAP-ER: Client negotiates full EAP only at the lower layer; 
> or, if we use the piggybacking approach will behave more or 
> less the same as above.
> 
> Piggybacking approach: Client receives an EAP 
> Request/Identity without HOKEY capability.  There are at 
> least two cases: in the first, 4284 hints and other stuff has 
> filled up the EAP Request/Identity packet capacity and the 
> client has no way of knowing whether the authenticator 
> supports HOKEY capability or not.  In the second, the client 
> knows that the authenticator does or doesn't support HOKEY 
> and carries out reauthentication or full authentication.
> 
[HZ] If the client cannot tell from the Request Identity whether HOAKEY
is supported or not, then the design of advertising HOAKEY in Request
Identity is bad. I believe that we can design a syntax that can easily
distinguish 4284 hints and others from HOAKEY. 

> EAP-ER: Client knows based on lower layer negotiation whether 
> EAP-ER is supported and proceeds to use reauthentication or 
> full authentication.
> 
> It may be plausible to introduce an EAP-ER trigger: one such 
> possibility is to use what you propose, i.e., send EAP 
> Request/Identity with HOKEY capability.  The considerations I 
> elaborated above apply.
> 
[HZ] No so fast. You assume that we can readily add to lower layer
capability to indicate HOAKEY support and pass other information needed.
I don't know if that assumption is correct or not. I like an approach
that self-contained within EAP and can work on existing lower layers
with minimum(or no) changes.
 
> changed one 
> >> way or another.  We reviewed all of this at the interim 
> meeting.  As 
> >> to one new code vs. two, one of the older versions of 
> EAP-ER did have 
> >> one code.
> Please see above.  Sure I appreciate the notion of adding 
> 4284 style hints (my recollection is that it was mentioned 
> before, but I am happy to call it your proposal), but there 
> are limitations to it.  4284 itself was a semi-solution (that 
> RFC says that much) or a semi-hack depending on how one looks at it.
> 
> > 
> > [HZ] I don't see adding two new codes will minimize the 
> modifications 
> > to EAP state machine, vs. reusing the existing codes.
> 
> "modifications" and "EAP state machine".  Put another way, 
> the idea is to "add" a new "EAP-ER state machine."
> 
> Consider the complexity in making EAP Success reliable.  
> Suppose the HOKEY-capable peer doesn't receive the Success 
> message with the additional data; what does it do?
> 
[HZ] I don't know why this is relevant in this discussion. You still
need to handle not receiving response if you use another EAP code.
Matter of fact, if you use the same EAP-Success code, the existing EAP
message timeout handling mechanism will still work.

> protocol 
> Like I said before, if the hangup is two vs. one, that can be 
> discussed as part of WG proceedings.  We had that discussion 
> once before.
> 
[HZ] I can live with one, but I prefer no new code for maximum backward
compatibility. Are you saying proposal of no new code is not part of the
WG proceedings? This whole discussion is part of the WG proceeding,
isn't it?

> Again, extensions to EAP packets have limitations and 
> introduce serious complexity; we have at least two examples: 
> on Request/Identity there is a space contention.  The other 
> thing is extending Success is a can of worms.  One reason is 
> the retransmission complexity and the other thing is other 
> protocols may want to add stuff to that message.  Protected 
> Finally, we have space for 252 new codes.  Why is using 2 new 
> codes for as important an application as HOKEY a big deal?  
> After all, the IETF chartered a whole new WG to do that work!
> 
[HZ] I am not against creating new code, but I think we can create new
ones for more generic use, not just HOAKEY. For instance, if we decide
not to piggyback EAP-Success and creating a new code instead, I would
suggest creating a new EAP-Success code that allow additional data, such
as protected result, re-authentication, etc. Better is to creating new
EAP codes to allow piggyback data on all existing EAP codes, call it
EAPv2. 

>   It has been helpful to me to understand fully what it 
> entails (I must say Vidya and I have debated about this in 
> the past and ruled out this direction; for instance, one of 
> the long and painful debates was on how one might make EAP 
> success reliable.  Can it be done?  Yes.  But, it requires 
> serious changes to 3748 behavior and I strongly think that 
> piggybacking any

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 09 Apr 2007 15:50:08 -0700

Hi,

As promised earlier, I am providing an analysis of use of EAP method for
handover and re-authentication signaling. To me it seems that without
introducing a new EAP code, one can accomplish the signaling with very
little change to authenticator state machine, given that the authenticator
already does receive and transmit AAA attributes along with AAA messages
encapsulating EAP packets.

I have called this new method, EAP Handover and re-authentication method
(EAP-HR), which consists of 3 messages (if you count EAP Success as method
specific).
I have shown the 3-party key distribution exchange (KDE) can be carried over
the EAP-HR messages easily.
As you can see in most of cases (handover, re-authentication and even in
some cases for network setup), a trigger is easily available for the
authenticator to start with EAP-HR Req, just the way EAP-identity starts
from the authenticator. So the urgent need for peer-initiated messaging and
hence the need to create new EAP code may go away.

Peer             authenticator             server
	EAP-HR REQ
	(DID, AID)
  <-------------
	EAP-HR RESP
      KDE message 1 and 2 (PID, AID and tokens)
------------------------------------------------->
		EAP/Success
		 (KDE message 3 and 4)
<---------------------------------------------------

DID: domain ID (used for creating Domain keys)
AID: authenticator ID advertised by the authenticator 
(note this can be done as part of lower layer beacon advertisement), so
carrying data through EAP-HR Request is not 100% necessary the KDE.

FAQ
=====

Roundtrips: 
============
1.1 when trigger is available at authenticator
(assuming authenticator-peer trip~20% of server-peer trip).
1.5 when trigger needs to arrive from the server.

Cases where trigger is available at authenticator
a) in handover, this is available through a handover request from the peer.
b) in re-authentication, the authentication/ key status is typically
available at the authenticator as a result of previous AAA signaling (e.g.
Session-life-time attribute)
c) in network setup, the server may send a session-life-time=0 to
authenticator along with the previous EAP authentication Success, to
indicate the need to start HOKEY signaling.

EAP-HR versus EAP identity
======================
I have discussed this with several EAP experts and it seems that using EAP
Identity request/ response versus using a new EAP method (EAP-HR) are almost
identical.
The issue with EAP Identity is that it does not carry data.
IMO, modifying EAP Identity to carry data is more straight forward than
creating EAP-HR.

EAP Success:
==========
It seems that quite a number of people have already backed up the idea of
modifying EAP success to carry data: people brought up the fact that 2284
did allow EAP success carrying data and the only reason 3748 banned EAP
Success from carrying data was the inadequate method independent way of
carrying data. It seems to me that keys derived from the hierarchy can be
used to protect the EAP success and its data and this would allow for
protected result indication as well. 

The other reason to allow EAP Success carry data is to provide a natural
extension to the AAA (authorization, etc) signaling that currently does not
reach beyond the authenticator.

So with that in mind, I hope we don't rehash the previous emails citing
sentences from 3748 about EAP Success carrying data...

3 Party key distribution (KDE)
=======================
I have modified the 3 party key distribution slightly to accomodate the EAP
method signaling.

   0  Authenticator to peer: EAP(DAID, DID)

   1  Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID,
      Np,KNps]Kps)

   2  Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas),
      AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps))

   3  Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas),
      AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,
      KNps]Kps))

   4  Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,
      KNpa,KLpa, KNps]Kps])

PID: peer ID.  
   DID: Domain ID
   AID: Authenticator ID
   DAID: Authenticator ID as perceived by the peer (down link ID)
   UAID: Authenticator ID as perceived by the server (uplink ID)
   {X}K: X encrypted with key K
   [X]K: Message Authentication Code over X with key K.
   X(Y): Y carried with X protocol
   Kps: A symmetric key shared between peer and Server for signing (IK,
   provisioned by EAP/HOKEY hierarchy) and identified by KNps.

   KEps: A symmetric key shared between peer and Server for encryption
   (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid

   KEas: A symmetric key shared between authenticator and Server for
   encryption (provisioned out of band).

   Kas: A symmetric key between authentication and server for MDCs for
   signing (provisioned out of band).

 Kpa: A symmetric key to be shared between peer and authenticator (key
   to be distributed to authenticator, the MDMSK in this document).  The
   key is named as KNpa.

   KLx : Key lifetime for key x

   KNx: Key name for Key x, e.g.  KENas: key name for KEas

   Nx : Nonce provided by the party X

I have provided more the details in a draft. 
http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-04.txt

Regards,

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,

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 09 Apr 2007 16:00:07 -0700

Hi Folks,

Trying to see how the various pieces of the puzzle from EAP signaling to key
hierarchy and 3 party key distribution fit together, I have updated the key
hierarchy draft. The draft tries to follow the new guidelines for use of
EMSK and is experimenting with use of EMSK in deriving the handover root key
for use in multiple domains.

The draft provides a suggestion for use an EAP method with the goal to show
an alternative to use of new EAP codes.

The draft also discusses the use of 3 party key distribution, the parameters
involved, the AAA attributes and EAP extensions.

The draft can be found at:

comments and discussions are welcome.

R,

Madjid

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 09 Apr 2007 19:00:28 -0400

Madjid,

How can key distribution by piggybacking data with EAP-Success work
when EAP-Success gets lost?  Note that EAP does not retransmit
EAP-Success.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 09 Apr 2007 16:12:13 -0700

Sorry for being really late on this one.

Thanks Hao for posting this. 

As I said in my other emails, I feel that either EAP identity or a new EAP
method request/response with loaded EAP Success is the least intrusive way,
given that almost all of the info in the EAP Success is destined for the
peer and not the authenticator, I don't really see a big impact on the
authenticators compared to the EAP code method which suggests swapping a
peer-initiated request and an EAP Response from the peer.

R,

Madjid

-----Original Message-----
From: Hao Zhou (hzhou) [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 12:06 PM
To: Lakshminath Dondeti; Avi Lior
Cc: [email-masked]; Madjid Nakhjiri
Subject: RE: [HOKEY] consensus call: EAP-ER as HOKEY protocol

> options into the

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 09 Apr 2007 16:26:27 -0700

One of us must have seriously missed the point and subject of this thread:
"Consensus call".

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 5:38 PM
To: Madjid Nakhjiri
Cc: 'Charles Clancy'; [email-masked]
Subject: Re: [HOKEY] consensus call: EAP-ER as HOKEY protocol

Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Mon, 09 Apr 2007 22:19:11 -0400

All the protocols look something like:

  - MSG0: [optional peer<-auth: identity advertisements]
  - MSG1: peer->server: reauth-request
  - MSG2: peer<-server: reauth-response

possible transports:

  - MSG0: id-request, L2 beacon, method, code
  - MSG1: id-response, method, code
  - MSG2: code, success

Proposals:

  - EAP-ER: [L2 beacon], code, code
  - EAP-HR: method, method, success

Major points:

  - MSG0 is required if we do peer authorization, and can also make
    backward compatibility easier
  - All approaches will require either changes or additions to the peer,
    authenticator, and EAP server
  - L2 advertisement of parameters will require L2 support
  - Use of "success" requires redefining the success packet format and
    retransmission characteristics

In general, I think the implementation differences are insignificant. 
Just as id-request/response encoding is just as easy as method-based 
transport from an implementation standpoint, I suspect that method vs 
code transport is equally easy.

Personally I think we should go the direction that's the cleanest, 
adding to standards rather than changing or re-purposing them.  It would 
also be good to avoid changes to L2 (i.e. for MSG0).

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 10 Apr 2007 11:37:15 -0700

Yoshi,

Please note the terminology, 

>       AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa,

the key to be shared by peer and authenticator (Kpa) is carried by AAA
attributes "AAA(...)" to the authenticator and not by EAP Success. Although
AAA message carrying these attributes is sent simultaneous as the AAA
message carrying the EAP success, or possibly the same AAA message carries
the authenticator keys and the EAP success as different attributes. So the
reliability rules for AAA messages apply not the reliability rules for EAP
or EAP success.

R,

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Monday, April 09, 2007 4:00 PM
To: Madjid Nakhjiri
Cc: 'Charles Clancy'; [email-masked]
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus call:
EAP-ER as HOKEY protocol

Madjid,

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 10 Apr 2007 16:45:45 -0700

Hi Charles,

Thanks for the quick summary. Only one small nit: MSG1 for HR is actually a
response.

Wrt your comment on not changing or repurposing the existing specs, adding
data to EAP Success won't really change authenticators as I mentioned in my
email to Yoshi. I don't think anybody said that we can do HOKEY without
changing peer or server, we are just trying to minimize impact on
authenticators. Furthermore, as Avi mentioned that is a useful provisioning
feature.

If however we feel that is too much of a change, we may (as Hao suggested)
create a new modified EAP Success code that accommodates the new things we
want. That may be the cleanest way with the least authenticator impact.

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Monday, April 09, 2007 7:19 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: Using an EAP method for HOKEY??: was: consensus call: EAP-ER as
HOKEY protocol

possible transports:

Proposals:

Major points:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Apr 2007 20:01:37 -0400

Madjid,

I was not mentioning server to authenticator part.  I was mentioning
authenticator to peer part.  I believe message 4 (which uses
EAP-Success in your proposal, right?) requires reliable delivery.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 10 Apr 2007 17:10:09 -0700

Oh, I see, Well, first off, there is no key being distributed to the peer.
The peer and the server derive the MDMSK (per-authenticator key) themselves.
The key distribution is only to the authenticator.

Now as far protecting other data to be carried by EAP Success, today's EAP
Success has some issues that needs fixing, as I mentioned in email to
Charles, either by fixing the current EAP success or by adding a new EAP
success that get both security and reliability protection.

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 5:02 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was: consensus
call:EAP-ER as HOKEY protocol

Madjid,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Apr 2007 20:20:02 -0400

Madjid,

The latter option (defining a new Success with acknowledgment) seems
much better than overloading the current EAP Success.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 10 Apr 2007 17:29:04 -0700

Yoshi,

I can relate to that point of view and think that sound like a good
compromise.

R,

Madjid
-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 5:20 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Using an EAP method for HOKEY??: was:
consensuscall:EAP-ER as HOKEY protocol

Madjid,

Yoshihiro Ohba

call:
> > > I have shown the 3-party key distribution exchange (KDE) can be
carried
> > over
> > > from the authenticator. So the urgent need for peer-initiated
messaging
> > and
> > > extension to the AAA (authorization, etc) signaling that currently
does
> > not
> > > I have modified the 3 party key distribution slightly to accomodate
the
> > EAP
separating

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 10 Apr 2007 19:15:49 -0700

I'm feeling a bit lazy to re-hash all the relevant discussions yet
another time, so, I'm just going to point to some old discussions on
this topic. The only means by which we can avoid authenticator changes
is using a method-based transport as shown in this email from Charles,
back in December: 

http://www.opendiameter.org/pipermail/hokeyp/2006-December/000450.html

And, the discussions we had about all the options captured above at the
interim meeting were summarized in the following email: 

http://www1.ietf.org/mail-archive/web/hokey/current/msg00077.html

We've had a number of other discussions on this list on the very same
topic as well, if people want to read further. 

Vidya

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 11 Apr 2007 12:33:43 -0700

I think we already discussed that we do not need EAP ID request/response
necessary for every exchange, so one 1 RT goes away there.

We can either load EAP ID or do a new method without EAP ID and carry IDs
inside tokens as I have shown.

We are also discussing loading EAP Success, rather than sending an empty
finish followed by a dumb success, so another RT goes away there too.

That analysis is pretty stale at this point. No need to keep resending that
link.

Madjid 

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 7:16 PM
To: [email-masked]
Subject: RE: [HOKEY] Using an EAP method for HOKEY??:
was:consensuscall:EAP-ERas HOKEY protocol

Vidya

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 11 Apr 2007 13:16:15 -0700

Sure HOKEY is a specific usage, but it is THE usage we have control on in
this group, which means we can go beyond just defining HRK and go further
down the hierarchy to see how handovers are actually managed. If we were
talking about Mobile IP and MIP-USRK, yes, we could not go down the
hierarchy as you said. As far as a generic protocol, say for Mobile IP, it
really depends on the usage architecture, for instance MIP4 has two agents,
only one of which may be on EAP signaling path, what do you do for keying
the other?

Even for HOKEY, as far as getting HRK to HOKEY server using a protocol, I
think this really depends on what architecture and key hierarchy you have in
mind. I can see the HOKEY server to be logical function of the AAA server.
The HOKEY server requests HRK (as a USRK) from EAP server through internal
API based on a trigger, but not using signaling. The HOKEY server could also
generate a domain specific HRK for other domain (HHRK for home, VHRK for
visited domains)

Madjid

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 11 Apr 2007 14:16:33 -0700

> necessary for every exchange, so one 1 RT goes away there.

Hmmm, on the Authenticator to AS side, there will still have to be a 
message even if the EAP Request & Response Id exchange on the Peer to 
Authenticator link is optional.  Do you agree?

> inside tokens as I have shown.

Not sure I understand that.  See above.  You need the EAP Response 
Identity message on the Authenticator to the AS.  If you want the 
Authenticator to send anything meaningful in that message, that means 
either modifications to the Authenticators or having the EAP Request & 
Response Id run between the Peer and the Authenticator.

> finish followed by a dumb success, so another RT goes away there too.

How do you send EAP Success, overloaded, reliably without modifying 
authenticators?

> That analysis is pretty stale at this point. No need to keep resending that

Err, ok, I will ignore this.

regards,
Lakshminath

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Apr 2007 10:06:11 +0200

> Hi Folks,
Hi Madjid,
> for use in multiple domains.
I have taken a look to the I-D and I'd suggest to separate the EAP 
method based signalling from the
handover key hierarchy content into a separate I-D. That would really 
help to clarify things.
You may count on me for this.

As a note, to me, EAP-HR you describe should work as a general transport 
(and therefore independent of the specific 3-party protocol) for a still 
under
definition 3-party protocol that should be in another I-D as Charles 
suggested.

Regarding to the message sent by EAP peer upon receiving the EAP Req/Id, 
I would like to comment that we are experimenting (with a 
proof-of-concept testbed) a trade-off solution based on 
cryptographically generated identities which are built by using keys 
derived from the EMSK. The identity is encoded in base64 format and 
included in the EAP response/identity and forwarded. The AAA server can 
verify that the identity was generated by using a valid key. We have 
tested this in a linksys access point and we have not found any problem 
so far. The solution implies little modifications at EAP peer and EAP 
server state machines (not the transitions itself but the states). 
Fortunately, the EAP authenticator state machine does not need any 
modification.
 
However, the EAP peer must relay in the security association protocol in 
order to complete the process and to know everything was ok. So a sort 
of EAP success carrying authenticated data would really help :).

<snip>
> involved, the AAA attributes and EAP extensions.
This might also be included in the separated EAP-HR I-D.

My 0.02 cents.

-- 
------------------------------------------------------
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: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Apr 2007 10:13:03 +0200

Hi Madjid , Yoshi, all
> success that get both security and reliability protection.
I'd rather see a new EAP success (as Yoshi suggests) but carrying some 
authenticated information instead of integrating that security in the 
EAP success itself. In other words, to allow the new EAP success having 
more than 4 bytes should be enough.

Best Regards...

>> attributes "AAA(...)" to the authenticator and not by EAP Success.
>>     
> Although
>   
>>> little change to authenticator state machine, given that the
>>>       
> authenticator
>   
>>> (EAP-HR), which consists of 3 messages (if you count EAP Success as
>>>       
> method
>   
>>> specific).
>>> I have shown the 3-party key distribution exchange (KDE) can be carried
>>>       
>> over
>>     
>>> from the authenticator. So the urgent need for peer-initiated messaging
>>>       
>> and
>>     
>>> a) in handover, this is available through a handover request from the
>>>       
>> peer.
>>     
>>> available at the authenticator as a result of previous AAA signaling
>>>       
> (e.g.
>   
>>> I have discussed this with several EAP experts and it seems that using
>>>       
> EAP
>   
>>> Identity request/ response versus using a new EAP method (EAP-HR) are
>>>       
>> almost
>>     
>>> identical.
>>> It seems that quite a number of people have already backed up the idea
>>>       
> of
>   
>>> modifying EAP success to carry data: people brought up the fact that
>>>       
> 2284
>   
>>> carrying data. It seems to me that keys derived from the hierarchy can
>>>       
> be
>   
>>> extension to the AAA (authorization, etc) signaling that currently does
>>>       
>> not
>>     
>>> I have modified the 3 party key distribution slightly to accomodate the
>>>       
>> EAP
>>     
>>> method signaling.
>>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 12 Apr 2007 02:46:25 -0700

Madjid,

Thanks for sharing the details of your proposal, please see inline for 
some notes:

> encapsulating EAP packets.

What is the goal here?  No changes to authenticator?  Very little 
changes to authenticator?

Let's examine what happens when a new code is introduced?  Here are the 
things the authenticator needs to do (I haven't worked on an EAP 
implementation before; my "IETF" implementation and/or interop 
experience is on GDOI, IKEv2 and GKDP).

* Accept EAP messages with Code=5 from the Peer
* if Type != Reauth { drop; return}
* else
* route just as EAP Response Identity is routed (reuse code)

* Accept EAP messages with Code=6 from the Server
* if Type!= Reauth {drop; return}
* else
* send the message to the Peer

I'd say that qualifies as a small change to the authenticator code. 
That kind of upgrade would be of inconsequential complexity; given how 
802.11 APs' Firmware is patched for all sorts of reasons rather 
frequently, it should be a non-issue!

The other thing to note is that such changes are required with your 
proposal too!

> hence the need to create new EAP code may go away.

How would the authenticator know to start EAP Request/HR instead of EAP 
Request/Identity?  That is a change to the authenticator, would you 
agree?  Could you explain what the trigger is?

How would it know how to parse and route EAP Response/HR just like EAP 
Response/Identity?  Parsing that message would be as simple/complex as 
parsing something like EAP Initiate/Re-auth (I guess in the latter case 
there is an extra if statement; I'll give you that!).

I have already asked the questions on how to reliably transport EAP 
Success without changes to authenticators (if the answer is to make the 
lower layer reliable, then surely that is a much bigger change!).  Next 
do we know that all authenticator implementations out there would work 
with Success messages larger than 4 Octets?

I will try to look at the message payloads and respond separately (Could 
you please use the notation everyone else has been using and resend that 
part of your message?  The PID, DID, DIDN'T, UAID, DAID, MAID, PAID, 
SAID stuff is confusing!)

regards,
Lakshminath

**Note: No experts were bothered or harmed in crafting this message.  I 
have, however, referred to some relevant RFCs, taken into account HOKEY 
mailing list discussions and meeting notes and offline suggestions from 
various IETF contributors.  Oddly enough, none of the people I spoke to 
had the label "expert" on their badges.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 12 Apr 2007 03:21:21 -0700

In the not too distant past, I implemented a protocol called GKDP (it is 
a work item in the IETF now).  It worked great.  I did some private 
demos with it; several people loved the proof of concept and bought into 
the use cases of that protocol.

It was also my own private combination of GDOI and IKEv2; well, that's 
the nice way of saying it.  It was a hack; I took many shortcuts to meet 
deadlines and to make my job simple (there is a nice name for that type 
of thing: quick and dirty prototyping).  Nothing wrong with what I did 
in that context.  The implementation served its purpose very well!  When 
GKDP is standardized, it would be silly to suggest that my hacks should 
be written up and called a protocol.  That would be the simplest way to 
get there, but won't be the correct way.

As long as I am telling implementation stories, here is another: when 
IKEv2 was being standardized, there was another candidate, JFK.  It had 
everything going for it: let's face it, IKE's (#34) successor was JFK 
(#35) in the real world and the acronym fit, what else do we need at the 
IETF?

There was also another aspect to JFK; it supported the responder being 
stateless by including the first message in its entirety in the third 
message.  I was in a hurry to prototype IKEv2 (or JFK, I didn't care, I 
was implementing each draft as it came out) then and implemented that 
version.  Of course, people saw it correctly that JFK was not such a 
good idea.  Not all responders cared to be stateless all the time and 
there are other simpler (message 3 would have been too long and thus 
most probably fragmented and that would not have been a great thing in 
some networks) ways to support stateless responders and we have 4306 (I 
implemented some of that spec too and interoperated with one of the best 
implementations out there now, Tero Kivinen's, when it was in its 
initial stages).

Running code or how fast/easily I or anyone else could implement JFK was 
not what figured in that decision; instead it was whether JFK's long 3rd 
message could have been an issue in most if not all networks over which 
IKE was running.

Implementation input is useful, but it only goes so far.  Some of that 
input, if we are not careful enough can take us toward ugly hacks that 
might work well in some settings but won't work in other compliant systems.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 14:33:54 -0400

I am not so much enthusiastic about EAP-ER or EAP-HR (I am more
enthusiastic about general 3-party key distribution protocol), but let
me comment one thing about EAP-HR.

I think that the authenticator that supports EAP-HR can always start
with EAP Request/HR.  If the peer does not support the method, it can
simply NAK and then the authenticator can fall back to legacy
authentication by sending a Request/Identity or other method request.
If the peer does not NAK, EAP-HR signaling will continue.  I think
this provides better backwards compatibility.  But in any case I agree
that the authenticator has to be upgraded to support EAP-HR or EAP-ER.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 12 Apr 2007 12:02:28 -0700

> 
> I think that the authenticator that supports EAP-HR can 
> always start with EAP Request/HR.  If the peer does not 
> support the method, it can simply NAK and then the 
> authenticator can fall back to legacy authentication by 
> sending a Request/Identity or other method request.

I don't understand. When a peer shows up, how does the authenticator
know if that peer has already done an initial EAP exchange and has valid
EMSK/DSRK, etc.? To me, the logical thing seems to be that the
authenticator always sends EAP Request/Identity - if the peer has valid
key material, it may send a re-authentication message (EAP
Initiate/Re-auth in the case of EAP-ER); authenticator support for such
re-auth can be known either at the lower layer or if we decide to
include a capability indication in EAP Request/Identity. Peers that
don't support re-auth or peers that are doing an initial access will
simply respond with EAP Response/Identity and will continue the EAP
procedure. 

> If the peer does not NAK, EAP-HR signaling will continue.  I 
> think this provides better backwards compatibility. 

Could you explain why it is better?  Perhaps call flows with
combinations of legacy peers or authenticators might help? 

> But in 
> any case I agree that the authenticator has to be upgraded to 
> support EAP-HR or EAP-ER.
> 

And I believe the upgrades are equally significant or insignificant,
depending on how you see it. I just don't understand how all the issues
are resolved with the authenticator starting with the re-auth stuff or
re-using EAP Success, etc. That seems to create more backwards
compatibility issues and complicate co-existence of schemes like network
selection and re-authentication, etc. 

Vidya

> > >As promised earlier, I am providing an analysis of use of 
> EAP method 
> > >for handover and re-authentication signaling. To me it seems that 
> > >without introducing a new EAP code, one can accomplish the 
> signaling 
> > >with very little change to authenticator state machine, given that 
> > >the authenticator already does receive and transmit AAA attributes 
> > >along with AAA messages encapsulating EAP packets.
> > 
> > Let's examine what happens when a new code is introduced?  Here are 
> > the things the authenticator needs to do (I haven't worked 
> on an EAP 
> > >I have called this new method, EAP Handover and re-authentication 
> > >method (EAP-HR), which consists of 3 messages (if you count EAP 
> > >Success as method specific).
> > >carried over the EAP-HR messages easily.
> > >As you can see in most of cases (handover, 
> re-authentication and even 
> > >in some cases for network setup), a trigger is easily 
> available for 
> > >the authenticator to start with EAP-HR Req, just the way 
> EAP-identity 
> > >starts from the authenticator. So the urgent need for 
> peer-initiated 
> > >messaging and hence the need to create new EAP code may go away.
> > >
> > 
> > How would the authenticator know to start EAP Request/HR instead of 
> > EAP Request/Identity?  That is a change to the authenticator, would 
> > you agree?  Could you explain what the trigger is?
> 
> > 
> > parsing something like EAP Initiate/Re-auth (I guess in the latter 
> > case there is an extra if statement; I'll give you that!).
> > 
> > Success without changes to authenticators (if the answer is to make 
> > the lower layer reliable, then surely that is a much bigger 
> change!).  
> > Next do we know that all authenticator implementations out 
> there would 
> > work with Success messages larger than 4 Octets?
> > 
> > I will try to look at the message payloads and respond separately 
> > (Could you please use the notation everyone else has been using and 
> > resend that part of your message?  The PID, DID, DIDN'T, 
> UAID, DAID, 
> > MAID, PAID, SAID stuff is confusing!)
> > 
> > regards,
> > Lakshminath
> > 
> > **Note: No experts were bothered or harmed in crafting this 
> message.  
> > I have, however, referred to some relevant RFCs, taken into account 
> > HOKEY mailing list discussions and meeting notes and offline 
> > suggestions from various IETF contributors.  Oddly enough, 
> none of the 
> > people I spoke to had the label "expert" on their badges.
> > 
> > >
> > >
> (note this can 
> > >be done as part of lower layer beacon advertisement), so carrying 
> > >data through EAP-HR Request is not 100% necessary the KDE.
> > >
> > >
> > >FAQ
> > >=====
> > >
> > >Roundtrips: 
> > >============
> > >1.1 when trigger is available at authenticator (assuming 
> > >authenticator-peer trip~20% of server-peer trip).
> > >I have discussed this with several EAP experts and it seems that 
> > >using EAP Identity request/ response versus using a new EAP method 
> > >(EAP-HR) are almost identical.
> > >IMO, modifying EAP Identity to carry data is more straight forward 
> > >than creating EAP-HR.
> > >
> > >
> > >
> > >EAP Success:
> > >==========
> > >It seems that quite a number of people have already backed up the 
> > >idea of modifying EAP success to carry data: people brought up the 
> > >fact that 2284 did allow EAP success carrying data and the only 
> > >reason 3748 banned EAP Success from carrying data was the 
> inadequate 
> > >method independent way of carrying data. It seems to me that keys 
> > >derived from the hierarchy can be used to protect the EAP 
> success and 
> > >its data and this would allow for protected result 
> indication as well.
> > >
> > >The other reason to allow EAP Success carry data is to provide a 
> > >natural extension to the AAA (authorization, etc) signaling that 
> > >currently does not reach beyond the authenticator.
> > >
> > >So with that in mind, I hope we don't rehash the previous emails 
> > >citing sentences from 3748 about EAP Success carrying data...
> > >
> > >the EAP method signaling.
> > >
> > >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.
> > >
> > >separating the EAP-ER-Bootstrap into a second set of messages that 
> > >could be transported by any service to obtain a USRK or DSUSRK.
> > >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 15:27:56 -0400

> EMSK/DSRK, etc.? To me, the logical thing seems to be that the

The authenticator knows that the peer has valid EMSK/DSRK if the peer
returns Request/HR instead of NAK.  
 
> combinations of legacy peers or authenticators might help? 

I would expect EAP-HR proponents to make the call flows, but the
reason is because the NAK-based method negotiation does not require
lower layer advertisement on re-auth support.  I don't buy the idea of
capability indication in EAP Request/Identity or any other proposal
that overloads Identity method because Identity is not a mandatory
method for EAP to start with.

> And I believe the upgrades are equally significant or insignificant,

Agreed.

> selection and re-authentication, etc. 

I don't buy the idea of overloading EAP-Success.  As I indicated in my
other email, if we want to use EAP-HR, a new Success message with
acknowledgment should be used instead.  If the peer and authenticator
have agreed on EAP-ER method, then it is natural to mandate support of
the new Success message with acknowledgment for them.  This is how
backwards compability issue can be addressed in EAP-HR in my view.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 15:30:45 -0400

> returns Request/HR instead of NAK.  

Correction: Request/HR should read Response/HR.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 12 Apr 2007 12:45:58 -0700

> > know if that peer has already done an initial EAP exchange and has 
> > valid EMSK/DSRK, etc.? To me, the logical thing seems to be that the
> 
> The authenticator knows that the peer has valid EMSK/DSRK if 
> the peer returns Request/HR instead of NAK.  
>  

Isn't it more generic for the authenticator to always send EAP
Request/Identity and let the peer start the re-auth process based on its
current state? I don't understand why having this NAK and then starting
the regular EAP process would be better. To map this to EAP-ER, for
instance, we considered doing a specific "EAP-ER start" type of message
from the authenticator - it's purpose would be pretty much the same as
this EAP Request/HR (triggering the re-auth) - but, that didn't map to
the most generic case and letting the authenticators always send EAP
Request/Identity seemed better. 

> > authenticator always sends EAP Request/Identity - if the peer has 
> > valid key material, it may send a re-authentication message (EAP 
> > Initiate/Re-auth in the case of EAP-ER); authenticator support for 
> > such re-auth can be known either at the lower layer or if 
> we decide to 
> > > this provides better backwards compatibility.
> > 
> I would expect EAP-HR proponents to make the call flows, but 
> the reason is because the NAK-based method negotiation does 
> not require lower layer advertisement on re-auth support.  

It is not mandatory to have lower layer support for this. For instance,
a peer capable of re-auth may send a re-auth specific message in
response to EAP Request/Identity. If the authenticator does not support
re-auth, that will be dropped. After a timeout, the peer would then do a
full EAP exchange. For optimized operation, I expect next generation
lower layers to indicate support for re-auth anyway. This would be the
non-optimized case. 

There is another advantage to having an independent peer initiated
message. In some lower layers, the peer can send that message in
parallel with L2 connection establishment without waiting for anything
to come from the authenticator. If we have to stick to EAP
Request/Response semantics, the authenticators will not accept
unsolicited responses and hence, the message from the authenticator now
becomes mandatory before the peer can send the Response. That is
inefficient and in some systems, the lack of ability to execute
authentication in parallel with L2 connection establishment is a
significant concern. 

>I 
> don't buy the idea of capability indication in EAP 
> Request/Identity or any other proposal that overloads 
> Identity method because Identity is not a mandatory method 
> for EAP to start with.
> 

Good. I'm in agreement there. In terms of including a capability
indication, that would be optional as well - so, if that is really
needed, we can have that discussion. But, in general, I don't like
overloading existing codes - so, I agree with you. 

> > And I believe the upgrades are equally significant or insignificant,

Good :)

> > depending on how you see it. I just don't understand how all the 
> > issues are resolved with the authenticator starting with 
> the re-auth 
> > stuff or re-using EAP Success, etc. That seems to create more 
> > backwards compatibility issues and complicate co-existence 
> of schemes 
> > like network selection and re-authentication, etc.
> 
> I don't buy the idea of overloading EAP-Success.  

Okay. We agree there. 

>As I 
> indicated in my other email, if we want to use EAP-HR, a new 
> Success message with acknowledgment should be used instead.  
> If the peer and authenticator have agreed on EAP-ER method, 
> then it is natural to mandate support of the new Success 
> message with acknowledgment for them.  This is how backwards 
> compability issue can be addressed in EAP-HR in my view.
> 

I prefer not having to add more messages when we don't need to. If
re-auth can be peer-initiated with new message codes, the response from
the server has the proper semantics and we don't need any additional
messages. Optionally, the process is tirggered by the authenticator
using EAP Request/Identity with no changes. 

Regards,
Vidya

> > > > >with very little change to authenticator state machine, given 
> > > > >that the authenticator already does receive and transmit AAA 
> > > > >attributes along with AAA messages encapsulating EAP packets.
> > > > 
> > > > Let's examine what happens when a new code is introduced?  Here 
> > > > are the things the authenticator needs to do (I haven't worked
> > > on an EAP
> > > > The other thing to note is that such changes are required with 
> > > > your proposal too!
> > > > 
> > > > >
> > > > How would the authenticator know to start EAP 
> Request/HR instead 
> > > > of EAP Request/Identity?  That is a change to the 
> authenticator, 
> > > > would you agree?  Could you explain what the trigger is?
> > > 
> > > > 
> > > > I have already asked the questions on how to reliably transport 
> > > > EAP Success without changes to authenticators (if the 
> answer is to 
> > > > make the lower layer reliable, then surely that is a much bigger
> > > change!).  
> > > > (Could you please use the notation everyone else has been using 
> > > > and resend that part of your message?  The PID, DID, DIDN'T,
> > > UAID, DAID,
> > > > I have, however, referred to some relevant RFCs, taken into 
> > > > account HOKEY mailing list discussions and meeting notes and 
> > > > offline suggestions from various IETF contributors.  
> Oddly enough,
> > > none of the
> > > > >IMO, modifying EAP Identity to carry data is more straight 
> > > > >forward than creating EAP-HR.
> > > > >
> > > > >
> > > > >
> > > > >EAP Success:
> > > > >==========
> > > > >idea of modifying EAP success to carry data: people brought up 
> > > > >the fact that 2284 did allow EAP success carrying data and the 
> > > > >only reason 3748 banned EAP Success from carrying data was the
> > > inadequate
> >http://www.ietf.org/internet-drafts/draft-nakhjiri-hokey-hierarchy-
> > > >04
> > > > >.txt
> > > > >
> > > > >Regards,
> > > > >
> > > > >Madjid
> > > > >
> > > > >separating the EAP-ER-Bootstrap into a second set of messages 
> > > > >that could be transported by any service to obtain a 
> USRK or DSUSRK.
> > > > >

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 12 Apr 2007 13:14:29 -0700

EAP does not have an inbuilt method negotiation process, meaning if a party
does not support a method it simply NAKs it.

Plus, authenticator may have other indication about a HOKEY peer, as I have
discussed in my draft. 

1)For boot up, which is the hardest one, for instance the server sending the
initial EAP method success and the AAA authorization attributes, may send
some attributes down indicating this, or simply send a session-life time of
zero to indicate this.

2)for handover and re-auth, could be based on lower layer requests for
associations, etc. Most of lower layers, e.g. 802.11/16 have messaging for
this.

Getting a trigger to an authenticator through a lower layer method is simply
a matter of building the system and not necessarily part of the protocol. 

I don't think it is absolutely necessary to change EAP to include the
triggers. This is very similar to getting a trigger to start Mobile IP,
based on lower layer handover triggers

Many times in IETF we do the actual protocol, whereas the triggers that
start the protocol come from somewhere that may not be discussed in the
protocol. You can argue in the same way how the system starts an EAP access
control, how does the system knows a phone/ laptop just booted up and needs
to access the network? But EAP has been working all along based on lower
layer association requests that trigger it.

Madjid

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 12 Apr 2007 16:46:49 -0700

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 2:17 PM
To: Madjid Nakhjiri
Cc: 'Narayanan, Vidya'; [email-masked]
Subject: Re: [HOKEY] Using an EAP method for
HOKEY??:was:consensuscall:EAP-ERas HOKEY protocol

Madjid>>Not sure I understand, do you mean AS to Authenticator? If yes, then
I agree, as I said in other emails, if the request has to come all way from
the AS, then you have 1/2 RT, but I was thinking the same way that EAP ID
request comes from Authenticator, we could start the signaling from
authenticator (authenticator-peer trip<<1/2 RT IMO). You could say it is a
hack to have the method started at authenticator and I agree, but EAP ID is
done that way today. The alternative to a new EAP method would be to load
the EAP ID response, but that would mean changing existing ID response.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 12 Apr 2007 17:05:11 -0700

Hi Rafa,

Thanks for the note.

As far as 3 party KDE, I agree it can be transported differently, I was just
trying to show it can be done with an EAP method, that is all. The draft I
submitted shows other things that are needed for a complete solutions as
well.
As long as the bundle of specifications the group creates provides a
complete solution, does not leave any holes or create too many
uninteroperable options, it should not matter whether we have one or two
docs, However, please remember that we are defining a 3-party KDE for two
specific purpose (delivering MDMSK to an authenticator, or delivering
visited HRK to another domain), so I think we should keep that context in
mind and then try to deliver a complete solution for the hokey problem, not
a bunch of generic specifications.

Also, thanks a lot for the note on loaded EAP ID implementation, good to
know it does not change authenticator state machine, that is what I was sort
of expecting. However, I would think you could replace the crypto-generated
ID with protection provided by keys protecting EAP signaling (IK and CK) and
that way do not have to have specific crypto for IDs. I showed this in the
draft as well. The only thing I was not sure about was whether to generate
the CK and IK from HRK or directly from EMSK.

Madjid

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 1:06 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] nakhjiri-hokey-hierarchy-04 available

Hi Madjid,

 

<snip>

My 0.02 cents.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 12 Apr 2007 17:11:56 -0700

I missed this question.
I agree that we need to fix a few issues for EAP Success, such as adding
protection for it, but EAP community has been crying over lack of protection
for result indication for quite some time, so that would be a welcome
change. I think it can be achieved.

As far as adding EAP Success reliability, it may be tricky (since EAP
success is not acked), but I am not sure at EAP layer it has to do with
authenticator, does it? I am curious, why you say that?

---

From: Charles Clancy <[email-masked]>
Date: Thu, 12 Apr 2007 22:08:35 -0400

All,

One problem I have with using methods instead of codes is protocol 
layering.  Hao mentioned it would be easier to implement a new method 
rather than a new code, and I assume this is because you can simply load 
a new DLL into whatever implementation you're using.  I disagree.  The 
method-based transport we're talking about here doesn't behave like 
normal methods.

It needs to interact with and modify keying material generated by 
*other* methods, stored at the EAP layer.  It needs to modify EAP state 
in ways that methods don't normally modify EAP state.  In Madjid's 
proposal, it may need to have a message generated at the authenticator 
instead of the EAP server.  Consequently, the existing method APIs that 
would make methods easy to implement won't work for a HOKEY method.

So, if what we're doing doesn't behave like a method, I don't think it 
should be transported by a method.

I think a new EAP Success would be reasonable.  Overloading the current 
one is problematic.  I think defining a new EAP ID request/reply would 
also be reasonable.  Overloading the current ones is problematic.

What about using a transport similar to EAP-HR, but defining new codes 
for the messages rather than reusing the current ones?  We could address 
a variety of other EAP problems at the same time, for example by 
defining a TLV structure for data contained in EAP ID request/responses 
and EAP success.

What do others think about this?

---

From: Charles Clancy <[email-masked]>
Date: Thu, 12 Apr 2007 22:31:09 -0400

> layering.  Hao mentioned it would be easier to implement a new method 

Sorry, it was actually Michaela that made that comment... though it 
sounds like something Hao would say.  ;-)

>> From: Lakshminath Dondeti [mailto:[email-masked]] Sent: 
>> Wednesday, April 11, 2007 2:17 PM
>> To: Madjid Nakhjiri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 12 Apr 2007 19:48:54 -0700

Hi Charles,
I don't know what you mean by using a transport similar to EAP-HR with
new codes - isn't the point of EAP-HR to re-use codes? Maybe, I am
really confused at the moment :) 

In any event, here are some slides comparing the approaches:

http://www.geocities.com/hellovidya/Re-auth_Backwards_Compatibility_Anal
ysis.pdf

The additional messages needed in EAP-HR to accommodate the
Request/Response behavior and Success semantics make it less efficient.
I'm concerned about doing something that is replaced with non-secure
uses anyway in wireless networks where latency wins over any kind of
security. If such messages are needed for security reasons, that's one
thing - in this case, it is only needed because we want to re-use codes
and authenticator retransmission behaviors. 

Vidya

> Sent: Thursday, April 12, 2007 7:09 PM
> To: Madjid Nakhjiri
> Cc: [email-masked]
> Subject: [HOKEY] HOKEY transport compromise? :was: Using an 
> EAP method forHOKEY??
> 
> All,
> 
> One problem I have with using methods instead of codes is 
> protocol layering.  Hao mentioned it would be easier to 
> implement a new method rather than a new code, and I assume 
> this is because you can simply load a new DLL into whatever 
> implementation you're using.  I disagree.  The method-based 
> transport we're talking about here doesn't behave like normal methods.
> 
> *other* methods, stored at the EAP layer.  It needs to modify 
> EAP state in ways that methods don't normally modify EAP 
> state.  In Madjid's proposal, it may need to have a message 
> generated at the authenticator instead of the EAP server.  
> Consequently, the existing method APIs that would make 
> methods easy to implement won't work for a HOKEY method.
> 
> So, if what we're doing doesn't behave like a method, I don't 
> think it should be transported by a method.
> 
> I think a new EAP Success would be reasonable.  Overloading 
> the current one is problematic.  I think defining a new EAP 
> ID request/reply would also be reasonable.  Overloading the 
> current ones is problematic.
> 
> What about using a transport similar to EAP-HR, but defining 
> new codes for the messages rather than reusing the current 
> ones?  We could address a variety of other EAP problems at 
> the same time, for example by defining a TLV structure for 
> data contained in EAP ID request/responses and EAP success.
> 
> > I agree that we need to fix a few issues for EAP Success, such as 
> > adding protection for it, but EAP community has been crying 
> over lack 
> > of protection for result indication for quite some time, so 
> that would 
> > be a welcome change. I think it can be achieved.
> > 
> > success is not acked), but I am not sure at EAP layer it has to do 
> > with authenticator, does it? I am curious, why you say that?
> > 
> > 
> >> We are also discussing loading EAP Success, rather than sending an 
> >> empty finish followed by a dumb success, so another RT 
> goes away there too.
> >

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 12 Apr 2007 20:00:40 -0700

Charles,

Thanks for your thoughts.  Some notes inline:

Agreed.

> also be reasonable.  Overloading the current ones is problematic.

I am curious what this means.  Are we talking about a new EAP Code for a 
message initiated by the Authenticator with similar semantics as 
Request/Response, perhaps something like EAP-Success-New/Initiate 
EAP-Success-New/Finish?

Same question goes for EAP ID thing.  Do you mean EAP 
Request/Identity-New and EAP Response/Identity-New?

> What do others think about this?

All interesting ideas, but in my opinion, we will be trying to solve too 
much, and we won't achieve our goals for re-authentication.

Specifically, we will need a EAP Request/Id-new pair and EAP Success-New 
pair of messages for reauthentication, i.e., 2 RTs for reauthentication. 
  Furthermore, for Peer-initiated re-authentication we may need 2.5 RTs 
in all.  Do you agree with that?  If so, aren't we too far away from our 
goals for reauthentication?

thanks,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 23:22:13 -0400

One good thing of using type-based messaging for the first message
exchange is that the peer can simply NAK if it does not support the
new type.  This does not require lower layer changes and I don't think
this adds significant lantency for legacy peer as long as NAK does not
propagated to EAP server.

Regarding a new EAP Success with acknowledgment, if we consider lower
layer impact, we might add legacy EAP-Success after the acknowlegment
of the new Success.  This will work with all existing EAP lower layers
without modifying them at all.

Peer                 Authenticator         Server
----                 -------------         ------
                 <-- Request-HR            
Response/HR-->
                     Response/HR-->
                                       <-- New Success
                 <-- New Success
ACK-->
                 <-- Success

Yet another option is just giving up use of EAP and expect lower
layers to define media-specific transport for a general 3-party key
distribution protocol.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 12 Apr 2007 20:43:07 -0700

Yoshi,
Exactly why would someone use this over just re-doing EAP-AKA or
EAP-GPSK? If we're just designing for the chattiest of EAP methods, we
might as well not do this - the systems that are looking for
optimization already use the most optimized of EAP methods. 

Some more specific questions inline. 

> Sent: Thursday, April 12, 2007 8:22 PM
> To: Charles Clancy
> Subject: Re: [HOKEY] HOKEY transport compromise? :was: Using 
> an EAP method forHOKEY??
> 
> One good thing of using type-based messaging for the first 
> message exchange is that the peer can simply NAK if it does 
> not support the new type. 

What's good about this? Why are we re-defining authenticator behavior
for the regular EAP exchange as well now? It doesn't co-exist with
network selection or identity hints or such and has nothing to add over
just always sending EAP Request/Identity. I really have a tough time
seeing the usefulness of this.

> This does not require lower layer 
> changes and I don't think this adds significant lantency for 
> legacy peer as long as NAK does not propagated to EAP server.
> 

There is no lower layer change that is "required" in any approach. If
the lower layer supports a capability indication, the operation will be
optimized. Otherwise, a peer will just time out and do a regular EAP
upon accessing via legacy authenticators. 

Vidya

> Regarding a new EAP Success with acknowledgment, if we 
> consider lower layer impact, we might add legacy EAP-Success 
> after the acknowlegment of the new Success.  This will work 
> with all existing EAP lower layers without modifying them at all.
> 
> 
> Yet another option is just giving up use of EAP and expect 
> lower layers to define media-specific transport for a general 
> 3-party key distribution protocol.
> 
> Yoshihiro Ohba
> 
> 
> > rather than a new code, and I assume this is because you can simply 
> > load a new DLL into whatever implementation you're using.  
> I disagree.  
> > The method-based transport we're talking about here doesn't behave 
> > like normal methods.
> > 
> > *other* methods, stored at the EAP layer.  It needs to modify EAP 
> > state in ways that methods don't normally modify EAP state.  In 
> > Madjid's proposal, it may need to have a message generated at the 
> > authenticator instead of the EAP server.  Consequently, the 
> existing 
> > method APIs that would make methods easy to implement won't 
> work for a HOKEY method.
> > 
> > I think a new EAP Success would be reasonable.  Overloading the 
> > current one is problematic.  I think defining a new EAP ID 
> > request/reply would also be reasonable.  Overloading the 
> > for the messages rather than reusing the current ones?  We could 
> > address a variety of other EAP problems at the same time, 
> for example 
> > by defining a TLV structure for data contained in EAP ID 
> > request/responses and EAP success.
> > 
> > >adding protection for it, but EAP community has been 
> crying over lack 
> > >of protection for result indication for quite some time, so that 
> > >would be a welcome change. I think it can be achieved.
> > >

---

From: Charles Clancy <[email-masked]>
Date: Fri, 13 Apr 2007 07:56:04 -0400

Lakshminath,

I'd see the EAP-Request/Identity-new as an advertisement, containing any 
necessary identity information, and advertising re-auth support.  We 
could make it optional, so the peer wouldn't need to receive it before 
transmitting an EAP-Response/Identity-new, which would contain the 
re-auth request data.  In response, the server would send an 
EAP-Success-new.  So we still have 1.1 RT (since the 
EAP-Request/Identity is being generated by the authenticator, not the 
EAP server).

Picture:

peer                      auth                    server

  [<------- EAP-Req/Id-new -]  (optional)
  -------- EAP-Resp/Id-new(Reauth data) ------------->
  <-------------- EAP-Success-new(Reauth data) -------

I don't think the EAP-Success-new needs to be ACK'd.  If it's not 
received, the peer can retransmit the EAP-Response/Id-new.  This could 
be flexible though, if others wanted to use the EAP-Success-new.  There 
could be a bit in the header that indicated whether or not it should be 
ACK'd.

We basically have the exact same messaging as EAP-ER -- we're just 
renaming some of the messages and defining them a little more generally 
so they could be useful to others in the future.

If we're worried about backward compatibility, the EAP-Request/ID could 
still use the old code, though that's possibly problematic as discussed 
in the past.

Lakshminath Dondeti wrote:
>> load a new DLL into whatever implementation you're using.  I 
>> disagree.  The method-based transport we're talking about here doesn't 
>> behave like normal methods.
>>
>> authenticator instead of the EAP server.  Consequently, the existing 
>> method APIs that would make methods easy to implement won't work for a 
>> HOKEY method.
>>
>> request/reply would also be reasonable.  Overloading the current ones 
>> is problematic.
> 
>> address a variety of other EAP problems at the same time, for example 
>>>> empty

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Apr 2007 09:57:36 -0400

Vidya,

> optimization already use the most optimized of EAP methods. 

Any of existing EAP methods does not address 3-party key distribution
issue.  To me it's not just an optimization issue.

> seeing the usefulness of this.

I could not find a requirement on support for network selection or
identity hints in hokey-reauth-ps.  What is it :)

> upon accessing via legacy authenticators. 

Timeout is a problem, not a solution.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 13 Apr 2007 16:38:22 +0200

Hi Yoshi,
> enthusiastic about general 3-party key distribution protocol), 
As you know I am in favor about general 3-party key distribution
protocol but i think this is orthogonal to EAP-ER or EAP-HR as long as
both mechanism work as a transport... don't you agree?.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 13 Apr 2007 08:29:24 -0700

:).  So, I'll preface this message saying that if something like this 
can be done, I am all for it.  All I care about is having a 
peer-initiated 1 RT exchange that can be standardized quickly (to avoid 
being cryptic, my point is that if we mess with 3748 behavior, we'll 
face huge delays after the document gets forwarded to the AD).

EAP Request (Identity or Identity-New) by itself is not optional, so I 
am not sure how peer-initiated aspect works with the proposed approach. 
  3748 says at the moment:

"The Identifier field of the Response MUST match that of the
       currently outstanding Request.  An authenticator receiving a
       Response whose Identifier value does not match that of the
       currently outstanding Request MUST silently discard the Response."

As to sending the old Response to have the Success-new message repeated, 
that is a change to the EAP state machine.  Now this kind of technique 
is not new in the pre-EAP world, so such a change to the EAP state 
machine may be palatable to people (it would make the state machine 
complex).  I actually recall having a heated debate with Vidya on this 
very point some 8-10 months ago :).  To her credit, she was suggesting 
the technique and I said that would require 3748bis.

I guess the behavior is that EAP-Success-New can carry data and it MUST 
be cached for some period and EAP-Response/Id must result in 
retransmission on that message.

I do wonder whether such drastic changes to 3748 are needed, but I am 
tired of this debate.

If all of that can be done, let's do it.  Thanks.

best regards,
Lakshminath

Charles Clancy wrote:
>>> disagree.  The method-based transport we're talking about here 
>>> doesn't behave like normal methods.
>>>
>>> method APIs that would make methods easy to implement won't work for 
>>> a HOKEY method.
>>>
>>> So, if what we're doing doesn't behave like a method, I don't think 
>>> it should be transported by a method.
>>
>> Agreed.
>>
>>>
>> I am curious what this means.  Are we talking about a new EAP Code for 
>> a message initiated by the Authenticator with similar semantics as 
>>> What about using a transport similar to EAP-HR, but defining new 
>>> codes for the messages rather than reusing the current ones?  We 
>>> could address a variety of other EAP problems at the same time, for 
>>> example by defining a TLV structure for data contained in EAP ID 
>> All interesting ideas, but in my opinion, we will be trying to solve 
>> too much, and we won't achieve our goals for re-authentication.
>>
>> Specifically, we will need a EAP Request/Id-new pair and EAP 
>> Success-New pair of messages for reauthentication, i.e., 2 RTs for 
>> reauthentication.  Furthermore, for Peer-initiated re-authentication 
>> we may need 2.5 RTs in all.  Do you agree with that?  If so, aren't we 
>> too far away from our goals for reauthentication?
>>
>> thanks,
>> Lakshminath
>>
>>>
>>> -- 
>>>> adding

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 13 Apr 2007 17:38:35 +0200

Hi Madjid,
> so I think we should keep that context in
I am not against that. What I am saying is that the specific 3 party 
protocol should be independent of the transport (EAP-ER/EAP-HR etc...)
> of expecting. 
Mmmm... it is normal that EAP authenticator state machine does not 
change since the solution we have experimented carries a valid identity 
(but cryptographically generated). So no change at all in EAP 
Response/Id. I think the overload in EAP Response/Id that your I-D 
proposes is different right?.

> However, I would think you could replace the crypto-generated
> that way do not have to have specific crypto for IDs. 
As I mentioned, personally I am not in favour about using cryptography 
in the EAP signaling itself. To me it should be only a transport between 
the peer and server for the 3 party key distribution.

Having said that, the crypto-generated ID included in a normal EAP 
Response/Id does not require EAP authenticator modification, but what 
you propose may require it.

> I showed this in the
>> Trying to see how the various pieces of the puzzle from EAP signaling to
>>     
> key
>   
>> hierarchy and 3 party key distribution fit together, I have updated the
>>     
> key
>   
>> EMSK and is experimenting with use of EMSK in deriving the handover root
>>     
> key
>   
>> The draft also discusses the use of 3 party key distribution, the
>>     
> parameters
>

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 13 Apr 2007 11:52:51 -0400 (EDT)

To a certain extent, if we're defining new codes, we can dictate their
behavior.  Who's to say an Response/ID-new has to be preceeded by a
Request/ID-new?  Certainly we'll need to do more research.

I think the design constraints are clear, and we have general agreement on
them.  1 RT with an optional .1 RT to advertise identity information for
lower layers that can't advertise information like that, or scenarios
where server-initiation is required.  I don't see the benefits of using
method-based transport, since it won't be any easier to implement than
code-based transport.  Overloading existing EAP codes should be avoided if
possible, unless the benefits to backward compatability are compelling.

On Fri, April 13, 2007 11:29 am, Lakshminath Dondeti wrote:
>>>>> with

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 13 Apr 2007 09:02:02 -0700

> Request/ID-new?  Certainly we'll need to do more research.

Isn't ID-new a new type?  Perhaps we can define a new code Response-New?

thanks,
Lakshminath

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 13 Apr 2007 12:06:13 -0400 (EDT)

> Isn't ID-new a new type?  Perhaps we can define a new code Response-New?

Exactly.  That's what I was proposing.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 13 Apr 2007 09:12:40 -0700

Thanks for the clarification Charles.

regards,
Lakshminath

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Fri, 13 Apr 2007 12:17:52 -0400

Charles:

In general, I agree with you that a more generalized code approach would
be better. I do see one issue with proposed Request ID-new. Unless there
is lower layer capability negotiation that the authentication know the
peer supports the Request/ID-new, sending it to legacy client will be
dropped. That's why I suggest using the existing Request ID.  Somehow
you need capability negotiation that the new codes will be supported.
Unless you are only targeting lower layer that supports that, you will
need some backward compatibility. 

> Sent: Friday, April 13, 2007 11:53 AM
> To: Lakshminath Dondeti
> Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using 
> an EAP method for HOKEY??
> 
> To a certain extent, if we're defining new codes, we can 
> dictate their behavior.  Who's to say an Response/ID-new has 
> to be preceeded by a Request/ID-new?  Certainly we'll need to 
> do more research.
> 
> I think the design constraints are clear, and we have general 
> agreement on them.  1 RT with an optional .1 RT to advertise 
> identity information for lower layers that can't advertise 
> information like that, or scenarios where server-initiation 
> is required.  I don't see the benefits of using method-based 
> transport, since it won't be any easier to implement than 
> code-based transport.  Overloading existing EAP codes should 
> be avoided if possible, unless the benefits to backward 
> compatability are compelling.
> 
> --
> > peer-initiated 1 RT exchange that can be standardized quickly (to 
> > avoid being cryptic, my point is that if we mess with 3748 
> behavior, 
> > we'll face huge delays after the document gets forwarded to the AD).
> >
> > As to sending the old Response to have the Success-new message 
> > repeated, that is a change to the EAP state machine.  Now 
> this kind of 
> > technique is not new in the pre-EAP world, so such a change 
> to the EAP 
> > state machine may be palatable to people (it would make the state 
> > machine complex).  I actually recall having a heated debate 
> with Vidya 
> > on this very point some 8-10 months ago :).  To her credit, she was 
> > suggesting the technique and I said that would require 3748bis.
> >
> > I guess the behavior is that EAP-Success-New can carry data and it 
> > MUST be cached for some period and EAP-Response/Id must result in 
> >> I'd see the EAP-Request/Identity-new as an advertisement, 
> containing 
> >> any necessary identity information, and advertising 
> re-auth support.  
> >> We could make it optional, so the peer wouldn't need to receive it 
> >> before transmitting an EAP-Response/Identity-new, which 
> would contain 
> >> the re-auth request data.  In response, the server would send an 
> >> received, the peer can retransmit the EAP-Response/Id-new.  This 
> >> could be flexible though, if others wanted to use the 
> >> EAP-Success-new.  There could be a bit in the header that 
> indicated 
> >> whether or not it should be ACK'd.
> >>
> >> renaming some of the messages and defining them a little more 
> >> generally so they could be useful to others in the future.
> >>
> >> If we're worried about backward compatibility, the EAP-Request/ID 
> >> could still use the old code, though that's possibly 
> problematic as 
> >> discussed in the past.
> >>
> >> --
> >>>> layering.  Hao mentioned it would be easier to implement a new 
> >>>> method rather than a new code, and I assume this is 
> because you can 
> >>>> simply load a new DLL into whatever implementation 
> you're using.  I 
> >>>> existing method APIs that would make methods easy to implement 
> >>>> won't work for a HOKEY method.
> >>>>
> >>>> request/reply would also be reasonable.  Overloading the current 
> >>>> ones is problematic.
> >>>
> >>> I am curious what this means.  Are we talking about a new 
> EAP Code 
> >>> for a message initiated by the Authenticator with similar 
> semantics 
> >>> as Request/Response, perhaps something like 
> EAP-Success-New/Initiate 
> >>> EAP-Success-New/Finish?
> >>>
> >>> we may need 2.5 RTs in all.  Do you agree with that?  If 
> so, aren't 
> >>> we too far away from our goals for reauthentication?
> >>>
> >>> thanks,
> >>> Lakshminath
> >>>
> >>>>
> >>>> --
> crying over 
> >>>>> lack of protection for result indication for quite some 
> time, so 
> >>>>> that would be a welcome change. I think it can be achieved.
> >>>>>
> >>>>> As far as adding EAP Success reliability, it may be 
> tricky (since 
> >>>>> EAP success is not acked), but I am not sure at EAP 
> layer it has 
> >>>>> to do with authenticator, does it? I am curious, why 
> you say that?
> >>>>>
> >>>>>
> >>>>>> We are also discussing loading EAP Success, rather 
> than sending 
> >>>>>> an empty finish followed by a dumb success, so another RT goes 
> >>>>>> away there too.
> >>>>>
> >>>>> How do you send EAP Success, overloaded, reliably without 
> >>>>> modifying authenticators?
> >>>>>
> >>>>>
> >>>>>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 16 Apr 2007 12:51:05 -0700

Hi Charles,

The problem is as I have mentioned before on list or in drafts, EAP was
designed for point to point authentication and is now being stretched for
not only a backend server scenario, but also for key distribution, so we are
kind of using a hammer to tighten a screw.

I proposed EAP-HR request, because I was worried people did not want to see
EAP-ID being loaded with stuff. Note that EAP ID is many times sent from
authenticator today. I understand that something like EAP-HR is not a
conventional method, since it just wants to do work based on a previous
method. But remember that types 1-3 don't behave like methods either:) You
already see EAP-start from the peer to authenticator in SDOs, or EAP-ID
request or Challenge going from authenticator the peer.

So I think, if we are creating new codes, then we should provide something
that is more than a hammer with a sharp edge, hoping it can do some screws
(agreeing with you that we should address some of the other issues as well):

1) We can add peer-initialized messaging, if we need to, or allow the
authenticator (not the server) to send messages to the peer (since this
really a 3 party scenario and we are looking at mobility), this could be in
form of loading ID request, or creating a new ID that also does capability
exchange that allows the parties to communicate that they are running HOKEY
and using EMSK, etc.

2) We need to be able to load and protect EAP-Success (if it is a new code,
I don't have a problem), because today AAA messaging ends at the
authenticator (not at the peer) and there is no protected result indication.
However, to add reliability, you may have to include an ACK to the Success
as well. So I don't know how people are planning to deal with reliability.

Regards,

Madjid
-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 7:09 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: [HOKEY] HOKEY transport compromise? :was: Using an EAP method
forHOKEY??

All,

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 16 Apr 2007 14:57:04 -0700

Hi Charles,

I think we are getting close. I am not sure whether a new EAP-ID code or a
modified EAP-ID with the same code will be easier. It seems that we need to
hear opinions of Ads and implementers/operators.
 
However, I don't want to see the request from authenticator optional,
because the peer would send a response based on no requests and that seems
to be odd, counterintuitive and it seems that it requires state machine
considerations. Have a request and response tied together is a bit cleaner
what EAP-ER suggested. Plus I don't want to see the MSK used at all,
regardless what scenario or network set up stage we are at.

As we seem to agree, 0.1 RT from authenticator to peer should not make a
difference. We only need to add the capability so that both server and
authenticator can send this request if they want to.

Regardless of new code or not, we should use foresight and add identity
exchange, capability exchange and maybe even "left-over" stuff from previous
AAA exchanges (previous EAP success).

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 4:56 AM
To: Lakshminath Dondeti
Cc: [email-masked]; Madjid Nakhjiri
Subject: [HOKEY] Re: HOKEY transport compromise? :was: Using an EAP method
for HOKEY??

Lakshminath,

Picture:

peer                      auth                    server

> Specifically, we will need a EAP Request/Id-new pair and EAP Success-New 
air of messages for reauthentication, i.e., 2 RTs for reauthentication.