[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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?
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?
--
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/>