Subject: [HOKEY] HOKEY re-key architecture

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 08:53:10 -0500

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 10:08:14 -0500

One correction:

On Tue, Jan 30, 2007 at 08:53:10AM -0500, Yoshihiro Ohba wrote:
(snip)
> transport.  This can be done via management frames such as Action

s/re-auth/re-key/.

> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
>

---

From: "Saber Zrelli" <[email-masked]>
Date: Wed, 31 Jan 2007 00:31:18 +0900 (JST)

Hi Yoshihiro,

I like the architecture you proposed,
some comments inline,

> this is simple, straightforward and scalable.

Some question that might be asked :
How can HOS authenticate HOC before issuing a TGS_REP ? i.e. How did HOC
get a TGT that can be used with HOS.

> acts as pass-through forwarder of Step 1 re-key messages.

Do you mean EAP passthrough, or a specific protocol-proxy for the rekey
protocol ?

> - No need to change EAP, EAP transport and AAA.

However, I think that adding a new entity 'HOC' in the AP could be a
disadvantage.

> transport.  This can be done via management frames such as Action

If a new EAP method is specified for the re-auth I think that lower layer
changes can be avoided.

> two roundtrips does not go beyond the access network.

I think this is the main advantage.

> HOKEY servers just like a hierarchy of Kerberos realms.

Also, based on the same analogy between the rekey protocol and Kerberos,
a model similar to the enhanced Kerberos cross-realm operations (XASP in
draft-zrelli-krb-xkdcp-00.txt) could be used to allow a client to obtain a
TGT for the visited realm without contacting its home KDC.

IMHO a third-party based protocol such as Kerberos is a good approach to
solve the concerns in HAKEY. Such solution would be more efficient if it
uses a new EAP-Kerberos method to deliver credentials and authenticate
clients to the access network.

Best Regards,
Saber.

---

From: "Saber Zrelli" <[email-masked]>
Date: Wed, 31 Jan 2007 01:30:39 +0900 (JST)

Hi,

> get a TGT that can be used with HOS.

I forgot about HOC-HOS SA.
I guess the HOC uses the pre-established HOC-HOS SA (which is some sort of
TGT) to build the TGS_REP message to authenticate and get a key for the
HAN.

Regards,
Saber.

---

From: "Saber Zrelli" <[email-masked]>
Date: Wed, 31 Jan 2007 01:36:18 +0900 (JST)

Hi,

Regards,
Saber.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 12:13:39 -0500

Hi Saber,

Thank you for liking it ;)

Please see my comment below (including a comment to your another
email).

> get a TGT that can be used with HOS.

I think TGS_REQ with padata of PA-TGS-REQ can be used here, where
PA-TGS-REQ contains AP_REQ that carries HOC's TGT.  Or we can define
an integrity protection envelop for protecting TGS_REQ and TGS_REQ.

> I forgot about HOC-HOS SA.  I guess the HOC uses the
> pre-established HOC-HOS SA (which is some sort of TGT) to build the
> TGS_REP message to authenticate and get a key for the HAN.

Yes.  The pre-establishment can be dynamically done by bootstrapping
HOKEY re-key protocol from EAP.

> Do you mean EAP passthrough, or a specific protocol-proxy for the rekey

It should be a specific protocol-proxy for the rekey protocol since
EAP has a problem with peer-iniated messaging.

> However, I think that adding a new entity 'HOC' in the AP could be a

There is misunderstanding here.  The HOC is supposed to be a mobile
device, not an AP.

> If a new EAP method is specified for the re-auth I think that lower layer

(Note: s/re-auth/re-key/) There is no EAP in this re-key architecture
(no EAP peer, server and authenticator at all).  While it is possible
to use EAP method for re-key transport, EAP method transport is not
optimized as discussed in the past.  Since IEEE 802.11r is working on
modifying lower layer for fast transition, I don't think modification
to lower layer matters if it is really worthwhile.

> TGT for the visited realm without contacting its home KDC.

Thank you for the pointer.  I will read the draft.

> clients to the access network.

I agree, except for EAP-Kerberos method which I believe not necessary
in this architecture.  On the other hand, bootstrapping HOKEY re-key
protocol from EAP would be needed.

Best Regards,
Yoshihiro Ohba

---

