Subject: [HOKEY] Proposed WG Item: Problem Statement

From: "Charles Clancy" <[email-masked]>
Date: Wed, 3 Jan 2007 13:31:37 -0500 (EST)

All,

I'd like to get WG consensus on whether or not to adopt the following
reauthentication problem statement as an informational WG document to
satisfy charter deliverable #1:

http://www.cs.umd.edu/~clancy/stuff/draft-clancy-hokey-reauth-ps-01.txt

(Recently submitted to the I-D editor; should appear at ietf.org in the
next day or so.)

This document represents the consolidation of the following two documents:

http://tools.ietf.org/html/draft-nakhjiri-aaa-hokey-ps
http://tools.ietf.org/html/draft-vidya-eap-reauth-ps

Please post your comments to the list.  Thanks!

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

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 04 Jan 2007 04:56:49 -0800

I support adoption of this document as a WG item.

thanks,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Jan 2007 11:46:17 -0500

I have one clarification question before sending my opinion.

In Section 5:

"
   EAP method independence:  Changes to existing EAP methods MUST NOT be
      required as a result of the extensions to EAP itself.  Note that
      the only EAP methods for which independence is required are those
      that conform to the specifications of [I-D.ietf-eap-keying] and
      [RFC4017].
"

Does this text imply that modifying EAP itself would be the only
solution for the re-authentication problem, or is other solution such
as a method-based general re-authentication mechanism also possible?

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 04 Jan 2007 10:02:52 -0800

Well so the charter says method-independence and low latency are 
requirements for re-authentication.  Of late, we've talked about 
whether re-authentication is possible without modifications to 
Authenticators.  A method-based (note that re-authentication would be 
another "method" in this case) re-authentication came about as an 
idea.  As Charles's analysis showed, it appears that a method-based 
re-authentication would have 3+ RTs, and thus does not meet the low 
latency requirements.  At the moment, I am ok with having that as an 
"option" but continue with method-independence and low latency 
requirements in designing a re-authentication protocol.

HTH.

regards,
Lakshminath

---

From: "Sood, Kapil" <[email-masked]>
Date: Thu, 4 Jan 2007 10:09:29 -0800

How are we going to measure "latency" in meeting the low-latency
requirement?  Has any discussion occurred on this front in HOKEY?

Best Regards,
 
Kapil.
503.264.3759

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 10:03 AM
> To: Yoshihiro Ohba; Charles Clancy
> Cc: [email-masked]
> Subject: Re: [HOKEY] Proposed WG Item: Problem Statement
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 04 Jan 2007 10:15:02 -0800

We talked about this at length.  It is a difficult term as I am 
beginning to learn and it is relative at least in my mind :).  If the 
communication is between a peer Alice and a server Bob, we can 
measure it in number of RTs between Alice and Bob.  A method-based 
re-authentication requires 3+ RTs and another design I can think of 
and have documented requires 1 RT.

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 Jan 2007 10:46:59 -0800

I recall having a discussion on this at the WG meeting in San Diego and
saying that measuring latency in terms of RTs is reasonable for this WG.
The other angle in which we need to look at latency is when the EAP
server is too far away from the current location of the peer. 

Computational latency is yet another aspect, although I would not expect
that to be of major debate. 

Vidya 

> Sent: Thursday, January 04, 2007 10:15 AM
> To: Sood, Kapil; Yoshihiro Ohba; Charles Clancy
> Cc: [email-masked]
> Subject: RE: [HOKEY] Proposed WG Item: Problem Statement
> 
> We talked about this at length.  It is a difficult term as I 
> am beginning to learn and it is relative at least in my mind 
> :).  If the communication is between a peer Alice and a 
> server Bob, we can measure it in number of RTs between Alice 
> and Bob.  A method-based re-authentication requires 3+ RTs 
> and another design I can think of and have documented requires 1 RT.
> 
> regards,
> Lakshminath
> 
> > > Authenticators.  A method-based (note that 
> re-authentication would 
> > > be another "method" in this case) re-authentication came 
> about as an 
> > > >    EAP method independence:  Changes to existing EAP 
> methods MUST
> >NOT be
> > > >       required as a result of the extensions to EAP 
> itself.  Note
> >that
> > > >       the only EAP methods for which independence is 
> required are
> >those
> > > >       that conform to the specifications of 
> [I-D.ietf-eap-keying]
> >and
> > > >       [RFC4017].
> > > >"
> > > >
> > > >solution for the re-authentication problem, or is other solution 
> > > >such as a method-based general re-authentication 
> mechanism also possible?
> > > >
> > > >Yoshihiro Ohba
> > > >
> > > >
> > > > > reauthentication problem statement as an informational WG 
> > > > > document
> >to
> > > > > (Recently submitted to the I-D editor; should appear 
> at ietf.org
> >in the
> > > > > next day or so.)
> > > > >
> > > > > This document represents the consolidation of the 
> following two
> >documents:
> > > > >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Jan 2007 14:42:23 -0500

