Subject: Re: [HOKEY] HOKEY re-key architecture

From: Charles Clancy <[email-masked]>
Date: Thu, 01 Feb 2007 16:56:56 -0500

Yoshi,

I think this type of architecture is outside the scope of the consensus
achieved at the HOKEY interim meeting.

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

Yoshihiro Ohba wrote:
> Separation of re-auth and re-key can make our life much simpler.  To
> be honest, I am not at all in favor of being crazy about modifying EAP
> and AAA for re-key.
> 
> I suggest investigating the following re-key architecture.  I believe
> this is simple, straightforward and scalable.
> 
> -------------------------
> HOKEY Re-key Architecture
> -------------------------
> 
> 1. Functional Entities
> 
> HOKEY Client      (HOC)
> HOKEY Server      (HOS) 
> HOKEY Access Node (HAN)
> 
> 
> 2. Security Associations
> 
> 
> +---+         HOC-HOS SA          +---+
> |HOC|-----------------------------|HOS|
> +---+                             +---+
>   |                                 |
>   |                                 |
>   |              +---+              |
>   +--------------|HAN|--------------+
>     HOC-HAN SA   +---+  HAN-HOS SA
> 
> 
> HAN-HOS SA: Statically configured
> HOC-HOS SA: Bootstrapped from EAP (or statically configured)
> HOC-HAN SA: Dynamically established using HOKEY re-key protocol
> 
> 
> 3. HOKEY Re-key Protocol
> 
> HOKEY re-key protocol is a two-step, three-party protocol that uses
> Kerberos or alike in which key distribution is based on key-wrapping.
> For brevity, Kerberos is used for protocol explanation.
> 
> 
> Step 1: Ticket Acquisition
> 
> +---+ TGS_REQ -->                    +---+
> |HOC|--------------------------------|HOS|
> +---+                    <-- TGS_REP +---+
> 
> Step 2 Ticket Installation
> 
> +---+ AP_REQ -->  +---+
> |HOC|-------------|HAN|
> +---+  <-- AP_REP +---+
> 
> When Step 1 happens after handover, the HOC may not have IP
> connectivity to the HOS.  In this case, the HAN in the target network
> acts as pass-through forwarder of Step 1 re-key messages.
> 
> 
> 4. Characteristics
> 
> - HOKEY re-key protocol transport does not need to be secured.
> 
> - No key distribution protocol is needed between HOS and HAN.
> 
> - No need to change EAP, EAP transport and AAA.
> 
> - Lower layer change is needed to support HOKEY re-auth protocol
> transport.  This can be done via management frames such as Action
> Frames of 802.11.
> 
> - The number of message roundtrips for re-key is two, where one of the
> two roundtrips does not go beyond the access network.
> 
> - To address scalability issues, it is possible to form a hierarchy of
> HOKEY servers just like a hierarchy of Kerberos realms.
> 
> Best Regards,
> Yoshihiro Ohba
> 
> _______________________________________________
> 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: Yoshihiro Ohba <[email-masked]>
Date: Fri, 2 Feb 2007 00:36:44 -0500

Well it depends on which architecture is actually being discussed in
the consensus discussion.  

If only re-auth architecture is being discussed, my proposal is off
topic, because my proposal is specific to re-key.  I don't disagree
with modifying EAP for re-auth.

If both re-auth and re-key architecture is being discussed, my
proposal is relating to re-key part and thus part of the architecture.
I have a clear objection to modify or use EAP for re-key.
It is not clear to me which architecture is being discussed in the
consensus discussion.  I suggested to separate re-key and re-auth.

>From now on, I will not use the term "re-key" to mean re-key for
handover.  Instead, I'll use the term "handover keying" for it.

Yoshihiro Ohba

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 2 Feb 2007 15:58:02 -0500 (EST)

Indeed, more terminolgy confusion.  I was misinterpreting what you meant
by "re-keying".  I agree that "handover keying" should be used instead.

I think "re-keying"-based architectures (i.e. something that looks like
kerberos) are out of scope.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Feb 2007 16:21:43 -0500

Just to make sure that we are on the same page, is the architecture being
discussed in the consensus discussion for *re-auth* only?

For handover keying architecture, I think we need much more
discussion.

Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Mon, 05 Feb 2007 16:50:32 -0500

While the focus is on re-auth, the consensus was that this approach 
could be used for everything, including ho-keying and authentication in 
visited domains.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 5 Feb 2007 23:16:21 -0500

Then my position is against the single architecture to be used for
everything.  I would like to see separate architectures for re-auth
and handover keying.

Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 06 Feb 2007 08:40:44 -0800

As long as we are stating preferences, mine is to try and develop a 
single architecture (I was initially unsure about it, but I have to say 
Glen convinced me) as long as everything can be done in an efficient 
manner (we have text in the charter to guide this).

thanks,
Lakshminath