[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Informational                          January 21, 2020
Expires: July 24, 2020

           Realm Crossover for SASL and GSS-API via Diameter


   SASL and GSS-API are used for authentication in many application
   protocols.  This specification extends them to allow credentials of a
   home realm to be used against external services.  To this end, it
   introduces end-to-end encryption for SASL that is safe to relay to
   the client's home realm.

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 July 24, 2020.

Copyright Notice

   Copyright (c) 2020 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 July 24, 2020                 [Page 1]

Internet-Draft                Diameter SASL                 January 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Messages of GS2-SXOVER-PLUS . . . . . . . . . . . . . . . . .   3
     2.1.  Initial Client-to-Server Message  . . . . . . . . . . . .   4
     2.2.  Initial Server-to-Client Message  . . . . . . . . . . . .   5
     2.3.  Continued Client-to-Server Messages . . . . . . . . . . .   6
     2.4.  Continued Server-to-Client Messages . . . . . . . . . . .   6
   3.  GS2-SXOVER-PLUS as a GS2 Mechanism  . . . . . . . . . . . . .   7
     3.1.  Encrypting GS2-SXOVER-PLUS Messages . . . . . . . . . . .   7
     3.2.  Initial Round-trip Optimisation . . . . . . . . . . . . .   8
     3.3.  Initial Header for GSS-API  . . . . . . . . . . . . . . .   8
     3.4.  Initial Header for SASL . . . . . . . . . . . . . . . . .   9
   4.  AVP Definitions for SASL in Diameter  . . . . . . . . . . . .  10
     4.1.  SASL-Mechanism  . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  SASL-Token  . . . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  SASL-Channel-Binding  . . . . . . . . . . . . . . . . . .  11
   5.  Diameter Message Requirements for GS2-SXOVER-PLUS . . . . . .  11
     5.1.  C2S-Init Requests over Diameter . . . . . . . . . . . . .  12
     5.2.  S2C-Init Responses over Diameter  . . . . . . . . . . . .  12
     5.3.  C2S-Cont Requests over Diameter . . . . . . . . . . . . .  13
     5.4.  S2C-Cont Responses over Diameter  . . . . . . . . . . . .  14
   6.  Running Diameter as a SASL Backend  . . . . . . . . . . . . .  14
     6.1.  Diameter is an SCTP service . . . . . . . . . . . . . . .  14
     6.2.  Reliance on DANE and DNSSEC . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

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 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.

Van Rein                  Expires July 24, 2020                 [Page 2]

Internet-Draft                Diameter SASL                 January 2020

   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.

   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
   notifications.  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-crossing authentication exchange, there
   is 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.  Messages of GS2-SXOVER-PLUS

   GS2-SXOVER-PLUS establishes a session key and continues with an
   encrypted, but otherwise normal SASL exchange.  This cloak provides
   end-to-end encryption for the contained SASL exchange, which allows
   it to be passed through a foreign server.  This section defines the
   messages involved in the GS2-SXOVER-PLUS exchange in isolation, later
   sections specify how this fits into GSS-API and SASL contexts, and
   how these travel to the home realm's network access server.

Van Rein                  Expires July 24, 2020                 [Page 3]

Internet-Draft                Diameter SASL                 January 2020

   By announcing the GS2-SXOVER-PLUS mechanism for SASL, a foreign
   server declares it is willing to relay SASL messages for that
   mechanism to the authentication realm indicated by the client in its
   first GS2-SXOVER-PLUS message in a plaintext form.  Later sections
   define a standard mechanism for relaying such messages over Diameter,
   using DNSSEC and DANE so that the result can be trusted to have come
   from the indicated realm and thus warrant any user name scoped under
   that realm.  Offering GS2-SXOVER-PLUS does not preclude the offering
   of other SASL mechanisms; for instance, ANONYMOUS may be useful to
   allow clients to choose guest access.

2.1.  Initial Client-to-Server Message

   The GS2-SXOVER-PLUS exchange is initiated by the client, by sending a
   C2S-Init message:

      inictr   Counter,       -- Initial counter value
      keyno    KeyNumber,     -- With realm and encalg, identifies...
      encalg   EncryptAlg,    -- ...the key for svckeymud decryption
      seskey   OCTET STRING   -- RFC 3961 encrypted, key usage 1864

   Counter ::= INTEGER (0..4294967295)             -- Unsigned 32-bit
   KeyNumber ::= INTEGER (0..4294967295)           -- Unsigned 32-bit
   EncryptAlg ::= INTEGER (-2147483648..2147483647)  -- Signed 32-bit

   The inictr value is used as a bit of entropy, and will be incremented
   by one for every next message in the same flow.  This helps to bind
   messages into one flow and to distinguish among flows.  Though
   helpful to protect against replay attacks, dynamic challenges and
   channel binding offer better protection.

   The keyno and encalg values present identification information for a
   key at the Diameter/SASL server, and the seskey is a representation
   of a session key suitable for decryption with that identified key.
   The method by which the keyno and encalg and the key itself are
   established is not defined here, because its choice is local to the
   client's realm.  The reason for not authenticating with this key is
   that anonymous encryption keys are much easier to establish than
   authentication keys.  One possible mechanism is KIP, the Keyful
   Identity Protocol, but it is not prescribed herein.

   The value of the seskey MAY be locally determined, but by default it
   SHOULD be a random seed that can serve as input to the random-to-key
   function with the required key-generation seed-length [Section 3 of
   [RFC3961]] for a session key with the same encryption algorithm
   enctype as the identified key.  The random seed is protected by

Van Rein                  Expires July 24, 2020                 [Page 4]

Internet-Draft                Diameter SASL                 January 2020

   encryption to the identified key using the Encrypt function
   [Section 3 of [RFC3961]], which always involves authenticity.  The
   key usage number is shared from the independent KIP protocol, and is
   set to KIP_KEYUSAGE_MAPPING or 1864.

2.2.  Initial Server-to-Client Message

   In both SASL and GSS-API, this first message from server to client is
   passed as an S2C-Init message:

      ctr        Counter,                -- Counter value is inictr+1
      realm      IA5String,              -- Secure realm confirmation
      mechlist   SEQUENCE OF IA5String   -- Available SASL mechanisms

   The first message from the server to the client is named the Initial
   Response in SASL.  This message presents the client with a choice of
   mechanism names to use under the cloak of GS2-SXOVER-PLUS.  In
   addition, it securely confirms the realm name that will be assumed in
   the upcoming exchange.

   GS2-SXOVER-PLUS makes no assumptions about the mechanisms supported
   at the home realm.  Instead, S2C-Init lists mechanisms specific to
   the home realm of the client, which are concealed from the foreign
   server, so it cannot influence the list.

   The ctr value is simply inictr incremented by 1, with a wrap-around
   to stay within an unsigned 32-bit range.  It MUST be validated by the
   SASL client.  The counter mechanism is both a protection against
   message resending and a means of having concurrent SASL exchanges if
   the client wants to.

   The realm is repeated from the GS2-SXOVER-PLUS request, but this time
   it is protected by the session key.  Therefore, the SASL client MUST
   validate it before starting the wrapped SASL exchange.

   The mechlist informs the SASL client of the mechanisms available for
   authentication against the SASL server.  These can be used for the
   wrapped SASL exchange.  The list is not related to any mechanism list
   that the foreign server will have sent before.  Specifically, GS2-
   SXOVER-PLUS and ANONYMOUS mechanisms should not occur in the wrapped
   mechlist.  Furthermore, only mechanisms supporting channel binding
   SHOULD be supported, meaning that all strings in mechlist should have
   a -PLUS ending.

Van Rein                  Expires July 24, 2020                 [Page 5]

Internet-Draft                Diameter SASL                 January 2020

2.3.  Continued Client-to-Server Messages

   Further GS2-SXOVER-PLUS messages from client to server are named
   (initial) responses by SASL, and they are formed by encrypting the
   DER-form of C2S-Cont under the seskey.  There is one special case,
   namely the need for the first C2S-Cont to select a SASL mechanism to
   run under the seskey cloak.  For all C2S-Cont messages, there is a
   separate representation for no data, distinguishable from empty data:

      ctr       Counter,             -- 1 + Previous ctr value
      c2s       SaslToken,           -- NULL or token, client to server
      mechsel   IA5String OPTIONAL   -- SASL mechanism name selection

   SaslToken ::= CHOICE {
      token     OCTET STRING,
      no-token  NULL

   This is the first and later of the wrapped SASL messages sent from
   the client to the server.  When it is the first, the mechsel field
   MUST specify the SASL mechanism that the client selected from the
   mechsel issued before.  The mechsel MUST support channel binding, so
   it must have a -PLUS ending.  In any message, the ctr value is one
   more than the value in the previous SASL message, reduced to an
   unsigned 32-bit range; see Section 3.2 for an important detail caused
   by round-trip optimisation.

   The SaslToken in c2s is either a literal OCTET STRING with the SASL
   token to pass, or it is NULL if no token is passed.  This implements
   a distinction between an empty token and no token, as required by
   SASL [RFC4422].

2.4.  Continued Server-to-Client Messages

   After the first message from the server to the client, they adhere to
   the structure of S2C-Cont, defined below.  The SASL term for these
   messages would be a Challenge that is not an Initial Challenge.  The
   exchange is encrypted under the seskey:

      ctr     Counter,               -- 1 + Previous ctr value
      s2c     SaslToken,             -- NULL or token, server to client
      extra   OCTET STRING OPTIONAL  -- On success, optional extra token

Van Rein                  Expires July 24, 2020                 [Page 6]

Internet-Draft                Diameter SASL                 January 2020

   This is the first and later of the wrapped SASL messages sent from
   the server to the client.  In any message, the ctr value is one more
   than the value in the previous SASL message, reduced to an unsigned
   32-bit range.

   The SaslToken in s2c is either a literal OCTET STRING with the SASL
   token to pass, or it is NULL if no token is passed.  This implements
   a distinction between an empty token and no token, as required for

   The extra value can be passed along as a hint to the user for a
   successful authentication.  Mechanisms do not commonly use the field,
   but SASL offers it.  The distinction between an empty OCTET STRING
   and an absent value is assured through the OPTIONAL modifier.  Note
   that this value should not be passed as part of the GS2-SXOVER-PLUS
   exchange, as it is part of the SASL mechanism that was selected with
   mechsel in the wrapped exchange.  GS2-SXOVER-PLUS does not specify an
   extra value, so the field in the outer SASL exchange that runs GS2-
   SXOVER-PLUS will not be used.

3.  GS2-SXOVER-PLUS as a GS2 Mechanism

   The messages of GS2-SXOVER-PLUS will now be mapped to SASL and GSS-
   API.  The GS2 bridge [RFC5056] defines the requirements to make the
   two behave equavalently on the basis of a header preceding the first
   "raw" message which is the C2S-Init message.

   Further messages, so S2C-Init, C2S-Cont and S2C-Cont will be
   encrypted but otherwise used as-is under both SASL and GSS-API.

3.1.  Encrypting GS2-SXOVER-PLUS Messages

   Before inclusion in the GSS-API and SASL frames, most GS2-SXOVER-PLUS
   messages will be encrypted:

   C2S-Init  is not encrypted, but it contains a seskey field that is
         encrypted under the long-term key with key usage value
         KIP_KEYUSAGE_MAPPING or 1864;

   S2C-Init, C2S-Cont, S2C-Cont  are encrypted under the seskey, as
         supplied in the C2S-Init that started the session, with key
         usage value KIP_KEYUSAGE_USERDATA or 1863.

   The encrypt operation [Section 3 of [RFC3961]] uses default initial
   state and is known to also guarantee integrity.  The name KIP
   references the compatible Keyful Identity Protocol, which may or may
   not develop independently of GS2-SXOVER-PLUS.

Van Rein                  Expires July 24, 2020                 [Page 7]

Internet-Draft                Diameter SASL                 January 2020

3.2.  Initial Round-trip Optimisation

   This section introduces an optimisation that MUST be accepted by
   servers, and MAY be sent by clients.  In addition, the server MAY use
   it in response to optimised messages to clients which MUST then
   accept it.

   Normally, the C2S-Init, S2C-Init, C2S-Cont and S2C-Cont messages are
   all placed in a single GSS-API or SASL message, with encryption and
   headers applied as dictated for each occasion.  The optimisation
   described here concatenates an opportunistic C2S-Cont to C2S-Init,
   and upon acceptance of the opportunistic attempt the server sends not
   only a S2C-Init, but also the accepting S2C-Cont.

   Encryption is applied to the GS2-SXOVER-PLUS messages before they are
   concatenated.  The header is applied after concatenation.

   The Counter values used in case of success or failure of the
   opportunistic attempt are:

        Message   |  Counter on success  |  Counter on failure
        C2S-Init  |  inictr              |  inictr
        C2S-Cont  |  inictr + 2          |  inictr + 2
        S2C-Init  |  inictr + 1          |  inictr + 1
        S2C-Cont  |  inictr + 3          |  (message absent)
        next...   |  inictr + 4,5,6...   |  inictr + 3,4,5...

   or, in words, the counter is not incremented when failure causes the
   S2C-Init to not be sent.  This is reflected in the next messages,
   which would start with another attempted C2S-Cont, and normal
   counting commences from that point.

   The use of this pattern is that a mechanism may be tried immediately,
   without awaiting the mechanism list.  Very often, clients will be
   setup to validate using a particular mechanism, or they may have
   learnt from a prior exchange.  This is particularly useful because
   traffic concentrates at the home realm, which usually leads to a
   stable mechanism list.

3.3.  Initial Header for GSS-API

   The header to use for GSS-API is standardised as a Mechanism-
   Independent Token Format [Section 3.1 of [RFC2743]] and prefixed to
   the initial token of a GSS-API context establishment sequence,
   incorporating the object identifier
   (TBD:GSSOID) to identify GS2-SXOVER-PLUS.  When this object
   identifier is supplied to the call GSS_Inquire_SASLname_for_mech

Van Rein                  Expires July 24, 2020                 [Page 8]

Internet-Draft                Diameter SASL                 January 2020

   [Section 10 of [RFC5801]], the output reads "GS2-SXOVER-PLUS"
   (without the quotes).

   Following the header is a GSS-API variant of C2S-Init, which prefixes
   an authorization identity, interpreted as defined in the GS2 header
   for SASL.  The structure after the header in ASN.1 notation is:

     gs2-authzid  IA5String,
     c2s-init     C2S-Init

   The annotated bytes are shown below:

   60 02 ...length...   -- [APPLICATION 0] IMPLICIT SEQUENCE { ... }
      06 ...length... 2b 06 01 04 01 44469 TBD:666 TBD:5081 01  -- OBJECT IDENTIFIER
      -- GSS-SXOVER-Init
      30 ...length...  -- SEQUENCE { ... }

   The mapping of GS2-SXOVER-PLUS into GSS-API is less natural than into
   SASL, because it references SASL mechanisms.  This is not a strict
   problem however, and implementers MAY provide GS2-SXOVER-PLUS as a
   GSS-API mechanism.  The absense of a realm name in the generic parts
   of the protocol may however lead to difficulties routing.

   The function GSS_Inquire_SASLname_for_mech [Section 10 of [RFC5801]]
   maps the aforementioned object identifier for the GSS-API mechanism
   to the name "GS2-SXOVER-PLUS" (without quotes).

3.4.  Initial Header for SASL

   The header to use for SASL is the gs2-header [RFC5801] with a few
   extra constraints: constrained than its general form, namely:

   gs2-nonstd-flag  is absent;

   gs2-cb-flag  MUST NOT be "y" or "n" because channel binding is
         required; the only remaining general form is therefore ("p="
         cb-name); a foreign server MUST interpret this flag and relay
         the appropriate channel binding information through its
         Diameter backend;

   gs2-authzid  is used for routing of C2S-Init to the Diameter server
         of the authoritative backend realm.  This field MUST contain at
         least one AT symbol U+0040.  The domain name for the backend is
         mentioned after the last AT symbol.  Anything preceding the AT

Van Rein                  Expires July 24, 2020                 [Page 9]

Internet-Draft                Diameter SASL                 January 2020

         symbol is interpreted by the local realm, and MAY be used for
         realm-internal routing to a more specific Diameter backend
         service node, but identification is done within the realm by
         the inner SASL layer, and the foreign server MUST NOT rely on
         text before the last AT symbol.

   As an example, the gs2-header targeting a realm "example.com" and
   channel binding through tls-unique could be


   or, when example.com uses internal GS2-SXOVER-PLUS routing to a
   service node named +idp+sxover it might be


   In both cases, the last comma would be immediately followed by the
   DER-encoded S2C-Init structure.  Since SASL tokens are always carried
   over binary channels, there is no use in continuing the message in a
   textual form.

4.  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 an authentication

   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.  On top of that, the SASL-Mechanism AVP may
   also occur in a Capabilities Exchange Answer.  The User-Name AVP MUST
   be supplied in a successful 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.

4.1.  SASL-Mechanism

   The SASL-Mechanism AVP has AVP Code TBD0.  This specification only
   uses the mechanism name GS2-SXOVER-PLUS as a value for this AVP.  It
   MUST be included in the first message of an GS2-SXOVER-PLUS exchange
   sent to the home realm, and it SHOULD be verified by the home realm
   upon reception.  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.

Van Rein                  Expires July 24, 2020                [Page 10]

Internet-Draft                Diameter SASL                 January 2020

4.2.  SASL-Token

   The SASL-Token AVP has AVP Code TBD1.  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.

4.3.  SASL-Channel-Binding

   The SASL-Channel-Binding AVP has AVP Code TBD2.  It MUST appear along
   the first SASL-Token AVP for a Network Access session if the SASL-
   Mechanism ends in -PLUS.

   This AVP may occur more than once, to indicate support of multiple
   forms of channel binding.  Note however that all mechanisms suitable
   for Diameter relaying use the GS2 bridge [RFC5056] in which case the
   channel binding name to pass along in this message can be derived.

   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 concatenates two values:

   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 a SASL 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.

5.  Diameter Message Requirements for GS2-SXOVER-PLUS

   This section explains how the various GS2-SXOVER-PLUS messages are
   forwarded over Diameter by the foreign server.  The foreign server is
   connected to the SASL client, usually over a TLS connection, and
   relays requests over Diameter, usually over SCTP with DTLS.

   Diameter servers provide success and failure responses, based on the
   corresponding final results from a SASL service that they in turn
   use.  When no such final result comes from a Diameter request, a

Van Rein                  Expires July 24, 2020                [Page 11]

Internet-Draft                Diameter SASL                 January 2020

   challenge will instead be produced over Diameter, holding a SASL
   challenge token from the server.

5.1.  C2S-Init Requests over Diameter

   To send C2S-Init, possibly including the C2S-Cont that the
   optimisation adds, the Diameter client MUST include at least the
   following AVPs in an AA-Request [Section 3.1 of [RFC7155]]:

   Realm is the client's requested realm, replicated here for routing
         purposes; GS2-SXOVER-PLUS provides this value in the
         gs2-header's authorization identity field;

   SASL-Mechanism  is set to the fixed string GS2-SXOVER-PLUS;

   SASL-Token  is set to the C2S-Init and optional C2S-Cont as it
         arrived from the SASL client;

   SASL-Channel-Binding  is set to the channel binding information 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 if the client and
   server have agreed on this, perhaps as a result of capability
   negotiation during Diameter connection setup.

   The C2S-Init Request is likely to hold other Diameter AVPs for
   general housekeeping of Diameter in general and the NAS application,
   such as Session-Id.  Though User-Name and User-Password would be sent
   with password-based Diameter mechanisms, they are not required in
   C2S-Init messages, but they MAY be sent with empty contents to
   accommodate software and the RECOMMENDED status of the AVPs in the
   AA-Request, in which case they MUST be ignored on reception.

5.2.  S2C-Init Responses over Diameter

   The Diameter server serves as a SASL server to which the foreign
   server relays requests.  To this end, the Diameter server responds
   with acceptance, denial or a further challenge.  Acceptance and
   denial are used for the corresponding SASL outcomes, the further
   challenge also matches logically.

   When the SASL server responds with S2C-Init over Diameter, the
   Diameter server MUST include at least the following AVPs in a
   successful AA-Answer [Section 3.2. of [RFC7155]]:

Van Rein                  Expires July 24, 2020                [Page 12]

Internet-Draft                Diameter SASL                 January 2020

   User-Name  is set to the identity of the SASL client, which resulted
         from the encapsulated SASL exchange and possibly further
         authorisation processing in the SASL server; the name MUST NOT
         add the realm name in this attribute; it is up to the foreign
         server to assign it under the authoritative realm, possibly by
         appending the last U+0040 (AT) character and its realm name
         observed from the GS2 header sent in C2S-Init over Diameter.

   Permissions  may be expected from a Diameter server, but are
         considered optional for SASL over Diameter.  The reason is that
         SASL focusses on authentication, not authorisation.  This
         especially applies to realm crossover, where authentication is
         a matter of the home realm and authorisation is, at least by
         default, the prerogative of the foreign server implementing its
         own resource with its own semantics.  Extensions to this
         specification could however be made to use the infrastructure
         proposed herein to also centralise the storage and/or
         processing of resource access rights.

   If the SASL exchange requires continuation, then the AA-Answer
   represents a challenge to follow up, represented in the an AA-Answer
   that MUST include at least the following AVPs:

   Result-Code  is set to the value DIAMETER_MULTI_ROUND_AUTH;

   SASL-Token  is set to the S2C-Init value;

   State is set to server state to be reproduced in the followup.

   If the AA-Answer is a final failure report, this MUST be represented
   in a failing Result-Code AVP.

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 is forwarded as a Diameter AA-
   Request [Section 3.1 of [RFC7155]] which MUST contain at least the
   following AVP:

   SASL-Token  is set to the token from the SASL client.

   The C2S-Cont Request MUST NOT contain AVPs for SASL-Mechanism or
   SASL-Channel-Binding.  It is however likely to hold other Diameter
   AVPs for general housekeeping of Diameter in general and the NAS
   application, such as Session-Id and State AVPs.  Though User-Password
   would be sent with password-based mechanisms, it is not required in
   C2S-Cont messages, but it MAY be sent with empty contents to

Van Rein                  Expires July 24, 2020                [Page 13]

Internet-Draft                Diameter SASL                 January 2020

   accommodate software and the RECOMMENDED status of the AVP, in which
   case it MUST be ignored on reception.

5.4.  S2C-Cont Responses over Diameter

   The S2C-Cont Response message may inform the Diameter client of
   success, failure or a further challenge.  It is transmitted over
   Diameter as a Diameter AA-Answer [Section 3.2 of [RFC7155]] message,
   with the customary Result-Code interpretations.

   Processing of these Diameter messages is the same as for S2C-Init,
   with the exception that the SASL-Token, if it is present, is not
   interpreted as S2C-Init but as S2C-Cont.

6.  Running Diameter as a SASL Backend

   Following are a few practical considerations in relation to the
   Diameter connectivity for SASL.

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 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

   Diameter can fallback to run over TCP, which is mostly of use to
   client-only machines, but then 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 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

6.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

Van Rein                  Expires July 24, 2020                [Page 14]

Internet-Draft                Diameter SASL                 January 2020

   upholds for its client identities, but any foreign server can choose
   to raise the bar by setting a minimum standard.

   DNSSEC offers a 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,
   can be used as specified for DANE [RFC6698].  This use of DNSSEC and

   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.

7.  Security Considerations

   The SASL mechanism GS2-SXOVER-PLUS separates the authentication of a
   foreign identity into its realm and the username underneath it.  The
   realm is authenticated by the relying server, such as the proposed
   foreign server, whereas the username is obtained from a backend realm
   server that is known to be responsible for that realm.

   From the perspective of the foreign server, assurance of an identity
   is the vital aspect of the GS2-SXOVER-PLUS flow that it relays over
   Diameter.  Through TLS or DTLS, with DNSSEC and DANE to validate the
   certificate it uses, the link from a realm (which is read as a domain
   name) to the Diameter connection can be verified, so the relying
   server can be certain about the realm under which the backend
   connection resides.  By receiving a response over that connection to
   a known-authoritative server for the realm, the username can also be
   trusted.  The relying server continues to treat the username and
   realm 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 a claimed realm does help.  The intermediate
   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 home realm, the safety of
   the SASL credentials is paramount.  When addressing a foreign server,
   which is not part of the home realm, 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 assigns no

Van Rein                  Expires July 24, 2020                [Page 15]

Internet-Draft                Diameter SASL                 January 2020

   rights, and GS2-SXOVER-PLUS, which applies end-to-end encryption to
   another SASL mechanism that may or may not be secure.

   The GS2-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.

8.  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"

   AVP Code | Attribute Name       | Reference
   TBD0     | SASL-Mechanism       | (this spec)
   TBD1     | SASL-Token           | (this spec)
   TBD2     | SASL-Channel-Binding | (this spec)

9.  Normative References

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743,
              DOI 10.17487/RFC2743, January 2000,

   [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>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,

   [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>.

Van Rein                  Expires July 24, 2020                [Page 16]

Internet-Draft                Diameter SASL                 January 2020

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,

   [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,

   [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,

   [RFC7155]  Zorn, G., Ed., "Diameter Network Access Server
              Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,

Appendix A.  Acknowledgements

   Thanks to Nico Williams for input on the GS2 bridge and Channel

Author's Address

   Rick van Rein
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl

Van Rein                  Expires July 24, 2020                [Page 17]