I agree with Brian on the points about the difference between validating the certificate at the AS for client authentication and the RS. This was defiantly intentional.
Lets face it people do a crap job of validating certificates in general. While browsers validating TLS certificates is not bad for the most part, asking developers to do PKIX validation is almost always going to go wrong in deployment some significant percentage of the time. The idea is to have the AS do all the heavy lifting and allow the RS to be as dumb as possible. It should not need to check certificate expiry or other validity. It should do a simple compare and be done with it. If people want something else fine but we should not add extra options for edge cases that are likely to go wrong. In the SAML R&E community using bear keys in meta-data rather than CA certificates is the preferred option to avoid runtime certificate issues and only validate certificates for meta-data. I personally would be happiest if the AS also just compared a thumbprint of the cert based on a registered HTTPS JWKS_URI and validate any cert at that level where things are better understood and OCSP pinning etc is available. Cutting out the AS validating the cert via PKIX was a bridge to far for banking due to perceived EU digital signature regulations. However it is fragile and will cause issues. We struck a balance. The same is true about requiring mutual TLS at the AS. Yes you could do it other ways, however that requires more complexity passing the cert to the AS. This is simple and harder to mess up. This is the striped down 80% spec without the chrome hood ornament. The feeding is that if you want mutual TLS then doing it on all the legs is not a huge burden. Mobile clients can use it via dynamic registration if there is a real use case. In general the authors still think that token binding will be the more mass market consumer option. This is intended to fill the need for people that are forced to use MTLS by regulation or can’t wait to deploy. It is always tempting to add features, I am perhaps one of worst perpetrators of that. This we wanted to be simple enough to cover the EU banking use case and get implemented and deployed in a reasonable amount of time. John B. > On Aug 1, 2017, at 3:57 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > > Thanks Justin. > > In my original announcement email, I should have given credit to Torsten as > he made many of the updates in -03. So complements on improvements as well as > blame for issues can be pointed to him as well! > > Your point about document structure is taken and we will look to make the > separation of the client authentication and resource access more clear in > future revisions. The document was aiming for something conceptually along > those same lines already. But it could be made more clear. > > This could define a new “token_type” but other than having different token > type names in messages, I don't know that a new token_type or HTTP auth > scheme that would probably have to come along with it adds value to the use > cases here. However, they would very likely make deployment of this stuff > much 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. > > Fair point about breaking out all the registered parameters into their own > hanging list items. It is somewhat inconsistent in that regard now. Will look > to address that in a future revision. > > Using just a certificate hash for mTLS sender constrained access tokens was > intentional to allow mTLS at the resource to be used as a proof-of-possession > method only. It's part of the authorization check at resource access and > deliberately not about authentication with the RS. Using the hash simplifies > the check at the RS to one consistent way of doing things while allowing for > different modes of doing client authentication at the AS. So the lack of > parallelism with the client authentication at the token endpoint was very > much intentional. Following from that, the need to do mTLS at the token > endpoint in order to get mTLS-bound access tokens for an RS was also kind of > intentional. Though, as §4.3 > <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03#section-4.3> attempts > to describe, a public client could do mTLS at the token endpoint with a > generated self-singed cert to have an access token bound but not actually > authenticate to the token endpoint. You are certainly right that there are > other ways an AS could decide on the certificate to bind the access token to. > And other ways a cnf claim member could provide for such a binding. But we > were aiming to not provide too many options in the doc. So my thinking here > was that this draft is about mTLS and so saying how to use mTLS for the AS to > do the access token binding seemed like the most appropriate and > straightforward approach. It's not so much that mTLS authentication is needed > for the client at the token endpoint to allow for bound access tokens. But > rather that having mTLS at the token endpoint provides a strong signal of the > certificate to which to bind the issued access token. > > > > > > > > On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer <jric...@mit.edu > <mailto:jric...@mit.edu>> wrote: > Brian, thanks for the update. This is really coming along! > > I think the spec would benefit from a more clear separation of the client > authentication and resource access sections. They’re really almost two > different but related specs, but there’s enough overlap that I think that > keeping them in the same document is fine with some structural changes > applied. I think the content is by and large all here, it’s just jumbled > together. > > To that end, I think there might be three major sections to this document > (not counting the IANA, security, privacy, and other boilerplate bits). A > suggested breakdown: > > 1) Types of mTLS client auth under consideration. This is where the > definition of public key vs. pki comes in, and where the two authentication > methods are defined for both registration and discovery. Some implementor’s > notes on what kinds of things you need to store here, including the > tls_client_auth_ client metadata extensions. For better or worse, 7591 > defines OAuth’s client model, and not just for dynamic registration. > > 2) How to use mTLS to authenticate a client. This can be a relatively short > section that says use (1) in the context of getting an access token at the > token endpoint. Here is where you point out that you still need to send > client_id and that the association with the cert’s DN and the client_id is > done at the AS (there’s existing text for this). > > 3) How to use mTLS to bind an access token. This is a bit more complicated > because it’s the RS that needs to know the binding between the token and the > cert’s DN, so that’s where you’d define the “cnf” stuff. An unfortunate side > effect of spec history means that the “cnf” claim for 7662 also gets defined > here. This is also where you’d put the bits about > mutual_tls_sender_constrained_access_tokens for discovery and registration. > Should this be a new “token_type”? > > > A few more comments: > > §2.3 really should break out all registered parameters into their own hanging > list items (even if you break them up into different sections like suggested > above) > > §3 seems to say that you can only do mTLS-bound access tokens at an RS if you > do mTLS authentication at the token endpoint. Is that an intentional > restriction? To me these two functions seem to be more orthogonal than the > spec is hinting at. Like, I could use private_key_jwt or PKCE or magic to > authenticate at the RS but use mTLS at the RS, for whatever esoteric reason, > like the AS and RS being in different security domains. Still, functionally, > if the client’s registered parameters are enough to trust for token issuance, > they should be enough to trust for token usage. In other words, have the RS > depend on tls_client_auth_subject_dn etc. instead of "the same certificate > that was used for mutual TLS at the token endpoint". > > Along those lines, §3 also depends entirely on matching a specific > certificate hash instead of validating a certificate (and possibly it’s > chain) and associated DN. This isn’t in parallel with the client > authentication at the token endpoint, and I’d like to see these come > together. Should we have a third certificate validation method in §2 for > “certificate hash”? Or maybe we should have a separate list for > “resource_server_auth_method” for the client? > > In any event, it still feels like there are two things that are fighting for > attention in this spec: cert-based authentication of the client at the token > endpoint, and cert-based PoP of the token at the resource. > > — Justin > >> On Jul 28, 2017, at 2:33 PM, Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>> wrote: >> >> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with >> the changes listed below based on comments and dissuasion in Prague. >> >> draft-ietf-oauth-mtls-03 >> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03> >> >> o Introduced metadata and client registration parameter to publish >> and request support for mutual TLS sender constrained access >> tokens >> o Added description of two methods of binding the cert and client, >> PKI and Public Key. >> o Indicated that the "tls_client_auth" authentication method is for >> the PKI method and introduced "pub_key_tls_client_auth" for the >> Public Key method >> o Added implementation considerations, mainly regarding TLS stack >> configuration and trust chain validation, as well as how to to do >> binding of access tokens to a TLS client certificate for public >> clients, and considerations around certificate bound access tokens >> o Added new section to security considerations on cert spoofing >> o Add text suggesting that a new cnf member be defined in the >> future, if hash function(s) other than SHA-256 need to be used for >> certificate thumbprints >> >> >> ---------- Forwarded message ---------- >> From: <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>> >> Date: Fri, Jul 28, 2017 at 12:25 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> >> Cc: oauth@ietf.org <mailto:oauth@ietf.org> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-03.txt >> Pages : 17 >> Date : 2017-07-28 >> >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the token endpoint as well as for >> certificate bound sender constrained access tokens. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >> <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/> >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 >> <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 >> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 >> <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org >> <http://tools.ietf.org/>. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