Hi Lakshminath,

I am not sure whether any method-based re-authentication requires 3+
RTs, and not sure whether any EAP-layer re-thentication does not
require more than 1 RT.  The actual latency could depend on many
factors which we may not know until we enter design phase.  Said that,
I don't think we can conclude at this moment that which RT value will
or will not satisfy the low latency requirements.

Yoshihiro Ohba

---

From: "Sood, Kapil" <[email-masked]>
Date: Thu, 4 Jan 2007 13:35:11 -0800

I'd be (almost) tempted to ask the group to re-think the latency
requirement.  Anytime a network transaction goes across multiple (and at
times, public) hops, we cannot assure any time boundaries for when that
will be concluded.  At most, we can have a theoretic minimum and a
theoretic maximum.  So, I think we can never empirically conclude that
we have "lowered" latency.

The number of round-trips does play a role in the overall time duration
of executing a protocol, but that pre-supposes a solution.  Not a
requirement.

Best Regards,
 
Kapil.
503.264.3759

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 11:42 AM
> To: Lakshminath Dondeti
> Cc: [email-masked]
such
> > >> reauthentication problem statement as an informational WG
document to

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 04 Jan 2007 16:41:51 -0500

I agree with Kapil.

We should probably look at some of the ITU-T documents to find out the 
latency requirement and threshold values. In addition, it may also vary 
from application to application as well (e.g., real-time (interactive, 
streaming) vs. non-realtime)).

Thanks
Ashutosh

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 Jan 2007 13:54:44 -0800

Hi Yoshi,
No matter how we do re-authentication, one of the goals is that it
should be usable, irrespective of what EAP method is used for initial
EAP authentication. There must be no constraint on the EAP method used
to arrive at an MSK and EMSK. The term "method-based transport" is
getting too confusing. What it really means is that the packets have new
values from the "type" space, rather than from the "codes" space - it is
along the lines of "Identity" or "Notification" or "Legacy Nak" rather
than along the lines of "Request" or "Response" (although Response
Identity is a slightly special case where the authenticator gets the
domain info) - so, if we defined a value of, say, "Re-auth" in method
type, we'd have to use Request Re-auth and Response Re-auth and stick to
the semantics of Request/Response messages. However, sticking to the
semantics of the Request/Response messages is what makes that a 3.5 RT
protocol (as Charles had illustrated in one of his emails earlier). That
is why introducing new packet codes for systems where the authenticator
can be upgraded is much more efficient. 

Now, coming to latency, I am not sure what you mean by "actual latency"
- at the IETF, we cannot measure latency in terms of time - that's a
deployment thing and depends on the kind of links, etc. When we talk
about latency at the IETF, we usually deal with it in terms of number of
messages exchanged in a protocol, the kind of crypto operations that it
entails and if we can optimize by allowing a re-run of the protocol
without having to go to the same server every time, irrespective of
location. Beyond that, clearly we cannot say something like
"re-authentication must not take more than 20ms", since that is of no
value to what we do at the IETF. As I said, there was a long discussion
on this in San Diego and I thought we had agreed on what "low latency"
implies. We seem to be going in circles with this discussion :) 

Vidya

> To: Dondeti, Lakshminath
> I am not sure whether any method-based re-authentication 
> requires 3+ RTs, and not sure whether any EAP-layer 
> re-thentication does not require more than 1 RT.  The actual 
> latency could depend on many factors which we may not know 
> until we enter design phase.  Said that, I don't think we can 
> conclude at this moment that which RT value will or will not 
> satisfy the low latency requirements.
> 
> Yoshihiro Ohba
> 
> 
> re-authentication would be 
> methods MUST NOT be
> itself.  Note that
> required are those
> [I-D.ietf-eap-keying] and
> > >      [RFC4017].
> > >"
> > >
> > >> I'd like to get WG consensus on whether or not to adopt the 
> > >> following reauthentication problem statement as an 
> informational WG 
> > >> document to satisfy charter deliverable #1:
> > >>
> > >> 
> > >> (Recently submitted to the I-D editor; should appear at 
> ietf.org in 
> > >> the next day or so.)
> > >>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 04 Jan 2007 13:56:46 -0800

