Internet DRAFT - draft-vanrein-diameter-sasl
draft-vanrein-diameter-sasl
Network Working Group R. Van Rein
Internet-Draft OpenFortress BV
Intended status: Informational 14 October 2022
Expires: 17 April 2023
Realm Crossover for SASL and GSS-API via Diameter
draft-vanrein-diameter-sasl-07
Abstract
SASL 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Van Rein Expires 17 April 2023 [Page 1]
Internet-Draft Diameter SASL October 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Messages of SXOVER-PLUS . . . . . . . . . . . . . . . . . . . 4
2.1. Preparation for Messaging . . . . . . . . . . . . . . . . 4
2.2. Initial Client-to-Server Message . . . . . . . . . . . . 5
2.3. Initial Server-to-Client Message . . . . . . . . . . . . 6
2.4. Continued Client-to-Server Messages . . . . . . . . . . . 6
2.5. Continued Server-to-Client Messages . . . . . . . . . . . 7
2.6. Using SXOVER-PLUS with GSS-API . . . . . . . . . . . . . 8
2.7. Application Key Derivation . . . . . . . . . . . . . . . 8
3. AVP Definitions for SASL in Diameter . . . . . . . . . . . . 9
3.1. SASL-Mechanism . . . . . . . . . . . . . . . . . . . . . 10
3.2. SASL-Token . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. SASL-Channel-Binding . . . . . . . . . . . . . . . . . . 11
3.4. Key Groups for Derived Application Keys . . . . . . . . . 11
4. Diameter Session Requirements for SASL . . . . . . . . . . . 12
5. Diameter Message Requirements for SXOVER-PLUS . . . . . . . . 13
5.1. C2S-Init Requests over Diameter . . . . . . . . . . . . . 13
5.2. S2C-Init Responses over Diameter . . . . . . . . . . . . 14
5.3. C2S-Cont Requests over Diameter . . . . . . . . . . . . . 14
5.4. S2C-Cont Responses over Diameter . . . . . . . . . . . . 15
6. Running Diameter as a SASL Backend . . . . . . . . . . . . . 15
6.1. Diameter is an SCTP service . . . . . . . . . . . . . . . 16
6.2. Reliance on DANE and DNSSEC . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Normative References . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Centralised handing of SASL over Diameter . . . . . 20
Appendix B. Support Levels for Realm Crossover . . . . . . . . . 24
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
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 [RFC4422] and GSS-API [RFC2743] together is instrumental in
authentication across a wide range of application protocols; it
allows these protocols to abstract from the actual authentication
Van Rein Expires 17 April 2023 [Page 2]
Internet-Draft Diameter SASL October 2022
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:
+--------+ SASL +--------+ SASL +---------+
| Proto |-----------> | 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 [RFC6698]. 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 [RFC5056] [RFC5801]; 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.
Van Rein Expires 17 April 2023 [Page 3]
Internet-Draft Diameter SASL October 2022
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.
2. Messages of SXOVER-PLUS
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.
2.1. Preparation for Messaging
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 [RFC4120] 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.
Van Rein Expires 17 April 2023 [Page 4]
Internet-Draft Diameter SASL October 2022
2.2. Initial Client-to-Server Message
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 [RFC6116]].
This notation is compatible with the GS2 bridge [RFC5801].
When the client connects to the foreign service over TLS, the tls-
exporter form [RFC9266] 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 [RFC5929]. 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:
C2S-Init ::= [APPLICATION 1] IMPLICIT SEQUENCE {
clirnd OCTET STRING, -- Entropy to allow client variety
keyno KeyNumber, -- Given realm and encalg, identify...
encalg EncryptAlg, -- ...the key for keymap decryption...
keymap OCTET STRING -- ...yielding server-acceptable data
}
EncryptAlg ::= Int32
KeyNumber ::= UInt32
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 [RFC3961], 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 [RFC6113]]
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
Van Rein Expires 17 April 2023 [Page 5]
Internet-Draft Diameter SASL October 2022
this is similar to the KRB-FX-C2 procedure [Section 5.1 of [RFC6113]]
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.)
2.3. Initial Server-to-Client Message
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:
S2C-Init ::= [APPLICATION 2] IMPLICIT SEQUENCE {
srvrnd OCTET STRING, -- Entropy to allow server variety
mechlist IA5String -- Available SASL mechanisms
}
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
[RFC6113]] 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.
2.4. Continued Client-to-Server Messages
Further messages from the client to the server hold DER content
encrypted with key K2, following this ASN.1 format:
Van Rein Expires 17 April 2023 [Page 6]
Internet-Draft Diameter SASL October 2022
C2S-Cont ::= [APPLICATION 3] IMPLICIT SEQUENCE {
mechsel IA5String OPTIONAL, -- SASL mechanism name selection
c2s SaslToken -- NULL or SASL token passed
-- from client to server
}
SaslToken ::= CHOICE {
token OCTET STRING,
no-token NULL
}
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.
2.5. Continued Server-to-Client Messages
Further messages from the server to the client hold DER content
encrypted with key K2, following this ASN.1 format:
S2C-Cont ::= [APPLICATION 4] IMPLICIT SEQUENCE {
success BOOLEAN DEFAULT FALSE, -- When TRUE, s2c is an
-- additional token
s2c SaslToken -- NULL or SASL token from
-- server to client
}
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.
Van Rein Expires 17 April 2023 [Page 7]
Internet-Draft Diameter SASL October 2022
2.6. Using SXOVER-PLUS with GSS-API
SXOVER-PLUS can be used with GSS-API [RFC2743] 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 [RFC2744] to gss_init_sec_context() and
gss_accept_sec_context() MUST follow the GS2 data structure for
channel binding information [Section 5.1 of [RFC5801]]. 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:" [RFC5056] 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 [RFC2743]] 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 [RFC5801]], 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.
2.7. Application Key Derivation
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 [RFC5801]] 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.
Van Rein Expires 17 April 2023 [Page 8]
Internet-Draft Diameter SASL October 2022
In general, security layers may be derived from the key K2 by yet
another pass through the PRF+() function [Section 5.1 of [RFC6113]].
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:
Pepper as 32 ASCII bytes | Purpose | Direction
---------------------------------+----------+------------------
SXOVER-PLUS/GSS-API/SIGN-C2S-KEY | signing | client --> 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 [RFC6734] 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.
3. AVP Definitions for SASL in Diameter
SASL messages in Diameter use a number of AVPs [Section 4 of
[RFC6733]] 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 [RFC7155], 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 [RFC7542]] 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
Van Rein Expires 17 April 2023 [Page 9]
Internet-Draft Diameter SASL October 2022
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 [RFC7542].
The Identity Domain may choose to send back key material as part of a
successful AA-Answer, using [RFC6113]. Triggers to do this are not
specified hierein, but possible reasons could be founded on user
identity or Foreign Server identity.
3.1. SASL-Mechanism
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 [RFC4422]] 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.
3.2. SASL-Token
The SASL-Token AVP has AVP Code TBD1 and is of type OctetString. It
may be passed in AA-Request and AA-Answer messages.
Van Rein Expires 17 April 2023 [Page 10]
Internet-Draft Diameter SASL October 2022
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.
3.3. SASL-Channel-Binding
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.
3.4. Key Groups for Derived Application Keys
The key derivation mechanism in Section 2.7 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 [RFC6734]. This groups key
information under a Key AVP. Keys derived with the procedure in
Section 2.7 use a Key group containing these AVPs:
Van Rein Expires 17 April 2023 [Page 11]
Internet-Draft Diameter SASL October 2022
Key-Type 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.
Key-Name 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.
Keying-Material 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.
Key-Lifetime 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.
Key-SPI 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.
4. Diameter Session Requirements for SASL
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.
Van Rein Expires 17 April 2023 [Page 12]
Internet-Draft Diameter SASL October 2022
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.
5. Diameter Message Requirements for SXOVER-PLUS
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.
5.1. C2S-Init Requests over Diameter
To send C2S-Init the Diameter client MUST include at least the
following AVPs in an AA-Request [Section 3.1 of [RFC7155]]:
Destination-Realm 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 [RFC6116]] 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
Van Rein Expires 17 April 2023 [Page 13]
Internet-Draft Diameter SASL October 2022
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.
SASL-Mechanism MUST be set to the fixed string SXOVER-PLUS for this
SASL mechanism's name;
SASL-Token MUST be set to the GS2 header and C2S-Init;
SASL-Channel-Binding 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.
5.2. S2C-Init Responses over Diameter
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:
Result-Code MUST be set to an error or failure code [Section 7.1 of
[RFC6733]].
The initialisation of SASL forms a S2C-Init response, and an AA-
Answer MUST be sent with the following AVPs:
Result-Code MUST be set to the value DIAMETER_MULTI_ROUND_AUTH
[Section 7.1.1 of [RFC6733]];
SASL-Token MUST be set to the S2C-Init value.
5.3. C2S-Cont Requests over Diameter
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:
SASL-Token MUST be set to the C2S-Cont value from the SASL client;
SASL-Mechanism MUST NOT be sent;
SASL-Channel-Binding MUST NOT be sent;
User-Name MAY be sent but MUST NOT be processed when received by
implementations of this specification;
Van Rein Expires 17 April 2023 [Page 14]
Internet-Draft Diameter SASL October 2022
User-Password MOST NOT be sent.
5.4. S2C-Cont Responses over Diameter
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:
Result-Code is set to the value DIAMETER_MULTI_ROUND_AUTH
[Section 7.1.1 of [RFC6733]];
SASL-Token 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:
Result-Code is set to an error or failure code [Section 7.1 of
[RFC6733]].
If the SASL exchange succeeds, then the AA-Answer MUST represent that
in the following AVPs:
Result-Code is set to a success code [Section 7.1.2 of [RFC6733]];
SASL-Token is included when the SASL exchange produced an additional
token upon success [Section 4 of [RFC4422]];
User-Name may be provided, and then contains the utf8-username part
of a NAI [RFC7542], 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.
6. Running Diameter as a SASL Backend
Following are a few practical considerations in relation to the
Diameter connectivity for SASL.
Van Rein Expires 17 April 2023 [Page 15]
Internet-Draft Diameter SASL October 2022
6.1. Diameter is an SCTP service
Diameter is primarily an SCTP-based protocol [RFC6733], 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 [RFC6951], 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.
6.2. Reliance on DANE and DNSSEC
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 [RFC6698]. 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.
Van Rein Expires 17 April 2023 [Page 16]
Internet-Draft Diameter SASL October 2022
7. Security Considerations
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
Van Rein Expires 17 April 2023 [Page 17]
Internet-Draft Diameter SASL October 2022
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.)
8. IANA Considerations
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:
AVP Code | Attribute Name | Reference
---------+----------------------+------------
TBD0 | SASL-Mechanism | (this spec)
TBD1 | SASL-Token | (this spec)
TBD2 | SASL-Channel-Binding | (this spec)
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:
AVP Value | Attribute Name | Reference
----------+----------------+------------
TBD3 | SXOVER-PLUS | (this spec)
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:
Mechanism | Usage | Reference | Owner
------------+--------+------------+-------------------------------------
SXOVER-PLUS | COMMON | (this doc) | Rick van Rein <rick@openfortress.nl>
9. Normative References
Van Rein Expires 17 April 2023 [Page 18]
Internet-Draft Diameter SASL October 2022
[I-D.vanrein-internetwide-realm-crossover]
van Rein, R., "InternetWide Identities with Realm
Crossover", Work in Progress, Internet-Draft, draft-
vanrein-internetwide-realm-crossover-01, 6 October 2022,
<https://www.ietf.org/archive/id/draft-vanrein-
internetwide-realm-crossover-01.txt>.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743,
DOI 10.17487/RFC2743, January 2000,
<https://www.rfc-editor.org/info/rfc2743>.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, DOI 10.17487/RFC2744, January 2000,
<https://www.rfc-editor.org/info/rfc2744>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
2005, <https://www.rfc-editor.org/info/rfc3961>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<https://www.rfc-editor.org/info/rfc4120>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
July 2010, <https://www.rfc-editor.org/info/rfc5801>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication", RFC 6113,
DOI 10.17487/RFC6113, April 2011,
<https://www.rfc-editor.org/info/rfc6113>.
Van Rein Expires 17 April 2023 [Page 19]
Internet-Draft Diameter SASL October 2022
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011,
<https://www.rfc-editor.org/info/rfc6116>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
[RFC6734] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute-
Value Pairs for Cryptographic Key Transport", RFC 6734,
DOI 10.17487/RFC6734, October 2012,
<https://www.rfc-editor.org/info/rfc6734>.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951,
DOI 10.17487/RFC6951, May 2013,
<https://www.rfc-editor.org/info/rfc6951>.
[RFC7155] Zorn, G., Ed., "Diameter Network Access Server
Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
<https://www.rfc-editor.org/info/rfc7155>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC9266] Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,
DOI 10.17487/RFC9266, July 2022,
<https://www.rfc-editor.org/info/rfc9266>.
Appendix A. Centralised handing of SASL over Diameter
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
Van Rein Expires 17 April 2023 [Page 20]
Internet-Draft Diameter SASL October 2022
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.
Quick-DiaSASL DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- ## SASL ready for Diameter
--
-- This is targeted at Diameter backends and avoids loading all of
-- Diameter into applications.
--
-- Open a connection; return is DiaSASL-Open-Answer.
-- The service-realm defines the context of the
-- identity provider; this is where Diameter requests
-- should be send, and it helps to determine what
-- sasl-mechanisms may be used.
--
-- The front-end is identified by a service-trunk code
-- (for the long-term relation between a front-end and
-- back-end) and/or a service-proto protocol that can
-- be used while driving SASL (it could be the "imap"
-- part before the "imap/imap.example.com"PrincipalName
-- for a service in a Kerberos Ticket).
--
DiaSASL-Open-Request ::= [APPLICATION 10] IMPLICIT SEQUENCE {
service-realm [1] UTF8String,
service-trunk [8] INTEGER OPTIONAL,
service-proto [9] IA5String OPTIONAL
}
-- Close a connection; session-id identifies which
-- and there is no response. This is ignored when the
-- session-id is unknown; the call is not required
-- after a DiaSASL-Authn-Answer that sets a value for
-- final-comerr, but it is harmless when sent anyway.
--
DiaSASL-Close-Request ::= [APPLICATION 11] IMPLICIT SEQUENCE {
Van Rein Expires 17 April 2023 [Page 21]
Internet-Draft Diameter SASL October 2022
session-id [2] OCTET STRING
}
-- Relay an authentication request message; response is
-- DiaSASL-Authn-Answer with a copied session-id.
--
DiaSASL-Authn-Request ::= [APPLICATION 12] IMPLICIT SEQUENCE {
session-id [2] OCTET STRING,
sasl-mechanism [3] IA5String OPTIONAL,
sasl-channel-binding [4] OCTET STRING OPTIONAL,
sasl-token [5] OCTET STRING OPTIONAL
}
-- This is the response to a DiaSASL-Open-Request.
--
-- The final-comerr is set when Diameter was conclusive.
-- It is an error code from com_err to allow for errors,
-- but it may be sufficient to know that 0 indicates success
-- and everything else is a failure.
--
-- The service-realm is copied from the Diasasl-Open-Request
-- so it can be used to match; the session-id will continue
-- to identify this session in requests and responses.
--
-- The sasl-mechanisms holds a space-separated string of
-- SASL mechanism names.
--
DiaSASL-Open-Answer ::= [APPLICATION 13] IMPLICIT SEQUENCE {
final-comerr [0] INTEGER (-2147483648..2147483647) OPTIONAL,
-- Only set when Diameter was conclusive.
-- 0 for success, different for failure.
-- The code is a com_err code, so int32_t.
service-realm [1] UTF8String,
session-id [2] OCTET STRING,
sasl-mechanisms [3] IA5String
}
-- This is the response to a DiaSASL-Authn-Request.
--
-- The final-result is only set if Diameter was conclusive.
-- It is an error code from com_err to allow for errors,
-- but it may be sufficient to know that 0 indicates success
-- and everything else is a failure.
--
-- Only a successful authentication response can hold values
-- for client-userid and client-domain. The latter overrides
-- the initial realm, which was provided in the open call,
-- but may be substituted as a result of Realm Crossover.
Van Rein Expires 17 April 2023 [Page 22]
Internet-Draft Diameter SASL October 2022
-- The client-userid is the local part and may be absent on
-- anonymous sessions; the client-userid value is approved
-- by the local Diameter peer as having come from a Diameter
-- Diameter peer that tends to client-domain.
--
DiaSASL-Authn-Answer ::= [APPLICATION 14] IMPLICIT SEQUENCE {
final-comerr [0] INTEGER (-2147483648..2147483647) OPTIONAL,
-- Only set when Diameter was conclusive.
-- 0 for success, different for failure.
-- The code is a com_err code, so int32_t.
session-id [2] OCTET STRING,
sasl-token [5] OCTET STRING OPTIONAL,
client-userid [6] UTF8String OPTIONAL,
client-domain [7] UTF8String OPTIONAL
}
-- Requests are Open, Close and Authn requests. This simple
-- CHOICE differentiates between the variants.
-- Note that no extra tags are needed; the [APPLICATION n]
-- tag can be used, or the presence of fields in variants.
--
DiaSASL-Request ::= CHOICE {
open-request DiaSASL-Open-Request,
close-request DiaSASL-Close-Request,
authn-request DiaSASL-Authn-Request
}
-- Answers are sent in response to Open and Authn requests.
-- This simple CHOICE differentiates between the variants.
-- Note that no extra tags are needed; the [APPLICATION n]
-- tag can be used, or the presence of fields in variants.
--
DiaSASL-Answer ::= CHOICE {
open-answer DiaSASL-Open-Answer,
authn-answer DiaSASL-Authn-Answer
}
-- ## A simple API for DiaSASL
-- A `diasasl` API only needs a small number of calls:
-- http://quick-sasl.arpa2.net/group__quickdiasasl.html
-- This presents only a modest extension to existing software,
-- and easily merges into a variety of concurrency models.
END
Van Rein Expires 17 April 2023 [Page 23]
Internet-Draft Diameter SASL October 2022
Appendix B. Support Levels for Realm Crossover
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 Appendix A 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.
Appendix C. Acknowledgements
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.
Author's Address
Van Rein Expires 17 April 2023 [Page 24]
Internet-Draft Diameter SASL October 2022
Rick van Rein
OpenFortress BV
Haarlebrink 5
Enschede
Email: rick@openfortress.nl
Van Rein Expires 17 April 2023 [Page 25]
