RE: Crypto-agility work item

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

Bernard Aboba writes...

> The focus is on negotiation of cryptographic algorithms for
> existing RADIUS security mechanisms. 

Let's poke into this a little deeper.

The existing RADIUS security mechanisms include:

-- The MD5-based stream cipher used to obscure the User-Password
attribute.

-- The MD5-based MAC used to create the Response-Authenticator header
field.

-- The HMAC-MD5 MAC used to create the Message-Authenticator attribute.

There are other ways of securing RADIUS, most notably running it over a
protected transport, such as IPsec, TLS, DTLS, etc.  I don't consider
these as RADIUS security mechanisms, however, as they are external to
RADIUS.

When we discuss new cryptographic algorithms for existing RADIUS
security mechanisms do we mean simply replacing MD5 or HMAC-MD5, as they
appear above, with some other algorithm?

Do we anticipate the creation of new attributes, such as a
Message-Authentication-Code attribute, to replace/supplement the
Message-Authenticator attribute?

Since the scope of this work includes key-wrap, we anticipate the
definition of new attributes, for key distribution, that are protected
by reversible encryption, using one or more algorithms.

Do we anticipate that other new attributes, similarly protected, could
be defined for use in transmission of other information besides keys?

Do we anticipate defining, by reference to other work, how key agreement
for the KEK (and other keys) shared by RADIUS clients and servers is
accomplished in an interoperable fashion?


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