I have suggested earlier to drop the upper bound RT requirements as it does
not mean anything in terms of real time delay, which a real time application
cares about anyway.
RT is very different with an in-domain AAA server referal, compared to
visited-home domain AAA referal, compared to a Local ADC referral (that does
not even touch AAA server). We should focus on the actual architecture,
signaling and what can be gained by a key hierarchy. 
This is why focus on just re-auth is not enough for a complete solution.

Madjid

-----Original Message-----
From: Sood, Kapil [mailto:[email-masked]] 
Sent: Thursday, January 04, 2007 1:35 PM
To: Yoshihiro Ohba; Lakshminath Dondeti
Cc: [email-masked]
Subject: RE: [HOKEY] Proposed WG Item: Problem Statement

Best Regards,
 
Kapil.
503.264.3759

such
> > >> I'd like to get WG consensus on whether or not to adopt the
following
document to

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Jan 2007 18:16:11 -0500

Hi Vidya,

> can be upgraded is much more efficient. 

I understand that those restrictions on "Re-auth" in method type, but
I don't understand why it can't be 2.5 RT.

Regarding new packet codes, we would also need to assume lower layer
upgrade in addition to authenticator upgrade, according to previous
discussion on existing EAP lower layers.

> implies. We seem to be going in circles with this discussion :) 

Yes, my comment on latency was in terms of the number of message
roundtrips and and my comment still remains the same: I don't think we
can conclude at this moment that which RT value will or will not
satisfy the low latency requirements.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 Jan 2007 15:27:40 -0800

Kapil,

> To: Yoshihiro Ohba; Dondeti, Lakshminath
> Cc: [email-masked]
> I'd be (almost) tempted to ask the group to re-think the 
> latency requirement.  Anytime a network transaction goes 
> across multiple (and at times, public) hops, we cannot assure 
> any time boundaries for when that will be concluded.  At 
> most, we can have a theoretic minimum and a theoretic 
> maximum.  So, I think we can never empirically conclude that 

As I mentioned in my email to Yoshi earlier, latency in terms of time
units is of no meaning to what we can realistically do at the IETF. 

> The number of round-trips does play a role in the overall 
> time duration of executing a protocol, but that pre-supposes 
> a solution.  Not a requirement.
> 

Roundtrips is one very important requirement we need to have - if we
design a protocol that is no more optimal than running a full EAP
method, this effort would really be pointless. If you take a look at the
HOKEY WG meeting minutes from San Diego, we basically said that "low
latency" means "Significantly lower than doing an EAP round again" - the
only way to measure it for a protocol design is using roundtrips and
allowing localized re-authentication when the EAP server is too far
away. 

Vidya

> requires 3+

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 Jan 2007 15:43:59 -0800

Hi Yoshi,

<snip>

> 
> I understand that those restrictions on "Re-auth" in method 
> type, but I don't understand why it can't be 2.5 RT.
> 

Please see the call flow from an email that Charles sent (I've pasted
the relevant part below for reference): 

"Method-based transport (3.5-4 RT):

[optional EAPoL-Start ->]
<- EAP-Request/Identity
EAP-Response/Identity ->
<- EAP-Request/HOKEY (empty message)
EAP-Response/HOKEY-Method (contains Request/Reauth) ->
<- EAP-Request/HOKEY-Method (contains Response/Reauth-Finished)
EAP-Response/HOKEY-Method (empty message) ->
<- EAP-Success"

The empty messages are needed due to the Request/Response semantics. I'm
not sure how it can be any less than this. If you skipped the
Request/Response Identity, it is 2.5 RTs - may be that is what you were
talking about? 

> Regarding new packet codes, we would also need to assume 
> lower layer upgrade in addition to authenticator upgrade, 
> according to previous discussion on existing EAP lower layers.
> 

