Skip to main content

Diameter as a Carrier Protocol for SASL
draft-vanrein-diameter-sasl-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Rick van Rein
Last updated 2018-11-04
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-vanrein-diameter-sasl-00
Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Standards Track                        November 4, 2018
Expires: May 8, 2019

                Diameter as a Carrier Protocol for SASL
                     draft-vanrein-diameter-sasl-00

Abstract

   Diameter is a scalable protocol to support authentication and
   authorisation inquiries.  It handles a variety of challenge and
   response types for applications such as network access.  For use in
   application protocols, a different class of challenge and response
   types are needed, most commonly captured in SASL.  This specification
   allows SASL handshakes to be carried in Diameter messages.

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 May 8, 2019.

Copyright Notice

   Copyright (c) 2018 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

Van Rein                   Expires May 8, 2019                  [Page 1]
Internet-Draft                Diameter SASL                November 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Embedding SASL in Diameter  . . . . . . . . . . . . . . . . .   3
     2.1.  AVP Definitions for SASL  . . . . . . . . . . . . . . . .   3
       2.1.1.  SASL-Mechanisms . . . . . . . . . . . . . . . . . . .   3
       2.1.2.  SASL-Encrypted-Token  . . . . . . . . . . . . . . . .   4
       2.1.3.  SASL-Channel-Binding  . . . . . . . . . . . . . . . .   6
     2.2.  Server Name Binding . . . . . . . . . . . . . . . . . . .   8
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Diameter Message Examples  . . . . . . . . . . . . .  11
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   SASL [RFC4422] is a general standard for inserting authentication and
   authorisation strings into protocols to alles clients to authenticate
   to servers.  The format is general, and indeed quite list of security
   mechanisms have been crafted to fit its shape.  SASL is also generic
   in terms of how it can be embedded into the protocols that desire
   authentication and authorisation, and again it is used in many
   protocols.

   Diameter, being targeted at authentication and authorisation, has
   never been setup with support for SASL.  This is perhaps because
   Diameter is often used with network-level access control, where the
   EAP protocol usually takes care of these tasks; SASL is mostly used
   with application protocols.  The design of Diameter however, is
   flexible enough to be very useful to this class of protocols as well.

   By carrying SASL in Diameter messages, a few interesting usage
   scenarios are enabled.  First, due to the ability to take SASL
   strings from one protocol and forward them in another, we can use
   Diameter as a connection to a backend service that conceals
   credentials from the applications that rely on them.  In a variation
   on the first scenario, the second usage scenario addresses the domain
   of a user to validate against credentials held there.  We refer to
   that as BYOID, short for Bring Your Own IDentity.

Van Rein                   Expires May 8, 2019                  [Page 2]
Internet-Draft                Diameter SASL                November 2018

   The general assumption for the use of SASL over Diameter is the
   following diagram, where the client enters a password to gain access
   to a server for an arbitrary application protocol, after which the
   server finds Diameter under the client's home domain through SRV
   records in DNS, and then uses those to connect to the backend
   authentication service.

      +--------+    SASL     +--------+    SASL    +---------+
      | Client |-----------> | Server | ---------> | Backend |
      +--------+  AppProto   +--------+  Diameter  +---------+
          ||                     ||                    ||
   john@example.com        find SRV, TLSA          example.com
     & credential            relay SASL          user validation

2.  Embedding SASL in Diameter

   SASL messages in Diameter use a number of AVPs that are defined for
   this purposes.  They occur in those combinations that are defined for
   SASL.

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

   For each AVP, we provide an informal drawing of its contents; arrows
   indicate an impact on the contents and perhaps on presence; sides
   with a colon indicate optional parts of the AVP contents.  We provide
   an informal name and Data Format for each sub-field.  Precision is
   only found in the descriptive text.

2.1.1.  SASL-Mechanisms

   The SASL-Mechanisms AVP has AVP Code TBD1.

   +-----------------------------+
   |  mechanism(s) : UTF8String  |
   +-----------------------------+

   This AVP holds an ASCII string with zero or more names of SASL
   mechanisms, separated by one space.  Since spaces do not occur in
   SASL mechanism names, there is no need for escaping anything.

