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

[Brian Campbell <[e-mail]>]

I went ahead and pushed a -17, which I think addresses everything discussed
in this thread.

https://tools.ietf.org/html/draft-ietf-oauth-mtls-17

Thanks again for the review and suggestions.

On Fri, Aug 23, 2019 at 3:07 PM Brian Campbell <[e-mail]>
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?
>
>
> > 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.
>
>
>
>>
>> > 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."
>
>
>
>> > >    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.
>

-- 
_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._