RE: comments on draft-zorn-radius-keywrap-12.txt

["Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>]

Hi Dan,

Comments inline.

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Dan Harkins
> Sent: Monday, January 22, 2007 4:45 PM
> To: radiusext@ops.ietf.org
> Subject: comments on draft-zorn-radius-keywrap-12.txt
> 
> 
>   Hi,
> 
>   I recently read draft-zorn-radius-keywrap-12.txt and have a few 
> comments. I hope they can be addressed before this draft is advanced 
> to RFC.
> 
>   general:
>     * there is a real lack of requirements in this draft. Most things
>       are MAY and it looks like a compliant implementation could do
>       almost nothing, which seems odd for an RFC. Furthermore
>       interoperability will be extremely difficult since little 
> behavior
>       MUST be followed. Ironically. one of the rare MUSTs in the draft
>       really should be a SHOULD.

[Joe] There are interoperable implementations of this specification
between different vendors, however the specification could probably be
improved for clarity. 
 
>   section 3.1:
>     * the Key ID, lifetime, IV and Key material fields MAY be omitted
>       but then the length of the keying material attribute would not
>       be >= 24 as defined later on when the layout of the attribute is
>       defined. I suggest changing the length to be >= 8 and specify 
> that
>       if any of these attributes are omitted then they MUST all be 
> omitted
>       otherwise someone could legitimately omit one field and include
>       another and it would be impossible to parse the attribute on 
> receipt.

[Joe] I agree. 


>     * "if the client requires the use of the Keying-Material 
> Attribute"
>       but it's not present then it "MAY ignore the message"? 
> This should
>       be MUST or else "require" doesn't mean what I believe most 
> people
>       think it means.
> 
[Joe] This seems reasonable to me. 


>     * KEK ID, KM ID are both unspecified. They are supposed to 
> identify
>       the key but how? If the Frobnitz corporation defines the ID to 
> be
>       sha("the KEK ID") and the Fubar corporation defines it as the
>       string "this is your KEK ID!" (both 20 bytes) then how do they
>       interoperate? 20 bytes? Why won't 4 do? Or even 2? Does this 
> have
>       something to do with hashing to produce an ID? It's not 
> specified.
> 
>       Having unspecified things and then say "Further specification of

> the
>       content of this field is outside the scope of this document" 
> means
>       that specification in its entirety is outside the scope of this
>       document. That being the case then why is this even part of an 
> IETF
>       document? These fields should be removed before the document is
>       advanced.
> 
>       The KEK ID and KM ID, being entirely unspecified, are gigantic
>       subliminal channels. I really don't think that's appropriate.
> 
[Joe] I disagree here.  The KEK ID is an opaque octet string to identify
the key that is being used to encrypt the key.  This document does not
specify a way to establish a key and the KEK ID is there to facilitate
different forms of key management.  In particular the attributes are
designed not to require additional state on the RADIUS server so the use
of a KEK ID allows a new key to be brought into use.  The KEK ID is
necessary unless a particular key management scheme is specified that
does not require it.  

The KM ID serves to identify they key that is being transported.  This
definition of this is specified by the application for which the key is
to be used.  Incorporating this identity in the attribute reduces the
need to have separate attributes for key ID which would be difficult to
disambiguate if there are multiple attributes keys in the packet. The
draft should specify that for a the EAP-MSK application this field is
not used since there already is an attribute defined to hold the EAP-MSK
ID.   


>     * if the Enc Type field is 0 then "the IV field MUST be as 
> specified
>       in RFC3394". Is it supposed to be the "default IV"? If so then 
> why
>       even bother sending it in the attribute? It would be painful to
>       make the attribute variable length-- i.e. if Enc Type field is 0
>       then there is no IV field-- so why not change this MUST to a 
> SHOULD?
>       Also, there may be legitimate reasons to use a different IV than

> the
>       default one listed in RFC3394 (which is why that RFC allows it).
> 

[Joe] Apparently there are many different opinions on whether they IV
MUST be the default specified in RFC 3394.  Originally we meant it to be
variable with the default suggested, however during expert review it was
strongly suggested by an expert that it MUST be the default IV.  


>   section 3.3:
>     * MAC Key ID, same comments apply here as with KEK ID and KM ID 
> above.
>
[Joe] Same comment as the KEK ID above.
 
>   section 5:
>     * If two new keys are being defined then there is no point in 
> having 3
>       ID fields to identify them. They are implicitly identified here.

> One
>       key is for key wrapping and the other key is used for integrity
>       checking. Again, there is no need for a KEK ID, KM ID, or MAC 
> Key ID.
> 
[Joe] there are 3 keys the key used for MAC, the key used for key
encryption and the key being encrypted.  All are currently identified as
they are different keys.  As for the KEK and MAC keys it is possible for
them to be derived from the same key or key exchange.  If a key
management mechanism is decided upon perhaps one of these fields may be
deprecated.  However, the freedom to be able to have these keys vary can
facilitate different deployment models that are not possible with RADIUS
today.  


>     * I think these two new keys MUST be cryptographically independent

> of
>       the RADIUS shared secret (not SHOULD). The RADIUS shared secret
>       already has a defined use and it's not as a key deriving key. 
> There
>       is no valid reason in any particular circumstance to ignore this
>       particular item (to paraphrase RFC2119).
> 
[Joe] We had some discussion of this among the authors.  In general we
all agreed that these keys SHOULD be independent of the RADIUS shared
secret.  We stopped short of mandating this because several felt that
these new attributes provided a significant advantage over the current
RADIUS mechanisms even if the current shared secret is used to
facilitate deployment.  Ideally we would be able to specify a key
management mechanism that would allow for automated key exchange.  

>   I think it's great to have an RFC3394-style way to send keys from a 
> RADIUS server to a RADIUS client but this seems to go way beyond that 
> simple task. And there isn't any real apparent justification for those

> excesses. KEK ID, KM ID, MAC Key ID... please just get rid of them. If

> someone wants to pass VSAs then they should just pass VSAs.
> 
>   thanks,
> 
>   Dan.
> 
> 
> 
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>