Realm Crossover for SASL and GSS-API via DiameterOpenFortress BVHaarlebrink 5EnschedeOverijssel7544 WPThe Netherlandsrick@openfortress.nlSASL and GSS-API are used for authentication in many application
protocols. This specification extends them to allow credentials of
an identity domain to be used against external services. To this end,
it introduces end-to-end encryption for SASL that is safe to relay
through a foreign server.It is common for Internet users to work with services from a varierity of
providers. An ad hoc practice has arisen of using local identity
schemes for each of these providers. There is no integration of
identity systems, and the practice reduces the control of
users over their online identity. A solution to this is support
for Realm Crossover TODO.xref.target=draft-vanrein-internetwide-realm-crossover,
where an externally acquired service can make a
callback to a home realm to authenticate a user's identity and use that
for service-specific authorisation.SASL and GSS-API together
is instrumental in authentication across a wide range of application
protocols; it allows these protocols to abstract from the actual authentication
mechanisms, and at the same time it allows authentication mechanisms to not
be concerned with the application protocol. SASL can easily be funneled
from one protocol into another, modulo a number of security concerns.Diameter and its Network Access Server application are instrumental in
authenticating a user under a realm, while not handing over any resources
like an application protocol would. Furthermore, Diameter integrates
with realm-crossing security; service can be declared under a domain name
in a manner that is standardised, scalable and secure.This can be used by a foreign server to authenticate a client by
call the client's own domain as an authentication backend:
| Foreign| ---------> | Identity|
| Client |-----------> | Server | ---------> | Domain |
+--------+ AppProto +--------+ Diameter +---------+
|| || ||
john@example.com find SRV, TLSA example.com
& credential & relay SASL authentication
Realm Crossover authentication:
Client John authenticates to his own Domain
while using a foreign Server.
]]>The Diameter server in the domain needs to respond success or failure
on the SASL exchange forwarded to it. It delivers a User-Name on success,
but not its domain. The client domain is validated by the foreign server,
using DANE . The User-Name combines with the
validated domain to form the client identity for use in the foreign server.
The domain server also validates the foreign server, and MAY use this for
access control, and perhaps to decide on the release of additional AVPs.The client needs to assure that the authentication exchange cannot be
relayed anywhere but to the Diameter service in his realm. This can be
assured with
channel binding ;
the foreign server detects this information
and relays it to the Diameter service. Normally, protocol servers
should not accept externally dictated channel binding information;
the reason why it is safe to make an exception for Diameter is that it
provides no resources, making it an unattractive attack target.SASL tokens are not generally safe to pass over plaintext channels.
This is usually addressed
by wrapping the application protocol in TLS, but since that would only
protect one leg of the intended realm-crossing authentication exchange,
there is a need for end-to-end encryption.This specification describes a SASL mechanism named SXOVER-PLUS as an
end-to-end encrypted tunnel around another SASL exchange. It also defines
how SASL can be embedded in a Diameter authentication exchange, which
may be useful with SXOVER-PLUS or with any other SASL mechanism.Realm Crossover for SASL is part of a series of protocol enhancements,
as overviewed in
TODO:xref target="draft-vanrein-internetwide-realm-crossover".
Among the potential use cases are a global identity scheme for general
communication and group participation, establishment of encryption
keys, all with identity control under individually owned domains.SXOVER-PLUS consists of a few messages that derive an encryption
secret and then continue using it as an end-to-end encrypted tunnel
around a standard SASL authentication exchange. SXOVER continues
to be active as long as the tunneled exchange does.Before SXOVER-PLUS starts, the user uses an out-of-band protocol
to submit a long-term key to his domain and receives back a suitable
keyno and encalg in the style of Kerberos
along with a "keymap" blob that contains the originally submitted
long-term key in encrypted form. This process may be run at any
time desired by the client, like when a program first uses the
SXOVER-PLUS mechanism; keys may be kept for the remainder of the
program run, even if this lasts for weeks and crosses between security
realms, as a pre-validated key for protected contact with their realm;
but at any time desired, the client may drop the long-term key, for
example when a user desktop session is suspended or terminated.By offering the SXOVER-PLUS mechanism for SASL, a foreign server
announces its willingness to validate the client's domain.
relay SASL messages to it, trust its authentication conclusion and
User-Name and treat that as a user identity of the client's domain.Offering SXOVER-PLUS does not preclude the offering of other
SASL mechanisms; for instance, ANONYMOUS may be a useful option
to also offer guest access to clients.SXOVER-PLUS is a client-first mechanism. The first SASL Token
starts with "p=CHANBIND,,DOMAIN," where CHANBIND is the channel binding
name and DOMAIN is either the fully qualified domain name of the client,
or an e.164 Application Unique String [Section 3.1 of ].
This notation is compatible with the GS2 bridge .When the client connects to the foreign service over
TLS, the tls-exporter form
of channel binding is RECOMMENDED for protocols or their
implementation that encapsulate an entire SASL exchange
in one TLS connection. For protocols that spread the SASL
exchange over multiple connections it is RECOMMENDED to support
both tls-exporter and tls-server-end-point .
Special considerations may apply as a result of software
configuration per home realm.Following this is DER-encoded information for the following
ASN.1 structure:The clirnd is a salt that should hold enough entropy to satisfy
the client's cryptographic requirements. The other fields result
from the setup of the long-term key preceding SXOVER-PLUS.Upon reception, the server locates a key for the keyno and encalg
in the key store for DOMAIN and uses it to decrypt keymap into
entropy that serves as input to the random-to-key function
,
where the length of the decrypted keymap must match the
key-generation seed-length.The same key is constructed with random-to-key on both ends;
the client uses the key that it originally submitted to the
server. The result is now on both ends, and known as key K0.Both ends pass K0 into the PRF+() function [Section 5.1 of ]
with the entire message (the GS2 header followed by C2S-Init, which
includes the clirnd entropy field) to produce properly sized input to
the random-to-key function. The result is known as key K1. Note
how this is similar to the KRB-FX-C2 procedure [Section 5.1 of ]
except that it is applied to a single key. (Considering slight
generalisation of the procedure to a list of key/pepper pairs
that are composed with associative/commutative XOR operators.)After the client-first SASL Token, the server sends its
first challenge. It is encoded with DER and encrypted by K1,
and contains the following ASN.1 structure:The srvrnd is a salt that should hold enough entropy to satisfy
the server's cryptographic requirements. Note that the mechlist
and DER tagging add no entropy.The mechlist starts the SASL exchange inside the end-to-end
encrypted tunnel. If this inner list uses channel binding at all,
it should replicate the channel binding choices from the outer
layer.The key K1 is passed into the PRF+() function [Section 5.1 of ]
with the pepper set to the concatenation of the
entire S2C-Init message and the channel binding value.
This is used to produce a last input to the random-to-key function.
The result is known as key K2.The direct concatenation of S2C-Init with channel binding
information is secure because of the self-descriptive size
of the DER encoding of the former. Also note that there is
no risk of cross-polination between types of channel binding
because the name for the type has been hashed into key K1 and is
therefore already securely encompassed in the key derivation.Further messages from the client to the server hold DER content
encrypted with key K2, following this ASN.1 format:The mechsel indicates the client's choice of a SASL mechanism,
and MUST be in the first inner SASL message. It initiates a new
authentication exchange. The c2s holds the SASL Token and is sent
as NULL whenever the mechanism yields no token, which is distinct
from yielding an empty token.The inner SASL exchange may be used to select an authorisation
name that differs from the authentication name. This would be
subject to normal approval by the SASL server, but upon success
the authorisation name would be revealed in the User-Name over
Diameter, and the foreign server would not be told about the
authentication name. This can facilitate pseudonymity.Further messages from the server to the client hold DER content
encrypted with key K2, following this ASN.1 format:The s2c field carries the SASL token if it is provided, even
when it is empty. If the token is absent, it carries NULL.General reporting of success or failure is done for SXOVER-PLUS.
But not all encapsulating protocols support additional data, but
the success field makes this possible in any case. Note that this
is trivially supported in Diameter, by sending a SASL token as part
of a success message. Inside the SXOVER-PLUS tunnel it is also
possible by setting the success flag and supplying the additional
data in s2c.SXOVER-PLUS can be used with GSS-API
instead of SASL with minor changes, because it is mostly similar
to GS2. This results in a GSS-API tunnel wrapped around SASL
authentication.GSS-API calls to gss_init_sec_context()
and gss_accept_sec_context() MUST follow the GS2 data structure for
channel binding information [Section 5.1 of ].
This means that only the application_data field is filled, namely
with the "p=CHANBIND,," part of the first SASL token from client
to server, concatenated with the application's channel binding data.
Since such data starts with "CHANBIND:"
there is some duplication of data, which should be validated.
This outer layer of SXOVER-PLUS does not support an authorization
identifier; any desire to select an identity is to be encapsulated
inside the end-to-end encrypted tunnel of SXOVER-PLUS.The first message transmitted as GSS-API token does not repeat
the "p=CHANBIND,," prefix, but the "DOMAIN," and subsequent
DER-encoded C2S-Init data is retained. Instead, the standard
GSS-API header is inserted, adhering to the
Mechanism-Independent Token Format [Section 3.1 of ]
with object identifier 1.3.6.1.4.1.44469.5081.1 to identify
SXOVER-PLUS. When this object identifier is supplied to the call
GSS_Inquire_SASLname_for_mech [Section 10 of ],
the output reads "SXOVER-PLUS" (without the quotes).When the GSS-API data must be relayed to a SASL backend, then
the "p=CHANBIND,," prefix must be reinserted after removal of the
GSS-API header. Realm Crossover for GSS-API works like this; it
is rewritten to SASL and passed over Diameter in that form.SXOVER-PLUS adheres to most of the GS2 bridge, but deviates in two points.
First, security layers are not considered useful in GS2
[Section 12 of ] because it assumes a pre-existing
secure layer to provide this benefit. With SXOVER-PLUS however, the
end-to-end connection between a client and their authentication server
differs from the single-hop connection to the foreign service,
and it can be beneficial to extract secret key information between the
client and foreign server. The second deviation from GS2 is that SXOVER-PLUS is
defined but SXOVER is not. For these reasons, GS2- was not prefixed
to the mechanism name.In general, security layers may be derived from the key K2 by yet
another pass through the PRF+() function [Section 5.1 of ]. The pepper for
this is application-specific, and the requested length of octet-string
can also be requested by the application. Multiple keys can be defined,
each constructed from K2 and pepper.Specifically, when SXOVER-PLUS is used under GSS-API, the following
32-byte ASCII strings may be used as pepper to derive keys for each of
the four secure streams supported by GSS-API: server
SXOVER-PLUS/GSS-API/SIGN-S2C-KEY | signing | client <-- server
SXOVER-PLUS/GSS-API/WRAP-C2S-KEY | wrapping | client --> server
SXOVER-PLUS/GSS-API/WRAP-S2C-KEY | wrapping | client <-- server
]]>Definitions for one application do not preclude the generation of keys
for other applications. It is however vital to security that they all use
different pepper that share a SASL-authenticated session but distribute
keys to different trusted regions within an endpoint.The key sharing mechanism from may be
used to distribute key material from the Identity Domain to the
Foreign Server, based on a Key-Type for SXOVER-PLUS and using
the pepper as the Key-Name. Each of the peppers for the GSS-API
use case is packaged in its own Key group.SASL messages in Diameter use a number of
AVPs [Section 4 of ] that are
combined to relay SASL to a Destination-Realm that
is set to the client's domain name. The domain name may
be derived from the client's phone number with the
ENUM procedure.These AVPs are added to the set that is used with the
Network Access Server application ,
and can therefore be used in
AA-Request and AA-Answer messages. They are always sent
with the Mandatory Flag set to 0. When they are not
recognised upon reception, they will be silently igored.Normally, a successful AA-Answer would provide a
User-Name AVP to inform the server about a utf8-username NAI
without a utf8-realm [Section 2.2 of ]
under which the client is identified; without the User-Name
an anonymous session is the only available option,
possibly leading to reduced service and/or limited
data retention. Sending a pseudonym in the User-Name
may be an intermediate option. In all cases, the domain
under which an authenticated user name is defined
can be taken from the Destination-Realm handling the
Network Access Server session; with the domain also written
in UTF-8, the parts may be combined in the nai grammar
[Section 2.2 of .The Identity Domain may choose to send back key material
as part of a successful AA-Answer, using .
Triggers to do this are not specified hierein, but possible
reasons could be founded on user identity or Foreign Server
identity.The SASL-Mechanism AVP has AVP Code TBD0 and is of type
UTF8String, further restricted to a list of zero or more
SASL mechanism names in their standardised notation
[Section 3.1 of ]
separated by a space character U+0020.To retrieve a server's list of supported SASL mechanisms,
this AVP is included in an AA-Request message, containing an
empty list of SASL mechanism names, so an empty string.
When SASL is supported by the server, it responds with the
list of currently available SASL mechanisms.Clients MAY retrieve the server's supported mechanism
list without actually attempting authentication in the
same session; this can be a caching mechanism for a
given combination of Destination-Realm, Origin-Realm and
Origin-Host. An abort of such a session by the
server indicates that the cache entry has expired, and
should be retrieved anew for a following attempt.To relay a client's choice of SASL mechanism, this AVP
is included in an AA-Request message, containing a single
SASL mechanism name. This MAY be done in another session
than the one that retrieved the supported SASL mechanisms
from the server, as long as origin and use have a matching
Destination-Realm, Origin-Realm and Origin-Host.When the supported SASL mechanism list on a server is
changed, any open sessions that depend on one or more of
the modified mechanisms SHOULD be aborted by the server.Diameter peers MUST NOT send the SASL-Mechanism AVP
unless they also process SASL-Token and SASL-Channel-Binding
AVPs for any sessions with the same Destination-Realm.The SASL-Token AVP has AVP Code TBD1 and is of type
OctetString. It may be passed in AA-Request and AA-Answer
messages.SASL
requires distinction between empty and absent tokens;
absent SASL tokens are represented by absence of the
SASL-Token AVP and empty SASL tokens are represented
as a present SASL-Token AVP with zero content bytes.The interpretation of a SASL-Token is subject to the
SASL mechanism selection by the client. This is relayed
with a SASL-Mechanism AVP, which MUST be part of each
Network Access Server session, no later than the first
SASL-Token exchange in that session.The SASL-Channel-Binding AVP has AVP Code TBD2 and is
of type OctetString. The AVP contains the literal channel
binding information for a SASL mechanism, and may be sent
in an AA-Request that also holds a SASL-Mechanism AVP
that lists a single SASL mechanism.Without Realm Crossover, a SASL identity provider can source
channel binding information from the underlying communications
channel. This information is not available to a SASL backend
running Diameter. To enable channel binding between the end points,
and thereby authentication between the SASL end points, the foreign
server incorporates the channel binding information that the
client can use in its connection to the foreign server. This
is useful to mitigate replay attacks, which is why its use
is RECOMMENDED.Note that SASL requires channel binding information
when the client-selected SASL-Mechanism AVP ends
in -PLUS. Different kinds of channel binding exist,
and their representations are distinguished with
an IANA-registered prefix. As a result, more than
one SASL-Channel-Binding AVP can be safely included in one
AA-Request. Servers MAY refrain from learning the
client-chosen kind of channel binding from the SASL
exchange, but SHOULD then transmit all the kinds that
they support to avoid authentication failure.The key derivation mechanism in
can be used to find keys that the Proto Client and Foreign Server
can share. Such keys are derived from key material that is not
visible to the Foreign Server, so it can only be passed back to
the Foreign Server as part of an AA-Answer.Keys MAY be passed in a successful AA-Answer using the general
framework for sharing key material . This groups
key information under a Key AVP. Keys derived with the procedure in
use a Key group containing these AVPs:
is set to the value TBD3 for SXOVER-PLUS,
as registered by IANA. This drives the interpretation of
the following AVPs in the same Key group.is the pepper for the derived key.
Every Key group MUST contain precisely one Key-Name AVP.
To distrubute multiple keys, separate Key groups MAY be used.is a sufficiently long prefix of the
PRF+() output to accomplish a desired task. There is no risk in
sending a bit more than required, so administrators can set
a value that is simply high enough in practice at a minor
computational penalty. Applications SHOULD extract a prefix that
suits their cryptographic mode. Applications SHOULD NOT split the
Keying-Material into multiple keys, because that reduces
administrative control over cryptographic facilitation and it
may hamper the ability to update cryptographic modes.MAY be added if and when appropriate.
Care should be taken that this may cut short an application
session, and that this may be construed as a form of instability.MAY be added if and when appropriate.This specification does not detail administrative procedures
for when to pass keys, or which
peppers should be applied. Configuration settings may be locally
defined, and they may incorporate the Client Identity and/or the
Foreign Server identity.Any exchange under the Network Access Server application
must include a Session-ID. There MAY be two kinds of session,
and whether they are combined is an implementation requirement.A session can probe a SASL mechanism list as supported by a
Destination-Realm for a given Origin-Realm and Origin-Host.
This mechanism MAY be assumed valid for any other sessions with
these same three AVPs, for as long as this session is open.A session can make at most one SASL authentication attempt.
This is initiated with a SASL-Mechanism AVP that conveys
precisely one SASL mechanism name in the first token. The
same Diameter message MAY convey a SASL-Token AVP in support of
client-first mechanisms. The same Diameter message MUST convey
one or more SASL-Channel-Binding AVPs if the SASL-Mechanism
ends in -PLUS. Further messages in the session MUST NOT have
the SASL-Mechanism AVP, MUST NOT have the SASL-Channel-Binding
AVP and MAY have zero or one SASL-Token AVP.It is possible for a session that probed a SASL mechanism list
to continue as an authentication attempt. In this case, the
SASL mechanism list collapses to the one choice made by the
client, and other sessions cannot rely on the entire mechanism
list. The server MAY close the session if it drops support for
the client-selected SASL mechanism.Alternatively, a session that probed a SASL mechanism list
can be kept open, and the obtained SASL mechanism list is then
considered stable for sessions that use the same combination of
Destination-Realm, Origin-Realm and Origin-Host. This may be
used to cache mechanism lists. The server SHOULD close this
session if it changes the mechanism list, thus invalidating
the previously submitted mechanism list. As long as the client
has the mechanism list open, it MAY use that list for sessions
that directly enter into an authentication attempt.This section explains how the various SXOVER-PLUS messages
are forwarded over Diameter by the foreign server. The foreign
server is connected to the SASL client, possibly over a TLS connection
or a protocol under GSS-API protection,
and relays requests over Diameter, usually over SCTP with DTLS.Diameter servers eventually provide success and failure responses, based on
the corresponding final results from a SASL implementation that they in turn use.
Before the final result is reached, the SASL implementation may impose a
challenge that will be reproduced over Diameter, passing challenge and
response tokens over Diameter on behalf of SASL.To send C2S-Init the Diameter client MUST include at least the following
AVPs in an AA-Request [Section 3.1 of ]:
is the client's identity domain,
replicated here for Diameter routing purposes;
SXOVER-PLUS conveys this value in plaintext, and it
is normally copied literally;when the client's identity domain consists of only digits, it MUST
considered an international phone number; to transform it into
a domain name, it is prefixed with a plus sign "+" to form an
e.164 address, and then transformed as under ENUM
[Section 3.2 of ]
to derive the value for the Destination-Realm AVP, based on
which Diameter's customary routing rules apply.
It is RECOMMENDED to continue to use the international number
as a domain in feedback to users, and only use the
ENUM-mapped domain in backends, where they serve domain lookup
and Diameter routing purposes.MUST be set to the fixed string SXOVER-PLUS for this SASL mechanism's name;MUST be set to the GS2 header and C2S-Init;MUST be set to the channel binding bytes for the connection in which the SASL client attempts authentication, adhering to the channel binding mechanism named in the gs2-header in the SASL-Token.It is possible to extend the message with more AVPs.
Unless described herein, the SASL implementation ignores them.When SASL fails to initialise in response to the C2S-Init passed in
an AA-Request, then the AA-Answer MUST represent that in the following
AVP:
MUST be set to an error or failure code
[Section 7.1 of ].The initialisation of SASL forms a S2C-Init response, and an AA-Answer
MUST be sent with the following AVPs:
MUST be set to the value DIAMETER_MULTI_ROUND_AUTH
[Section 7.1.1 of ];MUST be set to the S2C-Init value.The C2S-Cont message is any further message that the SASL client passes
to the foreign server. It MUST be forwarded as a Diameter AA-Request with
the following AVPs:
MUST be set to the C2S-Cont value from the SASL
client;MUST NOT be sent;MUST NOT be sent;MAY be sent but MUST NOT be processed when
received by implementations of this specification;MOST NOT be sent.S2C-Cont tokens are produced as output from continued SASL processing
based on C2S-Cont tokens found in AA-Request messages.If the SASL exchange is not final, then the AA-Answer MUST represent that
in the following AVPs:
is set to the value DIAMETER_MULTI_ROUND_AUTH
[Section 7.1.1 of ];MUST be included, and set to the S2C-Cont value.If the SASL exchange fails, then the AA-Answer MUST represent that in
the following AVP:
is set to an error or failure code
[Section 7.1 of ].If the SASL exchange succeeds, then the AA-Answer MUST represent that
in the following AVPs:
is set to a success code
[Section 7.1.2 of ];is included when the SASL exchange produced an
additional token upon success [Section 4 of ];may be provided, and then contains the utf8-username
part of a NAI , but not a utf8-realm;
normally, this is the authentication identity for which the inner
SASL mechanism succeeded, but if an authorization identity string
was supplied and approved, then that is used instead; finally,
there may be circumstances that call for sending no User-Name,
such as when the inner SASL mechanism was ANONYMOUS (as that
does not yield an authenticated user identity).
Further AVPs may be included in a successful AA-Answer.
Examples are access control list information and backend tunnel creation.
No meaning is assigned herein to such additional AVPs.Following are a few practical considerations in relation
to the Diameter connectivity for SASL.Diameter is primarily an SCTP-based protocol
,
for reasons of scalabaility and efficiency. SASL Diameter
benefits from these properties and embraces the SCTP transport.
Operating system support for SCTP is wide-spread, but
parts of network infrastructure may not support it, and that
may cause implementations to add a fallback to more traditional
protocols. Standards offer two options for doing this.Diameter can fallback to run over TCP, which is mostly
of use to poorly connected client machines, but this sacrifices several
benefits of the SCTP carrier.
SASL Diameter embeddings typically involve
no client systems, so this option is NOT RECOMMENDED.SCTP may be run over a UDP transport using port 9899
, which does not
sacrifice much; it only inserts a UDP header
before each message. This is a reasonable expectation
of foreign servers as well as identity domain, so this additional
option is RECOMMENDED for situations where an alternative for
native SCTP is desired. It is standardised as a socket
option SCTP_REMOTE_UDP_ENCAPS_PORT, and only involves a small
repetition in code, with a minor change between the
attempts.Diameter always involves the use of DTLS or TLS, but there is a number
of choices concerning the validation of connections through DNSSEC
and DANE. It is the identity domain's prerogative what level of protection
it upholds for its client identities, but any foreign server MAY
choose to raise the bar by setting a minimum accepable level.DNSSEC offers a protection mechanism for the _diameters._sctp
SRV records that lead to the Diameter host and its port for the
identity domain. DNSSEC can also protect any following AAAA and
A records. DNSSEC does not protect
against forged IP routes or hijacked port mappings or routing.
To protect against this as well, a TLSA record
for the service host and port, along with the _sctp protocol label,
can be used as specified for DANE .
This use of DNSSEC and DANE is RECOMMENDED.When identity domains choose to be light on these measures they risk
that their user identities are hijacked, in spite of the use of DTLS or TLS.
Foreign servers MAY choose to reject such identity domains, or alternatively
be more restrictive about the certificates that are accepted.The SASL mechanism SXOVER-PLUS separates the authentication of
a client identity into a domain and a user name underneath it. The
user name is validated by an identity server whose authority to
identify users for the domain is authenticated by the relying foreign
server.From the perspective of the foreign server, assurance of an identity
is the vital aspect of the SXOVER-PLUS flow that it forwards over Diameter.
Through DTLS or TLS, with DNSSEC and DANE to validate the certificate it
uses, the link from an identity domain to the Diameter
connection can be verified, so the relying server can be certain about the
domain under which its backend connection resides. By receiving a response
over that connection to a known-authoritative server for the domain, the
user name can also be trusted. The relying server continues to treat the
user name and domain as a pair the for identification of the user.Channel binding is normally limited to two parties only, and forwarding
such information is not a trivial idea. The fact that the forwarding
connection is encrypted, and known to lead to an authoritative server for
an identity domain does help. The foreign server relies on proper
authentication, and has no interest in bypassing authentication, and it
would be doing that by adopting channel binding information from
anywhere else.From the perspective of the client and the identity domain, the
safety of the SASL credentials is paramount. When addressing a
foreign server that is not part of the identity domain, clients
therefore MUST NOT rely on mechanisms that might leak credentials.
Two mechanisms that are safe to use are ANONYMOUS, which passes no
credentials and yields no privileges, and SXOVER-PLUS, which
applies end-to-end encryption to another SASL mechanism that may or
may not be secure.The SXOVER-PLUS mechanism uses channel binding to ensure that
the authentication is specific to a stream. The level to which this is
secure depends on the channel binding mechanism. Therefore, in spite
of end-to-end encryption, most use cases will want a secure carrier
such as TLS between the client and foreign server.Key sharing in Diameter's AA-Answer messages relays sensitive
information, using a TLS connection for Diameter between the
Foreign Server and the Identity Domain. The parties already
validated mutual identities before this is done. Moreover,
the keys are specific to the session, and involve entropy from
each side, so that each can constrain the reuse across sessions
on the other side. Applications that want to protect from use of
the derived keys by administrators in the Identity Domain may choose
to mix the key material with material exchanged outside their focus,
such as an ECDH key exchange between the Proto Client and the
Foreign Server. Such key exchanges are not secure from Quantum Computing
on their own, but proper mixing with the shared key adds such protection
and the only remaining concern may be an Identity Domain that is run by
a party that is sufficiently rich to own a Quantum Computer. Given
that Identity Domains can be run by arbitrary parties, this is a
controllable risk. (This assumes that TLS will independently evolve
to mitigate Quantum Computer risk.)This specification defines three AVP Codes for use with Diameter.
IANA is requested to register the following AVP Codes for them in the
"Authentication, Authorization, and Accounting (AAA) Parameters" registry:
This specification defines a Key-Type value that IANA is requested
to register under the Key-Type AVP Values in the Authentication,
Authorization, and Accounting (AAA) Parameters registry:
This specification defines a SASL mechanism named SXOVER-PLUS.
IANA is requested to register the following in the Simple Authentication
and Security Layer (SASL) Mechanisms registry under SASL Mechanisms:
]]>This section is non-normative.Within foreign server networks, it can be useful to centralise Diameter
handling in one host, where service-neutral pooling of connections to remote peers
can improve efficiency and security. Diameter could facilitate this directly, but that would add quite a bit
of handling logic to various foreign servers. The following ASN.1 module was therefore designed as
the simplest possible request/answer protocol that could run over a TCP connection
between a foreign service host and a nearby/trusted centralised host running its
side of Diameter.The protocol can also be used over SCTP. In this case, a user message can
be defined to contain precisely one DiaSASL-Request in downstream direction, or
one DiaSASL-Answer in upstream direction, and sent with the SCTP_UNORDERED flag.There is no standardised support for key exchange. This being an internal
protocol, it is better to leave this to local practices, which are presumed
secure under internal supervision.This section is non-normative.There are a few levels of support at which Realm Crossover for SASL
can be used. An informal description of these levels can be useful for
communication purposes.Level 0 constitutes the normal mode with local SASL authentication.
This works well when clients are treated as local users of the foreign
server. Authentication is therefore carried out on the foreign server.Level 1/2 relays SASL authentication tokens to a statically configured
backend, perhaps specific for a host name or resource path. The client
is treated as a user of the statically configured backend, which may
serve their own domain. This setup can be used for virtual hosting of
a service without the need to hold authentication data.Level 1 supports SASL mechanisms for Realm Crossover like SXOVER-PLUS
and relays the SASL information to the DOMAIN embedded in the first SASL
token. In this case, clients can present their own identity regardless
of configuration on the foreign server; the foreign server welcomes a
user to Bring Your Own IDentity.The Diameter formalisms are required for level 1/2 and level 1, but
are an internal choice at level 0. In all cases, the Quick-DiaSASL
definition in may be used to locally
concentrate SASL authentication; the receiving end may be a local
SASL identity provider for level 0 and would be a local Diameter node
in level 1/2 and level 1.Thanks to Henri Manson for believing in this work, and making its first implementation,
while interrogating the protocol and helping to improve it.Thanks to Nico Williams for input on the GS2 bridge and Channel Binding.Thanks to NLNet and the NGI Pointer project of the European Union for
each funding parts of this work.