Diameter Messages in Kerberos5 AuthorizationData
ARPA2.net
Haarlebrink 5
Enschede
Overijssel
7544 WP
The Netherlands
rick@openfortress.nl
The Kerberos5 infrastructure is concerned with authentication, but
it can also carry AuthorizationData in a variety of formats.
Diameter is an extensible standard for the expression of authorisation
information. This specification defines an embedding of Diameter data
in the AuthorizationData fields of Kerberos5.
Kerberos5
is a single-signon system that automatically supplies users
with authentication tickets to individual services. Such tickets tend
to last as long as a maximum user session, usually up to a day. They
are provided by a central realm service known as the Key Distribution
Center or KDC.
Though designed for authention rather than authorisation, KDC exchanges lend themselves
well to facilitate both. The message formats can carry AuthorizationData
consisting of a numerical tag and data to be interpreted according to that
tag. This specification adds a tag value to describe AuthorizationData
holding Diameter protocol messages.
AuthorizationData can be included in requests to the KDC, and the
KDC can include AuthorizationData in a ticket. When requesting a
service ticket from the KDC, a single-signon ticket with possible
AuthorizationData is attached to that request.
All this data is protected in transit; requests to the KDC are
encrypted with the TGT secret or a sub-secret; tickets pass it to a
service using a key shared between the server and KDC.
Diameter frames
hold a list of Attribute-Value Pairs (AVP), with optional nesting into
group AVPs. The format is easily parsed and applications exist (or can
be defined) to capture a class of usage scenarios. Among the existing
applications is a network access application that lends itself for most
authorisation applications.
The purpose of using Diameter in this place is to employ the
existing communication infrastructure of Kerberos to pass authorisation
settings between hosts. The standardised format simplifies access to
services in foreign realms; this is useful to the InternetWide.org
purpose to Bring Your Own IDentity (BYOID), which requires passing
standardised authentication and authorisation information between
collaborating but otherwise independent parties.
Diameter messages consist of a header choosing an application,
followed by the AVPs that are meaningful within that application.
The header guides the interpretation of the AVPs and is therefore
a meaningful part in proper understanding of the exchange. This
is why inclusion of Diameter as Kerberos AuthorizationData must
not be limited to a set of AVPs but instead include a header.
Diameter messages are always carried over a protected transport
such as SCTP with DTLS or TCP with TLS, where the purpose is to
mutually authenticate Diameter Peers in protection of in-transit
data against rogue alterations and to conceal sensitive data from
similarly undesirable parties. These security requirements are
alternatively met when AuthorizationData is used to carry the
Diameter frames.
Diameter makes a distinction between sessions and connections.
Connections represent coherent message carriers such as TCP or SCTP
connections, whereas a session is more conceptual relationship
that may span multiple connections and connections may carry
multiple sessions. Requests over one connection may even be
responded to over another. For the purposes of Diameter, passing
messages through Kerberos can be viewed as an alternative form
of connection; the collaboration between KDC and services can
be considered a connection, consisting of a multitude of
individual packages but together forming a coherent message
carrier.
A normal exchange under Diameter is a request leading
to a response. This can be established by inclusion of
a request in a message going to a KDC, and a response
coming out of it. We can also imagine responses to be
supplied as a pro-active hint, to prepare an answer that
might come up when interpreting a service request. This
is possible because the client KDC is asked for a service
ticket, allowing it to preview upcoming inquiries. The
hint provided would stand for the entire duration of the
service ticket, effectively turning such tickets into
client-held caches of their authorisations.
Diameter connections must start interactions with a
Capabilities Exchange. This specification answers that
with a default setup with
the Network Access Application
and possible overrides to take place during administrative
setup, such as during the creation of service keys or the
esstablishment of realm crossover. This looseley addresses
the requirement for Capabilities Exchange.
The looseness is warranted because the customary need
for a Capabilities Exchange is not fully applicable to
the use of Diameter messages in AuthorizationData, not
even when crossing realms. First, this can be used as a
pro-active mechanism and it is generally safe to ignore any
misunderstood Diameter messages. Second, tickets tend
to be cached for a day, which makes their generation less
resource-demanding. Third, the purpose can help avoid
traditional Diameter traffic, thus limiting the danger
of a lot of spurious network traffic.
Peers that process Kerberos messages should not
be considered Diameter processing nodes, as they may
be just passing traffic, except for the end points
that produce and consume Diameter messages in
AuthorizationData. Intermediate nodes may choose to
process data though; for instance, during realm crossover
the KDC of the service domain may remove authorisations
that it does not find acceptable; the service may assume
that it's realm is managed thusly. In general however,
Kerberos defaults to passing AuthorizationData without
change, meaning that Kerberos nodes cannot be held
accountable for Diameter message content that it does
not interpret.
This section is not normative; it serves to present context.
The following patterns are proposed for the InternetWide.org
project, which aims to support secure and private interactions
across realm boundaries for standard Internet protocols,
including but certainly not limited to HTTP.
A general principle in the InternetWide Architecture is
that users can Bring Your Own IDentity (BYOID) which is
implemented with names with a local part and a domain part,
basically like an email address or Netword Access Identifier.
When crossing over to a remote realm, the intention is to
allow a change to an alias that may be specific to that
remote realm, thus allowing better control of online
presence.
The InternetWide Architecture treats user services such
as email and web as what Diameter calls Network Access Servers;
they grant access to a facility, and need authorisation from
the client's home realm. Diameter was designed to allow this
across realms, and the inclusion of these forms in Kerberos
tickets can greatly improve the scalability of such
interactions.
The Kerberos mechanism is very efficient for use across
realms, as is required under BYOID. Other current mechanisms
tend to be less efficient due to:
Everything is connected through HTTP over TLS;
The employed cryptography is public-key based;
There is only limited opportunity for caching;
Authorisation is performed on-demand;
Authorisation signatures must be separately verified;
The result is not protected against quantum computing.
In contrast, the proposed AuthorizationData used in Kerberos
with realm crossover permits:
All protocols can be used, with authentication in only a few exchanges;
The employed cryptography is symmetric;
AuthorizationData is cached for about a day with the client; realm crossover is cached in the KDC;
Authorisation is done pro-actively during authentication;
AuthorizationData is protected along with the authentication of a service ticket;
Kerberos can withstand quantum computing.
At the start of a session, a user logs in to the KDC for
his realm. During the day, service tickets are requested.
When the KDC needs to, it will forward the user to a remote
realm through realm-crossing tickets, that the user follows
using current Kerberos semantics .
For services in serviced realms, the KDC can insert
dedicated authorisation information into requested service
tickets.
The KDC cannot be configured to grant the supply of information
to remote realms during the dissimination of realm-crossing
tickets. Such information should not be specialised for a
service name found in the request that caused it to release a
realm-crossing ticket, because clients tend to cache these
tickets and thus be deprived of this refinement for future
use in the same realm. It is however possible to supply
more kinds of information, or generally usable information,
in such realm-crossing tickets.
The KDC of a service realm may prune information that does
not apply, or is considered improper, for a service for which
it received a request. This can be included into a specific
ticket for a specific service. Some authorisation information
during realm crossover is the prerogative of the client's KDC,
other information is the prerogative of the service's KDC.
Identity is a good example of client-sided control, whereas
rights to write to a resource tend to be decided about on
the service side. The InternetWide Architecture envisions
standardised contracts between client and service realms that
may enhance the information that could pass.
A targeted service can retrieve authorisation information
from a service ticket, and be sure that it came from the KDC
that constructed this ticket. In case of a user from a
realm that is not local to the service's realm, the service
may derive trust from any filtering that it knows is being
done in the KDC for the service realm.
This section is not normative; it serves as an example.
Shell services are often made available through
OpenSSH and it is common to provide
services (such as file transfer) as well as tunneling (such as
to a server port behind a firewall). Kerberos access to these
services take the form of rather general "host" tickets that
is also used for several other purposes on the same host.
The multitude of access opportunities with one ticket calls
for some restriction, but a change of the ticket naming
convention is not practical. Additional content describing
authorised purposes is. Diameter messages can be useful to
accommodate this. It may also help to provide access to
shared environments, where each client is given a different
kind of access profile. Even access to clients without a
local account may be possible under such conditions.
Everyday setups of OpenSSH are isolated; it may use a
plugin module to add Kerberos5 authentication and decide
on the access and session properties. These setups tend
to work in isolation without connectivity to a Diameter
infrastructure, but having such data can nonetheless be
beneficial.
This specification suggests some leniency in terms of
attempting to access Diameter services that may not be as
formally negotiated. This does mean that unrecognised
messages should be silently ignored. In typical uses of
Diameter, this would rather cause an explicit error
message. As long as no actions are taken on unrecognised
content, this should not impact security, however.
Diameter messaging parties must take responsibility
for what they send. Kerberos peers pass AuthorisationData
without looking, so these peers cannot be held responsible
and should be viewed as communication channels, not Diameter
peers.
During realm crossing, the right to setup certain
authorisation fields may vary. It is important for any
trusting realm to be mindful of this. Whether this
concern is implemented in individual services or generally
dealt with in the realm's KDC is an operational choice
that can be made locally to the realm; the realm's KDC is
involved in realm crossover at the time that a service
ticket is requested by the foreign client.
During realm crossing, the client's KDC releases a
general ticket for a remote realm. The information
contained in this ticket's AuthorizationData may be
visible to all services in the remote realm, and so
is subject to privacy concerns. It may be necessary
to either supply only generic information (such as
descriptive attributes) or use only one or a few
foreign services per realm.
When IANA takes on the registration of AuthorizationData tags, it
will take the following allocation into account:
TODO
This work was conducted as part of the InternetWide.org project, and aims to support
authorisation data that crosses over between platforms and realms. Implementation
projects under this architecture are named ARPA2 projects.