Subject: Re: [HOKEY] Charles' hokey plan

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 01 May 2007 18:54:04 -0400

Thank you for the writing up.  I basically support the plan.

I have several comments:

- I think that HRK may also be derived from USRK in some case where DSRK is
not used, right?

- Regarding "KeyTransport(K) = K or ENC(K)", I think we need more
discussion why we need to allow unencrypted key delivery in the
3-party key distribution protocol.  Allowing an option for relying on
transport security may not be a good idea for a key distribution
protocol.

- What happens if the "new" EAP-Success gets lost?

Regards,
Yoshihiro Ohba

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: Charles Clancy <[email-masked]>
Date: Tue, 01 May 2007 19:01:46 -0400

> Thank you for the writing up.  I basically support the plan.

Good to hear!

> - I think that HRK may also be derived from USRK in some case where DSRK is

This had been discussed, but I don't think there was any decision made. 
  If we allow multiple derivation trees, we have to advertise to the 
client which tree it should use before it attempts a reauth.  Personally 
I think we should stick with the DSUSRK, and allow the home EAP server 
not distribute the DSRK if its security policy dictates that behavior.

> transport security may not be a good idea for a key distribution

Theoretically I'd agree with your statement, but if HOKEY can't rely on 
AAA security, it can't be scalable.

> - What happens if the "new" EAP-Success gets lost?

Someone proposed ACKing it with a regular EAP-Success.  The protocol 
retransmission semantics still need to be sorted out.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 02 May 2007 11:00:33 -0400

Hi Charles,

> not distribute the DSRK if its security policy dictates that behavior.

If we have agreed on keep USRK as a child key of EMSK, I don't see a
point of always sticking with the DSUSRK.  This is not just an HRK
issue, this relates to other types of usages as well.

Also, I don't see a problem with advertisement of derivation trees,
because in general a mechanism would be needed to advertise what types
of keys are supported by EAP server.

> AAA security, it can't be scalable.

If scalability is the issue, it is possible to define a 3-party key
distribution protocol to scale in the same way as AAA security without
relying on AAA security.  So I still have a reservation here.

> retransmission semantics still need to be sorted out.

Agreed.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 02 May 2007 17:24:00 +0200

Hi Charles,

I also basically agree with the proposed plan. I have some 
questions/comments though (mainly for clarification). See inline.

<snip>
>    The IDbind(.) blob is a basic channel binding blob that binds three
>    identities together with a nonce using a secret key.  Using this
>    building block, the protocol would look like:
>   
Rafa: As a comment, I think this protocol does not meet a 3-party 
protocol approach unless I'm
missing something. For example, KH-USRK(B) doesn't provide any freshness 
information
(such as a NonceB) 
>    1.  peer -> KH-USRK: IDbind(peer, EAP Server, KH-USRK, NonceA, IK)
>    2.  KH-USRK -> EAP Server: IDbind(peer, EAP Server, KH-USRK, NonceA,
>        IK)
>    3.  EAP Server -> KH-USRK: IDbind(peer, EAP Server, KH-USRK,
>        NonceA+1, IK), KeyTransport(USRK)
>    4.  KH-USRK -> peer: IDbind(peer, EAP Server, KH-USRK, NonceA+1, IK)
>
>   
<snip>

>    Currently only EAP-ER formally specifies a protocol for delivering
>    the HRK to the HOKEY server.  Consequently section 6.2 of the EAP-ER
>    document [I-D.vidya-eap-er] will serve as a starting point for
>    development of this protocol.  It shall be generalized to work for an
>    arbitrary USRK or DSUSRK, and also define the IK and DSIK in terms of
>    the KDF specified by [I-D.ietf-hokey-emsk-hierarchy].
>   
Rafa: I'm not sure why we have to use an EAP transport-based protocol to
achieve this step. Basically a protocol over IP can also solve the problem.

<snip>

>    The "new" EAP-Success could include native support for protected
>    results indication.
>   
Rafa: What do you mean by "native support"? a signed new EAP success? If 
the key distribution protocol
is independent of the underlying transport I think the new EAP success 
doesn't need to be protected itself
as long as the new EAP success transports protected information. And 
that information is part of the secure
3-party key distribution protocol.

Best Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 02 May 2007 12:42:15 -0700

Hi Charles,

I thank you as well for writing this up. I will send a separate email later.

For now, I (almost) second Yoshi's first point. HRK may itself be the USRK
that comes out of the EAP server. We may opt to drive Domain HRKs from top
level HRK instead of HRK from DSRK. May be I am not understanding the
picture correctly.

I understand that Key transport may be simply handing K instead of ENC(K),
since I envision a very likely case where the server handling HOKEY service
is the same AAA server that implements EAP server and thus the key delivery
may not need a full blown 3 party delivery.
On the other hand, I see the per-authenticator key being generated from HRK
and its children, and this effects the description of key delivery for
DSUSRK.

Regards,

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, May 01, 2007 3:54 PM
To: Charles Clancy; Glen Zorn (gwz)
Cc: [email-masked]
Subject: Re: [HOKEY] Charles' hokey plan

I have several comments:

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 03 May 2007 07:53:51 -0400

> may not need a full blown 3 party delivery.

I think this specific case of co-located HOKEY/AAA/EAP server does not
jusify to make ENC(K) optional, because an implementation can use
whatever key management API used within the same server device and
bypass standard KeyTransport(K) anyways.  We don't need to care the
co-located server scenario to define KeyTransport(K) function.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 03 May 2007 07:47:08 -0700

If you have a spec that says ENC(K) is a MUST, would that implementation be
compliant? 

It is easy to say that if the receiver and the sender are collocated, e.g.
within the same trusted platform, encryption is optional. Otherwise it is a
MUST.

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, May 03, 2007 4:54 AM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; 'Charles Clancy'; 'Glen Zorn (gwz)'; [email-masked]
Subject: Re: [HOKEY] Charles' hokey plan

Yoshihiro Ohba