Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Fri, 23 August 2019 22:34 UTC
Return-Path: <kaduk@mit.edu>
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 D6DCA12002E; Fri, 23 Aug 2019 15:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 KfzEuTyRfVed; Fri, 23 Aug 2019 15:34:13 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A30712000F; Fri, 23 Aug 2019 15:34:12 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7NMY8lO024409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 18:34:10 -0400
Date: Fri, 23 Aug 2019 17:34:07 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-mtls@ietf.org, oauth <oauth@ietf.org>, oauth-chairs@ietf.org
Message-ID: <20190823223407.GF60855@kduck.mit.edu>
References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> <CA+k3eCSVnF8dA2zdtBz2XWQKVd31h5qgHTFV2vr3kh=KVDJ0bA@mail.gmail.com> <20190822231654.GS60855@kduck.mit.edu> <CA+k3eCSaLWPObUeOYoPLAnOiU6--Qo=4X0KYejG+Ahk0vRv9qg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+k3eCSaLWPObUeOYoPLAnOiU6--Qo=4X0KYejG+Ahk0vRv9qg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LZJwCvr0IoeXQhZaTVXGa9UiKcA>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 22:34:16 -0000
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 <kaduk@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-WG] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Brian Campbell
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Brian Campbell
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Benjamin Kaduk
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Brian Campbell
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Brian Campbell
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Benjamin Kaduk