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

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 5 Jan 2007 16:29:13 -0800

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

> Glen,
> Whether the re-auth protocol is an extension to EAP or a brand new
> protocol, it requires the same level of support from the lower layer
> as EAP. So, I am not sure I understand the benefit of not modifying
> EAP - it is a question of lower layer support for an EAP modification
> vs a new protocol that will have the same requirements as EAP on the
> lower layer. In fact, I think it would be simpler to add support for
> the extra EAP packet codes than specify a new lower layer for a new
> protocol.      

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.

> 
> 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: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 5 Jan 2007 17:05:46 -0800

> Sent: Friday, January 05, 2007 4:29 PM
> To: Narayanan, Vidya; Charles Clancy
> Narayanan, Vidya <mailto:[email-masked]> supposedly 
> scribbled on Friday, January 05, 2007 4:11 PM:
> 
> > Glen,
> 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. However,
isn't the same NAS entity doing regular EAP and re-auth? Don't we still
need the NAS to support this? Or, were you only referring to not having
to mess with the server? 

Vidya

> 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
> > 
> >> 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 
> >>>> 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
> >>>> 
> >>>>>> documents: 
> http://tools.ietf.org/html/draft-nakhjiri-aaa-hokey-ps