Re: Open issues on the Crypto-Agility Requirements draft

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> In a very large deployment (e.g. thousands of NASes) keeping track of
> which ones support the new capabilities is non-trivial.

  I'm not sure I understand this.  A server can't track 1 bit of
information for each NAS that connects to it?

>> The client should also have a per-server flag saying "negotiated
>> secure RADIUS". Once that flag is set, it refuses to use legacy RADIUS.
> 
> This requires that the RADIUS client population can be enumerated and
> clearly identified.  In a deployment that has a list of RADIUS clients at
> fixed IP addresses, that requirement can be met.   In other situations,
> that's not as obvious.

 No.  It requires that the *current* NAS population be permitted to talk
to the server.  Which it is.  It then requires that the server be
upgrade to support the above flag.  It then permits each NAS to be
upgraded to use the new security measures.

  Once the server sees a NAS use a new security system, it flips a bit
in a database for that NAS from "false" to "true".  This doesn't affect
any of the other NASes.

>> My suggestion in the DTLS document is for the NAS to simply start
>> using the better security method. Once the NAS has been authenticated,
>> the "NAS supports better security" flag is set, and legacy RADIUS
>> becomes impossible.
> 
> That represents the end state where all legacy NASes have been
> replaced.

  No.  The flag is *per* NAS.  It's not global.

> But that doesn't imply that the RRs are retrieved securely, so dynamic
> discovery doesn't address the downgrade issue.

  If a server sees an unknown client connect, it will be either (a) an
attacker, or (b) a client that discovered the server via RR's.  It
doesn't know until it validates the identity of the client.  And it MUST
use a secure method to do so.  It MUST NOT use the legacy RADIUS shared
secret, because the entire reason it's an unknown client is that it
doesn't have a legacy RADIUS secret for the client.

  At that point, the server opens itself up to SSL connection exhaustion
attacks.  But there are no *RADIUS* issues with that.  Once the server
has used TLS to validate that the client is known, it uses TLS to
transport the legacy RADIUS packets.

  If a client uses RR's to discover a server, it MUST use a TLS-based
method to communicate with that server.

  If a client has a fixed IP to communicate with a server, it SHOULD be
configurable as to whether or not it uses TLS.  If the admin says "no,
don't use TLS", then there's no downbidding attack.  If the admin says
"yes, use TLS", then there's no downbidding attack: the NAS refuses to
speak legacy RADIUS, because it's been told to *not* speak legacy RADIUS.

> In fact, one could argue
> that the introduction of (insecure) dynamic discovery complicates the
> security analysis considerably.

  Yes, that's true.

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