Internet-Draft Extended SASL March 2023
Cridland, et al. Expires 11 September 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-melnikov-sasl2-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Cridland
T. Molitor
M. Wild
A. Melnikov
Isode Ltd

Extensible Simple Authentication and Security Layer (SASL)

Abstract

The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.

This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change.

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 11 September 2023.

▲

Table of Contents

1. Introduction

The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. SASL provides a structured interface between protocols and mechanisms. SASL also provides a protocol for securing subsequent protocol exchanges within a data security layer. The data security layer can provide data integrity, data confidentiality, and other services.

SASL's design is intended to allow new protocols to reuse existing mechanisms without requiring redesign of the mechanisms and allows existing protocols to make use of new mechanisms without redesign of protocols.

SASL is conceptually a framework that provides an abstraction layer between protocols and mechanisms as illustrated in the following diagram.


                  SMTP    LDAP    XMPP   Other protocols ...
                     \       |    |      /
                      \      |    |     /
                     SASL abstraction layer
                      /      |    |     \
                     /       |    |      \
              EXTERNAL   GSSAPI  PLAIN   Other mechanisms ...

It is through the interfaces of this abstraction layer that the framework allows any protocol to utilize any mechanism. While this layer does generally hide the particulars of protocols from mechanisms and the particulars of mechanisms from protocols, this layer does not generally hide the particulars of mechanisms from protocol implementations. For example, different mechanisms require different information to operate, some of them use password-based authentication, some of then require realm information, others make use of Kerberos tickets, certificates, etc. Also, in order to perform authorization, server implementations generally have to implement identity mapping between authentication identities, whose form is mechanism specific, and authorization identities, whose form is application protocol specific. Section 2 discusses identity concepts.

It is possible to design and implement this framework in ways that do abstract away particulars of similar mechanisms. Such a framework implementation, as well as mechanisms implementations, could be designed not only to be shared by multiple implementations of a particular protocol but to be shared by implementations of multiple protocols.

Since the publication of [RFC4422] a number of shortcomings in the SASL framework were identified that are addressed in this document. [[Note that the current draft only shows changes from RFC 4422.]]

This specification addresses a number of shortfalls in [RFC4422]:

Extensions to SASL documented herein are primarily some clarifications to allow extensibility, and additional results beyond total success or abject failure.

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.

Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].

Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only, and are not part of the actual protocol exchange.

3. Tasks

A protocol profile might have a way to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time. We call this indicator a "continue outcome message". This can be used to indicate a need to execute extra task(s), for example, that the Client needs to perform a Second Factor Authentication ("2FA") and/or is required to change password (this list is not meant to be exhaustive in any way).

These tasks are analogous to a SASL mechanism, but have a number of differences - they may never attempt to negotiate a new authorization identifier, nor a new security layer.

Each task has a name ([[need to define syntax and maximum length]]) that SHOULD be registered with IANA.

A client MAY choose any one of the offered tasks; if multiple are required, once a task is successfully completed, the server will indicate that another one is required, and so on, until all mandatory tasks are complete.

The continue outcome message MAY include SASL mechanism specific additional data, as the successful outcome message does.

Finally, the continue outcome message MAY contain a textual data, which contains human-readable data explaining the nature of the step required.


Example 1. Continue Required (using XMPP protocol)

S: <continue xmlns='urn:xmpp:sasl:2'>
  <additional-data>
    SSdtIGJvcmVkIG5vdy4=
  </additional-data>
  <tasks>
    <task>HOTP-EXAMPLE</task>
    <task>TOTP-EXAMPLE</task>
  </tasks>
  <text>This account requires 2FA</text>
</continue>

If any SASL security layer was negotiated, it takes effect after the final octet of the first continue outcome message.

Clients respond with a task initiation message, which has a single mandatory parameter containing the selected task name, and MAY contain any task specific data.

Each task MUST end either by the server sending a task failure indicator message, if the task failed, a continue outcome message, if the task was completed successfully and the server requests the client to perform a new task, or a successful outcome message, indicating that the task was completed successfully and no further tasks are needed.


