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

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

  Hi Glen,

  That's very interesting. The App ID field only defines an EAP-MSK.
I can see how a KEK ID could indicate what key was used to encrypt
this EAP-MSK if the client and server had more than one KEK. I don't see
a point in having more than one KEK and since your draft only adds one
key to be used as a KEK (the other key it adds is for integrity
protection) the KEK ID seems extranneous. But KEK ID aside, having
multiple KM IDs would imply that there are more than one EAP-MSK being
disclosed in a single message. What EAP methods produce more than one
MSK that would require having different KM IDs but the same App ID in a
single message?

  Dan.

On Wed, August 1, 2007 3:09 pm, Glen Zorn (gwz) wrote:
> David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
> 2:56 PM:
>
> ...
>
>>> ...the first thing _I_ think should be done is to modify the
>>> attributes to align with the attribute extension work...
>>
>> What properties of the extended attribute format are particularly
>> attractive for the crypto-agility work?
>
> Attribute grouping.  The reason why the various key IDs, etc. are all
> part of the Keying-Material attribute is because they need to be
> associated w/a specific key (it's possible to deliver more than one key
> in a single message).  Attribute grouping enables that association w/out
> requiring the multiple sub-attribute technique that we use.
>
> --
> 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/>
>



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