[Din] IRTF/DIN topic? InternetWide Realm Crossover

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

Return-Path: <vanrein@vanrein.org>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA64C1522B3 for <din@ietfa.amsl.com>; Fri, 14 Oct 2022 09:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level:
X-Spam-Status: No, score=-1.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_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=no 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 PWyfKTUz2D9Q for <din@ietfa.amsl.com>; Fri, 14 Oct 2022 09:12:30 -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 25541C14CE3A for <din@irtf.org>; Fri, 14 Oct 2022 09:12:07 -0700 (PDT)
X-KPN-MessageId: f07187a1-4bda-11ed-823a-005056abad63
Received: from smtp.kpnmail.nl (unknown [10.31.155.37]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id f07187a1-4bda-11ed-823a-005056abad63; Fri, 14 Oct 2022 18:12:02 +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=iBz5Cd4Qeyqy6ZEmBkpEQw5UYAxyztOz9QE1lNCjkLM=; b=LToESdV1XbbXRvlh+3MZlzfmyXrzfGHFoc+piNOcePYCCIIlNC8O1nwhCohSb0Zo2wBWuBLSP1Fy4 SVJPrM9l/12+w2NnmCoPEDH1qE7ACWYs8lz68sIWhNhSoEepzx3+AADUdeLba/RQIYLpfGZCXN9bON IVc4pEwUeaCELZ1o=
X-KPN-MID: 33|OjsBdljIvsBYkx4pRGKpHtHrHhO0fjquYlRNPvWrdTcwT6pprVSPu4jODj0iWZu OjSGpYBfJ13Ss7teYqdTjs17N86H/8pZSJD9pFUypFTM=
X-KPN-VerifiedSender: No
X-CMASSUN: 33|gujA7gAwBA/XHuxR4J7wpzlEJJrKfUo2zrv0eKZOzlUiHE/sj6kJULUpqjFl3NM CQ9IMlakH1P+usEErzZDN1w==
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 f179bda5-4bda-11ed-929c-005056ab1411; Fri, 14 Oct 2022 18:12:04 +0200 (CEST)
Received: by fame.vanrein.org (Postfix, from userid 1000) id 5DA4F29B76; Fri, 14 Oct 2022 16:12:04 +0000 (UTC)
Date: Fri, 14 Oct 2022 16:12:04 +0000
From: Rick van Rein <rick@openfortress.nl>
To: din@irtf.org
Message-ID: <20221014161204.GF7248@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/din/RQzc4XYWceHiZX6Bfz8IyzLyM78>
Subject: [Din] IRTF/DIN topic? InternetWide Realm Crossover
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2022 16:12:38 -0000

Hello DIN workgroup,

Over the past years, we've been working on an approach for Realm Crossover,
which allows clients to "Bring Your Own IDentity" to foreign servers, and
relies on a callback to a domain's identity provider.  This spans most
protocols in use today, without modifications.

I think this may be of interest for the IRTF's DIN workgroup, but am unsure.
Can you please give your response on the document below, and whether it would
be proper input for DIN?

There are more detailed specifications in our pipeline, for now focussing on
SASL as the carrier mechanism (because Kerberos5 is easy enough and Client DANE
is work in progress).

  * draft-vanrein-internetwide-realm-crossover-02 overview (see below)
  * draft-vanrein-diameter-sasl-07 callback to a client's identity provider
  * draft-vanrein-httpauth-sasl-07 adds SASL to the HTTP Auth framework
  * draft-vanrein-sipauth-sasl-01 adds SASL to the SIP Auth framework

Thanks,
 -Rick


P.S. The preliminary agenda overlaps between DIN and HTTPbis...


----- Forwarded message from internet-drafts@ietf.org -----

Date: Fri, 14 Oct 2022 05:55:44 -0700
From: internet-drafts@ietf.org
To: Rick van Rein <rick@openfortress.nl>
Subject: New Version Notification for draft-vanrein-internetwide-realm-crossover-02.txt


A new version of I-D, draft-vanrein-internetwide-realm-crossover-02.txt
has been successfully submitted by Rick van Rein and posted to the
IETF repository.

Name:		draft-vanrein-internetwide-realm-crossover
Revision:	02
Title:		InternetWide Identities with Realm Crossover
Document date:	2022-10-14
Group:		Individual Submission
Pages:		20
URL:            https://www.ietf.org/archive/id/draft-vanrein-internetwide-realm-crossover-02.txt
Status:         https://datatracker.ietf.org/doc/draft-vanrein-internetwide-realm-crossover/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vanrein-internetwide-realm-crossover
Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanrein-internetwide-realm-crossover-02

Abstract:
   Domains and domain user identities are available in many protocols,
   and can be expressed as part of the URI grammar.  This document
   outlines how clients can bring their self-controlled identities over
   when crossing over to foreign realms that rely on authenticated user
   identities.

                                                                                  


The IETF Secretariat



----- End forwarded message -----