Example 2. Fictional TOTP task
<!-- Client starts TOTP-EXAMPLE task -->

<next xmlns='urn:xmpp:sasl:2' task='TOTP-EXAMPLE'>
  <totp xmlns="urn:totp:example">
    SSd2ZSBydW4gb3V0IG9mIGlkZWFzIGhlcmUu
  </totp>
</next>

<!-- Server provides needed data to Client -->
<task-data xmlns='urn:xmpp:sasl:2'>
  <totp xmlns="urn:totp:example">
    94d27acffa2e99a42ba7786162a9e73e7ab17b9d
  </totp>
</task-data>

<!-- Client responds with requested TOP data -->
<task-data xmlns='urn:xmpp:sasl:2'>
  <totp xmlns="urn:totp:example">
    OTRkMjdhY2ZmYTJlOTlhNDJiYTc3ODYxNjJhOWU3M2U3YWIxN2I5ZAo=
  </totp>
</task-data>

<!-- Server indicates successful completion of TOTP-EXAMPLE task -->
<success xmlns='urn:xmpp:sasl:2'>
  <totp xmlns="urn:totp:example">
    SGFkIHlvdSBnb2luZywgdGhlcmUsIGRpZG4ndCBJPw==
  </totp>
  <authorization-identifier>juliet@montague.example</authorization-identifier>
</success>

4. Channel Binding advertisement

Most modern SASL mechanism are expected to support channel bindings [RFC5056].

Explicit advertisement of server supported channel binding types improves interoperability and is also necessary to prevent certain MITM attacks.


Example 3. Channel Binding Type advertisement in XMPP (XEP-0440).
Note that the <sasl-channel-binding> element is the new channel
binding advertisement.

<stream:features>
  <sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'>
    <channel-binding type='tls-server-end-point'/>
    <channel-binding type='tls-exporter'/>
  </sasl-channel-binding>
  <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>EXTERNAL</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
  </mechanisms>
</stream:features>

5. Extra Protocol Requirements

[[Note that the item number continues the numbering of requirements from Section 4 of RFC 4422.]]

[[Alexey: All of the features below are optional (in order to remain backward compatible with RFC 4422). However if any is implemented, all of them MUST be implemented in a protocol. This makes client implementations easier.]]

6. Extra Mechanism Requirements

[[Note that the number continues the numbering of requirements from Section 5 of RFC 4422.]]

7. Example of a Protocol fulfilling extra requirements

[[Ideally need 2 protocols. For example XMPP and IMAP. IMAP can have a new command for tasks.]]

8. Open Issues

9. Security Considerations

TBD

10. IANA Considerations

IANA is requested to create a new subregistry of "SASL tasks" for registering SASL tasks as specified in this document.

The registration template is as follows:


Task Name: <need to define syntax!>
Task Type: <define the list of types and whether or not it will be extensible>
Pointer to specification text:
Notes (optional):

The registration procedure for the above registry is Expert Review.

11. Acknowledgements

TBD. Thank you XSF for XEP-0388, XEP-0440 and XEP-scram-upgrade.

12. References

12.1. Normative References

[CharModel]
Whistler, K. and A. Freytag, "Unicode character encoding model", Unicode tr17, , <https://www.unicode.org/reports/tr17/>.
[Glossary]
Consortium, U., "Glossary of Unicode Terms", Unicode glossary, , <https://www.unicode.org/glossary/>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4422]
Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, , <https://www.rfc-editor.org/info/rfc4422>.
[RFC4949]
Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, , <https://www.rfc-editor.org/info/rfc4949>.
[RFC5056]
Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, , <https://www.rfc-editor.org/info/rfc5056>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[Unicode]
Consortium, U., "Unicode 15.0.0", Unicode 15.0.0, , <https://www.unicode.org/versions/Unicode15.0.0/>.

12.2. Informative References

[RFC6238]
M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, , <https://www.rfc-editor.org/info/rfc6238>.

Authors' Addresses

Dave Cridland
Thilo Molitor
Matthew Wild
Alexey Melnikov
Isode Ltd