Yes, some upgrade may be needed for some lower layers. This is not an
issue for evolving new radio technologies that are yet to define the EAP
lower layer anyway (as in some cellular networks). 

<snip>

> Yes, my comment on latency was in terms of the number of 
> message roundtrips and and my comment still remains the same: 
> I don't think we can conclude at this moment that which RT 
> value will or will not satisfy the low latency requirements.
> 

We can only use protocols in use as points of reference. Let's take
EAP-AKA (AKA is used in 3gpp). If the Request/Response Identity messages
are skipped (as may very well be the case if 3gpp used EAP), EAP-AKA
takes 1.5 roundtrips to complete. AKA fast re-authentication allows
faster key computation. EAP-GPSK will take 2.5 roundtrips, again not
counting Request/Response Identity. 

If the re-authentication protocol we design is going to be less or only
as efficient as these methods, I don't see the benefit. 

In short, I really don't think we can get a re-authentication mechanism
optimal for some of these systems that are looking to use EAP, unless we
modify EAP with new Codes. The use of the "method-based" transport would
be a transition alternative to address legacy authenticators and lower
layers. 

Vidya

---

From: "Sood, Kapil" <[email-masked]>
Date: Thu, 4 Jan 2007 16:09:11 -0800

> If you take a look at the
[Sood, Kapil] Can you please define "far"?  

We should replace our requirement of "low latency" with what you stated
"Avoid a full EAP authentication".

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 Jan 2007 16:35:32 -0800

> Sent: Thursday, January 04, 2007 4:09 PM
> To: Narayanan, Vidya; Yoshihiro Ohba; Dondeti, Lakshminath
> Cc: [email-masked]

Another subjective term :) We can probably only say this - allow
re-authentication with a "re-auth server" that would be different from
the actual EAP server (which may be many hops away). The full EAP method
would be run with the EAP server (that's what the peer shares its
credentials with), but the re-authentication may be done with a local
re-auth server that the peer discovered closer to its current location. 

> We should replace our requirement of "low latency" with what 
> you stated "Avoid a full EAP authentication".

Well, the number of messages a full EAP authentication takes really
depends on what EAP method is used. So, I'm not sure that "avoid a full
EAP authentication" means anything. In other words, we can avoid full
EAP authentication and perform worse than the case where a full EAP
authentication is done, but we would have defeated the purpose. We need
a protocol that works better than re-running the method, considering the
most widely deployed and any promising new methods. The authentication
method with the lowest number of RTs is probably AKA (widely deployed)
and close behind will be the new GPSK that EMU is defining. Ultimately,
it is latency that the systems using such methods are after - without
addressing that, we do run into key-sharing and other insecure
approaches being adopted in place of something more secure, which is
what we are trying to avoid by designing a fast, yet secure
re-authentication protocol here. 

Vidya

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Jan 2007 20:09:44 -0500

Hi Vidya,

> Request/Response Identity, it is 2.5 RTs - may be that is what you were

I was not mentioning Identity exchange (it can be omitted in some
sceanrios, though).  Instead, I think the two "empty messages" is not
needed if re-authentication can be designed something like:

[optional EAPoL-Start ->]
<- EAP-Request/Identity
EAP-Response/Identity ->
<- EAP-Request/HOKEY (Reauth Data from Server)
EAP-Response/HOKEY-Method (Reauth Data from Peer) ->
<- EAP-Success"

> lower layer anyway (as in some cellular networks). 

I think that a solution should not be too biased to link layer
technologies that "yet to define the EAP lower layer".  I believe it
is important to consider a solution that works with both
existing link-layer technologies and new technologies without
requiring any change to existing link-layer technologies.  

It is also important to consider inter-technology handover.  If there
is only one solution that requires changes to existing link-layer
technologies, then inter-technology handover to existing link-layer
technologies is not possible without changing them, which would not be
acceptable.  To address this issue, we could define two solutions
where one solution is for existing link-layer technologies (as a
transition alternative in your wording) and the other is for new
link-layer technologies.  However, this would mean that a
re-authentication protocol is virtually dependent on link-layer
technology, which would not satisfy the requirement on EAP lower-layer
independence.

> as efficient as these methods, I don't see the benefit. 

If a re-authentication solution can achieve 1.5 or 2.5 roundtrips
without requiring any change to existing link-layer technologies, I
still see a benefit of the solution for deployment that uses EAP
methods other than EAP-AKA and EAP-GPSK for initial authentication.

