Subject: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

From: [email-masked]
Date: Fri, 3 Jul 2009 09:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS
	Author(s)       : S. Winter, M. McCauley
	Filename        : draft-ietf-radext-dynamic-discovery-00.txt
	Pages           : 7
	Date            : 2009-07-02

This document specifies a means to find authoritative AAA servers for
a given NAI realm as defined in [RFC4282].  It can be used in
conjunction with RADIUS over TLS and RADIUS over DTLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 03 Jul 2009 18:29:30 +0200

> 	Filename        : draft-ietf-radext-dynamic-discovery-00.txt

  My $0.02, as suggested in earlier emails:

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

  This discover should be *forbidden* for RADIUS/UDP and RADIUS/TCP.

  The only consumer of this dynamic discovery right now is RadSec.  So
forbidding RADIUS/UDP and RADIUS/TCP from using this method has no
impact on existing systems.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stefan Winter <[email-masked]>
Date: Mon, 06 Jul 2009 07:35:51 +0200

Hi,

> impact on existing systems.

I agree. I didn't put anything to that effect into the draft because it
got discussion (and IIRC some support) from others in the room last
time. I'm happy to restrict discovery to TLS-based methods (i.e. DTLS
and TLS) if nobody objects.

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

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 6 Jul 2009 13:41:20 +0700

> and TLS) if nobody objects.

Just out of curiosity, why are we doing this?  In the revision of RFC 3588,
the dime WG has pretty much removed this capability because it was used by,
well, no one.  If it actually used by EDU Roam, that's fine, but does it
need to be standardized?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 06 Jul 2009 10:11:57 +0200

> well, no one.  If it actually used by EDU Roam, that's fine, but does it

  I believe so.  There is interest in using this process inside of a
trusted network.

  e.g. An enterprise would configure NASes with CA && client
certificates.  The NAS would use DNS to discover the server, and then
use SSL to communicate with it.

  This has obvious benefits for operational networks.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 6 Jul 2009 15:57:18 +0700

>   I believe so.  There is interest in using this process inside of a

Inside of a trusted network?  Isn't this, then, a configuration issue,
rather than a standards issue?

>   This has obvious benefits for operational networks.

Maybe you could explain those benefits (and why they were not exploited by
the folks deploying Diameter).  The only real benefit I can see is in the
case where a new server is added to the network or the IP address of an old
one is changed (surely a rather rare occurrence).  Are there others?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 06 Jul 2009 11:08:38 +0200

> rather than a standards issue?

  If it's *only* inside of a trusted network, yes.  But there are
interests outside of that usage.  e.g. Eduroam, and other roaming operators.

> the folks deploying Diameter).

  Because the deployments of Diameter and RADIUS are largely orthogonal.
 They have different use-cases, and therefore different needs.

>  The only real benefit I can see is in the

  I'm spending a fair bit of time helping people migrate RADIUS servers
from one IP (and version of software) to another.  So while it may seem
fairly rare, many people see the benefit of an automatic discovery method.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 6 Jul 2009 17:31:15 +0700

> fairly rare, many people see the benefit of an automatic discovery

Of course, what was I thinking?  Setting up a CA, issuing client and server
certs and configuring secure DNS is _so_ much simpler than laboriously
typing an IP address.  This simplicity must explain the amazing popularity
(indeed, true ubiquity) of the PKI today.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 06 Jul 2009 13:44:01 +0200

> (indeed, true ubiquity) of the PKI today.  

  It's done for EAP methods.

  And the choice is up to the operational people.  Doing certs for
client/server authentication is a higher up-front cost than IP/secret.
However, the ongoing maintenance costs can be lower.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 Jul 2009 08:16:22 -0700

> (indeed, true ubiquity) of the PKI today.  

One of the concerns that Pasi Eronen raised in Issue 303 was credential support. 

I'd suggest that this issue needs to be thought through both with respect to
proxies/servers as well as for NASes. 

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). 

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. 

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. 

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. 

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?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 06 Jul 2009 17:34:27 +0200

> could be considerably more difficult. 

  It depends on how it's done.  Bob Moscowitz && I had a "RADIUS
bootstrap" draft years ago that would have helped.  But there was little
interest at the time.

> route configuration with IPv4.

  These addresses change from time to time.  (Months, maybe years).

> responder (either a RADIUS server or a DAS) to respond with the same

  Yes.

> to use that same transport in speaking to the DAS?

  Yes.  The RADIUS server should cache IP's for a client, and when
connecting to that client for purposes of dynamic authorization, use
that IP address.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 10 Jul 2009 15:46:27 +0200

Hi,

> This raises the question of what TLS ciphersuites should be

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).

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

> dynamic discovery capability.

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

> responder (either a RADIUS server or a DAS) to respond with the same

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).

> 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

Tel: +352 424409 1
Fax: +352 422473