[kitten] Relaying SASL to a Diameter backend, Realm Crossover

Rick van Rein <rick@openfortress.nl> Fri, 14 October 2022 17:14 UTC

Return-Path: <vanrein@vanrein.org>
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 6C1B6C1522D7 for <kitten@ietfa.amsl.com>; Fri, 14 Oct 2022 10:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.646
X-Spam-Level:
X-Spam-Status: No, score=-6.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kpnmail.nl
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 FEkw8k_I8v2V for <kitten@ietfa.amsl.com>; Fri, 14 Oct 2022 10:14:09 -0700 (PDT)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.169]) (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 F32A1C1522D8 for <kitten@ietf.org>; Fri, 14 Oct 2022 10:14:04 -0700 (PDT)
X-KPN-MessageId: 98194355-4be3-11ed-823a-005056abad63
Received: from smtp.kpnmail.nl (unknown [10.31.155.37]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 98194355-4be3-11ed-823a-005056abad63; Fri, 14 Oct 2022 19:13:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kpnmail.nl; s=kpnmail01; h=content-type:mime-version:message-id:subject:to:from:date; bh=r8/5JzzdUioad7dU4RQy81qhetvAVFw4bHLthuHOL3w=; b=LLYx8CYgU1BuBC71M8JQAq2CbNpgWACLYkdWveR0Jhw8KGc9ZuDbxYhV8VK0/PMorXqsaKpxh70XF MJNCIQzYeeajQ2XhDkEMAB8XUEkCRmrGe+qHnJXrGpFpiPIKGrD3Chrm5/byhhda/83vOXfeaKJBbf C3Zq+QmMysYr+O+E=
X-KPN-MID: 33|w5mKTYUzlrj55Tk20g0sIYF4EV4xpghqcrnGxbMUaKVfBiy/XfDVAPyDeE2zvCm qLjuqnJ4+ZUb+Y/xn+HZEqeE0cNoxyXxNC3j233UGfTw=
X-KPN-VerifiedSender: No
X-CMASSUN: 33|HVWnpEK2YLnyfMoPGkCx6HTm7nPnwLhc0bqNs6DqIu+O3vx7qoT36x1pGNc8Oyh MYKgMTCFFdRo6LYQ5ElXMpw==
X-Originating-IP: 77.173.183.203
Received: from fame.vanrein.org (77-173-183-203.fixed.kpn.net [77.173.183.203]) by smtp.xs4all.nl (Halon) with ESMTPSA id 992bec49-4be3-11ed-929c-005056ab1411; Fri, 14 Oct 2022 19:14:01 +0200 (CEST)
Received: by fame.vanrein.org (Postfix, from userid 1000) id D342729BB9; Fri, 14 Oct 2022 17:14:00 +0000 (UTC)
Date: Fri, 14 Oct 2022 17:14:00 +0000
From: Rick van Rein <rick@openfortress.nl>
To: kitten@ietf.org
Message-ID: <20221014171400.GA7961@openfortress.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/UILGwAckOe4cduBbM9s2RYErrdU>
Subject: [kitten] Relaying SASL to a Diameter backend, Realm Crossover
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: Fri, 14 Oct 2022 17:14:16 -0000

Hello,

The attached specification is (currently) on the Indendendent track,
but does something to SASL that may be useful for Kitten to have seen.

It defines an embedding for SASL into Diameter AVPs, and supports
relaying to a backend which runs under the domain (or ENUM tree)
to which the client wants to login.  This domain is validated over
TLS, DNSSEC and DANE and it is subsequently trusted to release a
username.

  * This uses Channel Binding to ensure the frontend that the
    client authenticates against;

  * Normally, relaying SASL is insecure, as it may break into a
    mailbox or other resource.  The trick is that Diameter is not
    a valuable resource to crack; it merely says "aye" or "nay".

This is a stretch -- both technically and in terms of user experience.
We are working towards "Bring Your Own IDentity" service, where users
can run their own IdP and use it anywhere, without local accounts.

Any feedback is kindly welcomed.  Kitten is not in London, I saw,
but I will be there and am open to dicussion.

All this is working well for us, so the plan is to move towards the
RFC Editor and acquire the AVP codes for Diameter.


Cheers,

Rick van Rein
InternetWide.org


   ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -----


A new version of I-D, draft-vanrein-diameter-sasl-07.txt
has been successfully submitted by Rick van Rein and posted to the
IETF repository.

Name:		draft-vanrein-diameter-sasl
Revision:	07
Title:		Realm Crossover for SASL and GSS-API via Diameter
Document date:	2022-10-14
Group:		Individual Submission
Pages:		25
URL:            https://www.ietf.org/archive/id/draft-vanrein-diameter-sasl-07.txt
Status:         https://datatracker.ietf.org/doc/draft-vanrein-diameter-sasl/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vanrein-diameter-sasl
Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanrein-diameter-sasl-07

Abstract:
   SASL and GSS-API are used for authentication in many application
   protocols.  This specification extends them to allow credentials of
   an identity domain to be used against external services.  To this
   end, it introduces end-to-end encryption for SASL that is safe to
   relay through a foreign server.