RE: RADEXT WG re-charter

["Dan Harkins" <[e-mail]>]

  Hi Joe,

  Pardon me for leaping so far back in this thread.

  Is it a requirement to support multiple pieces of data encrypted with
different keys in the same message? If it is then apparently both DTLS
and IPsec are out-of-the-running since both those options secure the
entire payload with one set of keys. Is this your view?

  regards,

  Dan.

On Tue, April 15, 2008 1:07 pm, Joseph Salowey (jsalowey) wrote:
> There are a few reasons why you would want to wrap keys separately from
> other data.  As you mentioned, the recommended algorithms for key wrap
> may not be suitable for encrypting bulk data without special
> consideration and some bulk data encryption algorithms may not be
> recommended for key wrap without special consideration.  Another reason
> is that you may want the entity that handles the keys and their context
> to be different from the entity that handles the rest of the attributes.
>
>
> Neither of these reasons forces you to have encryption tied directly to
> the key attribute.  It is convenient since one is very often interested
> in encrypting keys, but you can achieve the same thing with a generic
> encryption attribute if you take care.  You need to support multiple
> pieces of data encrypted with different keys (key IDs, alg IDs, message
> boundaries, etc.) in the same message and you need to make sure that the
> various supported encryption algorithms are used correctly (type of
> cleartext, sufficient randomization, integrity protection, etc.).  These
> things don't necessarily happen automatically or come for free.
>
> If you don't consider keys as part of the data you are wrapping for
> crypto agility, I'm not sure you will end up with a result that is very
> useful.
>
> Joe
>> -----Original Message-----
>> From: David B. Nelson [mailto:[e-mail]]
>> Sent: Monday, April 14, 2008 10:29 AM
>> To: [e-mail]; 'Glen Zorn'
>> Cc: Joseph Salowey (jsalowey); [e-mail]
>> Subject: RE: RADEXT WG re-charter
>>
>> Glen Zorn writes...
>>
>> > 'Frankly, my dear, I don't give a damn.'
>>
>> Cute...
>>
>> > It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt
>> > was posted ... for at least 3 years there have been at 2 (or more)
>> > independent, interoperable implementations that were FIPS-certified.
>>
>> Given that there are implementations of this key-wrap scheme,
>> presumably using VSAs, it might be well to publish an
>> Information RFC, describing the actual implementations, using
>> those VSAs.
>>
>> > But wait!  Let's spend a little (lot) more time conjecturing about
>> > another way, a way to solve "the general problem" (AKA "boiling the
>> > ocean" if it's a proposal we don't care for).  Well, gosh,
>> no thanks,
>> > but you guys go ahead & have fun!
>>
>> RADEXT has a chartered work item to address crypto-agility.
>> We have requirements for this wok, and we now have an ID
>> capturing those requirements.  We don't have a requirement to
>> specifically address key-wrap, as a separate problem.  My
>> questions is whether RADEXT really needs to create two drafts
>> to satisfy the crypto-agility work item, one for key-wrap and
>> one for general purpose encrypted attributes.  The fact that
>> solutions, and drafts, exist to address key-wrap and
>> encrypted attributes separately is a point in favor of
>> retaining the separation.  I'm just questioning whether
>> that's a sufficient basis on which to decide that we need
>> such separation of concerns.
>>
>> If the consensus us of the WG is that we should proceed with
>> separate documents for key-wrap and general crypto-agility,
>> we can propose doing that in our revised charter.  It would
>> be nice, however, to have a reason beyond the existence of (4
>> year old) drafts that are structured that way.
>>
>>
>>
>
> --
> to unsubscribe send a message to [e-mail] 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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>