|
> As a consequence, the selection of transports to communicate from a > client to a server is a manual administrative action. An automatic > fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to > down-bidding attacks on the peer communication. 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? > Please comment if this text can satisfactorily close this sub-issue. 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. 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? Is this advice still true if the RADIUS client has a DNSSEC-validating stub resolver and therefore is able to do secure discovery? 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. 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? |