RE: RADEXT WG re-charter

["Joseph Salowey (jsalowey)" <[e-mail]>]

This is not a requirement for all deployments. If it is a requirement
then transport security presents a challenge, but it seems you could
encrypt the attributes that need to be separated, such as keys, with an
appropriate algorithm, such as SIV or the ever unpopular AES keywrap,
and then encapsulate the whole message including the encrypted
attributes with DTLS, IPSEC, etc. to protect additional attributes in
transit.  

So, I don't view these mechanisms as mutually exclusive. 

> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]] 
> Sent: Friday, April 18, 2008 10:39 AM
> To: Joseph Salowey (jsalowey)
> Cc: David B. Nelson; [e-mail]; Glen Zorn; 
> [e-mail]
> Subject: RE: RADEXT WG re-charter
> 
> 
>   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/>