RE: RADEXT WG re-charter

["Joseph Salowey (jsalowey)" <jsalowey@cisco.com>]

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:dnelson@elbrysnetworks.com] 
> Sent: Monday, April 14, 2008 10:29 AM
> To: radiusext@ops.ietf.org; 'Glen Zorn'
> Cc: Joseph Salowey (jsalowey); Bernard_Aboba@hotmail.com
> 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>