Regards,
Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 Jan 2007 18:25:59 -0800

<snip>

> I was not mentioning Identity exchange (it can be omitted in 
> some sceanrios, though).  Instead, I think the two "empty 
> messages" is not needed if re-authentication can be designed 
> something like:
> 

Re-authentication needs to be peer-initiated for the most optimal
approach, AFAICT. If we want to keep that model the same (in other
words, the protocol the same), we would need those empty messages (the
reverse problem of what happened to TLS to run it over EAP :)). 

> lower layer 
> > issue for evolving new radio technologies that are yet to 
> define the 
> > EAP lower layer anyway (as in some cellular networks).
> 
> I think that a solution should not be too biased to link 
> layer technologies that "yet to define the EAP lower layer".  
> I believe it is important to consider a solution that works 
> with both existing link-layer technologies and new 
> technologies without requiring any change to existing 
> link-layer technologies.  
> 

I think that's the compromise that is achieved by having a protocol that
can either run over new EAP messages (with new packet codes) or using
existing EAP messages (with new method types). A peer will then run the
re-authentication protocol in native (modified) EAP mode over lower
layers and authenticators that support it and run it as an EAP method
over those that don't. Support for the re-authentication protocol in the
authenticator can be discovered at the lower layer, for instance. 

> It is also important to consider inter-technology handover.  
> If there is only one solution that requires changes to 
> existing link-layer technologies, then inter-technology 
> handover to existing link-layer technologies is not possible 
> without changing them, which would not be acceptable.  To 
> address this issue, we could define two solutions where one 
> solution is for existing link-layer technologies (as a 
> transition alternative in your wording) and the other is for 
> new link-layer technologies.  However, this would mean that a 
> re-authentication protocol is virtually dependent on 
> link-layer technology, which would not satisfy the 
> requirement on EAP lower-layer independence.
> 

Not really. The above takes care of inter-technology handoffs very well,
whether such handoffs entail switching from native EAP to method-based
mode or vice-versa. The re-authentication protocol itself still remains
the same. 

> > > roundtrips and and my comment still remains the same:
> > > I don't think we can conclude at this moment that which RT value 
> > > will or will not satisfy the low latency requirements.
> > > 
> > 
> > EAP-AKA (AKA is used in 3gpp). If the Request/Response Identity 
> > messages are skipped (as may very well be the case if 3gpp 
> used EAP), 
> > EAP-AKA takes 1.5 roundtrips to complete. AKA fast 
> re-authentication 
> > allows faster key computation. EAP-GPSK will take 2.5 roundtrips, 
> > again not counting Request/Response Identity.
> > 
> > If the re-authentication protocol we design is going to be less or 
> > only as efficient as these methods, I don't see the benefit.
> 
> If a re-authentication solution can achieve 1.5 or 2.5 
> roundtrips without requiring any change to existing 
> link-layer technologies, I still see a benefit of the 
> solution for deployment that uses EAP methods other than 
> EAP-AKA and EAP-GPSK for initial authentication.
> 

I think it is hard to find a method that this would be useful for. TLS
session resumption will get you down to 2 RTs for re-authentication. The
cellular systems (3gpp, for e.g.) are really evaluating the usefulness
of switching to EAP and that is not going to happen unless we have a
re-keying mechanism that can be at least as fast as their current
authentication mechanisms, if not better. UMTS-AKA, for instance is a
single roundtrip authentication protocol. Only when running over EAP, it
has the extra 0.5 RT due to an EAP success. As inter-technology handoffs
become more and more important and for sake of evolving to other better
authentication methods, EAP is useful as the authentication framework.
However, without providing efficient re-authentication options, EAP is
either not going to be deployed in such networks or is going to be
deployed using not-so-secure techniques (such as MSK-transfers) or with
a technology-specific re-authentication protocol, none of which are
attractive options. 

I think these points have been hashed and re-hashed so many times now -
the discussion is getting tiring. So, I really hope that we can move
forward with the acceptable compromise that we can design a protocol
that is most optimally executed by modifying EAP and can be somewhat
less optimally done by carrying it like an EAP method for transition
purposes. 

Vidya

