[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RADEXT WG re-charter



owner-radiusext@ops.ietf.org <> scribbled on Saturday, April 12, 2008
5:58 AM:

> Joseph Salowey writes...
> 
>> With respect to the key transport item, I don't recall this
>> discussion on the HOKEY list. I might have missed it.  In any case I
>> don't think this is the right approach.  Key transport is a general
>> problem that can be solved with a general solution.
> 
> The discussion in the HOKEY session at IETF-71, as I recall
> it, centered around whether HOKEY ought to define a
> non-protected RADIUS (Diameter) attribute for key transport (I
> called this a key container attribute) that could utilize
> various options for protection, one of which might be a
> generalized Encrypted Attribute format, as described in a RADEXT
> Crypto-Agility draft. 

There was indeed discussion, but mostly in the form of various
assertions by the radext Chairs that this would be a good idea; I don't
recall anything like consensus around this topic.  

> 
> Follow up discussion in the RADEXT WG session included the
> issue of whether or not the cryptographic requirements for key
> wrap (key transport) were sufficiently different from the
> cryptographic requirements for transport of bulk data that a
> separate protection mechanism needed to be defined.
> 
> We leaned that special purpose key wrap mechanisms could be
> "simpler" in some cryptographic sense because one can rely on
> the property of keys that their content is highly random.  The
> question that I think was never satisfactorily answered is why
> one would need to deploy special purpose key wrap mechanisms
> in addition to general propose attribute encryption mechanisms.

I guess, then, that "gaining FIPS certification" is an unsatisfactory
answer, since that was the one I (among others) gave.  So what would be
a satisfactory answer?

> 
> Having said that, it is true that the RADIUS community has
> existing "special purpose" key wrap attributes (the MSPPE key
> attributes) that do not meet the crypto-agility requirements.
> We need to decide what to do about these.

Can you say "deprecate"? :-)

> They are widely deployed today, e.g. in 802.11.
> 
> 
> 
> --
> 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/>