Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> 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