On Fri, Aug 23, 2019 at 03:07:43PM -0600, Brian Campbell wrote: > Thanks for the responses Ben. More inline below with stuff that warrants no > further discussion snipped out. > > On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk <ka...@mit.edu> wrote: > > > > > But it's possible to be naive and be correct at the same time... > > > > I rather like that and suspect I might have to use it in the future :) > > > > > In terms of proposed text, it looks like after the first paragraph of > > Section 3 would be a reasonable place, perhaps: > > > > In order for a resource server to use certificate-bound access tokens, it > > must have advance knowledge that mtls is to be used for some or all > > resource accesses. In particular, the client ID or access token itself > > cannot be used as input to the decision of whether or not to use mtls, > > since from the TLS perspective those are "Application Data", only exchanged > > after the TLS handshake has been completed, and the initial > > CertificateRequest occurs during the handshake, before the Application Data > > is available. Although subsequent opportunities for a TLS client to > > present a certificate may be available, e.g., via TLS 1.2 renegotiation > > [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document > > makes no provision for their usage. It is expected to be common that a > > mtls-using resource server will require mtls for all resources hosted > > thereupon, or will serve mtls-protected and regular resources on separate > > hostname+port combinations, though other workflows are possible. How > > resource server policy is synchronized with the AS is out of scope for this > > document. > > > > And then the following paragraph could start "Within the scope of an > > mtls-protected resource-access flow," > > > > Thank you for that. Super helpful. I'll incorporate. > > > > And my intent and assumption was that a mismatch covered the case where no > > > certificate was presented (i.e. null cert doesn't match expected cert > > just > > > as different cert doesn't match). But perhaps that particular case should > > > be made more explicit? The second to last paragraph of sec 3 > > > > It probably should; "if the presented certificate" as a predicate could > > fairly be easily read as to ignore the case where no certificate is > > presented. > > > > Fair enough. Maybe, "If no certificate is presented or that which is > presented doesn't match" would suffice to avoid that reading?
I think so :) > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar > > > guidance for error handing in the case of mismatch during resource > > access. > > > > > > The case of a so called public client that has > > > tls_client_certificate_bound_access_tokens metadata of true that shows up > > > at the token endpoint without having done MTLS is a bit more nuanced and > > I > > > think it's untimely a policy decision for the AS at that point as to > > > whether to error or issue an unbound token. > > > > Do you have any feelings about whether or not you want to mention that case > > explicitly as being up to local policy at the AS (vs. leaving it implicit > > as is presently being done)? > > > > I don't really *want* to add anything but it's probably better to be > explicit about it. I'll look for a place to work it in. Okay, thanks. > > > > > > > I am not *nix skilled enough to troubleshoot that command pipeline but I > > > suspect that the sha256sum output is in hex which represents each byte of > > > the hash output with two charterers and thus double the resultant size. > > > > Please excuse me while I wipe the egg off my face. > > Yes, that sha256sum output is in hex, and I should have counted the bits > > directly. I hope you did not waste too much time on this (and now I can > > get the thumbprint to agree). > > > > No worries. I only spent enough time second guessing everything so as to > try and avoid getting egg on my own face. > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > protected resource access in step (B) is only possible by the > > > > legitimate client bearing the access token and holding the private > > > > key corresponding to the certificate. > > > > > > > > nit: I guess it is only protected resource access "using this tokwn" > > > > that is only possible as specified. > > > > > > > > > > I kinda felt like that was implied at this point. But I can add "using > > this > > > token" there, if you think it's needed or helpful? > > > > Or perhaps "using a certificate-bound token". I think it's just barely > > worth adding, since this section is largely reiterating the general OAuth > > flow, and this helps emphasize that the "and holding the private key" is > > the important/new part. > > > > Works for me. > > > > It's gotta be done (unless using the self-singed method) and it is > > > definitely up to deployments as I wouldn't even pretend to know where to > > > begin on providing general guidance nor would I think it appropriate. > > > > > > I felt like this was pretty well implied and touched on in security > > > considerations too. But please suggest some specific text, if you think > > > it's needed or would be useful. > > > > Maybe a couple lines at the end of Section 7.3, "TLS certificate validation > > (for both client and server certificates) requires a local database of > > trusted certificate authorities (CAs). Decisions about what CAs to trust > > and how to make such a determination of trust are out of scope for this > > document, but such policy must be consistent between AS and RS for reliable > > operation."? > > > > The very last part isn't exactly true as this document recommends or at > least discusses the possibility that an RS run in a "trust em all" mode wrt > client certs and use the client cert only for private-key PoP of the bound > access tokens. As such, I'm inclined to take your text but end it with > "scope for this document." Good point; works for me. > > > > > > tls_client_auth_san_ip > > > > That all sounds reasonable to me; I'm happy to leave this topic to the > > other ballot threads (or remove the option entirely). > > > > I think the other thread(s) got it to an actionable way forward > https://mailarchive.ietf.org/arch/msg/oauth/KUb3G-Rr_7KsAWVCNsvwS9AgFSI > > > I think it helps my understanding, thanks. > > Perhaps it is the RS's verification of proof-of-possession that is > > decoupled from the client's authentication to the AS, then? > > > > Yeah, I think so. I guess I sometimes conflate the binding in the token and > the verification of the binding by the RS. I'll work on the wording a bit. > > > Per your clarification above, I think I misunderstood the meaning here. > > My new suggestion would be "indirectly certificate-bound by way of the > > clientID and the associated requirement for (certificate-based) > > authentication to the AS", if that's not too unwieldly. > > > > It's possible to be unwieldy and be correct at the same time:) I'm inclined > to use it. :) > > > > > > > Section 7.5 > > > > > > > > o handling of null-terminator bytes and non-canonical string > > > > representations in subject names; > > > > > > > > ASN.1 encodings are going to be using counted strings, so any > > > > NUL terminators will be in implementation languages. I think we might > > > > want to reword this to indicate that ASN.1 strings cannot be directly > > > > interpreted as native language strings in languages that use NUL > > > > terminators. > > > > > > > > > > I am not equipped with the knowledge to do that rewording. Please suggest > > > some specific text, if you'd like to have it reworded. > > > > How about: > > > > o handling of embedded NUL bytes in ASN.1 counted-length strings, and > > non-canonical or non-normalized string representations in subject names > > > > Sure. > > > > > > Thanks for all the updates! > > > > Likewise, thanks for the review. Yours can be long and painful at times but > are quite useful. Let me know when that stops being the case! I mean, just the last part ;) -Ben _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
