[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #13: Review
#13: Review
---------------------------------------+------------------------------------
Reporter: bernard_aboba@â | Owner: stefan.winter@â
Type: defect | Status: new
Priority: major | Milestone: milestone1
Component: dynamic-discovery | Version: 1.0
Severity: Active WG Document | Keywords:
---------------------------------------+------------------------------------
Date first submitted: August 9, 2009
Reference: http://ops.ietf.org/lists/radiusext/2009/msg00357.html
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?
[Alan DeKok]
Bernard Aboba wrote:
> [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?
That's a reasonable idea. I can update the DTLS document to say this.
> [BA] Given that RadSec is a product name, what should the SRV prefixes
be?
> _radtls._tcp? _raddtls._udp?
I would say the latter two. However, _radsec._tcp SHOULD also be used
for backwards compatibility.
> 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?
I would suggest so, yes.
--
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/13>
radext <http://tools.ietf.org/radext/>
--
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/>