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 15C2B129BD1 for ; Mon, 15 May 2017 11:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 zfSKhJeti6AP for ; Mon, 15 May 2017 11:46:24 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 B1F371243F6 for ; Mon, 15 May 2017 11:43:06 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u187so64124611pgb.0 for ; Mon, 15 May 2017 11:43:06 -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=5bphGGnhq3yFnP8yldevBgNF6XNNxEY7nTnIztF4hnA=; b=LZ1EEVNleBdn9XQpY3tCkfAz/zfqkIjZp9ywkGyNAlmok0p4gmL41QVwLJFiWZ5bDC UCElKseLkVjq02jzuR31wkC7dXcCsDKzUQkTd4bk8wI4DMBDkAw2/utIQWQQCtAkR5DF GQ4MNbqJlPnscVR1pwE93vzBIhQsbC4HPEnfI= 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=5bphGGnhq3yFnP8yldevBgNF6XNNxEY7nTnIztF4hnA=; b=PgZuF86RuxsdZH+fHqC2OICmejJTcrxPF/Wb7I3NCaD1dLHY6evSRPzjEc3oS7QIAF 0C55rUSMl+551Mt+Wqc7WAWzPR+rggsMMwOkirDFPqzVpMgcE75gG7jkR3LGCTOGSu6E ymKNOa+KBdVbGT/mBHohW2Rkormoj53mI5Dsbv9EcE8XFeQiJfOBecpukXfiK935a63A cdb6zcsSz/4FUb+1iO2YTHAfp5oZSU6b68WUPWE3VaOUzV6vGvQe2z7sw7aXq6ncsnt3 7wNJL8Tl34pLEB0DDAJAePizBnszE6JSr4DbsZA34EDHTwVkUf0NPiJB2QEHzpZCd/Ez xCUw== X-Gm-Message-State: AODbwcBqnyW8mAxPkUFjZD26646qkYeQlnKu/5fdhpUB5FqdAglS+/kH sLjLoKmTBxbM1FcziMzbJuoh+bkaK1Pl X-Received: by 10.84.212.15 with SMTP id d15mr10474498pli.51.1494873786269; Mon, 15 May 2017 11:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.205 with HTTP; Mon, 15 May 2017 11:42:35 -0700 (PDT) In-Reply-To: <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> References: <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> From: Brian Campbell Date: Mon, 15 May 2017 12:42:35 -0600 Message-ID: To: John Bradley Cc: "Manger, James" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="f403045d202e03da60054f946d5c" 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, 15 May 2017 18:46:30 -0000 --f403045d202e03da60054f946d5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 t= he > 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 certifica= te > 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 > 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 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. [=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 to= o >> easy to assume this pair refer to the issuer and subject fields of the c= ert. >> > > The accompanying text tries to make it clear that it's the root issuer bu= t > 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 th= e > 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 entitie= s > 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 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. [=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 upda= tes >> 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 suc= h > 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. 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 t= he > 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 t= op > 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 > > > --f403045d202e03da60054f946d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll add text/clarification that the DN meta= data fields being RFC4514 string representations of DNs in the next draft.<= br>
Given that this is a profile of use and the metadata fields ar= e 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 variation= s, I feel that keeping tls_client_auth_subject_dn as the subject distinguis= hed name of the client certificate is more straightforward and sufficient f= or this case.

Is there rough consensus to change "tls_client_au= th_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 chang= e 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.=C2=A0

Similar= ly 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, A= pr 21, 2017 at 6:18 PM, John Bradley <ve7jtb@ve7jtb.com> wro= te:
I= agree with Brian.

Trying to do anything with PKIX opens= up cans of worms.=C2=A0 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 D= N 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 representati= on that most tools produce.

We did talk about subj= ect alt DNS Names, however those may not be present in eIDAS certificates t= hat some people may need to use for legal reasons, or if it is present it m= ight be an email.

I suspect that users of this wil= l fall into two camps.=C2=A0 One that has a small set of trusted CA that ar= e configured out of band and any certificate from those roots with the corr= ect DN is OK.

The other group will be trying to do= something more dynamic with SSL server certs (May or may not be EV) =C2=A0= I could see those people preferring DNS Name subject alt, or using JWKS to= publish there certs.

The problem is finding the r= ight balance of flexibility without too many options to confuse people.

I am inclined towards DN for those that are willing t= o suffer the pain, and JWKS_uri for everyone else. =C2=A0 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. =C2=A0

For most proof of possession we should be promoting = token binding as the most flexible approach as it also works with mobile wi= thout 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'v= e 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><= /span> wrote:
I suppor= t 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 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


--f403045d202e03da60054f946d5c--