Subject: [Gen-art] draft-ietf-hokey-emsk-hierarchy-04.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Mar 2008 16:47:27 -0400

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: Specification for the Derivation of Root Keys from an Extended 
Master Session Key (EMSK)
Reviewer: Joel M. Halpern	
Review Date: 17-March-2008
IETF LC End Date: 17-March-2008?
IESG Telechat date: N/A

Summary: This document appears ready for publication.

Comments:
	While there has been much discussion on the IETF list of the references 
to "applications" in this document, I have chosen not to comment on 
that.  It seems to me that the relevant statement is that specific 
usages are out of scope for this document.
	The one thing that bothers me a little is the intended status of this 
document.  Given that the EMSK is entirely inside a system, and that 
therefore the actual generation process is internal to that system, I am 
not sure that a registry tied to the specifics of the generation 
mechanism, is appropriate.  A lot of this document is of the form "if 
you don't define it some other way, do this."  While very useful text, 
it actually doesn't seem to affect on-the-wire interoperability.  So I 
wonder if this whole document is more informational than "proposed 
standard?"  I'm not sure on this, but the containment property did 
strike me reading the document.

Minor:
    While I would guess that the usage is actually the normal usage, the 
definitions of Usage Specific Root Key, Domain Specific Root Key and Key 
Management Domain are somewhat confusing for the outside reader. 
Specifically, the Key Management Domain is defined as being the scope of 
a given root key.  This leads the reader to conclude that any root key 
is inherently domain specific, because it defines a domain.  So how can 
one have a special kind of "Domain Specific Root Key" that is 
"restricted to use in a specific key management domain."  At a guess it 
is the difference between a domain defined by the key and a key defined 
to fit an existing domain.  But I hate guessing when it comes to RFCs. 
Given that the document later defines the domain for DSRK in terms of 
domain names, "adding "separately defined" or even "defined by a domain 
name" to the DSRK definition would address this.

    The last of the requirements (about separation of domain keys and 
usage keys and avoiding label collision) requires material later in the 
document in order to be understood.  A forward reference would be a good 
idea, indicating where the domain name and usage key label are described.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 17 Mar 2008 14:28:25 -0700

Hi Joel,

Many thanks for your review.  Some notes inline:

I am a bit under the weather, and so if I am incoherent, please feel 
free to say so.  Thanks.

On 3/17/2008 1:47 PM, Joel M. Halpern wrote:
>     While there has been much discussion on the IETF list of the 
> references to "applications" in this document, I have chosen not to 
> comment on that.  It seems to me that the relevant statement is that 
> specific usages are out of scope for this document.
>     The one thing that bothers me a little is the intended status of 
> this document.  Given that the EMSK is entirely inside a system, and 
> that therefore the actual generation process is internal to that system, 
> I am not sure that a registry tied to the specifics of the generation 

The peer and the server need to arrive at the same derivations.  The 
keynames derived as specified in this document would be used in 
protocols specified elsewhere to refer to the keys derived independently 
at both ends.  So, whereas there are no "on the wire" packet formats in 
this document, other documents will put information derived as specified 
in this document in their packets.

> idea, indicating where the domain name and usage key label are described.
It looks like some clarification is in order in the text.

regards,
Lakshminath

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Mar 2008 21:47:50 -0400

Thank you.  Comment following your clarification.
Joel

Lakshminath Dondeti wrote:
...
>> that therefore the actual generation process is internal to that 
>> system, I am not sure that a registry tied to the specifics of the 
>> generation mechanism, is appropriate.  A lot of this document is of 
>> the form "if you don't define it some other way, do this."  While very 
>> useful text, it actually doesn't seem to affect on-the-wire 
>> interoperability.  So I wonder if this whole document is more 
>> informational than "proposed standard?"  I'm not sure on this, but the 
>> containment property did strike me reading the document.
> 

That does make for a good reason for PS.   I am however then confused by 
the description that the EMSK never leaves the server.  I presume that 
this relates to other aspects of EAP that I am not familiar with.  You 
may want to see if there is a way to phrase it that makes it a bit 
clearer.  But given what you say, this is another minor issue, not a big 
deal.
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 17 Mar 2008 21:35:39 -0700

Thanks Joel.  Followup notes inline:

On 3/17/2008 6:47 PM, Joel M. Halpern wrote:
>>> the form "if you don't define it some other way, do this."  While 
>>> very useful text, it actually doesn't seem to affect on-the-wire 
>>> informational than "proposed standard?"  I'm not sure on this, but 
>>> the containment property did strike me reading the document.
>>
>> protocols specified elsewhere to refer to the keys derived 
>> independently at both ends.  So, whereas there are no "on the wire" 
>> packet formats in this document, other documents will put information 
>> derived as specified in this document in their packets.
> 
The note about EMSK never leaving the server is contextual; the other 
master session key, the MSK is sent to the authenticator (and thus 
"leaves" the server).  We'll make a note of this as well for clarification.

So, on balance, we have two clarifications make: one on domains (that 
came up elsewhere too, so we'll work on the text once again -- we did 
that during WG discussions) and another on EMSK being held at the server.

regards,
Lakshminath