From: "Saber Zrelli" <[email-masked]>
Date: Wed, 31 Jan 2007 03:12:25 +0900 (JST)

Hi Yoshihiro,

> HOKEY re-key protocol from EAP.

Thank you for clarifying this.

> EAP has a problem with peer-iniated messaging.

I am sorry if I am bringing back an already discussed issue maybe.
But I dont understand something. IMO, Kerberos is client initiated
protocol indeed, but "EAP-Kerberos" isn't necessarily. Please refer to the
following diagram describing the EAP-based rekeying process that I am
thinking about :

Client                      AP                       EAP srv            KDC

    EAP-Identity-request
<--------------------------

       EAP-Nak (preferred method = EAP-Kerberos)
-------------------------------------------------------->

       EAP-Request(Kerberos realm, AN-ID)
<--------------------------------------------------------

                 EAP-Response(TGS-REQ)
----------------------------------------------------------------------->

                 EAP-Request(TGS-REP)
<----------------------------------------------------------------------

That was phase I, AP acted as an EAP pass-through.

Phase II starts here :

------- EAP-Response(AP-REQ)  ------------------------->

<------ EAP-Response(AP-REP) --------------------------

* AP always acts as an EAP pass-through.
* The EAP server has all the keytabs associated with the ANs  (registered
as service principals in the KDC). It forwards TGS-REQ/AS-REQ messages but
processes AP-REQ messages.

> There is misunderstanding here.  The HOC is supposed to be a mobile

I meant HAN. This point is related the the discussion below though.

> (no EAP peer, server and authenticator at all).

Yes I understood that.

> While it is possible
> optimized as discussed in the past.

I have missed this discussion about "why EAP method transport is not
optimized", I probably need to read it before arguing here.

> Since IEEE 802.11r is working on

In that case, work should be done in collaboration with 802.11r I guess ?

> in this architecture.

It is not necessary indeed because your architecture could work perfectly
I thin. However, I am thinking that if we use an EAP-Kerberos method, then
the transition to Hokey architecture could be easier since no new elements
are needed, just a new EAP-Kerberos method (as described in the diagram
above) . But as I said, I need to read the  archive  :)

What do you think.

Best Regards,
Saber Zrelli.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 14:38:19 -0500

Saber,

Use of EAP as transport of re-key protocol in the proposed re-key
architecture is rather harmful because EAP keying architecture and the
proposed re-key architecture are totally different in key distribution
mechanisms.  EAP keying architecture relies on secure transport to
distribute keys from EAP server to authenticator.  The proposed re-key
architecture can work over non-secure transport, and there is no key
distribution from HOS to HAN.  I think this fundamental difference
should be well understood.  It is much better to totally forget about
EAP for re-key.

Please see further comment below.

> following diagram describing the EAP-based rekeying process that I am

I don't think Nak for Request/Identity is allowed.  Also, how can the
AP forward the Nak to the EAP server without receiving a
Response/Idenity?

>        EAP-Request(Kerberos realm, AN-ID)

What is AN-ID?

>                  EAP-Response(TGS-REQ)

This should read EAP-Request?

> processes AP-REQ messages.

I don't understand this.  There is no need for Step 2 exchange
(AP-REQ/AP-REP) to go to the EAP server.

> above) . But as I said, I need to read the  archive  :)

I believe that EAP keying does not fit the proposed re-key
architecture mostly from key distribution perspective.

Thanks,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 30 Jan 2007 12:55:02 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Tuesday, January 30, 2007 5:53 AM:

...
/WG Chair hat ON
> - No need to change EAP, EAP transport and AAA.

This is the IETF; such changes are possible here.

> transport.  This can be done via management frames such as Action

This is the IETF, not IEEE.  Such changes are NOT possible here.  If you
want to change every lower layer on the planet, good luck, but this is
not the place to do it.

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

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 30 Jan 2007 16:10:48 -0800 (PST)

Hi Yoshihiro,

  I'm a little confused about the roles. Are we not supposed to be
solving the problem of an authenticator getting a network access
credential for some mobile device it has not seen before? Is that
a HOKEY client?

  In my mind we have a mobile device speaking to a AAA server through
