Network Working Group R. Van Rein
Internet-Draft ARPA2.net
Intended status: Standards Track April 10, 2019
Expires: October 12, 2019
Realm Crossover for SASL via Diameter
draft-vanrein-diameter-sasl-01
Abstract
SASL is used for authentication in many application protocols. This
specification extends it to allow credentials from a home realm to be
used against external services. To this end, it introduces a secure
end-to-end wrapper for SASL traffic and a link back from to the home
realm based on Diameter.
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 October 12, 2019.
Copyright Notice
Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Van Rein Expires October 12, 2019 [Page 1]
Internet-Draft Diameter SASL April 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The SASL crossover mechanism SXOVER . . . . . . . . . . . . . 3
2.1. SXOVER initial response . . . . . . . . . . . . . . . . . 4
2.2. SXOVER initial challenge . . . . . . . . . . . . . . . . 5
2.3. SXOVER responses . . . . . . . . . . . . . . . . . . . . 5
2.4. SXOVER challenges . . . . . . . . . . . . . . . . . . . . 6
3. Embedding SASL in Diameter . . . . . . . . . . . . . . . . . 6
3.1. AVP Definitions for SASL . . . . . . . . . . . . . . . . 6
3.1.1. SASL-Mechanism . . . . . . . . . . . . . . . . . . . 6
3.1.2. SASL-Token . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. SASL-Channel-Binding . . . . . . . . . . . . . . . . 7
4. Running Diameter as a SASL Backend . . . . . . . . . . . . . 7
4.1. Diameter is an SCTP service . . . . . . . . . . . . . . . 8
4.2. Reliance on DANE and DNSSEC . . . . . . . . . . . . . . . 8
4.3. Foreign Service SASL Mechanisms . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
It is common for Internet users to combine services from a varierity
of providers. Along with this, an ad hoc practice has arisen of
using the local identity schemes of these providers. These are not
integrated, and the practice tends to reduce the control of users
over their online identity. A solution to this is generic support
for 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] is instrumental in authentication across a wide range
of application protocols; it allows those protocols to abstract from
the actual authentication mechanisms, and at the same time it allows
authentication mechanisms to not be concerned about the application
protocol. SASL can easily be funneled from one protocol into
another, modulo a number of security concerns.
Diameter and its Network Access application are instrumental in
authenticating a user under a realm, while not providing the
resources that an application protocol would imply. Moreover,
Diameter service can be declared under a domain name in a manner that
is standardised, scalable and secure.
Van Rein Expires October 12, 2019 [Page 2]
Internet-Draft Diameter SASL April 2019
This allows a foreign server to authenticate a client to authenticate
with its home realm:
+--------+ SASL +--------+ SASL +---------+
| Client |-----------> | Server | ---------> | Realm |
+--------+ AppProto +--------+ Diameter +---------+
|| || ||
john@example.com find SRV, TLSA example.com
& credential relay SASL authentication
Diameter can send a mere notification of authentication, and the
foreign server can use DANE [RFC6698] to validate the origin of these
notification. Diameter in the foreign server will authenticate to
the home realm, which may then decide to add resources beyond the
basic notification of authentication.
SASL mechanisms are not generally protected against attacks by men in
the middle named Eve. This is usually compensated for by wrapping
the application protocol in TLS, but since that would only protect
one leg of the intended realm crossover, this raises a need for end-
to-end encryption. This can be established along with other
credentials for the home realm, but an end-to-end mechanism needs to
be defined. This specification introduces a wrapper for that pupose,
and nests a SASL exchange with the home realm under its cloak.
Finally, to avoid the use of one authentication exchange to validate
another, it is advisable to incorporate channel binding [RFC5056]
[RFC5801] when making use of backends. When passing SASL tokens
between application protocol and Diameter backend, the channel
binding information from the application protocol would be supplied
as a side-note to the Diameter backcall.
2. The SASL crossover mechanism SXOVER
SXOVER is a SASL authentication mechanism that encrypts all
information between a SASL client and SASL server, except for the
realm name to which they direct the authentication. The realm can be
used by an foreign server to redirect SXOVER to a home realm, for
instance using Diameter. SXOVER does not reveal success or failure
to this foreign server, but Diameter would release this information
in a manner that requires no knowledge of the SASL exchange.
The first SXOVER message supplies a session key to the SASL server.
The server responds with a list of SASL mechanisms to be used under
the cloak of the session key. Then, the client selects a mechanism
and the customary exchange follows, but under protection of the
session key.
Van Rein Expires October 12, 2019 [Page 3]
Internet-Draft Diameter SASL April 2019
All multi-byte integer values in SXOVER are represented in network
byte order. When these values represent a counter, then it is a
32-bit unsigned integer whose increment may wrap around from the
highest value to zero. A NUL byte is a single byte whose bits are
all zero; a NUL-terminated string is a string with no inner NUL and
an additional NUL following it. Length-prefixed byte strings consist
of a 16 bit unsigned integer up to 65534 with the length followed by
that number of bytes with the value. Optional length-prefixed byte
strings can take all values of length-prefix byte strings or, if they
are opted out from, then their value consists of a 16-but unsigned
integere valued 65535. Certain information in SXOVER is encrypted
with the encrypt operation [Section 3 of [RFC3961]] with default
initial state and key usage TODO; this always includes integrity
protection.
TODO: The number for key usage is KIP_KEYUSAGE_MAPPING and comes from
the Keyful Identity Protocol.
2.1. SXOVER initial response
The SXOVER exchange starts with an initial response message,
traveling along the selection of SXOVER as the SASL mechanism. This
initial response contains the following:
realm the domain name, in lowercase ASCII and no trailing dot, under
which the client wants to authenticate. This is a NUL-
terminated string.
inictr is an initial counter value for this SXOVER session. It can
be used by the client to keep sessions separated for replay
prevention.
kvno is a 32-bit unsigned integer, holding a key version number
[RFC4120] for a long-term key established between the client
and its home realm. To complete the identity of the key, the
following field is also needed.
enctype is a 32-bit signed integer, holding an encryption type
following the IANA registry for Kerberos encryption types.
This field and kvno together identify a long-term key shared
between the client and its realm.
seskey provides a random seed from which a session key can be
formed, encrypted with the long-term key for the client and its
realm. The session key will use the same enctype, which
defines a random-to-key function with a required key-generation
seed-length [Section 3 of [RFC3961]]. Once derived, the
Van Rein Expires October 12, 2019 [Page 4]
Internet-Draft Diameter SASL April 2019
session key is used for encryption in the remaining SXOVER
session.
When this arrives at the foreign server, the domain name can be
tested to see if a session to the realm already exiss; if not, a
lookup of _diameter._sctp SRV records under the realm (which is a
domain name) is used to locate a home realm server to connect to.
Once a session to the domain's Diameter server is established, the
SXOVER token can be forwarded in whole, including the domain name.
2.2. SXOVER initial challenge
The initial SXOVER challenge is a server's response in which it
presents the choice of mechanism names to use under the cloak of
SXOVER. It does not present any other information. The following
information is sent as one block under protection of the seskey:
ctr is a counter that is incremented from the inictr in the initial
response.
realm repeats the NUL-terminated string with the domain name from the
initial response.
mechlist is a NUL-terminated string with a space-separated SASL
mechanism names.
chanbindmth is a NUL-terminated string with the name of a channel
binding method. TODO:REALLY?
chanbindval is a length-prefixed string with the value of the
channel binding. TODO:REALLY?
2.3. SXOVER responses
Further SXOVER responses are essentially SASL responses and initial
responses, encrypted under the seskey, but there is one exception;
the first response must select a SASL mechanism. There is a separate
provision for sending no data, distinguishable from empty data, if
this is desired by the SASL mechanism:
ctr is a counter, incremented from the prior message in this SXOVER
session.
opt_mechsel is an optional NUL-terminated string. In the first
SXOVER response after the initial response, it MUST be present.
When present, it mentions a SASL mechanism name to start under
the cloak of SXOVER.
Van Rein Expires October 12, 2019 [Page 5]
Internet-Draft Diameter SASL April 2019
opt_token is an optional length-prefixed token for the SASL
mechanism selected with the most recently provided opt_mechsel.
2.4. SXOVER challenges
Further SXOVER challenges are essentially SASL challenges and initial
challenges, encrypted under the seskey. There is a separate
provision for sending no data, distinguishable from empty data, if
this is desired by the SASL mechanism:
ctr is a new 32-bit counter value, 1 more than the prior message in
the SXOVER session.
opt_token is an optional length-prefixed token for the selected SASL
mechanism that is protected by SXOVER.
opt_extra is an optional length-prefixed byte string with extra
information, as provided by SASL alongside a successful
response.
3. Embedding SASL in Diameter
SASL messages in Diameter use a number of AVPs [RFC6733] that are
defined for this purposes. They occur in those combinations that are
defined for SASL.
SASL over Diameter can only be used to relay the SXOVER mechanism to
a home realm. This means that no negotiation of mechanisms is needed
at the Diameter level; this is handled under the SXOVER cloak. The
same holds for any negotation of channel binding; it is part of the
cloacked SASL exchange.
3.1. AVP Definitions for SASL
These AVPs are added to the set that is used with the Network Access
application, and can therefore be used in AA-Request and AA-Answer
messages. On top of that, the SASL-Mechanisms AVP may also occur in
a Capabilities Exchange Answer. The User-Name AVP MUST be supplied
in the AA-Answer to inform the server about the user name that the
backend decided on; the server MAY send a hint requesting a value in
the User-Name AVP in the AA-Request.
3.1.1. SASL-Mechanism
The SASL-Mechanism AVP has AVP Code TBD0. This specification only
uses the mechanism name SXOVER as a value for this AVP. It MUST be
included in the first message of an SXOVER exchange sent to the home
realm, and it SHOULD be verified by the home realm upon reception.
Van Rein Expires October 12, 2019 [Page 6]
Internet-Draft Diameter SASL April 2019
Its purpose is mostly to distinguish this specification from
potential future specifications to encapsulate SASL in Diameter.
Though not used in this specification, this AVP may also be supplied
from the home realm to the Diameter client to hold a space-separated
list of SASL mechanisms.
3.1.2. SASL-Token
The SASL-Token AVP has AVP Code TBD1. Note that 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.
3.1.3. SASL-Channel-Binding
The SASL-Channel-Binding AVP has AVP Code TBD2. It SHOULD appear
along the first SASL-Token AVP for a Network Access session. The AVP
may occur more than once, to indicate support of multiple forms of
channel binding.
When the client connects to the foreign service over TLS, the tls-
unique form [RFC5929] of channel binding is RECOMMENDED. Specific
foreign servers may however be exempted by the home realm.
The contents of this AVP are:
name is the standard name of the channel binding information,
followed by a zero-valued byte.
value contains the bytes of the channel binding information.
Normally, channel binding information should be sourced from the
underlying communications channel, but this information is not
available to backend running Diameter. To enable channel binding
between the 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. Channel binding provides better
guarantees than the simple inictr/ctr mechanism used in SXOVER.
4. Running Diameter as a SASL Backend
Following are a few practical considerations in relation to the
Diameter connectivity for SASL.
Van Rein Expires October 12, 2019 [Page 7]
Internet-Draft Diameter SASL April 2019
4.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 carrier. 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
client-only machines, but it sacrifices several benefits of the SCTP
carrier. Since the SASL Diameter embedding typically involves no
client systems, 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 home realms, so this additional option is RECOMMENDED for
situations where a fallback for plain 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.
4.2. Reliance on DANE and DNSSEC
Diameter always involves the use of TLS, but there is a number of
choices concerning the validation of connections through DNSSEC and
DANE. It is the home realm's prerogative what level of protection it
upholds for its client identities, but any foreign server can choose
to raise the bar by setting a minimum standard.
DNSSEC is a useful protection mechanism for the _diameter._sctp SRV
records that lead to the Diameter host and its port for the home
realm. This does not protect against forged IP addresses, 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,
should be used as specified for DANE [RFC6698].
Home realms that choose to be light on such measures risk that
identities are forged, in spite of their use of TLS. Foreign servers
MAY choose to reject such home realms, or alternatively be more
inquisitive about the certificates used.
Van Rein Expires October 12, 2019 [Page 8]
Internet-Draft Diameter SASL April 2019
4.3. Foreign Service SASL Mechanisms
A foreign server MUST offer SXOVER if it wants to support realm
crossover via Diameter as specified herein. In addition, it MAY
offer SASL mechanisms that it resolves locally.
The ANONYMOUS method for SASL [RFC4505] may be offered for guest
access. The PLAIN method [RFC4616] continues to be ill-advised,
especially with modern methods such as SCRAM [RFC5802] to address the
needs of local accounts with password validation.
The HTTP protocol does not yet support SASL, and it is not optimal
from a security viewpoint to integrate credentials in the dynamic
environment of HTML, where dynamic content from potentially
undesirable origins come together in a manner not controllable to the
end user. One remedy is to use HTTP and its authentication methods
that match with SASL, such as SCRAM for HTTP [RFC7804]. Another
remedy is to switch to generic SASL embedding in HTTP
[TODO:REF:draft-vanrein-httpauth-sasl] and gain replay protection
through channel binding.
Many application protocols offer richer semantics than HTTP, making
them better targets for automation. Their reliance on SASL has made
them less tractable as a service to third parties. One reason for
introducing SXOVER is in the hope to make it possible to have those
semantically rich applications as a third-party offering.
5. Security Considerations
From the perspective of the client and the home realm, the safety of
the SASL credentials is paramount. Since not all SASL mechanisms are
safe from inspection by the foreign server, and since TLS cannot help
there either, there is a need for some caution.
The limitation of the Diameter carrier for SASL to SXOVER reduces
this risk, by only authenticating SASL mechanisms under end-to-end
encryption between the client and home realm. It is generally
understood that clients must not send unprotected SASL authentication
attempts to arbitrary parties, but SXOVER adds a facility that is
safe for clients to use in this manner. The SXOVER mechanism could
even be used without TLS protection.
From the perspective of the foreign server, the security concern is
to be certain of an identity. The home realm sends this information
back when SXOVER authentication succeeds, and the communication doing
so is protected with TLS. The certificate of the Diameter server can
be validated, and for cautious home realms there could be an
additional check based on DANE.
Van Rein Expires October 12, 2019 [Page 9]
Internet-Draft Diameter SASL April 2019
6. IANA Considerations
This specification defines three AVP Codes for use with Diameter.
IANA registers 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)
7. References
7.1. Normative References
[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>.
Van Rein Expires October 12, 2019 [Page 10]
Internet-Draft Diameter SASL April 2019
[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>.
[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>.
7.2. Informative References
[RFC4505] Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505,
DOI 10.17487/RFC4505, June 2006,
<https://www.rfc-editor.org/info/rfc4505>.
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616,
DOI 10.17487/RFC4616, August 2006,
<https://www.rfc-editor.org/info/rfc4616>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010,
<https://www.rfc-editor.org/info/rfc5802>.
[RFC7804] Melnikov, A., "Salted Challenge Response HTTP
Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
March 2016, <https://www.rfc-editor.org/info/rfc7804>.
Appendix A. Acknowledgements
Thanks go to TODO for useful discussions during the creation of this
document.
Author's Address
Van Rein Expires October 12, 2019 [Page 11]
Internet-Draft Diameter SASL April 2019
Rick van Rein
ARPA2.net
Haarlebrink 5
Enschede, Overijssel 7544 WP
The Netherlands
Email: rick@openfortress.nl
Van Rein Expires October 12, 2019 [Page 12]