> Regards,
> Yoshihiro Ohba
> 
> > 
> > In short, I really don't think we can get a re-authentication 
> > mechanism optimal for some of these systems that are looking to use 
> > EAP, unless we modify EAP with new Codes. The use of the 
> > "method-based" transport would be a transition alternative 
> to address 
> > legacy authenticators and lower layers.
> > 
> > Vidya
> > 
> > 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 04 Jan 2007 21:44:24 -0800

Could you explain how a protocol with 1.5 roundtrips would work 
without any changes to link-layer?

thanks,
Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Fri, 05 Jan 2007 08:29:19 -0500

Perhaps "lower-latency" instead of "low-latency" would be better 
language?  The point isn't to put any absolute bounds on anything, but 
rather relative ones.  By performing fewer RTs than is typically 
required now, we should theoretically be faster than we were before.

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

---

From: Charles Clancy <[email-masked]>
Date: Fri, 05 Jan 2007 08:31:06 -0500

> as a method-based general re-authentication mechanism also possible?

No -- it's stating that it should work with any initial authentication
method, and shouldn't require changes to any existing methods or impose
constraints on future methods.

---

From: Charles Clancy <[email-masked]>
Date: Fri, 05 Jan 2007 09:06:53 -0500

> needed if re-authentication can be designed something like:

My motivation for including the empty messages was so that the 
native-EAP version and the method-based version were the same protocol. 
  Since the native-EAP version was peer-initiated, transporting it over 
a method required empty messages.  Otherwise we'd be creating two 
protocols, rather than one protocol with two transports.  If I can be 
convinced that's not something I should worry about, then it seems to me 
the empty messages could be removed.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Jan 2007 09:24:19 -0500

Please see the diagram in my response to Vidya (the one
with removing the two empty messages).  I was not counting 
Identity exchange in "1.5".

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 05 Jan 2007 09:49:28 -0800

Yoshi,

I don't think we can simply discount the Identity exchange in all 
cases.  Consider the exchange you proposed:

<- EAP-Request/Identity
EAP-Response/Identity ->

Could you clarify how the server would know which reauth data to 
send?  It has to know the client ID somehow, doesn't it?  I can think 
of other exchanges, where you can remove the Identity exchange, and 
the protocol will still work: challenge-response protocols are an example.

thanks,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 05 Jan 2007 12:20:52 -0800

Not sure I understand, why re-auth is considered another method?
And why would a method based re-auth would have 3+ RTs? Curious to see the
analysis?
Having said that, on the other hand, a key hierarchy can create keys for
re-authentication and that way reduce the roundtrips for re-auth to AAA
server significantly. I have shown this in a draft.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Thursday, January 04, 2007 10:03 AM
To: Yoshihiro Ohba; Charles Clancy
Cc: [email-masked]
Subject: Re: [HOKEY] Proposed WG Item: Problem Statement

HTH.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Jan 2007 15:27:36 -0500

Vidya,

On Thu, Jan 04, 2007 at 06:25:59PM -0800, Narayanan, Vidya wrote:
(snip)
> authenticator can be discovered at the lower layer, for instance. 

As far as I recall, this compromise was discussed before we knew a new
fact that existing lower layers need to be changed to support a new
EAP Code.  I am revisiting this issue based on the new fact.

If a re-authentication protocol implementation has to choose its
transport scheme (i.e., use of a new EAP Code or a new EAP Type) not
only based on whether authenticator supports the new EAP Code but also
whether lower layer allows required state transitions to support the
new EAP Code, isn't it acutually lower-layer dependent?

> mode or vice-versa. The re-authentication protocol itself still remains

I believe the requirement on choosing a re-authentication transport
scheme based on the type of link-layer is not desirable.  I don't see
much value of having the same re-authentication protocol with
different transport schemes, if transport schemes still depend on
link-layer.

> has the extra 0.5 RT due to an EAP success. As inter-technology handoffs

Are you saying that 3GPP does not accept EAP and EAP-AKA mainly
because of EAP-Success in re-keying?  I am not sure if that is the
main reason.  Do you have any publically available information on
this?

> a technology-specific re-authentication protocol, none of which are

If a re-authentication protocol that needs to use different
re-authentication transport schemes (i.e, a new EAP Code or a new EAP
Type) depending on link-layer, I'd argue that the entire re-auth
solution is still technology-specific.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Jan 2007 15:41:57 -0500

> the protocol will still work: challenge-response protocols are an example.

