RE: RADEXT WG re-charter

["David B. Nelson" <dnelson@elbrysnetworks.com>]

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.

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.

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