Van Rein                   Expires May 8, 2019                  [Page 3]
Internet-Draft                Diameter SASL                November 2018

   When used to indicate that no mechanism is available, this field
   contains zero mechanisms names, or a zero-length string.  When used
   to indicate the choice of a mechanism, this field contains precisely
   one mechanism name.  When used to list optional mechanisms available,
   any number of mechanisms can be named, including none, one and more.

   The server MAY impose requirements on acceptable SASL mechanisms, to
   ensure a minimum security level.  If this is desired, the server MAY
   remove mechanisms from the list before it is presented to the client
   as part of the application protocol.  There will be many cases where
   the server refuses to accept the ANONYMOUS [RFC4505] mechanism; and
   it is also likely that PLAIN [RFC4616] and other weak methods are
   suppressed, or that only strong mechanisms such as SCRAM [RFC5802]
   [RFC7804] are accepted from the backend offering.  An empty set of
   mechanisms might result, and lead to the conclusion that no
   authentication is possible.

   The server may be in a position to authenticate the client on grounds
   of their application connection; usually, this will be the result of
   client credentials bound into the TLS exchange.  If this is the case,
   the server MAY ensure that the EXTERNAL mechanism is mentioned to the
   client and handle it locally without communication with the backend.

   The server may be in a position to provide ANONYMOUS [RFC4505]
   authentication; usually, this will be the case if application
   protocol can be serviced in a guest mode.  If this is the case, the
   server MAY ensure that the ANONYMOUS mechanism is mentioned to the
   client and handle it locally without communication with the backend.

2.1.2.  SASL-Encrypted-Token

   The SASL-Encrypted-Token AVP has AVP Code TBD2.

   +-------------------------+
   |   server : UTF8String   |
   +-------------------------+
   |     0x00 : ASCII NUL    |
   +-------------------------+
   |  enc-alg : UTF8String   |
   +-------------------------+
   |     0x00 : ASCII NUL    |
   +-------------------------+
   |   key-id : UTF8String   |
   +-------------------------+
   |     0x00 : ASCII NUL    |
   +-------------------------+
   |    token : OctetString  |
   +-------------------------+

Van Rein                   Expires May 8, 2019                  [Page 4]
Internet-Draft                Diameter SASL                November 2018

   This AVP holds four strings, separated by ASCII NUL characters
   `\x00`.  The first three strings are UTF-8 strings, prepared with
   SASLprep [RFC4103]; the last is an OctetString that holds the SASL
   token, usually in encrypted form.  All fields MAY be empty.  As a
   result of these formatting requirements, the SASL-Encrypted-Token
   MUST contain at least three bytes valued 0x00.

   The server in the first string represents the name of the server.
   This information MUST be made available in the first SASL-Encrypted-
   Token message from the client to the server.  It MAY be an empty
   string in any following messages.  For encryption algorithms with
   AEAD support, the suggested use is to include the server name in the
   MAC as additional data; in any other encryption algorithm the
   suggestion is to include the server name with a trailing ASCII NUL
   character `\x00` before the encrypted content, and to verify and
   remove it while decoding.

   The enc-alg in the second string selects the encryption algorithm by
   name.  This can be any form agreeable to both the client and the
   backend, but as an informative suggestion the encryption type names
   for Kerberos [RFC4120] may be used; most SASL implementations have
   access to a Kerberos5 implementation and may be able to use those.
   It is also the most likely candidate to allow for generic
   pluggability between client and server software from different
   vendors.

   The key-id in the third string indicates the key instance to use.
   Any local standard can be used, but as an informative suggestions a
   UUID in textual lowercase form may be considered.

   The token in the fourth string would normally be encrypted with the
   indicated encryption algorithm using the identified key.  The octet
   string holds the literal output from the encryption algorithm,
   applied to the literal SASL token as agreed by the mechanism.  The
   enc-alg and key-id need not be repeated in follow-up messages, and
   are assumed to be retained on the Diameter server, or stored in the
   State that the Diameter client is supposed to replicate in follow-
   ups.  Some protocols will map these strings to a representation such
   as base64, but for the 8-bit clean form of an OctetString in Diameter
   this shall not be done.

   The fourth string usually holds a challenge string when it is part of
   an AA-Answer, and mostly a response string when it is part of an AA-
   Request.

   The anticipated use of encryption is based on stored secrets,
   possibly protected by a login password.  This is not the same as
   authentication, because it has no user-controllable start and end.