Surely the server needs to know the identity of the peer.  But this
does not mean that Identity exchange is always required.  Identity
exchange may be skipped for some scenarios perhaps including 3GPP case
as Vidya mentioned.  Please refer to RFC 3748 for a couple of
scenarios on how the server can know the peer identity.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 5 Jan 2007 12:49:12 -0800

Yoshi,
I think this has also been discussed before. I believe you are confusing
"lower layer needs to be upgraded" with "lower layer dependence". By
that definition, EAP can also be classified as lower layer dependent,
since EAP requires support from each lower layer to run. IIRC, Charles
clarified this earlier on the list - that when we modify EAP, lower
layer upgrades may be needed (mainly due to the way in which certain EAP
lower layers have already been designed), but we are not looking for a
solution that will depend on particular characteristics of any
technology - so, it is still not technology dependent. 

Vidya

> Sent: Friday, January 05, 2007 12:28 PM
> To: Narayanan, Vidya
> Cc: Yoshihiro Ohba; Dondeti, Lakshminath; [email-masked]
> > > technologies that "yet to define the EAP lower layer".
> > > I believe it is important to consider a solution that works with 
> > > both existing link-layer technologies and new 
> technologies without 
> > I think that's the compromise that is achieved by having a protocol 
> > that can either run over new EAP messages (with new packet 
> codes) or 
> > using existing EAP messages (with new method types). A peer 
> will then 
> > run the re-authentication protocol in native (modified) EAP 
> mode over 
> > lower layers and authenticators that support it and run it 
> as an EAP 
> > method over those that don't. Support for the re-authentication 
> > protocol in the authenticator can be discovered at the 
> lower layer, for instance.
> 
> As far as I recall, this compromise was discussed before we 
> knew a new fact that existing lower layers need to be changed 
> to support a new EAP Code.  I am revisiting this issue based 
> on the new fact.
> 
> If a re-authentication protocol implementation has to choose 
> its transport scheme (i.e., use of a new EAP Code or a new 
> EAP Type) not only based on whether authenticator supports 
> the new EAP Code but also whether lower layer allows required 
> state transitions to support the new EAP Code, isn't it 
> acutually lower-layer dependent?
> 
> > 
> > > If there is only one solution that requires changes to existing 
> > > link-layer technologies, then inter-technology handover 
> to existing 
> > > link-layer technologies is not possible without changing 
> them, which 
> > > would not be acceptable.  To address this issue, we could 
> define two 
> > > solutions where one solution is for existing link-layer 
> technologies 
> > > (as a transition alternative in your wording) and the 
> other is for 
> > > technology, which would not satisfy the requirement on EAP 
> > > lower-layer independence.
> > > 
> > 
> > Not really. The above takes care of inter-technology handoffs very 
> > well, whether such handoffs entail switching from native EAP to 
> > method-based mode or vice-versa. The re-authentication 
> protocol itself 
> > still remains the same.
> 
> I believe the requirement on choosing a re-authentication 
> transport scheme based on the type of link-layer is not 
> desirable.  I don't see much value of having the same 
> re-authentication protocol with different transport schemes, 
> if transport schemes still depend on link-layer.
> 
> > 
> > > > 
> > > > <snip>
> > > > 
> > > > We can only use protocols in use as points of reference. Let's 
> > > > take EAP-AKA (AKA is used in 3gpp). If the Request/Response 
> > > > Identity messages are skipped (as may very well be the case if 
> > > > 3gpp
> > > used EAP),
> > session resumption will get you down to 2 RTs for 
> re-authentication. 
> > The cellular systems (3gpp, for e.g.) are really evaluating the 
> > usefulness of switching to EAP and that is not going to 
> happen unless 
> > we have a re-keying mechanism that can be at least as fast as their 
> > current authentication mechanisms, if not better. UMTS-AKA, for 
> > instance is a single roundtrip authentication protocol. Only when 
> > running over EAP, it has the extra 0.5 RT due to an EAP success. As 
> > inter-technology handoffs
> 
> Are you saying that 3GPP does not accept EAP and EAP-AKA 
> mainly because of EAP-Success in re-keying?  I am not sure if 
> that is the main reason.  Do you have any publically 
> available information on this?
> 
> > become more and more important and for sake of evolving to other 
> > better authentication methods, EAP is useful as the 
> authentication framework.
> > deployed using not-so-secure techniques (such as MSK-transfers) or 
> > with a technology-specific re-authentication protocol, none 
> of which 
> > are attractive options.
> 
> Type) depending on link-layer, I'd argue that the entire 
> re-auth solution is still technology-specific.
> 
> Regards,
> Yoshihiro Ohba
> 
> > 
> > I think these points have been hashed and re-hashed so many 
> times now 
> > - the discussion is getting tiring. So, I really hope that 
> we can move 
> > > > mechanism optimal for some of these systems that are looking to 
> > > > use EAP, unless we modify EAP with new Codes. The use of the

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 05 Jan 2007 13:59:36 -0800

