[kitten] Request for review of a SASL mechanism using the OPAQUE aPAKE

Nadja von Reitzenstein Cerpnjak <me@dequbed.space> Thu, 06 October 2022 16:45 UTC

Return-Path: <me@dequbed.space>
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 B6F9DC1526EA for <kitten@ietfa.amsl.com>; Thu, 6 Oct 2022 09:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.306
X-Spam-Level:
X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dequbed.space
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdNZhojYxY-p for <kitten@ietfa.amsl.com>; Thu, 6 Oct 2022 09:45:45 -0700 (PDT)
Received: from mail2.paranoidlabs.org (tureis.comfix.cc [148.251.10.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A944C152596 for <kitten@ietf.org>; Thu, 6 Oct 2022 09:45:44 -0700 (PDT)
Received: from [IPV6:2001:9e8:17c1:4800:40ac:99b6:6535:18aa] (unknown [IPv6:2001:9e8:17c1:4800:40ac:99b6:6535:18aa]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail2.paranoidlabs.org (PlabsMail) with ESMTPSA id E32C132E2D3 for <kitten@ietf.org>; Thu, 6 Oct 2022 16:45:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dequbed.space; s=rsa-20210101; t=1665074739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=cbf4kCB9sFINLIby4Tcjc7AYcVXLm+goXDxAHlfqjrU=; b=pc2GN+NtHVgs7K7avTk8kTO4ACB7yiWxdm4EYtG+COoYd1Jw+AJ1x6H8YTgWfryUGWg2B/ vSbrVo7BVVV02c2H36GMlV5jtOkLZjw3DEZyXu0/EQVDkMhHD+qmu6QE/mngb1q+l3S6Te d/zEy+wxe1BUNdO6LXLnpcpzwWnqdUVKRVNHkUnGycGF204HuLc5ndEwL2uuzl8L9BxWfP cmiJ2XVb5PiOp8nS/KfokIANvC+MkIoik/6QG6XUVlpCeOJzTV2o68cHcHuj8QFrwfi+E+ ukQZ7aGkMa/wtwnG6hZrXic5BjvfQTs9/8a9R2S8QswqJkIzPiUdNnr46BKlwg==
Message-ID: <e5a00d86-48a1-d602-0ee8-8cb80c06f826@dequbed.space>
Date: Thu, 06 Oct 2022 18:45:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1
From: Nadja von Reitzenstein Cerpnjak <me@dequbed.space>
Content-Language: en-US
To: kitten@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/XKXsoXMZhsVJiaji5qTegchC0Eg>
Subject: [kitten] Request for review of a SASL mechanism using the OPAQUE aPAKE
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 06 Oct 2022 16:45:49 -0000

Ohai!


I've been working on a SASL mechanism specification making use of the 
asymmetric PAKE currently being worked on by the CFRG, OPAQUE 
(https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/).

This mechanism offers much of the same advantages of SCRAM, but OPAQUE 
additionally specifies a method to register without exposing the 
clear-text password of an user to the server, and provides a client with 
a long-term secret, that can be used as e.g. an encryption key, without 
needing any further key exchange between multiple clients of the same user.

The current text of the draft can be found here: 
https://datatracker.ietf.org/doc/draft-reitzenstein-kitten-opaque/

While this document is far from standardization, as OPAQUE is itself 
too, I would nonetheless appreciate comments or reviews. For one to make 
sure I'm on the right track with my current approach on the technical 
side, and to get feedback on getting this document moving in the 
direction of WG adoption, should there be interest in that.


Thanks,
     Nadja