Van Rein                   Expires May 8, 2019                  [Page 5]
Internet-Draft                Diameter SASL                November 2018

   Encryption is about holding something (namely the client's terminal)
   that others like the server cannot use; authentication is knowing
   something (namely the credential).  This distinction may also be
   supportive of use of the same encryption key and algorithm over
   multiple users; and that includes pseudonyms of one user.

2.1.3.  SASL-Channel-Binding

   The SASL-Channel-Binding AVP has AVP Code TBD3.

   +---------------------------+
   |  iniadrtyp : Unsigned32   | -------+
   +---------------------------+        |
   |  iniadrlen : Unsigned32   | -------+
   +---------------------------+        |
   |  accadrtyp : Unsigned32   | ---+   |
   +---------------------------+    |   |
   |  accadrlen : Unsigned32   | ---+   |
   +---------------------------+    |   |
   :     iniadr : OctetString  : <--|---+
   +---------------------------+    |
   :     accadr : OctetString  : <--+
   +---------------------------+
   :    nameval : OctetString  :
   +---------------------------+

   This AVP provides information about SASL channel binding.  It
   indicates whether this information MUST or MAY be taken into account.
   Normally, channel binding information should be sourced from the
   underlying communications channel, but this information is not
   available to backend running Diameter.  What will work however, is if
   a relying party supplies such information to the backend to which the
   decision is delegated.

   Through this facilitation, Diameter is able to service as a backend
   authenticator.  It can also be used across realms, because no service
   is offered, other than informing about acceptance or rejection and
   possible some variables explaining why or how.  Alternative backends
   that run application protocols such as LDAP or IMAP are not suitable
   during realm crossover, because they actually provide access to a
   service and data.  Diameter's simple acceptance or rejection does
   not.

   Channel binding information [RFC5554] [RFC5801] is generally
   described as:

   name  consisting of US-ASCII alphanumerics, dot and dash [Section 7
         of [RFC5056]];

Van Rein                   Expires May 8, 2019                  [Page 6]
Internet-Draft                Diameter SASL                November 2018

   value the byte string with the values whose interpretation is decided
         by the name;

   address types  for both ends of a connection [Section 3.11 of
         [RFC2744]] with a skipping value GSS_C_AF_NULLADDR;

   address  for each end.

   These fields belong together; they are concatenated into the SASL-
   Channel-Binding AVP as follows (where integers are 32-bit unsigned in
   big-endian order):

   o  is an integer holding the type of the initiator address as used in
      GSS-API [RFC2744]; the value GSS_C_AF_NULLADDR may be used to
      explicitly indicate that this address is not available for channel
      binding;

   o  is an integer holding the type of the acceptor address as used in
      GSS-API; the value GSS_C_AF_NULLADDR may be used to explicitly
      inidicate that this address is not available for channel binding;

   o  is the integer length of the address information of the initiator
      of the session being verified; this field MUST be set to 0 when
      iniadrtype is set to GCC_C_AF_NULLADDR;

   o  is the integer length of the address information of the acceptor
      of the session being verified; this field MUST be set to 0 when
      accadrtype is set to GCC_C_AF_NULLADDR;

   o  is the address of the initiator, represented as a sequence of
      bytes interpreted according to iniaddrtyp by Diameter and GSS-API
      but treated as opaque binaries during transport; this field MUST
      occupy the number of bytes that are declared in iniadrlen, and it
      MAY therefore be empty;

   o  is the address of the acceptor, represented as a sequence of bytes
      interpreted according to accaddrtyp by Diameter and GSS-API but
      treated as opaque binaries during transport; this field MUST
      occupy the number of bytes that are declared in accadrlen, and it
      MAY therefore be empty;

   o  selects and holds the binary value of a channel binding method
      that incorporates, for instance, an underlying secure channel
      through its cryptographic summary; this field is optional and so
      it may be empty; if it is not empty, the contents are the name as
      specified above, followed by an ASCII NUL character '\x00' and
      then the value as specified above; in light of this last part,

Van Rein                   Expires May 8, 2019                  [Page 7]
Internet-Draft                Diameter SASL                November 2018

      this entire field must be considered as an opaque binary during
      transport.

   Note how each of the components can be explicitly denied; this can be
   used by a relying server to suppress certain fields from being
   permitted in channel binding.  It is generally assumed that the
   trusting server and its client have a way of negotiating the form of
   channel binding to be used.  When unsure, a relying server may offer
   more than one SASL-Channel-Binding AVP and Diameter shall treat these
   as alternatives.  Note however, that not all SASL mechanisms can
   handle concurrent alternatives, and that security sanity should
   impose an upper limit to any such facilitation.

2.2.  Server Name Binding

   Due to the use of a backend server, normal channel binding conditions
   do not apply.  To still be able to support binding to secure
   channels, the SASL-Channel-Binding AVP allows the transfer of this
   information to the backend, which would not otherwise be aware of it.
   This enables the SASL exchange to include this information, where
   client and server pass it to the backend over their individual
   channels.

   Applications that use Diameter in the backend differ from traditional
   SASL applications by their interpretation of the AT character U+0040
   in the user name, and using it to forward the name to a backend.
   When this practice is followed in a realm, it is strongly advised
   that it adheres to this section, though it is formally a local policy
   and therefore this section is informative in nature.

   Server names are important, and should be incorporated in much the
   same fashion as channel binding.  The intention is to allow side-
   tracking of authentication information to other services, either
   under same or different operational control.  Such practices might
   lead to abusive services luring users into credential use and
   secretly using it to attack another part of a user's service
   pallette.  The solution is quite simply to scatter the credentials of
   the user.  This is why SASL-Encrypted-Token incorporates the server
   name, and uses it to scatter the encryption scheme.

   The Diameter backend receives the server name and should use it to
   get assurance of its incoming connection as related to the server
   name.  It can find assurance in DNS, where information SHOULD be
   protected with DNSSEC.  The use of an SRV record for the server's
   Diameter information [TODO:server2realm] is desired, followed by TLSA
   lookups to perform DANE validation.

Van Rein                   Expires May 8, 2019                  [Page 8]
Internet-Draft                Diameter SASL                November 2018

   It may seem simpler to validate the TLS certificate [RFC5929] itself,
   and demanding that the same be used towards the client as to the
   Diameter backend.  This does not scale up well however.  Specifically
   large infrastructures may prefer to bundle Diameter connections so
   they can collate traffic to paired realms into a bulk channel.

3.  Security Considerations

   SASL is designed for direct use between a client and a server, but as
   clients rarely feel the need to login to Diameter, the reason will
   usually be an intermediate server passing SASL traffic to its
   backend.  This is not always a safe idea; the server is a man-in-the-
   middle and the SASL mechanisms are at least at risk of being attacked
   by this middle man.

   This middle man may not be a problem if the server and Diameter
   backend fall under the same operational control.  It may also not be
   a problem if the server is part of a contractual arrangement with the
   client.  Finally, it may be a tolerable risk if the server is
   operated in a jurisdiction where cracking of SASL algorithms is
   considered as illegal as breaking into a home, both when this is done
   by private and public parties.

   In all other cases, end-to-end encryption of the SASL tokens between
   client and server is required.  The quality of protection then rests
   with the encryption standard.  This specification does not choose an
   algorithm, key management standards or otherwise, but refers to the
   vast body of general knowledge on this.  Doing this properly can
   easily be effective in mitigating the risks of the known middle-man.

   An additional concern caused by the middle-man is that it does not
   become a switching point between use and abuse.  To mitigate this
   risk, its server name MUST be validated.  This can be done with the
   credentials obtained from the Diameter connection.  TLS Certificates
   may be checked with DANE, to be concrete.  Without this, a rogue
   server might repeatedly make inquiries with the SASL backend,
   claiming to be a reliable server, until it finds a password.

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

Van Rein                   Expires May 8, 2019                  [Page 9]
Internet-Draft                Diameter SASL                November 2018

   AVP Code | Attribute Name       | Reference
   ---------+----------------------+------------
   TBD1     | SASL-Mechanisms      | (this spec)
   TBD2     | SASL-Encrypted-Token | (this spec)
   TBD3     | SASL-Channel-Binding | (this spec)

5.  References

5.1.  Normative References

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

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
              <https://www.rfc-editor.org/info/rfc4103>.

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

   [RFC5554]  Williams, N., "Clarifications and Extensions to the
              Generic Security Service Application Program Interface
              (GSS-API) for the Use of Channel Bindings", RFC 5554,
              DOI 10.17487/RFC5554, May 2009,
              <https://www.rfc-editor.org/info/rfc5554>.

   [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 May 8, 2019                 [Page 10]
Internet-Draft                Diameter SASL                November 2018

5.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.  Diameter Message Examples

   This section is non-normative.  It shows a number of examples of SASL
   exchanges over Diameter.

Appendix B.  Acknowledgements

   Thanks go to TODO for useful discussions during the creation of this
   document.

Author's Address

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

   Email: rick@openfortress.nl

Van Rein                   Expires May 8, 2019                 [Page 11]