Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)

Brian Campbell <bcampbell@pingidentity.com> Mon, 22 May 2017 15:03 UTC

Return-Path: <bcampbell@pingidentity.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 CA6A612EAF9 for <oauth@ietfa.amsl.com>; Mon, 22 May 2017 08:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=pingidentity.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 Vp8-myzOsiF8 for <oauth@ietfa.amsl.com>; Mon, 22 May 2017 08:03:20 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 0AEAB12EAFC for <oauth@ietf.org>; Mon, 22 May 2017 08:03:11 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id e193so85036427pfh.0 for <oauth@ietf.org>; Mon, 22 May 2017 08:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4VwqlwHcP4GBf+xvlrNBCt9v/IZ125aHc6RLI1pBnVg=; b=h/k14faV7lNVzv3KQCV/jhDGzXmKRNmO6d34zaP0wC7voxb1zSUX65xjvjFNze73eN qwV1SIpLfSZ/ydVkKyj8A/Gi+505GBg39OmZFxUI1gYk7j49JB/lOqOEU9QBjXmbGsJr 92yYiWKz051Ez8bT2exooTHjb7F0ymciMU+Sk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4VwqlwHcP4GBf+xvlrNBCt9v/IZ125aHc6RLI1pBnVg=; b=NTeXLF9gQOJvbXTfo6AFxz//G1ko+rwOk6kuLMfOMuAHC42VLsfhaNKe5ZTgXaGDW6 WCcV5GfbiOfSvnSpqtk8Vglu6+UZVj+zih1rK93yFSvMr90+6rb8lSYG31r/G132veH9 /QWxFE1pDk9i8LjaVDV8R89jTuIF+GzeXn4GGQg5r7H8LB3E2C4g0YmUvxF7KTSWzVVJ q94QQpO2ShMV+ocoerz0P2VtPrDxRU1u/0QlUUtAVvCCFv9pC/UNq4yOU2xk+6SAHJSH 90fQUp8alEMO0Cp5UaKcx0ntpkMu06vXyYrO66eXz0N5VIeKcp9/JqSg16mCtgDwPg+N wtgg==
X-Gm-Message-State: AODbwcDRObj7DaebvLN1GXym85I4Vy0Y3e7acFfGQNYKixkJxvB0sku7 CelLvNhQayi7Vg/RUN3cZ3ou5+jwF5+k
X-Received: by 10.84.202.163 with SMTP id x32mr29804385pld.51.1495465390413; Mon, 22 May 2017 08:03:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.154.205 with HTTP; Mon, 22 May 2017 08:02:39 -0700 (PDT)
In-Reply-To: <77F2A1D2-5A8E-4E88-9920-A15BC24795E6@ve7jtb.com>
References: <CA+k3eCSqVmevpN_Rc5mcVborRk3hh0H6T_o8SAsJ=cJ6uw16xg@mail.gmail.com> <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> <CA+k3eCQHn4VAZyznQGu+61A9uNtYSGRpD0PBLJjUW00TBaAcSQ@mail.gmail.com> <77F2A1D2-5A8E-4E88-9920-A15BC24795E6@ve7jtb.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 22 May 2017 09:02:39 -0600
Message-ID: <CA+k3eCQ6Az8PMu_tuLWYEFF7+twJrFynYYYkrokDXzupYrA1sA@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1486b65eb8ff05501e2bfa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gBOFhHeaSyQGP9bxFKHRB3rHnc4>
Subject: Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 22 May 2017 15:03:23 -0000

Thought I was looking to get a sense of preference from the WG, I tend to
lean the same way as John. The issuer constraint is an optional thing
that's applied per client and the only use I can see in supporting more
than one is for the client to change issuers without updating it's
registration/configuration.

On Sat, May 20, 2017 at 8:44 AM, John Bradley <ve7jtb@ve7jtb.com>; wrote:

> +1 for “tls_client_auth_root_dn"
>
> On making it an array, I think that adds complexity for little gain, and
> perhaps introduces new trust issues.
>
> I think it should be one trusted root or all the trusted roots.  If you
> only trust 5 then configure that in the AS.
>
> An array seems only useful where the client has a cert from x but may want
> to get the next one from y and not re-register.
> I think if the client or federation operator is locking itself down to
> specific issuers one per client should be fine.
> I expect that in most cases the issuer will need to be in the trust store
> of the AS anyway so this is just pinning the cert to one of a limited set.
>
> John B.
>
> On May 15, 2017, at 2:42 PM, Brian Campbell <bcampbell@pingidentity.com>;
> wrote:
>
> I'll add text/clarification that the DN metadata fields being RFC4514
> string representations of DNs in the next draft.
>
> Given that this is a profile of use and the metadata fields are just one
> way to express the binding of certificate and client, and after thinking
> about it some more and not wanting to introduce too many variations, I feel
> that keeping tls_client_auth_subject_dn as the subject distinguished name
> of the client certificate is more straightforward and sufficient for this
> case.
>
> Is there rough consensus to change "tls_client_auth_issuer_dn" to
> "tls_client_auth_root_dn" as was suggested? The latter name makes sense to
> me but I don't want to make that change without a little more input or
> buy-in from the WG. So please respond one way or the other, if you've got
> an opinion.
>
> Similarly I'm looking for some rough consensus around if a single
> root/issuer is sufficient in the metadata before potentially making any
> changes. Should "tls_client_auth_issuer/root_dn" remain a single DN
> string value or should it be an array allowing for more than one?
>
>
>
> On Fri, Apr 21, 2017 at 6:18 PM, John Bradley <ve7jtb@ve7jtb.com>; wrote:
>
>> I agree with Brian.
>>
>> Trying to do anything with PKIX opens up cans of worms.  One of the
>> reasons we have resisted to this point.
>>
>> However there are server to server use cases that legitimately need this.
>>
>> I agree that in general DN is a mess, I suspect that telling people to
>> directly use the DER encoded version wont fly, so my thought was to use the
>> RFC 4514 string representation that most tools produce.
>>
>> We did talk about subject alt DNS Names, however those may not be present
>> in eIDAS certificates that some people may need to use for legal reasons,
>> or if it is present it might be an email.
>>
>> I suspect that users of this will fall into two camps.  One that has a
>> small set of trusted CA that are configured out of band and any certificate
>> from those roots with the correct DN is OK.
>>
>> The other group will be trying to do something more dynamic with SSL
>> server certs (May or may not be EV)   I could see those people preferring
>> DNS Name subject alt, or using JWKS to publish there certs.
>>
>> The problem is finding the right balance of flexibility without too many
>> options to confuse people.
>>
>> I am inclined towards DN for those that are willing to suffer the pain,
>> and JWKS_uri for everyone else.   One advantage of the JWKS_URI approach is
>> that self signed certs should work just fine, that is something that the
>> R&E people will want if they use this.
>>
>> For most proof of possession we should be promoting token binding as the
>> most flexible approach as it also works with mobile without per instance
>> registration.
>>
>> John B.
>>
>>
>> On Apr 21, 2017, at 7:41 PM, Brian Campbell <bcampbell@pingidentity.com>;
>> wrote:
>>
>> Thanks, James, for the adoption support as well as the review and
>> comments. I've tried to respond to the comments inline below.
>>
>> On Thu, Apr 20, 2017 at 11:33 PM, Manger, James <
>> James.H.Manger@team.telstra.com>; wrote:
>>
>>> I support adoption of draft-campbell-oauth-mtls.
>>>
>>> Now some comments on the doc:
>>>
>>> 1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified.
>>> Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]?
>>> Perhaps a base64url-encoding of a DER-encoded DN? It would actually be
>>> better to allow any subjectAltName to be specified, instead of a DN.
>>>
>>
>> How about calling it tls_client_auth_subject and defining it as a string
>> and allowing it to represent the expected subject which could be in the
>> cert as the subject DN or a subjectAltName? For Subject DN and DN
>> subjectAltNames it would be the "String Representation of Distinguished
>> Names" and an appropriate string for the other subjectAltName types (I'll
>> have to look at what's there 'cause I don't know off hand and guidance or
>> suggested text is always more than welcome).
>>
>>
>>
>>
>>> 2. [§2.3] Change the name of tls_client_auth_issuer_dn (maybe
>>> tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too
>>> easy to assume this pair refer to the issuer and subject fields of the cert.
>>>
>>
>> The accompanying text tries to make it clear that it's the root issuer
>> but the tls_client_auth_issuer_dn name can certainly be changed to
>> tls_client_auth_root_dn or something along those lines, if folks think the
>> name in -01 is liable to cause confusion?
>>
>>
>>
>> PKI chains can be complex so the expected root might not be such a stable
>>> concept. For example, the Let's Encrypt CA chains to an ISRG Root and an
>>> IdenTrust DST Root [https://letsencrypt.org/certificates/].
>>>
>>
>> The goal was to provide a metadata field to express some constraint for
>> what is kind of expected to be a common deployment of a number of entities
>> participating in some OAuth API thing and are being issued certificates
>> from a common issuer for the group of participants.
>>
>> Perhaps it should be an array of strings rather than a single value?
>>
>> Or do you have suggestions for some alternative?
>>
>>
>>
>>
>>> 3. [§2.3] If a client dynamically registers a "jwks_uri" does this mean
>>> the authz server MUST automatically cope when the client updates the key(s)
>>> it publishes there?
>>>
>>
>> If the authz server supports that kind of trust model as well as
>> dynamically registration, then I would expect so, yes.
>>
>>
>>
>>
>>> 4. [§3] An access token is bound to a specific client certificate. That
>>> is probably ok, but does mean all access tokens die when the client updates
>>> their certificate (which could be every 2 months if using Let's Encrypt).
>>> This at least warrants a paragraph in the Security Considerations.
>>>
>>
>> In my own mind that was implied and okay because it's likely that access
>> tokens will have a shorter lifespan than certificates and refreshing or
>> getting a new access token is typically easy anyhow.
>>
>> Anyway, it doesn't hurt to be explicit about it, can you propose some
>> such text for the Security Considerations?
>>
>>
>>
>>
>>>
>>> 5. [§3.1] "exp" and "nbf" values in the example need to be numbers, not
>>> strings (drop the quotes).
>>>
>>
>> Silly mistake on my part. Thanks for catching that. Will fix.
>>
>>
>>
>>>
>>> 6. An access token linked to a client TLS cert isn't a bearer token. The
>>> spec should really define a new token_type for responses from the token
>>> endpoint. That might not necessarily mean we needs a new HTTP
>>> authentication scheme as well (it might just hint that "Bearer" wasn't
>>> quite the right name).
>>>
>>
>> Indeed "Bearer" isn't quite right and very likely a name that would be
>> different with the benefit of hindsight. But other than having names on the
>> wire that are more true to the nature of the tokens, I don't know that a
>> new token_type or HTTP auth scheme adds value to the use cases here.
>> However, they would likely make deployment of this stuff more cumbersome
>> and take longer.  Whereas many systems can likely plug in mutual TLS on top
>> of the existing token_type and HTTP auth scheme without major changes. I'm
>> strongly inclined to not introduce a new token_type and more inclined to
>> not do a new HTTP auth scheme.
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>