[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap



Since AES Key Wrap is the only one specified & SIV doesn't actually
exist as a standard, this doesn't make much sense to me.

Since the proposal supports negotiation, SIV could be supported in the future, once it is specified.

Actually, this is largely irrelevant: the purpose of the Mac-Randomizer
is to facillitate the use of the Message-Authentication-Code in
accounting & CoA messages.  It is actually independent of the
Keying-Material attribute.  I suppose that we could further specify it
as only required if the Message-Authenticator-Attribute is used in one
of those messages...

The Mac-Randomizer is designed to prevent against replay where RADIUS doesn't provide that protection, correct?

>   - not everyone is comfortable with massive covert channels like KEK
>     ID and KM ID. I suggest making them optional and using a bit it
>     the reserved field to indicate their presense or absense.

So having optional "massive covert channels" is somehow better?  Why?

I'm not clear why the KEK ID or KM ID is a covert channel any more than the IPsec SPI is a covert channel in the case where manual keying is used.

However, two other questions come to mind:

1. As I understood it, the need for an explicit RADIUS shared secret name arises from the potential for key rollover and dynamic key management. Given the use of AES as the algorithm, is rollover support really necessary? Also, is there really a need for dynamic key management? If not, could we get by with the RADIUS shared secret key naming scheme (using the IP addresses of the client and server as the key name)?

2. There is also the question of compatibility with the keying naming scheme in the EAP Key Management Framework document as well as in the RADIUS ERX proposal. Couldn't we just wrap the MSK and send the MSK key name separately as specified in RFC 4072?



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