W3C home > Mailing lists > Public > uri@w3.org > September 2004

Re: AAA URI draft

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 10 Sep 2004 15:28:07 -0700
Message-Id: <B06C5F88-0378-11D9-83F4-000393753936@gbiv.com>
Cc: uri@w3.org
To: aaa-wg@merit.edu

Here are my comments regarding the AAA URI draft

   http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt

update to RFC 3588.  Sorry for the late review.

The basic premise of this update, namely

    RFC 3588 [RFC3588] describes the Diameter base protocol for
    authentication, authorization and accounting purposes.  The RFC
    provides for the existence of a DiameterURI AVP that contains a "aaa"
    or "aaas" URI.  That definition of the "aaa" and "aaas" URI schemes
    follows the so-called hierarchical model specified in RFC 2396
    [RFC2396], although aaa/aaas resources do not point to hierarchical
    resources.

appears to be incorrect.  For one thing, use of a namespace delegation
mechanism like DNS within the scheme is inherently hierarchical in
nature and benefits from using the common syntax forms.  Furthermore,
if Diameter is actually a deployed protocol, an arbitrary change in
syntax to an existing scheme would significantly impact 
interoperability.

What is more problematic, however, is that the "aaa" and "aaas"
schemes seem to have been defined without a clear indication of
what is being identified:

    RFC 3588 [RFC3588] does not provide semantics for the
    "aaas" URI nor it provide instructions to IANA to register any of
    those URI schemes in the official IANA registry of URI schemes.

Unfortunately, the new draft doesn't really define what kind of
resources are being identified either.  It only says

    Both the "aaa" and the "aaas" URI schemes are used to identify
    resources related to authentication, authorization and accounting
    (AAA) functions that are accessed with AAA protocols such as RADIUS
    [RFC2865] or Diameter [RFC3588].

but as near as I can tell, the only resources ever provided by those
protocols are the service points (i.e., the fact that there is an AAA
listener at that address).  Why, then, is there a desire for a grab-bag
identification scheme like "aaa", which hides the most important bits
of information at the end of the URI, when the same thing can be
better accomplished by specific URI schemes for each service?

In other words, what I would propose is the following:

    d      = "diameter"         "://" authority    ; Diameter/sctp
    d-tcp  = "diameter.tcp"     "://" authority    ; Diameter/tcp
    d-tls  = "diameter.tls"     "://" authority    ; Diameter/tls/sctp
    dtc    = "diameter.tls.tcp" "://" authority    ; Diameter/tls/tcp

    r      = "radius"           "://" authority    ; RADIUS/udp

    t      = "tacacs"           "://" authority    ; TACACS+/sctp
    t-udp  = "tacacs.udp"       "://" authority    ; TACACS+/udp

Note that the above removes all of the complexity described in
section 3 regarding the various combinations of AAA protocol,
transport, and session-based security that are not allowed.  If you
simply define the URI schemes such that illegitimate combinations
aren't even an option, then you don't have to require that
applications keep track of what combination of parameters
are allowed.  Likewise, all of the aliases (multiple URIs for the
same service) are removed by specifying that the short scheme
defines the most common protocol case (just as the "http" scheme
defines HTTP over TCP, not HTTP over any transport).

Furthermore, if we later discover that there are more resources
hidden within the Diameter, TACACS+, and RADIUS servers beyond
the mere existence of the service points, then all we need to
do is add a path to the URI definition and those new services
can be used by other information systems beyond AAA.

A FAQ about URI scheme definitions is why doesn't the port component
in authority come with parameterization, similar to that described
in the draft for the aaa and aaas schemes?  The reason is because
applications use URI schemes as a hook by which to select modular
handlers for the processing of requests. Therefore, placing that
distinction in the scheme allows handlers for different transports
to be developed and deployed independently.  In contrast, embedding
access parameters within a URI forces the application to choose
either a generic handler that may be incapable of handling the URI,
or to hard-code inspection of the URI path prior to URI handling
(effectively breaking the orthogonality principle that is the
central point of URI design).


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>
Received on Friday, 10 September 2004 22:28:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:34 GMT