RE: Open issues on the Crypto-Agility Requirements draft

["Glen Zorn" <glenzorn@comcast.net>]

Dave Nelson [mailto://d.b.nelson@comcast.net] write:

> Alan DeKok writes...
> 
> >   The alternative to TLS methods is something like the following
> > (created after about 10 minutes of thought).
> >
> >   1) Change MD5 to SHA-256
> >   2) Set the high bit in the RADIUS "code" field.
> 
> Well, the term "crypto-agility" implies that the protocol is not bound
> to
> any *single* cipher-suite.  Substituting SHA-256 for MD5 would not be a
> crypto-agility solution, IMO.  It would be a "fix" for internal RADIUS
> security until such time as SHA-256 becomes ineffective.

Right.

> One *could* make the argument that RADIUS doesn't need to be crypto-
> agile,
> all we need is a "fix" for the internal security mechanisms to tide us
> over
> until the transport wrapper security mechanisms are widely deployed.

As I mentioned in the meeting, this is making a rather huge assumption about
deployment issues over which the IETF has no control; in addition, the
experience WRT Diameter security deployment is not especially encouraging.

> In terms of revising the RADIUS Crypto-agility Requirements draft, it
> would
> be helpful to know whether the WG still thinks that RADIUS needs
> internal
> security that is indeed crypto-agile.

I think that it would make the protocol much more useful; OTOH, that seems
to be a non-goal of the WG & so is likely irrelevant.  As far as providing
simple, hop-by-hop security in a better way DTLS (presupposing that its
usage is properly specified _and_ it is widely deployed) is certainly more
than adequate.

...


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