Abstract
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.
[BA] References aren't allowed in the abstract. Also, this is only about RADIUS, not AAA in general, no?
1.2
RadSec node: a RadSec client or server
RadSec Client: a RadSec instance which initiates a new connection.
RadSec Server: a RadSec instance which listens on a RadSec port and
accepts new connections
[BA] As we discussed at IETF 75, RadSec is a product name. Can we use "RADIUS over TLS" and "RADIUS over DTLS"
(or maybe RAD-TLS and RAD-DTLS) instead?
Section 2.1
Dynamic server discovery as defined in this document is only
applicable for AAA transactions where a AAA server receives a request
with a NAI realm for which no home AAA server is known. I.e. where
static server configuration does not contain a known home
authentication server, or where the server configuration explicitly
states that the realm destination is to be looked up dynamically.
Furthermore, it is only applicable for new user sessions, i.e. for
the initial Access-Request.
[BA] Is this about AAA in general (including Diameter) or just about RADIUS?
2.2. DNS RR definition
DNS definitions of RadSec servers can be either NAPTR records or SRV
records. When both are defined, the resolution algorithm prefers
NAPTR results (see section Section 2.3 below). The NAPTR service
field used is "AAAS+RADSECT". The SRV prefix used is "_radsec._tcp".
It is expected that in most cases, the label used for the records is
the DNS representation (punycode) of the literal realm name for which
the server is the AAA server.
[BA] Given that RadSec is a product name, what should the SRV prefixes be?
_radtls._tcp? _raddtls._udp?
bank-rupt.com
[BA] Suggest use of an example.com domain instead (e.g. bank.example.com).
2.3. Realm to AAA server resolution algorithm
Input I to the algorithm is a User-Name in the form of a NAI as
defined in [RFC4282] as extracted from the User-Name attribute in an
Access-Request. Output O of the algorithm is a set of hostname:port
and an assoiciated order/preference; the set can be empty.
Note well: The attribute User-Name does not necessarily contain well-
formed NAIs and may not even contain well-formed UTF-8 strings. This
document describes server discovery only for well-formed NAIs in
UTF-8 encoding. The result of all other possible contents of User-
Name is unspecified; this includes, but is not limited to:
[BA] Given the problems with RFC 4282 described by Alan at IETF 73, I'd suggest not referencing RFC 4282
if possible, just focusing on the User-Name attribute, which is defined as UTF-8 by RFC 2865.
As far as I can tell here, the issue here is whether it is possible to utilize the realm-name in UTF-8
to resolve the address of the RADTLS/DTLS server. As noted in the IAB document, there are several possible
ways that this resolution could take place:
a. An A/AAAA query could be sent via mDNS and/or LLMNR, using the realm encoded in UTF-8.
b. An A/AAAA query could be sent, by converting the realm in UTF-8 to punycode, using ToASCII().
c. An A/AAAA query could be sent, using the realm encoded in UTF-8.
When attempting resolution via b), it is possible that the conversion will fail. If none of the other
resolution mechanisms are attempted, or if they fail too, then resolution of the server will not be
possible.
Now that the IDNAbis documents are headed toward WG last call, my recommendation is to reference these,
rather than IDNA.
2.3. Realm to AAA server resolution algorithm
In addition to the material here, I recommend providing advice on IPv4/IPv6 usage. One issue that
has been encountered in IPv6 implementations is that attempting to connect via IPv6 preferentially
is problematic. Even though a AAAA RR might be available, and IPv6 might be supported and available
on a link, this doesn't mean that IPv6 connectivity exists, due to routing table issues. As a result,
attempting bring up an IPv6 connection before failing over to IPv4 will often result in a performance
problem. A better approach (implemented in MacOS X) is to attempt to bring up both IPv4 and IPv6
connections and then use the connection that comes up first.
Section 3
[Note:
assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT
deliver the shared secret in the DNS response!]
[BA] I certainly hope not. This somewhat begs the question of when server resolution is useful. Presumably,
this is primarily for use with certificate-based authentication, no? I'd assume that if TLS PSK is being
used then you'd have static configuration, correct?
Section 4
This document contains no actions for IANA. Maybe. Not sure about
the labels "AAAS+RADSECT" and "_radsec._tcp.".
[BA] What about RADIUS over DTLS? Does this document apply to that as well?
the labels "AAAS+RADSECT" and "_radsec._tcp.".
|