Re: [Secdispatch] Requesting agenda time for draft-halen-fed-tls-auth

Eric Rescorla <ekr@rtfm.com> Thu, 07 July 2022 22:30 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEDCC15AB55 for <secdispatch@ietfa.amsl.com>; Thu, 7 Jul 2022 15:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.com
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 yC-xgP5aOCLK for <secdispatch@ietfa.amsl.com>; Thu, 7 Jul 2022 15:30:41 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 ietfa.amsl.com (Postfix) with ESMTPS id AFE13C15AB59 for <secdispatch@ietf.org>; Thu, 7 Jul 2022 15:30:41 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id y2so18197751ior.12 for <secdispatch@ietf.org>; Thu, 07 Jul 2022 15:30:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UPkr6bLzBMqsu1jKGxEYfMoWbvs0xhgLcRoVTTOj9hY=; b=pt4An3h3Qcy1gdtYVL1kbIZ2I3vIznzAR2jdxTe0mbB361D3o/HM5osJLqUZAS8hDt XVqrzOPsACWKfFutplJM65WmKSuvF+H0VAWLoeMZycfnvHSUkXCI+SK9KSPQZaB9Bfkw gQg5+rWDwZr69vG8qPkHaWTfL6suTpt0Tf04uP541h7YV0FrxGrbxyEdwtyuJ4y4uTI6 RkepzriFzk0NAv5+S3neu1IeS6H9O5m7O0yIMCM8yDWoU4NhllMFE6G/ORtAKvqOz8VW +Y1Ikiw8+MLu/hVAmGRJHRDr6CsZUTuQEYNS58bLtstOgpCTHhgzEyvd3fLAgirpfQEq qBkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UPkr6bLzBMqsu1jKGxEYfMoWbvs0xhgLcRoVTTOj9hY=; b=YGs+RJhXWl2Zglyk0NsV0YrwGNylZX2z7de1CpK/6MNnTc9HHbHL3cEEewaWv11REF OHXFrwi5sCl29kSPuEVMMW8AYBv5BheAvc41ZOfW85e+Wk7mTHk+xl4g4NXruABRePhs ORsaHrog24QiCkf+nv82t/6LxmFTGjD1WSu4jloAWmgQQ5JW0W/gZ7bJd8FWqD3X36QF NmbNn4uqbiufl0meE5jKfPoza0ReAjnaZlYBiNGGmSOpSGRVRj8s1M2e+Te/r3pBbg8e XXdgDDdRdYCSiK1gzC3Czmqgh1h1tdBRsnsxH5WqrMsW4L13NxE4r61ne6pIqsHdWFCl aVXQ==
X-Gm-Message-State: AJIora+ZS12wVYVKLF5yj1ubOIjuNuoysVuxLEdICtny/ttje4oQUWod B7fLbh+PscYMfQh0tSsqFz0IAKMfWTKEe5AQ4JL7PVs/4THfwg==
X-Google-Smtp-Source: AGRyM1ulCw1g5YqjcqP52J9TpRL5+IsLka4BCd/PsRvRtN/4jJy1T1TBta7KNIBHh6C+25UV/25aR2c9NhRwmx3YQd4=
X-Received: by 2002:a05:6638:250c:b0:33b:adde:3077 with SMTP id v12-20020a056638250c00b0033badde3077mr309235jat.148.1657233040943; Thu, 07 Jul 2022 15:30:40 -0700 (PDT)
MIME-Version: 1.0
References: <e5685a29-f8b6-f44a-ad8a-cda5da1c1e75@internetstiftelsen.se>
In-Reply-To: <e5685a29-f8b6-f44a-ad8a-cda5da1c1e75@internetstiftelsen.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 07 Jul 2022 15:30:04 -0700
Message-ID: <CABcZeBPn+FuHWFffWBTtQW9wzhuSO8piBRrTfDQ3ikJZRS_FFw@mail.gmail.com>
To: Stefan Halen <stefan.halen=40internetstiftelsen.se@dmarc.ietf.org>
Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>, "secdispatch-chairs@ietf.org" <secdispatch-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b74dab05e33ea281"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/UCL8psazFBAaVKmG76jeyeIDJ0o>
Subject: Re: [Secdispatch] Requesting agenda time for draft-halen-fed-tls-auth
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2022 22:30:45 -0000

Document: draft-halen-fed-tls-auth-03.txt

I took a quick look at this document. It's not entirely clear
to me what it is you want to standardize. Is it the metadata
structures defined in S. 4? Assuming so, then I think this
would need a new WG and I would suggest a BOF to assess
IETF interest.


I'm having a little trouble understanding the main idea
here. You say:

   This key exchange is performed through the publication of the
   federation metadata by the federation and the use of that federation
   metadata by its members.  Without a federation, the server side is
   often required to create a public key infrastructure (PKI) in order
   to distribute client certificates.The Swedish education sector uses

But as I understand this design, you in fact have a PKI, it's
just that it's carried in a single JWS-signed metadata object
rather than in X.509 certificates. This seems less flexible,
so it's not clear to me what the advantage of this design
is.

This needs considerably more detail about how it is used
in practice. Specifically, it's not clear to me what
the reference identity is that I am supposed to compare
the pins to. I.e., if I think I am connecting to a given
domain name, which is the common practice, how do I look
that up in the metadata?

-Ekr



On Wed, Jul 6, 2022 at 6:28 AM Stefan Halen <stefan.halen=
40internetstiftelsen.se@dmarc.ietf.org> wrote:

> Hi Secdispatch,
>
> I would like to request agenda time at IETF 114 for dispatching
> draft-halen-fed-tls-auth
> https://datatracker.ietf.org/doc/draft-halen-fed-tls-auth
>
> Time: 15 min
>
> The draft describes how to federate machine-to-machine authentication
> using already well-established protocols. Federated TLS Authentication
> (FedTLS) is a simple layer on top of TLS utilizing mutual TLS and public
> key pinning to establish a secure end-to-end channel. Information about
> the peers (e.g., organization, certificate issuers, pins) are aggregated
> and published by a federation as a JWS.
>
> Background
>
> In Sweden we are running a SAML federation and a FedTLS federation for
> the school sector. The school's administrative processes are digitized
> and automated. There is also a standardized protocol that enables
> schools to automate the User Lifecycle Management (ULM) for remote
> services. One of the stakeholders is the National Agency for Education.
> They will use the FedTLS federation to secure the ULM API for the
> digital national tests. FedTLS is also used for license management and
> for ordering digital teaching material and more to come. We are also
> considering providing FedTLS as a service in the federation for the
> Swedish health care sector.
>
> Open Source implementations:
> https://github.com/Sambruk/EgilSCIM
> https://github.com/joesiltberg/bowness
> https://github.com/Sambruk/windermere
>
> Feedback is greatly appreciated.
>
> Regards,
> Stefan Halén
> The Swedish Internet Foundation
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>