RADIUS Keywrap (was RE: RADEXT Milestone revisions)

["Nelson, David" <dnelson@enterasys.com>]

Glen Zorn writes...
 
> Just humor a moron a bit longer: how do you expect to "address
modularity
> of cipher suites" in RADIUS w/o modifying (at the very least the
> processing of) the RADIUS headers?

At a very simplistic level, adding new attributes is OK; changing the
headers or PDU format is not.  There are other things that are out of
scope, of course, such as new commands.

> Neither do I.  Are you saying now that key management _is_ in scope of
the
> radext charter?

No. I think that the definition new key management protocol(s) for use
between RADIUS entities (clients, servers, proxies) is out of scope for
RADEXT.  I would not suggest that RADEXT invent its own key management
protocol, in any event.  I'm quite certain our friends in the Security
Area would frown upon any such effort.  Surely there are existing RFCs
for such protocols that could have been referenced.  What would satisfy
my concerns would be a reference to existing key agreement protocols.  I
would like to see statement similar to: "Agreement of the KEK among
RADIUS entities is not specified in this document.  The following
existing key agreement protocols are potentially suitable for this use:
<insert list here>.  To obtain global interoperability, the following
method <insert protocol here> SHALL be mandatory to implement for RADIUS
Keywrap."

> Rather than, oh, say, discussing them on the list.

Let's do so now.  Starting with the issue around key agreement protocols
for the KEK, and any other keys required in your draft that SHOULD NOT
be derived from the RADIUS shared secret.


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