[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
Dan Harkins <> allegedly scribbled on Wednesday, August 01, 2007 11:04
> Hi Joe,
> As I mentioned at the mic during the meeting at IETF69
> draft-zorn-radius-keywrap is not really very (crypto-)agile and I
> think with some minor modifications could be made more so. For
> - do not require that Message-Authentication-Code MUST be present
> if Keying-Material is present. SIV is a much preferrable key
> wrapping technique than RFC3394 and if SIV was specified in the
> enc-type of Keying-Material then Message-Authentication-Code would
> be redundant. Please say that if enc-type is RFC3394 then
> Message-Authentication-Code MUST also be present. Other enc-types
> can mandate it or not as needed.
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.
> - do not require Mac-Randomizer if Message-Authentication-Code is
> present. The reason a deterministic authenticated encryption
> scheme like RFC3394 can provide what amounts to probabilistic
> authenticated encryption is because what it's wrapping is,
> itself, random. The further addition of randomness is unnecessary.
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 IV is not necessary. Key wrapping (RFC3394 or even SIV in its
> key wrapping varient) is deterministic. RFC3394 has a default IV
> which is used to determine whether the unwrapping was successful
> or not but that does not need to be communicated.
> draft-zorn-radius-keywrap even says that if RFC3394 is being used
> as the enc-type then the IV MUST be A6A6A6A6A6A6A6A6. That serves
> no useful purpose.
> - 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?
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.