Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Tue, 06 November 2018 21:03 UTC
Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EAB130E0C for <oauth@ietfa.amsl.com>; Tue, 6 Nov 2018 13:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0a7Wc1597JRR for <oauth@ietfa.amsl.com>; Tue, 6 Nov 2018 13:03:28 -0800 (PST)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 C85E01277D2 for <oauth@ietf.org>; Tue, 6 Nov 2018 13:03:27 -0800 (PST)
Received: by mail-it1-x12d.google.com with SMTP id h13so19970654itl.1 for <oauth@ietf.org>; Tue, 06 Nov 2018 13:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sD36WHIEQgIdY2bWR/ISsLIgF1QQyq1kQYHhfdf2dMI=; b=JG6gaU8nJ9Q2r331in75OXZ4HgDFDPxDtbzkWFyMDMS6xv3ayHMaOyBBweIrdpQalk SrhztlmAoUeoqfZ0rZP+soPtLf+rRLR2xOqlCOov+PV3Vyji8D8EYnFVLqcqjH1/OFf2 k0rF2+cy8kkPlAXP0Hc5unjHSGfTPRXvvvPCa+Uj+/Yr3wbtkfD2bP7mizfpqhz687f+ jvYLZ5b5CAVkMjqXauOikzUbrvsxTLjp7W7xjCjfn+wuhpxAREJy6gRjLdCvHUfvK3DC A4ZMhY+47rG5piHXQ5XkXTfYUh3leBeBVD3IsNbiPk4OdZ+bNaqZ2iiitRsCR3pzwUKQ VzZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sD36WHIEQgIdY2bWR/ISsLIgF1QQyq1kQYHhfdf2dMI=; b=mhH90n9yfxidVYJHJxsl2UVxZqWPS5InOFSfKDAPbzJmXOuLrOpxvlyhWfjcfZFYG8 OamrjXJzLtXU1d+B+iLkZ4lEY08G2dqAFo7newfGlK2vPRts0Cd1Zhxp7tkBT6uaYbb+ G7W0CxgrrB/p8C2TFG89Q0hzQvY6J2n7rVKL+mcv7joXplQL/nPqWulF1MIUF9s8spPx q9I5aPGCQWhWZSiPlTOYaNW/52vg8TiGwbtquC1pnspO8HXlfVH0y8Kmp7gb3CwW/qSD PEefXGLhVUAB2foQZXigb5VF98n55JztIFr414+HXpgGUExIlivnzS150K3pScQWkWTE Farg==
X-Gm-Message-State: AGRZ1gLMYx7KvZklmF2ci9tWZPqoeOxTBL70KxHf30OkX8aAxHemHZqp k7M4uktmc9hetfz9uBhANAJZ7Wbtjr0aiog7xhA=
X-Google-Smtp-Source: AJdET5ftmipbG/Qslk7JdWRSVQIKdgYERIkdg1BdoieTrp9AN3swZOhGkb1Dz3SHEu0/Jo7dDv+r/ocPo3h24CKrBRw=
X-Received: by 2002:a05:660c:247:: with SMTP id t7mr3767188itk.107.1541538207065; Tue, 06 Nov 2018 13:03:27 -0800 (PST)
MIME-Version: 1.0
References: <CAL841A_29YGLC-LtQcj1Mw15skys59V0DvDmyOpDS6V+x1LxWw@mail.gmail.com> <CA+k3eCSuU=3ENrYk75e5waGD7erKsf5mX1vT+wfjkqL76QomwQ@mail.gmail.com> <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> <CAL841A90GbZ7c47Lpv=c5mmVRQUwZFVSZ_4CCu10xAsUsk11mg@mail.gmail.com>
In-Reply-To: <CAL841A90GbZ7c47Lpv=c5mmVRQUwZFVSZ_4CCu10xAsUsk11mg@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Tue, 06 Nov 2018 16:03:09 -0500
Message-ID: <CAGL6epKXJ-kTyyoVjVFSAhDMMFXMsjfZ6U4fNmvVSooH28jLFQ@mail.gmail.com>
To: evan2645@gmail.com
Cc: neil.madden@forgerock.com, bcampbell=40pingidentity.com@dmarc.ietf.org, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003d6bd1057a055572"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/cdBlEDJAWq3h8sat51f_4yc2AVM>
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 21:03:31 -0000
You might want to look at RFC6125 which covers this topic and provides recommendations for representing application in certificates: https://tools.ietf.org/html/rfc6125 Regards, Rifaat On Tue, Nov 6, 2018 at 3:53 PM Evan Gilman <evan2645@gmail.com> wrote: > Response(s) inline > > On Mon, Nov 5, 2018 at 11:53 PM Neil Madden <neil.madden@forgerock.com> > wrote: > > > > Is there an intention that any semantics are attached to the SAN being a > URI or DNS name or IP or ...? Or is it still intended to be an opaque > identifier? > > There are some extra things we could do if we attached type-specific > semantics to the matching (e.g. DNS wildcarding etc), however I think > that continuing to use the values as opaque identifiers would get us > most of what we need while keeping things simple. > > > On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell= > 40pingidentity.com@dmarc.ietf.org> wrote: > > > > Thanks Evan for bringing this to the WG's attention. More or less the > same question/issue was raised yesterday in the area director's review of > the document as well. I plan to bring this up as a discussion item in the > meeting today. But my sense from some early discussions is that there is > likely to be (rough) consensus to make some change in order to allow a SAN > to be specified as the certificate subject identifier in the PKI client > auth mode. We'll need to figure out the specifics of how that works. I > don't think there are significant drawbacks to extending the number of > client registration metadata parameters per se. I guess I've just been > attracted to the idea of overloading the existing value because that felt > like maybe a less invasive change. But perhaps that's shortsighted. And > there's nothing inherently wrong with additional client metadata parameters. > > > > I don't know if we could get away with a single new parameter that could > carry the value for any SAN type. Something like, { ... > "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I > feel like that'd probably be okay but in theory there's the potential for > confusion of the value across different types. So probably there's a need > to indicate the SAN type too. Either with more client metadata parameters > like tls_client_auth_san_uir, tls_client_auth_san_email, > tls_client_auth_san_ip, etc. or maybe with a structured value of some sort > like {... "tls_client_auth_san": {"type":"URI", > "value":"spiffe://trust-domain/path"} ... }. And then deciding which types > to support and if/how to allow for the extensible types. > > I am far from an authority here, but it is my understanding that one > of the primary drivers in supporting SAN over Subject is that the > values are strongly typed. While some of the advantages gained from > this may be less useful in our own context, I feel that it make sense > to keep the values separate and not overload a single value. Whether > that means dedicated metadata parameters or a structured parameter > value, I am not sure what the tradeoffs would be, but both options > sound suitable to me. > > > Anyway, those are just some thoughts on it. And it'll be discussed more > today. Suggested/proposed text is always helpful though (even if it's not > used directly it can help move the conversation forward and/or help > editor(s) to have prospective wording). > > Great. I will work on some sample text since it sounds like that would > be generally helpful > > > On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman <evan2645@gmail.com> wrote: > >> > >> Hello everyone.. > >> > >> Very excited to see this draft. It helps tremendously in addressing > >> use cases around oauth client management in machine-to-machine > >> scenarios. Particularly, the PKI authentication method. > >> > >> In reviewing the document, I noticed that the only supported method > >> for identifying a client using the PKI authentication method is by > >> referencing its distinguished name. This caught me a bit by surprise - > >> many newer projects aimed at automating X.509 issuance in the > >> datacenter utilize SAN extensions rather than distinguished name in > >> order to encode identity. I am further under the impression that the > >> community is, in general, moving away from the subject extension > >> altogether in favor of SAN-based identification. > >> > >> Full disclosure: I am one of the maintainers on a project called > >> SPIFFE, which provides identity specifications for datacenter workload > >> applications. For X.509, SPIFFE encodes identity into a URI SAN > >> extension. A number of projects using SPIFFE do not configure the > >> subject with identifying information (SPIRE and Google Istio being > >> just a couple). I am also hearing of other X.509 automation projects > >> which are moving away from subject/distinguished name (even if they > >> are not using SPIFFE). > >> > >> While I think support for distinguished name is absolutely necessary, > >> I worry that supporting it solely will render it incompatible with > >> some of the more modern PKIX systems and not stand the test of time. I > >> know that I am a little late to this, and for that I apologize... but > >> I feel this is a significant point. > >> > >> I would like to open a discussion on supporting the most commonly used > >> SAN extension types in addition to distinguished name. To accomplish > >> this, amending section 2.1.2 `Client Registration Metadata` with > >> additional parameters seems appropriate. In my experience, the most > >> commonly used SAN extensions are: DNS name, IP address, URI, and email > >> address. > >> > >> Are there significant drawbacks to extending the number of client > >> registration metadata parameters? I would very much like to see this - > >> without it, many existing projects will be unable to use the spec. I > >> am happy to contribute time and text to this, assuming people feel > >> that this is a beneficial addition. Sorry again for the timing > >> > >> -- > >> evan > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > evan > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls Evan Gilman
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Brian Campbell
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Neil Madden
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Evan Gilman
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Justin P Richer
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Torsten Lodderstedt
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Brian Campbell
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Brian Campbell
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Evan Gilman
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Torsten Lodderstedt
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Evan Gilman
- Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mt… Brian Campbell