Agree with the last statement! Lets drop the RT upper bounds for now.

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, January 04, 2007 11:42 AM
To: Lakshminath Dondeti
Cc: [email-masked]
Subject: Re: [HOKEY] Proposed WG Item: Problem Statement

Hi Lakshminath,

Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Fri, 05 Jan 2007 17:09:06 -0500

Madjid,

It's not considered another method.  The idea is to simply use a type 
code to transport the reauthentication protocol.  I'm not sure I'd call 
it an "analysis", but I posted the following last month:

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

One RT could possibly be removed if the goal was not to use the same 
structure in the type-code transport as the packet-code transport.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Jan 2007 17:10:46 -0500

Vidya,

I am not saying that lower-layer upgrade means lower-layer dependent.

I think the following three solutions are lower-layer independent:

- Use a single solution for any lower layer without any upgrade.

- Use a single solution for any lower layer, but some lower layers
will need to be upgraded.

- Use Option 1 for Authenticators that support Option 1 and use Option
2 for other Authenticators, for any lower layer.

What I am saying that *the entire solution* that allows different
options for different types of lower-layers (not for different types
of authenticators) would end up with breaking lower-layer
independency, regardless of lower-layer upgrade, if we consider
inter-technology handover.  I don't think this particular aspect was
discussed.  My simple question is, how can we claim that the following
solution is lower-layer independent?

- Use Option 1 for lower-layers that support Option 1 and use Option 2
for other lower-layers.

BTW, I don't agree with the statement that EAP is lower layer
dependent.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 05 Jan 2007 14:27:01 -0800

What if you are doing a really efficient EAP method that only requires 2 RT?
Then what?

Another thing that people are missing is the fact that we can use the
initial EAP keying material (such as EMSK) to achieve this optimization. Not
sure if that can or should be turned into a requirement? But it is a clue.

Personal advice: I worked on seamoby for 4 years, and we had all these
discussions around latency and never got anywhere. Mobile IP groups have
designed fast Mobile IP methods without having such RT requirement. Lets not
dwell so much on this.

I think "lower than full EAP auth" (not even "significantly lower") is
sufficient.

R,

Madjid
-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Thursday, January 04, 2007 3:28 PM
To: Sood, Kapil; Yoshihiro Ohba; Dondeti, Lakshminath
Cc: [email-masked]
Subject: RE: [HOKEY] Proposed WG Item: Problem Statement

Kapil,

Vidya

> value will

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 05 Jan 2007 14:43:28 -0800

>What if you are doing a really efficient EAP method that only requires 2 RT?

We can do less than 2 RTs too.  IKEv2 rekeying works in 1 RT, so can EAP.

Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 05 Jan 2007 14:45:51 -0800

Yes,thx

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 05 Jan 2007 14:49:40 -0800

I was referring the bound of 3RT for re-auth:)

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 2:43 PM
To: Madjid Nakhjiri; 'Narayanan, Vidya'; 'Sood, Kapil'; 'Yoshihiro Ohba'
Cc: [email-masked]
Subject: RE: [HOKEY] Proposed WG Item: Problem Statement

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 05 Jan 2007 15:50:05 -0800

At 12:41 PM 1/5/2007, Yoshihiro Ohba wrote:
>does not mean that Identity exchange is always required.

Well there needs to be a message from the NAS/Authenticator to the 
Server, right?  So, if we are counting all of the *necessary* 
messages, it is a 2 RT exchange at the very least.

>Identity
>as Vidya mentioned.

Skipping identity exchange basically means one of two things, Case a) 
the LL or other messaging is required so the client ID can reach the 
server or b) a CHAP like exchange is being used and the server sends 
the same message to any client.  Case b does not apply to us.

Lakshminath

>Please refer to RFC 3748 for a couple of