Return-Path: 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 ; 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 ; 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 ; Mon, 22 May 2017 08:03:11 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e193so85036427pfh.0 for ; 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: <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> <77F2A1D2-5A8E-4E88-9920-A15BC24795E6@ve7jtb.com> From: Brian Campbell Date: Mon, 22 May 2017 09:02:39 -0600 Message-ID: To: John Bradley Cc: "Manger, James" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1486b65eb8ff05501e2bfa" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:03:23 -0000 --94eb2c1486b65eb8ff05501e2bfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > +1 for =E2=80=9Ctls_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 wan= t > 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 > 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 fe= el > 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 t= o > 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 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 presen= t >> 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 certific= ate >> 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 preferrin= g >> 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 >> 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. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specifie= d. >>> 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'l= l >> have to look at what's there 'cause I don't know off hand and guidance o= r >> suggested text is always more than welcome). >> >> >> >> >>> 2. [=C2=A72.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 t= oo >>> 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 t= he >> name in -01 is liable to cause confusion? >> >> >> >> PKI chains can be complex so the expected root might not be such a stabl= e >>> concept. For example, the Let's Encrypt CA chains to an ISRG Root and a= n >>> 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 entiti= es >> 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. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does this= mean >>> the authz server MUST automatically cope when the client updates the ke= y(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. [=C2=A73] An access token is bound to a specific client certificate.= That >>> is probably ok, but does mean all access tokens die when the client upd= ates >>> 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. [=C2=A73.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. Th= e >>> 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 >> >> >> > > --94eb2c1486b65eb8ff05501e2bfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thought I was looking to get a sense of preference from th= e WG, I tend to lean the same way as John. The issuer constraint is an opti= onal thing that's applied per client and the only use I can see in supp= orting more than one is for the client to change issuers without updating i= t's registration/configuration.
=C2=A0
On Sat, May 20, 2017 at 8:44 AM,= John Bradley <ve7jtb@ve7jtb.com> wrote:
+1 for =E2=80=9Ctls_client_auth_root_dn"

On making= it an array, I think that adds complexity for little gain, and perhaps int= roduces new trust issues.

I think it should be one= trusted root or all the trusted roots.=C2=A0 If you only trust 5 then conf= igure that in the AS.

An array seems only useful w= here the client has a cert from x but may want to get the next one from y a= nd not re-register.=C2=A0
I think if the client or federation ope= rator is locking itself down to specific issuers one per client should be f= ine.
I expect that in most cases the issuer will need to be in th= e 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:4= 2 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

= I'll add text/clarification that the DN metadata fields being RFC4514 s= tring representations of DNs in the next draft.

Given that thi= s is a profile of use and the metadata fields are just one way to express t= he 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 cert= ificate is more straightforward and sufficient for this case.

Is the= re rough consensus to change "tls_client_auth_issuer_dn" to &quo= t;tls_client_auth_root_dn" as was suggested? The latter name makes sen= se to me but I don't want to make that change without a little more inp= ut or buy-in from the WG. So please respond one way or the other, if you= 9;ve got an opinion.=C2=A0

Similarly I'm looking for some= rough consensus around if a single root/issuer is sufficient in the metada= ta before potentially making any changes. Should "tls_client_auth_issu= er/root_dn" remain a single DN string value or should it be an ar= ray allowing for more than one?



On Fri, Apr 21, 2017 at 6:18 PM= , John Bradley <ve7jtb@ve7jtb.com> wrote:
On Apr 21, 2017, at 7:41 PM, Brian Campb= ell <bca= mpbell@pingidentity.com> wrote:

Thanks, James, for the adopti= on 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-c= ampbell-oauth-mtls.

Now some comments on the doc:

1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specified. P= erhaps LDAP's "String Representation of Distinguished Names" = [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would actua= lly be better to allow any subjectAltName to be specified, instead of a DN.=

How about calling it tls_client_auth_s= ubject and defining it as a string and allowing it to represent the expecte= d 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 Represe= ntation of Distinguished Names" and an appropriate string for the othe= r subjectAltName types (I'll have to look at what's there 'caus= e I don't know off hand and guidance or suggested text is always more t= han welcome).
=C2=A0



2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe tls_clie= nt_auth_root_dn). Given tls_client_auth_client_dn, it will be too easy to a= ssume this pair refer to the issuer and subject fields of the cert.

The accompanying text tries to make it clear t= hat it's the root issuer but the tls_client_auth_issuer_dn name can cer= tainly 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?
=C2=A0


PKI chains can be complex so the expected root might not be such a stable c= oncept. 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 metad= ata field to express some constraint for what is kind of expected to be a c= ommon deployment of a number of entities participating in some OAuth API th= ing 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 fo= r some alternative?




3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" doe= s this mean the authz server MUST automatically cope when the client update= s the key(s) it publishes there?

If the= authz server supports that kind of trust model as well as dynamically regi= stration, then I would expect so, yes.
=C2=A0



4. [=C2=A73] An access token is bound to a specific client certificate. Tha= t is probably ok, but does mean all access tokens die when the client updat= es their certificate (which could be every 2 months if using Let's Encr= ypt). 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 tha= n certificates and refreshing or getting a new access token is typically ea= sy anyhow.

Anyway, it doesn't hurt to be explicit abo= ut it, can you propose some such text for the Security Considerations?
<= br>
=C2=A0

5. [=C2=A73.1] "exp" and "nbf" values in the example ne= ed to be numbers, not strings (drop the quotes).

<= /div>
Silly mistake on my part. Thanks for catching that. Will fix.
=C2=A0

6. An access token linked to a client TLS cert isn't a bearer token. Th= e spec should really define a new token_type for responses from the token e= ndpoint. That might not necessarily mean we needs a new HTTP authentication= scheme as well (it might just hint that "Bearer" wasn't quit= e the right name).

Indeed "Bearer&= quot; 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 tok= en_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= .=C2=A0 Whereas many systems can likely plug in mutual TLS on top of the ex= isting token_type and HTTP auth scheme without major changes. I'm stron= gly inclined to not introduce a new token_type and more inclined to not do = a new HTTP auth scheme.



_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth



--94eb2c1486b65eb8ff05501e2bfa--