The Hashed Token SASL Mechanism
draft-schmaus-kitten-sasl-ht-03

Document Type Active Internet-Draft (individual)
Last updated 2017-11-11
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Additional URLs
- Document source repository
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Common Authentication Technology Next Generation              F. Schmaus
Internet-Draft                                                  C. Egger
Intended status: Experimental           University of Erlangen-Nuremberg
Expires: May 15, 2018                                  November 11, 2017

                    The Hashed Token SASL Mechanism
                    draft-schmaus-kitten-sasl-ht-03

Abstract

   This document specifies the family of Hashed Token SASL mechanisms,
   which are meant to be used for quick re-authentication of a previous
   session.  The Hashed Token SASL mechanism's authentication sequence
   consists of only one round-trip.  This is achieved by the usage of
   short-lived, exclusively ephemeral hashed tokens.  It further
   provides hash agility, mutual authentication and is secured by
   channel binding.

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 15, 2018.

Copyright Notice

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

Schmaus & Egger           Expires May 15, 2018                  [Page 1]
Internet-Draft                                             November 2017

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
     1.2.  Applicability . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The HT Family of Mechanisms . . . . . . . . . . . . . . . . .   3
   3.  The HT Authentication Exchange  . . . . . . . . . . . . . . .   4
     3.1.  Initiator First Message . . . . . . . . . . . . . . . . .   4
     3.2.  Initiator Authentication  . . . . . . . . . . . . . . . .   5
     3.3.  Final Responder Message . . . . . . . . . . . . . . . . .   6
   4.  Compliance with SASL Mechanism Requirements . . . . . . . . .   6
   5.  Requirements for the Application-Protocol Extension . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This specification describes the the family of Hashed Token (HT)
   Simple Authentication and Security Layer (SASL) [RFC4422] mechanisms.
   The HT mechanism is designed to be used with short-lived, exclusively
   ephemeral tokens, called SASL-HT tokens, and allow for quick, one
   round-trip, re-authentication of a previous session.

   Further properties of the HT mechanism are 1) hash agility, 2) mutual
   authentication, and 3) being secured by channel binding.

   Clients are supposed to request SASL-HT tokens from the server after
   being authenticated using a "strong" SASL mechanism like SCRAM
   [RFC5802].  Hence a typical sequence of actions using HT may look
   like the following:

      A) Client authenticates using a strong mechanism (e.g., SCRAM)
      B) Client requests secret SASL-HT token
      C) Service returns SASL-HT token
         <normal client-server interaction here>
      D) Connection between client and server gets interrupted,
         for example because of a WiFi <-> GSM switch
      E) Client resumes previous session using HT and token from C)
      F) Service revokes the sucessfully used SASL-HT token
         [goto B]

Schmaus & Egger           Expires May 15, 2018                  [Page 2]
Internet-Draft                                             November 2017
Show full document text