[kitten] The Hashed-Token SASL Mechanism (SASL-HT)

Florian Schmaus <flo@geekplace.eu> Fri, 29 September 2017 09:08 UTC

Return-Path: <fschmaus@gmail.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78203126B6E for <kitten@ietfa.amsl.com>; Fri, 29 Sep 2017 02:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level:
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXXkQumkyQwK for <kitten@ietfa.amsl.com>; Fri, 29 Sep 2017 02:08:17 -0700 (PDT)
Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D977124239 for <kitten@ietf.org>; Fri, 29 Sep 2017 02:08:17 -0700 (PDT)
Received: by mail-wm0-f50.google.com with SMTP id q124so2048454wmb.0 for <kitten@ietf.org>; Fri, 29 Sep 2017 02:08:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version; bh=sMfILGwuC+l5qhxrZKecrxHGjL9w03RlkS5wgB2TM3o=; b=RiyLioZo3ljRbujchfHHIcNSlErMkMfof17/8FkDTRPWbMTlXJBN/gDe3V4BYrcLUZ g8HzfiRx6itCSeGKTW9Z60pP7dYTrK0kWkZfSQrZ4yIDYf8QumyUmq3GC65T54knRZpb hgjFU2lL82zrccDNobdeYix8cMAUKlbJQ/xYlG5aWyTc7FyR7efwCFPDHM2+1ynJ+aG7 xtkr5AHjZxtgP6xfnsD+SwiOjDfcBlZwBn2BXT//0OzfD1meD5eWjwiUK57pA3X6aF4Y prJStYmnAo77Ejb89pBRS+AcySLKL/hmm62IzKz/gl+ItIso/968TRj38MwtrnAUpnqe af9g==
X-Gm-Message-State: AHPjjUiRWq56Umy2igdFuxrzAOsxnJ0dyk4qDE5pNHDjWssr+yowM5N1 z8onpGkFVcmQ7YWuCN245Ypxn/r8
X-Google-Smtp-Source: AOwi7QCvsqHn+A6xZNmEo/hjBEf0iUatkLmoNb2YNwQDKdkFNAKG15M3zk1a1gbVeWlNwc5H3X8GGg==
X-Received: by 10.80.151.206 with SMTP id f14mr8876034edb.27.1506676095287; Fri, 29 Sep 2017 02:08:15 -0700 (PDT)
Received: from ?IPv6:2001:a62:11f3:ee01:54eb:8b20:9338:80c? ([2001:a62:11f3:ee01:54eb:8b20:9338:80c]) by smtp.googlemail.com with ESMTPSA id j6sm681716edj.58.2017.09.29.02.08.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 02:08:13 -0700 (PDT)
To: kitten@ietf.org
Cc: XMPP Standards <standards@xmpp.org>, Christoph Egger <egger@cs.fau.de>, Peter Saint-Andre <stpeter@stpeter.im>
From: Florian Schmaus <flo@geekplace.eu>
Message-ID: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu>
Date: Fri, 29 Sep 2017 11:08:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1wPL8f8arTj9MASOoMHS9uwkbkOjPX2i7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/v7X6WBMxMDpNGvXu9N5DEggVdmQ>
Subject: [kitten] The Hashed-Token SASL Mechanism (SASL-HT)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2017 09:08:20 -0000

I would like to note the existence of draft-schmaus-kitten-sasl-ht-01:

https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01

Fast, ideally instant, session reattachment becomes increasingly
important, partly because of the rising share of mobile sessions. A
while ago I started thinking about a new approach for quick XMPP session
reattachment. Currently in XMPP a session obtains a (non-sensitive)
token which, after authentication via SASL, it can use to resume an
existing session (XEP-0198). However, this does lead to a number of
round-trips during session setup, many of which we can elide by
combining the authentication and resumption steps.

Thus we initially authenticate an XMPP session using a strong mechanism
like SCRAM, but at resumption-time we want a single round trip
mechanism. The basic idea of such a mechanism is that the client
requests a short-lived, exclusively ephemeral token after being
authenticated, which can be used to authenticate the resumption in an
efficient manner.

Members of the XSF community pointed out that that it eventually makes
sense to split the work into a number of distinct portions so that other
application protocols can re-use and benefit from it:

  1) An extensible SASL profile, replacing the existing SASL profile
     specified in RFC 6120, being developed within the XSF as XEP-0388
     [1] (although we might well move this to IETF once it fits our
     needs).
  2) An extension to this profile to support the framework of XEP-0198
     session resumption (XEP-ISR-SALS2, [2]).
  3) A new SASL mechanism suitable for the purpose (HT-*, as specified
     in draft-schmaus-kitten-sasl-ht-01).

The SASL HT-* mechanism outlined is attempting to provide a reasonably
secure authentication based around a token obtained over the application
protocol, in a single round-trip. This single-round-trip is a key
requirement. The proposal uses a single-use token as a shared secret,
provides channel binding and mutual authentication.

Because neither the XSF nor the authors of the Internet Draft do claim
to have the expertise required to adequately review and otherwise
develop a SASL mechanism it has been submitted as an Internet Draft by
an individual.

The XSF does AFAIK not operate a formal liaison process with the IETF in
general; instead we will simply encourage interested individuals to
participate here instead. In particular, the XSF will neither
participate, nor attempt to control, as an organisation. Many of the
participants within the XSF are also IETF participants, so we'll play
nicely.

Your feedback is highly appreciated.

Thanks
 Florian

1: https://xmpp.org/extensions/xep-0388.html
2: http://geekplace.eu/xeps/xep-isr-sasl2/xep-isr-sasl2.html