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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Dan Harkins <> allegedly scribbled on Wednesday, August 01, 2007 11:04
AM:

>   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
> example:   
> 
>   - 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. 

Fine.

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