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

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 5 Jan 2007 15:56:34 -0800

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 5 Jan 2007 16:11:00 -0800

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. 

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

Vidya

> 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 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 
> 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:
> >>>> 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: <[email-masked]>
Date: Mon, 8 Jan 2007 11:57:29 -0600

Glen,

>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).  
>
I guess this depends on what would make the deployment of Hokey
a reality. It looks like the peer has to change for sure. Now
for the authenticator and EAP-server, these are the options that
were discussed earlier.

- No Authenticator change is required but EAP server can be
  changed. This was the original motivation for Type-based
  transport AFAICT. A HOKEY server may or may not exist in
  the visited domain. If a hokey server does not exist, you
  still go back home and hence not fully optimized.
  But you are still providing optimization for the methods that
  do not have fast-reauth or for methods that are used as
  "inner" methods inside the tunnel.

- Both Authenticator and EAP server is changed. HOKEY server
  may or may not exist in the visited domain. This is what
  is referred to as EAP-code based transport here.

Before we start on a solution, we should agree on whether
we are solving both cases or not including whether a HOKEY
server is present or not. Your proposal is addressing the
latter and i do agree that it is potentially one of the solutions
that should be considered for that.

-mohan

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 08 Jan 2007 14:41:17 -0800

I agree with Glen here.
I spent a couple of hours studying EAP 3748 use of Type and the requirements
around pass-through authenticators and I don't quite think use of Type is
that pretty. It is just spaghetti design.
One problem is obviously the fact that in a handover, the trigger from
handover is many times available to the peer, not to the authenticator and
EAP signaling with its server-initiated approach, with Request from Server
and response from peer just is not suited for this.
Furthermore, any Type over 4 gets only optional support from other methods.

Re-auth can be established with a single RT with whomever the re-auth needs
to happen simply through proof of possession of a key. I have shown this in
my hokey hierarchy draft. The messaging to accommodate this can be and
should be non-EAP to avoid even more Type confusions.

Madjid 

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

b=n9U4Q/oNMXtsYCFeSIAspUpg1jvLe46mT2H7jatn7cGvYJIt7qvnQVqP/9rAHX+43igGOk
	GLYB3SOjfVUvGxolb/v0Wia1UwWtXqkt0YX4hVUydElurN7H1WdzfTYR;