RADIUS and Diameter
Authorisation (authz) under the InternetWide Identity Framework is performed through Diameter, possibly falling back to RADIUS. Very interesting about this choice is that all future developments in our work will concentrate at these servers.
The InternetWide Identity Framework supports of quite a plethora of identities with various clever uses and that may seem confusing to the implementer of a service. Interestingly, it is not difficult at all.
Authentication not via Diameter or RADIUS
Very often, RADIUS or Diameter are used for authentication, as well as authorisation. In general however, this is a choice that applications can make based on their specific requirements. For the InternetWide Identity Framework, Diameter is only used for authorisation, but not authentication. RADIUS may be supported in a backward compatible manner, but it lacks semantics such as secure connections and is far less suitable to securely connect realms.
It is an explicit InternetWide Goal to welcome remote users when they want to access services. This means that these users must be authenticated, and that is not easily done with a locally oriented protocol; instead, the secure transport connecting locations is highly suitable for this purpose.
What remains to be done with Diameter is authorisation -- especially if we are capable of authenticating remote users there is a need to regulate which parties may be granted access.
Authorisation Questions
The two major questions that should concern us are simple:
- Can authenticated
user_A
act as though he is authenticateduser_B
? - Can authenticated
user_B
accessresource_R
(and possibly itsinstance_I
) inmode_M
? - Can authenticated
user_B
communicate with targeted localuser_C
? (optional)
In the first question, we see user_A
change its identity to user_B
, which
might be a group, role, psuedonym or alias in which the user takes part. If
this is done, we will continue to treat user_B
as the authenticated user
instead of user_A
, because apparently the client or his application decided that this is
desirable for the resource being used, maybe for reasons of privacy.
The second question makes a decision on the use of a resource, which may be
anything; for instance, a Git stashing server. As a general form, we
describe resources as a class (which is a
UUID, generated per application and possibly
registered for ARPA2)
and an optional UTF-8 key that
instantiates the class. Classes represent conceptual resources, not so much
a protocol implementation; so a Git stash may be made available over HTTP,
SSH and Git, always with the resource class.
The instance exists to further localise a resource; in case of a Git service
it can add a unique code for one Git repository on a stash. It might also
use a URI format. The resourceClassUUID
is explicitly allocated for an application
class and defines the format to be used for the resourceInstanceKey
applic
The second question also mentions a mode of use, for
which we identify the CRUD rights and more; for example, Create and Delete may be the
privileges of an administrator group member, whereas Read is public and Update
limited to a webmaster or an author of a resource.
The third question is for another kind of authorisation. Instead of talking to a resource, it asks to communicate with a user. This question is independent of protocol; so the same answer would apply to email, telephony and chat.
An authorisation inquiry always involves the first form, though it may be
trivial because user_A
and user_B
can be set to the same value. This
is valid as a method of testing that this user exists. On top of this
inquiry, it is possible to add either the second form, the third form or
neither.
Abstract Resources to Serve all Protocols
Thinking in terms of resources is not new at all; it underpins the HTTP model, and RESTful APIs celebrate this idea too. What we do here is abstracting it so that it can be applied to many other protocols as well. This is why there are not HTTP paths but UUIDs in this reasoning. It is up to a service if each protocol (HTTP and XMPP, for example) uses its own set of UUIDs, or whether they overlap, but when they are alternate representation forms of the same data it is advised to share the UUID, even if one protocol can only show a partial view. The need to set a fixed UUID for each conceptual application means that a quick, local scan can be made to decide if a question about authorisation is useful at all; without a resource, no authorisation questions can be asked.
Note that frameworks like OAuth conduct authorisation through HTTP redirection. There is indeed no problem setting up a separate authorisation server and publishing the interactions between that and a resource service; but it is not clear at this point what value that will add, since usually the authorisation service will be controlled by the resource whose access is being granted. For that reason, we consider an internal Diameter service to work fine.
What we do see happening in future ARPA2 phases is that the authorisation handlers near services will interact with a remote identity provider, this is a split of responsibilities that seems to make good architectural sense when the goal is to allow end users more control over their online presence. For these cases, we intend to unleash a standard communication mechanism as part of our 3rd phase, ServiceHub. This mechanism will be based on Diameter, probably with GSS-API protection and run over an SCTP/IPv6 channel. All can then be encapsulated inside the authorisation interface described here, so services should not have to change when we add this extra level.
Formulating the Authorisation Question in Diameter (or RADIUS)
Services can pose authorisation inquiries over either Diameter. We discourage reliance of RADIUS because it is seriously hampered for realm-crossing uses, especially in terms of security which is mostly done with a separate TLS session for each query; that scales really badly.
It is advised to already keep in mind that the uplink to a remote identity provider will standardise on Diameter, though. This hint may help to design the most useful networking components. We currently feel inclined to advise the use of OpenDiameter because it can service both Diameter.
Now, let's see how to ask authorisation questions detailing them:
- Can authenticated
user_A
act as though he is authenticateduser_B
? - Can authenticated
user_B
accessresource_R
(and possibly itsinstance_I
) inmode_M
? - Can authenticated
user_B
communicate with targeted localuser_C
? (optional)
The combined forms that can make sense are:
- Only the first question, with
user_A
equal touser_B
to test if a user exists - Only the first question, with
user_A
different fromuser_B
- Both the first question and the second question without instance key
- Both the first question and the second question with instance key
- Both the first question and the third question
Only the second form uses the AVP NAS-Identifier
.
Only the third form uses the AVP NAS-Port-Id
.
An Access Request packet for these two questions contains the following AVPs:
Destination-Realm
holds the domain being targeted.User-Name
holds theuser_B
name that should be used; not just the local part, but also the domain, even if it matches theDestination-Realm
.User-Password
holds theuser_A
name as it has been authenticated before, including the domain name even if it matchesDestination-Realm
. In RADIUS, this field is subjected to feel-good "encryption", but Diameter drops this habit. Advise is given to employ end-to-end encryption, but no specification has been approved for this use. This is not a problem; the data that we intend to store in it is not sensitive.NAS-Identifier
is used in the second form, where it holds the Resource Class UUID soresource_R
, in lowercase text form; if a resource instance is added, the Resource Class UUID is followed by a space and the instance keyinstance_I
in its textual form. Note that this entire field is considered case sensitive.NAS-Port-Id
is only used in the third form, where it is set to a targeted localuser_C
.- We never send both a
NAS-Identifier
andNAS-Port-Id
AVP; both may be absent. - Other fields may be added to facilitate local distinctions or RFC 7155.
- Note that the
mode_M
does not occur in theAccess-Request
; it is instead returned as a string of flags and can then be tested.
Normally, there is no challenge/response interaction; successful authorisation directly returns an Access Accept packet with the following AVPs:
User-Name
is the actual user name that should be used; authorisation may have reasons to not set it touser_B
but to yet another form; it may even set other values derived from its own internal configuration; the application should process this outcome and forget about its originally requested user names, or it may treat an unexpected user name as a rejection of the desired authorisation. The field contains the user name with its domain.-
Filter-Id
holds a series of letters, each serving as a flag to indicate some permission; we standardise letters and precede it with a%
sign. Access Requests withNAS-Identifier
ask for a resource (instance) and geta
for administrations
for servicesd
for resource deletersc
for resource creators (who may fill it with content)w
for writing to an existing resourcer
for readers of a resourcep
for provers who may prive statements without seeing the info usedk
for knowers who may know that the targeted data existso
for owners of a resourcev
for visitors, who may only receive limited facilitation
The permissions usually include the ones listed below them; so the permission
r
usually comes asrpkov
— the Diameter server is responsible for providing them all; the user-facing server (a "NAS" in terms of Diameter) can simply look for the presence of a flag to know what a user may or may not do with a resource.On the other hand, when requesting communication with a user through
NAS-Port-Id
, the flag letters areW
for white-listed communicationG
for gray-listed communicationH
for honeypot-listed communicationB
for black-listed communication
It is sometimes rumoured that
H
is for "hellbound", but this is not what is defined above. It is generally a mode dedicated to attack handling, and should not be selected lightly; it involves computational overhead on both ends.The fallback mode is
B
for communication andv
for visitors. These are regularly returned for entries rejected in the ACL, so do not expect an error for any other reasons than operational concerns. This makes it more difficult to probe for accounts through the NAS.If neither
NAS-Identifier
norNAS-Port-Id
were in the Access Request, thenFilter-Id
is absent from the Access Accept.Note that these rules hold all the potential, and so a response will always succeed; just maybe with very low facilitation levels.
-
Reply-Message
may be added; it holds a textual description from the authorisation process that may be shown to the user. Configuration-Token
may be added; it holds a sequence of bytes that the NAS can use to unleash the requested resource; this value should not be shown to the client application, but remain within the resource server.- Local configurations or RFC 7155 may add attributes that may be specific to a requesting application.
An example of changes to the User-Name
by the authorisation server
occurs when a member attempts to authorise
to a group; in that case, authorisation may conclude that access is accepted,
but as a separately named group member; for instance, authenticated user john@example.net
may be authorised as a member of support@example.com
under member name
support+john@example.com
. This can be helpful to protect the privacy of
John's individual email address; the same mechanism can be used to change
from or to external user addresses when domain users hold an alias to such
an address.
In situations of operational problems, there may be flat-out rejection,
relayed through an Access-Reject message. This is not usually done
to reject an attempted access; for that, we return a more subtle result
in the Filter-Id
that just happens to drop all the way down to guest
mode for resource (instance) access, or to black-listed mode for communication.
Within the ARPA2 framework, we pride ourselves on always including
at least:
Reply-Message
holds a textual error message about the authorisation process that should be shown to the user
There is a third possible response, and this occurs when access has been gray-listsed. In such situations, the user is asked to somehow prove their identity before they can be added, and to try authorisation again.
The Access Challenge reply contains the following AVPs:
Reply-Message
holds a textual instruction to the user, indicating how to respond to the challenge (although automated handling is usually preferred)State
holds a binary object to be reproduced in the matching response; it holds state for the current challenge/response authorisation attempt; the authorisation server will generally encrypt and/or sign this attribute to avoid tamporing and tapping; the contents of this field may therefore be shown to the user, but the size can easily exceed 100 bytesIdle-Timeout
holds the number of seconds that the user may take to respond
In response to this challenge, a somewhat different Access Request should be sent, holding the following AVPs:
User-Name
holds the same value.User-Password
holds the same value.NAS-Identifier
holds the same value or is also absent.NAS-Port-Id
holds the same value or is also absent.State
replicates the same attribute from the Access Challenge.- Other fields may be added to facilitate local distinctions.
- As before, the
mode_M
is not mentioned in the Access Request.
The difference with the normal Access Request is the addition of the State
attribute.
When we add gray-listing facilities to ACLs, presumably as a default policy, we may use the Access Challenge response. Note that services that lack support for gray-listing are supposed to consider this a black-listed response. This method nicely matches the idea of service-specific gray-list handling, and it gives the user a choice.
Consider the Nginx web server. When using its internal TLS support, it
sets a variable $ssl_session_id
that cannot be falsified by sessions,
especially because we trust Nginx to serve our interests. This makes the
variable suitable as a key to the current TLS-wrapped connection or session.
Within this session, one authorisation effort usually suffices, and it may
serve the interests of the client for a prolonged period. The client can be
told to "reload" or "reconnect" to refresh their rights to the service.
Note that HTTP servers can suggest prolonging connections to a period that
matches the caching time for the corresponding information in the
authorisation cache that responds locally to access questions that the
Nginx proxy forwards, usually through a
HTTP Auth Request.
As a transport, the InternetWide Architecture chooses Diameter over RADIUS, because Diameter frames can be carried over SCTP, which saves an application the complexity of resends and uncertainty about the authorisation server being online. It also means that a security layer such as DTLS can be negotiated for a long-lasting connection, causing all future queries to be quickly streamed to the authorisation server, without per-query setup delays. RADIUS has been used in similar setups, but this has rather stretched it beyond its designed-in capacities.