Re: Issue 282: backward compatibility, proposed text

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

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

DNSSEC could secure the SRV response, yes. The overall security of
discovery also depends on the subsequent A/AAAA lookups, and I think
there's a loophole DNSSEC can't close. Which would in turn mean that
adding DNSSEC doesn't completely secure the process in the end, and so
manual configuration of a desired minimum security level is the only
proper answer. In the (yet unpublished) dynamic discovery draft, I've
just scribbled down the following (the second para relating to bidding
down):

   When using DNS without security, the replies to NAPTR, SRV and A/AAAA
   requests as described in section Section 2 can not be trusted.
   RADIUS transports have an out-of-DNS-band means to verify that the
   discovery attempt led to the intended target (TLD/DTLS: ceritifcate
   verification or TLS shared secret ciphers; UDP/TCP: the RADIUS shared
   secret) and are safe from DNS-based redirection attacks.  [Note:
   assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT
   deliver the shared secret in the DNS response!]

   The discovery process is always susceptible to bidding down attacks
   if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well
   as for RADIUS/TLS and/or RADIUS/DTLS.  While the SRV query will
   expose both transports, an attacker in the routing path might
   suppress the subsequent A/AAAA results for the TLS or DTLS peer and
   trick the inititating peer into using the weakly protected UDP or TCP
   transports.  The use of DNSSEC can not fully mitigate this attack,
since it
   does not provide a means to detect packet suppression.  The only way
   to disable such bidding down attacks is by intiating connections only
   to the peer(s) which match or exceed a configured minimum security
   level.  An implementation SHOULD provide a means to configure the
   administratively desired minimum security level.

Does that make sense?

Greetings,

Stefan Winter


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