Re: Crypto-agility work item

["Alan DeKok" <aland@ox.org>]

"Nelson, David" <dnelson@enterasys.com> wrote:
> 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.

  In my experience, that's why people add security mechanisms to
RADIUS.  They can't trust that the external security mechanisms exist,
or that they work.  e.g. the IETF where the wireless sniffer grabbed
someone's userid & password, because their admin had un-checked the
"use encryption" box on the VPN box.  There was no warning or
notification to the end applications (or user) that traffic was being
sent in the clear.

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

  I would say that is a good first step.

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

  That is an option.  I'm not sure how else we would add security to
RADIUS.

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

  It would seem so.

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

  If we're defining encryption methods using new algorithms, we might
as well use them for attributes other than keys.  It would be minimal
additional work, either in the spec or implementations, and could have
significant utility in deployments.

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

  I would guess so.

  Alan DeKok.

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