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