Re: Open issues on the Crypto-Agility Requirements draft

[Alan DeKok <aland@deployingradius.com>]

Dave Nelson wrote:
> One of this issues we are facing is carving out a relatively narrow scope
> for crypto-agility work in RADIUS as opposed to fixing RADIUS security, or
> making RADIUS compliant with current day IETF protocol security
> requirements.  A clear scoping statement may avoid some of these comments.

  My $0.02: the crypto-agility work can be put into two rough classes.

1) Minor changes to RADIUS

2) TLS methods

  The goal with RadSec && DTLS is to fix RADIUS security.  RadSec can
address the inter-organization security, for organizations that find
IPSec too problematic.  DTLS can address intra-organization security, so
that we have an upgrade path for when MD5 is broken completely.

  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.

  i.e. packets with the high bit set use SHA-256 for security, rather
than MD5.  We would need a new "SHA-only" secret, too.  Everything else
in RADIUS is unchanged.

  This would provide a *simple* upgrade path, with minimal amounts of
work for all parties involved.  It will not address the issue that 100's
of 1000's of legacy devices don't support the new system.  It won't
address the issue that many vendors won't upgrade their firmware.

  I think TLS is a better solution.  It requires more work, but many
vendors already rely on OpenSSL for HTTPS traffic, so the code exists,
and is largely already on the machines.

  The alternative to SHA-256 or TLS would be public shame and
humiliation for this WG.  Once MD5 is broken, we would be responsible
for a security protocol that has *zero* security.  A much better
approach is to have a solution in place before the break.

  The onus then gets pushed back to the vendors.  Once MD5 is broken,
vendors will be subject to shame for not implementing this WG's solution
to the problem.  The vendors that care will upgrade.  The vendors that
don't care will knowingly accept the consequences of shipping broken
equipment.

  Let's also not forget that the majority of the AAA server market is
provided by only 5-6 vendors.  Those vendors are largely on this list,
and can choose to have an upgrade path available for when MD5 is broken.

> Also, Bernard has proposed some textr around a phase-in / transition plan
> that addresses some of the backwards compatibility and negotiation issues.

  See also the DTLS document, which addresses some of this.  It assumes
that the people running the NAS communicate with the people running the
AAA server.  It assumes that the upgrade path is negotiated *once*.
After that, the NAS is marked as "DTLS enabled", and the server refuses
to talk legacy RADIUS with the NA.  Changing the flag back requires
administrator intervention.

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