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

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

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Thursday, April 19, 2007 5:12 PM
> To: dharkins@lounge.org; radiusext@ops.ietf.org
> Subject: RE: comments on draft-zorn-radius-keywrap-12.txt
> 
> >[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 the existing implementations, what forms of key management 
> are used to establish the KEK ID?
> Is there a specification for the key management mechanisms?
> 
[Joe] Currently it is done by manual keying, which is less than ideal.

> >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.
> 
> RADIUS as it exists today does not require a KEK ID because 
> it impliictly assumes that there is only one key used between 
> a RADIUS client and server at a time and that this key is 
> identified by the client and server IP 
> addresses.   At IETF 68, Key Rollover was given as the 
> primary reason why 
> more than one key might be valid at a given time, so that 
> some other key identifier might be needed.  Assuming that 
> credible ciphers (e.g. AES) are used, why should key rollover 
> represent a problem?
> 

[Joe] yes, the primary reason to have a key ID is so you can change
keys.  Credible ciphers are not the problem.  People may wish to change
keys for administrative reasons (change of personnel etc.).  In addition
if an automated key management is performed "out-of-band" then you may
need to identify a specific key from several generated keys. Regardless
of whether it is cryptographically necessary or not a key lifetime is
often defined for management purposes, when the life time expires the
key needs to be replaced. 


> >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.  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.
> 
> So you are saying that this specification is designed to 
> enable future RADIUS key managment applications, rather than 
> the existing ones?
> 

[Joe] No, the specification supports existing RADIUS key management
applications as well as enables future one.  

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

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