a HOKEY server. The HOKEY server is going to get the EMSK from the
AAA server and use that to distribute new network access credentials
to various authenticators (among other things).

  Before we get bogged down in specifics-- kerberos or kerberos-like--
we should discuss what we need and then how we know if we're there or not.
We need to protect the distribution of those credentials and some goals
for that are:

  1. confidentiality -- the keys must be encrypted when sent from
     the HOKEY server to the new authenticator.
  2. integrity protection -- it must be possible to detect tampering
     of a network access credential.
  3. source authentication -- the recipient of a network access credential
     must be able to prove who it came from.
  4. validation of authorization -- the scope of the network access
     credential must be distributed as part of the credential and must
     be protected to the same degree as the credential itself.
  5. credential is not distributed, or cannot be used, without the consent
     of the client.
  6. identities of the 3 parties involved are confirmed by all 3 parties.

The solution also must not suffer from the "misplaced trust in server"
flaw that results in the "Lying NAS" problem we have today. I agree that
the security of this key distribution scheme must not depend on the
security of the transport on which it is made.

  Furthermore, I think it should be possible to have both a push (server
initiated) and pull (client initiated) model, where the HOKEY server can
proactively send out credentials to authenticators or where the client
instructs the HOKEY server to send a credential out to a specific
authenticator, respectively.

  regards,

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 19:59:46 -0500

Hi Dan,

> credential for some mobile device it has not seen before? Is that

Mobile device is HOKEY client.  HOKEY access node needs to see the
HOKEY client to have a network access credential to be used for the
the HOKEY client.

> to various authenticators (among other things).

Depending on key distribution model, AAA may not be used for
installing a re-key key to the HOKEY server.  On the other hand, HOKEY
server may need to talk to a AAA server for authorization.

>   6. identities of the 3 parties involved are confirmed by all 3 parties.

I fully agree with you that we need to agree on goals like listed
above before discussing solutions in details.

> security of the transport on which it is made.

Agreed.

> authenticator, respectively.

There is no need for key distribution (push or pull) from HOKEY Server
to HOKEY Access Node in the proposed re-key architecture.

Thanks,
Yoshihiro Ohba

---

From: "Saber Zrelli" <[email-masked]>
Date: Wed, 31 Jan 2007 15:34:56 +0900 (JST)

Hi Yoshihiro,

Thank you for your comments,
please see my answers below.

On Wed, January 31, 2007 4:38 am, Yoshihiro Ohba wrote:
> distribution from HOS to HAN.

IMHO the key distribution from HOS to HAN is not an issue since
the secure transport of keys from HOS to HAN is already deployed and
widely used, (precisely, it corresponds to the transport of key over AAA
protocol from EAP server to AN). A re-key over EAP protocol could build
upon that.

>> Client                      AP                       EAP srv
>> KDC

I agree, (BTW, I don't understand why RFC 3748 says that Nak can only be
sent as a Response for Requests of type > 4.)

But the point is that the AP and the peer can negotiate the use of
EAP-rekey even if rekey protocol is peer-initiated: The AP and peer can
perform identity exchange then AP may send an EAP-Request of a certain
type > 4. at that moment the peer sends a Nak to say that it does not want
authenticate but rather rekey.

Then the Nak can be forwarded to the EAP server and the EAP server then
issues an EAP-re-key request to initiate the re-keying procedure.

> What is AN-ID?

ID of Access Node/NAS

> This should read EAP-Request?

Yes.

> (AP-REQ/AP-REP) to go to the EAP server.

In that case, we assume that the AP can handle AP-REQ messages.
Which mean adding a new re-key function in the AP.

The AP-REQ may be processed by the local EAP-Server which is a hop away
from the AP. This avoids changing and the AP and putting keys on the AP.

> architecture mostly from key distribution perspective.

I agree that the EAP keying does not exactly fit with your _proposed_
re-key architecture, it is rather inspired by it.

What you proposed is a plain third-party based re-key protocol.
for creating a new SA between the HOC and the HAN based on the SA between
the HOC and the HAS. I agree on the "third-party based re-key protocol",
but I don't agree with L2 changes and new element on the AP since IMHO it
can be avoided. When using EAP as an underlying protocol with your
proposed architecture we can have two benefits  :

    1- Move the HAN function to a central server (the EAP server)
    2- Avoid L2 changes

Best Regards,
Saber.