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

Brian Campbell <bcampbell@pingidentity.com> Fri, 23 August 2019 21:08 UTC

Return-Path: <bcampbell@pingidentity.com>
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 84BC0120122 for <oauth@ietfa.amsl.com>; Fri, 23 Aug 2019 14:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
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 CRHgr6T_e4RG for <oauth@ietfa.amsl.com>; Fri, 23 Aug 2019 14:08:11 -0700 (PDT)
Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8268A120047 for <oauth@ietf.org>; Fri, 23 Aug 2019 14:08:11 -0700 (PDT)
Received: by mail-io1-xd41.google.com with SMTP id z3so23286814iog.0 for <oauth@ietf.org>; Fri, 23 Aug 2019 14:08:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MtEclJgIQngIhR4Hj5fzZCx86mlL0cwxvdsfEvq5x04=; b=eTdiRApO5o+L7/gzUYgpzIh0T4VHK5cCtsebJsbCXmUwlkrW/cpwq1p8PKKElIsLpQ wuiiMoGpA0QHfOWCKCdgPHDOYDR92Zfh+tzMMsmSyKzfPHLXcG5e10erpoJN/PQGNTJw /+brQz30LbgZDCZMKEHGMWdtwkfgdI0Rt8cXY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MtEclJgIQngIhR4Hj5fzZCx86mlL0cwxvdsfEvq5x04=; b=mXAofprqVLYj9ZIs1Gwku20SUWCyanuqnGVn5kQ1gLf4YSqhzBDh/av6LybwwRN/FG uG0OVWWAe9dS4lCa4HzZ6Wt2coMhaL4eRNPp1tOQtqFROZCPJSQNCQSnCDWkzDBCsWK9 RYeiEZ05nPT91qrgSXIjLvRGdmZi4gb0n+TBXYy02ImPrj6aObhhtpB8K0o6Z3mvK4Id HzLUM+MYCE+nW7Ux7q+237AyemL5B0bWcM5K10xlobxk6GNJmDgA+jOZmJO6dMkXwdCv IQVstvEmEZQuXPXFJDd5b2+qNHaAlJMCjHlRomJZh/0IwpTboz37Sfrb4KLJejgRq0Uc AZjA==
X-Gm-Message-State: APjAAAWxNzQDJJSiP4dnpyS7U4VKgrm22hSNgRxtZIWVRelE0JhKCNRe XftLjp7V6v7+SDK/OaBLwhAKzMVYGRyYkQDFgSaD/V6UgXpIBWnhuJ95YiXMifcM9efj40prkeq 0Ymf+/9ps3XBqtA==
X-Google-Smtp-Source: APXvYqzbMfN4Momxnv0j/c5ep7bdvKcqnh5sGhDYjyIaTpVKe7czIhvcd3hXJB7uR4ZID/nERvfshrE1vP7N6rEnxl8=
X-Received: by 2002:a6b:ea16:: with SMTP id m22mr8190467ioc.115.1566594490541; Fri, 23 Aug 2019 14:08:10 -0700 (PDT)
MIME-Version: 1.0
References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> <CA+k3eCSVnF8dA2zdtBz2XWQKVd31h5qgHTFV2vr3kh=KVDJ0bA@mail.gmail.com> <20190822231654.GS60855@kduck.mit.edu>
In-Reply-To: <20190822231654.GS60855@kduck.mit.edu>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 23 Aug 2019 15:07:43 -0600
Message-ID: <CA+k3eCSaLWPObUeOYoPLAnOiU6--Qo=4X0KYejG+Ahk0vRv9qg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-mtls@ietf.org, oauth <oauth@ietf.org>, oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001dd4810590cf3421"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zB7W-IrVZTlbCmAgZ6vAw0tPPCk>
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 21:08:14 -0000

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?


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