Subject: [HOKEY] review of draft-ietf-hokey-key-mgm

From: Charles Clancy <[email-masked]>
Date: Mon, 23 Jul 2007 02:42:39 -0400

Madjid,

(issues 24-31 created)

I think the key-mgm document is a good start.  Certainly it will need a 
lot more work.  Below are some of the major technical nits.  I've 
captured them as issues in the issue tracker.

issue24: I think editorially, it will need to be pared down to be a lot 
more succinct, so I'm not going to go through editorial nits.  I think 
much of the document is overjustified in explanation, and it should 
focus more on the protocol than the design decisions.

Section 1:

issue25: Figure 1 will likely need to be updated to reflect the adopted 
EMSK hierarchy.

issue26: I'm not sure why we need to reference the HRK and DSHRK.  These 
keys are simply specific instantiations of the USRK and DSUSRK.  I 
assume these will just be used as an example service throughout?  It 
might be good to move that into an appendix or some non-normative 
section, as the ERX document will specify how HOKEY instantiates the 
protocol described within this document.

Section 4.1:

issue27: We need a formal protocol description, to include formatting, 
ASCII-art packet diagrams, etc.  Sure, we're independent of transport, 
but we need to define a blob that can be transported.

issue28: We can't assume that "SA2" is secured with an actual key (i.e. 
Kts).  In the proxied AAA environment, this certainly is not true. 
Consequently, the encryption in message 3, {.}KCts, MUST be optional. 
We must allow for a mode where the underlying transport is providing the 
necessary security.  Sure, affects some of the overall security 
properties, but is necessary for deployability.  It needs to be fully 
documented in the security considerations section.

Section 4.3.1:

issue29: We should not discuss keys derived from the DSUSRK.  The DSUSRK 
is a terminal key, handed off to a different protocol, and we have no 
control over its hierarchy.

issue30: What are "KX" and "KY"?  Should these be DSUSRK_X and DSUSRK_Y? 
  I think we need further description/protocol that describe how the DCK 
and DIK are used to protect the delivery of the DSUSRK from the DSRK. 
Perhaps a forward freference to section 5.4, or consolidation of the two 
sections?

Section 5.1:

issue 31: I don't think we should have this section.  This should be 
covered in the ERX document.

Section 5.2:

issue 28b: As in section 4.1, the encryption {.}KCds needs to be 
optional in order to allow underlying transport protocols to handle the 
transport security, and allow feasible deployment in AAA environments.

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

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