Subject: RE: [HOKEY] Proposed WG Item: Problem Statement

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 5 Jan 2007 17:35:01 -0800

Narayanan, Vidya <mailto:[email-masked]> supposedly scribbled on
Friday, January 05, 2007 5:06 PM:

>> I don't think you're getting my point.  I didn't say anything about a
>> new protocol, what I said was, basically, to remove all the backwards
>> compatibility issues by _not_ going back to the _standard_ EAP/AAA
>> servers _ever_.  If the hokey reauth protocol happens to be a
>> modification of EAP or uses something that looks remarkably like
>> RADIUS/Diameter between the NAS  & hokey server is immaterial.
>> 
> 
> I guess I'm confused. Sure, the re-auth server can logically be a
> separate entity from the EAP server, if that's what you mean.

No, I don't mean _can_, I mean _must_.  

> However, isn't the same NAS entity doing regular EAP and re-auth?
> Don't we still need the NAS to support this? 

Sure, but once again, it's easier to add then modify...

> Or, were you only
> referring to not having to mess with the server?  

Or actually modify EAP...the hokey proto can certaily be EAP-like, even
EAP-based, but not EAP.
  
> 
> Vidya
> 
>>> 
>>> If that's not your thinking, could you please elaborate on what you
>>> see as the benefits of doing a new protocol, considering that the
>>> re-auth protocol is also meant for network access, prior to
>>> availability of routable IP addresses, etc.?
>> 
>> The obvious advantage, from a deployment POV, is that it's always
>> easier/less risky to add something new (that may or may not work) to
>> a network than it is to modify things that already work fine.
>> 
>>> 
>>> Vidya
>>> 
>>>> -----Original Message-----
>>>> From: Glen Zorn (gwz) [mailto:[email-masked]]
>>>> Sent: Friday, January 05, 2007 3:57 PM
>>>> To: Charles Clancy
>>>> Cc: [email-masked]; Madjid Nakhjiri
>>>> Subject: RE: [HOKEY] Proposed WG Item: Problem Statement
>>>> 
>>>> Charles Clancy <mailto:[email-masked]> supposedly scribbled on
>>>> Friday, January 05, 2007 2:09 PM:
>>>> 
>>>>> 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. 
>>>> 
>>>> It seems to me that we could do away with a lot of complexity by
>>>> leaving the EAP & AAA servers pretty much out of the picture
>>>> entirely. Suppose that we have established a PSK between the peer
>>>> and a hokey server in some way (an initial EAP authentication,
>>>> say, for the peer & a secure key transfer in the case of the hokey
>>>> server). For reauth, we no longer need EAP at all, nor for that
>>>> matter AAA (unless we choose to use them). There seem to be
>>>> several other salutary effects of this approach, not least among
>>>> them obviating the need to massively modify either EAP protocol or
>>>> the AAA infrastructure, not to mention avoiding the creation of
>>>> new AAA traffic (in _all_ cases, not just roaming).
>>>> 
>>>>> 
>>>>> 
>>>>> Madjid Nakhjiri wrote:
>>>>>> 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
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> At 08:46 AM 1/4/2007, Yoshihiro Ohba wrote:
>>>>>>> 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
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Jan 03, 2007 at 01:31:37PM -0500, Charles Clancy wrote:
>>>>>>>> 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
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> HOKEY mailing list
>>>>>>> [email-masked]
>>>>>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> HOKEY mailing list
>>>>>> [email-masked]
>>>>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> HOKEY mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>> 
>>>> _______________________________________________
>>>> 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: Madjid Nakhjiri <[email-masked]>
Date: Mon, 08 Jan 2007 17:15:45 -0800

Hi Glen,

I changed the subject, since it was getting boring:)
I am also playing a bit of devil advocate here.

I like the "EAP-like" idea. I don't however understand why the re-auth
server _has_ to be separate from EAP server? If you upgrade your EAP server
to handle hokey features: the cooler hierarchy and the re-auth, you say the
server that does initial EAP and the re-auth should be separate?

I also like "add instead of modify", but the question that I have had for
while, is at what point and how the peer and the server indicate to each
other that they both support hokey?
I mean, we all assume that the peer and the server initially run EAP and
establish MSK/EMSK. Then after that the EAP compliant server/peer do one
thing, but the hokey compliant server/peer do another. Can something be
added to the initial EAP signaling to indicate Hokey (other than Type?)

Madjid

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 9 Jan 2007 11:33:59 -0800

Madjid Nakhjiri <mailto:[email-masked]> supposedly scribbled on
Monday, January 08, 2007 5:16 PM:

> Hi Glen,
> 
> I changed the subject, since it was getting boring:) I am also
> playing a bit of devil advocate here. 
> 
> I like the "EAP-like" idea. I don't however understand why the
> re-auth server _has_ to be separate from EAP server? If you upgrade
> your EAP server to handle hokey features: the cooler hierarchy and
> the re-auth, you say the server that does initial EAP and the re-auth
> should be separate? 

What I think would be good is if the architecture is homogenous in all
cases.  In the architectures I've seen so far, the roaming case is
treated differently than the non-roaming case, generally through the
introduction of a "special" server in the visited network.  What I'm
proposing is that, instead of bolting fast re-auth on to EAP (in order
to go to the EAP server in the home network in the non-roaming case),
make re-auth a separate app.  Therefore, the "special" server would not
be an optimization in the roaming case, but a constant component of the
architecture & the protocol would always operate in the same way.
   
> 
> I also like "add instead of modify", but the question that I have had
> for while, is at what point and how the peer and the server indicate
> to each other that they both support hokey?  

If the hokey server is always an independent entity (regardless of what
protocol it speaks), this seems to solve the problem.

> I mean, we all assume that the peer and the server initially run EAP
> and establish MSK/EMSK. Then after that the EAP compliant server/peer
> do one thing, but the hokey compliant server/peer do another. Can
> something be added to the initial EAP signaling to indicate Hokey
> (other than Type?)  

I don't think that this is really necessary.
  
>>> I don't think you're getting my point.  I didn't say anything about
>>> a new protocol, what I said was, basically, to remove all the
>>> backwards compatibility issues by _not_ going back to the
>>> _standard_ EAP/AAA servers _ever_.  If the hokey reauth protocol
>>> happens to be a modification of EAP or uses something that looks
>>> remarkably like RADIUS/Diameter between the NAS  & hokey server is
>>> immaterial. 
>>> 
>> 
> Or actually modify EAP...the hokey proto can certaily be EAP-like,
> even EAP-based, but not EAP. 
> 
>> 
>> Vidya
>> 
>>>> 
>>>>>> type code to transport the reauthentication protocol. I'm not
>>>>>> sure I'd call it an "analysis", but I posted the following last
>>>>>> month: 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>>>> them obviating the need to massively modify either EAP protocol
>>>>> or the AAA infrastructure, not to mention avoiding the creation
>>>>> of new AAA traffic (in _all_ cases, not just roaming).
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Madjid Nakhjiri wrote:
>>>>>>> reduce the roundtrips for re-auth to AAA server significantly.
>>>>>>> I have shown this in a draft. 
>>>>>>> 
>>>>>>> Madjid
>>>>>>> 
>>>>>>> does not meet the low latency requirements.  At the moment, I
>>>>>>> am ok with having that as an "option" but continue with
>>>>>>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> This document represents the consolidation of the following
>>>>>>>>> two documents:

---

From: "Julien Bournelle" <[email-masked]>
Date: Wed, 10 Jan 2007 09:33:32 +0100

Hi glen, all,

 I'm not sure to well understand your suggestion. Are you proposing to not
 use EAP for the re-auth ?

 Julien