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

["Dan Harkins" <dharkins@lounge.org>]

  Hi Glen,

On Wed, August 1, 2007 12:51 pm, Glen Zorn (gwz) wrote:
> 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.

  It makes sense if you think about it in terms of crypto-agility.
If you're submitting a draft that only does AES Key wrap with no
capability to substitute anything else then you can mandate other
attributes that may be necessary. This isn't crypto-agile though.

  The subject of this thread concerns the crypto-agility requirement and
to be crypto-agile it doesn't make sense to mandate use of attributes that
are only necessary if you're using one particular enc-type. The whole
idea is that we're going to be plugging in other enc-types, no?

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

  That would work I think. My comment was not very good because my real
concern is the dependency on having a Mac-Randomizer if you have a
Keying-Material attribute. The dependency may be happenstance but
according to the draft if you have the Keying-Material attribute then you
MUST also have a Mac-Randomizer. If that dependency was not there then
I don't think I'd care so much.

  (Unrelated to crypto-agility, but an informative note on the point
behind the Mac-Randomizer-- replay? some esoteric security property?--
would be most helpful and some text in the Security Considerations
regarding the implications on reuse of this "random" number in different
messages would be very important).

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

  Actually no they're not but I was trying to be generous since it is
claimed that there are implementations using this already. But you're
right. Get rid of the whole key id stuff. That is certainly acceptable.
You're only recommending the creation of 2 new keys to implement this
draft so key id fields are, strictly speaking, unnecessary.

  Dan.




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