Re: Dynamic discovery: applicability questions

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

Hi,

> While my understanding is that certificates have been used in RADSEC
> deployments,  deploying certificates on NASes for use with RADIUS/DTLS
> could be considerably more difficult. 
> This raises the question of what TLS ciphersuites should be
> recommended/required
> (e.g. PSK for DTLS).

The RadSec document right now includes TLS-PSK, certificates with
fingerprint validation only, and certificates with PKI chain validation.

I share the opinion that deploying a certificate backed by a proper PKI
on a NAS would be too complicated for some deployments. Such deployments
can then use TLS-PSK or deploy a self-signed certificate *once*, and
configure the expected fingerprint on the server side. Using these two
options disables dynamic discovery due to the need for a fixed
configuration, but that is arguably not a priority for a NAS anyway.

However, deploying proper PKI-backed certificates on a NAS can also have
its merits: Alan has mentioned bootstrapping mechanisms before, which
could make use of that. (e.g. the NAS inspects its own certificate on
boot, extracts its domain name from the cert, looks up the RadSec SRV
for the domain name, connects).

> Also, typically NASes are configured with the address of the proxy or
> server, and
> therefore don't need to dynamically discover it.  The situation is a
> bit like default
> route configuration with IPv4.

Exactly. PSK modes are jsut fine for these operation modes. And a more
ambitious bootstrapping can still be done, as it is not prohibited by
the specs.

> So I'm wondering whether this is primarily a concern for proxies
> running RADSEC,
> since those seem the most likely to have a certificate as well as to
> be in need of
> dynamic discovery capability.

Dynamic discovery makes most sense in proxy environments, yes. But one
can imagine other uses.

> With respect to standardization of dynamic discovery, experience with
> SIP (e.g. RFC 3263)
> has been that supporting multiple transports can be the source of
> interoperability problems,
> and that if not carefully specified, dynamic DNS discovery can
> actually make things worse.
>
> For example, I'd suggest that a RADIUS server should probably not use
> dynamic discovery
> to decide how to answer an incoming Request.  This could result in an
> incoming RADSEC
> packet being answered with a RADIUS over DTLS packet.  The logical
> thing to do is for a
> responder (either a RADIUS server or a DAS) to respond with the same
> transport that was
> used in the Request.

Certainly. It was not intended to create "asymetric" routing of messages
on the return path. That is, an incoming Access-Request from a client
will always be responded to using the same channel the request came in.
Only if the server decides to proxy the request elsewhere, dynamic
discovery can be used to determine the proxy destination. This does not
preclude though that a client can send a request using one channel, and
proxying to  a home server can be done on another one. That is

[Access-Request] (client) --DTLS--> (proxy)  --TCP/TLS--> (home server)
[ Access-Accept] (client) <--DTLS-- (proxy)  <--TCP/TLS-- (home server)

is possible (whether the home server was determined dynamically or
statically configured is irrelevant here).

> I'm also not sure whether a DAC should use dynamic discovery to decide
> how to speak
> to a DAS.  In this situation, there is presumably information
> available on the transport used
> by the RADIUS client in the Access-Request.  Wouldn't it make more
> sense for the DAC
> to use that same transport in speaking to the DAS?

Yes. Existing transport relationships with clients should be remembered
for all communication relating to the established user sessions of these
clients.

I will update the draft accordingly to make these things clear.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


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