Re: Issue 282: backward compatibility, proposed text

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Question:  At various points we have talked about separating out the
> material on DNS SRV-based discovery.  How does this recommendation
> relate to that?  For example, assuming that DNS SRV RR queries aren't
> protected by DNSSEC, couldn't the discovery process generate a "fallback
> to classic RADIUS"?

  Yes.

> (e.g. if only the FQDN of the server is provided and
> DNS SRV RR queries are used to determine whether RADSEC and/or RADIUS
> was supported).   For example, couldn't an attacker spoof a response to
> the DNS SRV RR query and convince the querier that only RADIUS was
> available? 

  Systems should be implemented so that administrators can require
RADSEC for particular home servers.  This turns the down-bidding attack
into a DoS attack, as the proxy will refuse to connect over plain RADIUS.

> I think you need to say a bit more about the assumed deployment model
> and configuration/discovery.  For example, that RADSEC is deployed for
> use by proxies in talking to each other, and that as a result, these
> proxies *only* talk RADSEC.

  And are configured to require RADSEC.

>  It's a bit trickier if a NAS is capable of
> speaking both RADSEC and RADIUS.  In that situation it seems that the
> NAS would be configured to speak one or the other to a given RADIUS
> server, and that DNS-based discovery would play no role.  Is that
> right?

  Likely, yes.  However, it may be simple for clients to use SRV
lookups, too, as it avoids manual reconfiguration when the network
changes.  Clients should also be configurable to require RADSEC.

  If you assume that the client DNS lookups are performed over a
"secure" administrative network, then DNSSEC may not be required.

>   Is this advice still true if the RADIUS client has a
> DNSSEC-validating stub resolver and therefore is able to do secure
> discovery?

  Dynamic discover is always useful, and should be implemented where
possible.

> In the discussion of RADIUS over DTLS, there had been discussion of the
> ability to distinguish RADIUS/DTLS from RADIUS on the fly.  So I'm
> wondering if this advice on manual configuration applies there too, or not.

  Yes.

> And overall, I'm curious about where the text relating to DNS discovery
> is going/belongs.  In the draft?  Outside of it in a separate document? 
> None of these?

  In a separate draft.  DTLS and normal RADIUS could be using dynamic
discovery, too.

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