Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT)

Brian Campbell <bcampbell@pingidentity.com> Wed, 21 August 2019 22: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 EB75D120113 for <oauth@ietfa.amsl.com>; Wed, 21 Aug 2019 15:08:07 -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 smbMEg5wfjcv for <oauth@ietfa.amsl.com>; Wed, 21 Aug 2019 15:08:05 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 2BCD012010F for <oauth@ietf.org>; Wed, 21 Aug 2019 15:08:05 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id p12so7847268iog.5 for <oauth@ietf.org>; Wed, 21 Aug 2019 15:08:05 -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=y4C1D54pGHVMqaazZQxb2P/p9WUu2iLQdqFhSV23Ebg=; b=NZ8LE6LOB6p1HXRGM+33LTAUhrJuTKjCqDclLycJ4/j00BhWJmOyk+2ydz49k0NQH1 zSFdo+FdU92eicHMc3WUAkHOSaKm02nvsEbU4kpIcaG8lZuHpuDYvJ55y/QqyJaewOnd Jn68rx22ghJALJJIcKgAp8E8t2zEHV5/P9KrI=
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=y4C1D54pGHVMqaazZQxb2P/p9WUu2iLQdqFhSV23Ebg=; b=SuL2AbGehtf+0ZenrdR2QdcT4UwJJEs5tyUurnZEeQcC8m0QuZzy0rWsXYVE3a8vif h2iIbId5Irys9cvyeGzTATMd1gajciaS14YGWFVlisjA+IqUH+DCB/ogrLQ8vMu5GVRU b5gMhHUDb/FFZe6CMwOYjfbXZt+f9OFXbU25SqDUZoh31QRsjDirCMt4kwrEhzPMeZ6v eiI0PUnByAexKf/BnMxNHpHoePs8ssvCnibRncrtSdkOaOCJbYKPtkEvz7mVzRldDuRD 1OlW9bGDRasZJt8EHdhXoaDt6zBlr91KytP29r7pmUpR9aPId/+QCOUBSWAcBRt/Yq5e 8M/A==
X-Gm-Message-State: APjAAAXAKq9Vg71DJAo+ay6T4eKJ2q3PZrhBsACVoLQSjRqy/0+K+7W8 HDbp2ZtB3VqFGmIkI1mveMQ1SRLxs+lEiQ88vFCUHw6I5QEclP9bUtYCT4IFznQjDWHwb9RUyvs 5m224fPqDtuh4Og==
X-Google-Smtp-Source: APXvYqw25mlCI/hk0dbEj5v364wAaDotpPcCsVnccrZ58T0cCItlFkG6q0O+tuZvlux7jgdPIKPE4cRBD+Fc9LhMcbM=
X-Received: by 2002:a6b:ea16:: with SMTP id m22mr1950626ioc.115.1566425284339; Wed, 21 Aug 2019 15:08:04 -0700 (PDT)
MIME-Version: 1.0
References: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com>
In-Reply-To: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 21 Aug 2019 16:07:38 -0600
Message-ID: <CA+k3eCQ5yOpqnbB+5eNmkOuLc+X=7MQvhx0VvXLAnXRE-k=sMg@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
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="000000000000a3f88c0590a7cef9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/tyaR9oBvdxPg1KL0mJrW9orwOeI>
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with 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: Wed, 21 Aug 2019 22:08:08 -0000

Thanks Adam, I attempt to provide not-too-terrible replies to your comments
inline below.

On Mon, Aug 19, 2019 at 8:02 PM Adam Roach via Datatracker <noreply@ietf.org>
wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> Thanks for the work that everyone did on this document. I have one
> suggestion
> for clarification, followed by a handful of editorial nits.
>
> ---------------------------------------------------------------------------
>
> §2.1.2:
>
> >  tls_client_auth_san_ip
> >     A string representation of an IP address in either dotted decimal
> >     notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
> >     defined in [RFC4291] section 2.2) that is expected to be present
> >     as an iPAddress SAN entry in the certificate, which the OAuth
> >     client will use in mutual TLS authentication.
>
> This probably needs some text that clarifies expectations around comparison
> and/or normalization. For example, if the iPAddress value in the cert is
> "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all F's),
> one
> should presume that this would match both tls_client_auth_san_ip values
> "2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no, then
> this document needs to talk about normalization of address representation.
>

Can you help me with some text here? I'm a bit out of my realm, to be
honest. I naively just want it to say that the tls_client_auth_san_ip value
and iPAddress value in the cert need to be the same IP address. But I do
realize "same" isn't totally clear as your comment and others have pointed
out. But I don't know enough to know how to write it in a way that's
suitable for this kind of thing.

Alternatively, as I mentioned in my response to Ben (down a ways in
https://mailarchive.ietf.org/arch/msg/oauth/TMaNYXJgZ3-kz4GNsIL4O-9ncgQ),
I've never personally been able to think of a situation where
tls_client_auth_san_ip is actually needed.  So maybe removing it all
together is an option as well?



> ---------------------------------------------------------------------------
>
> §1:
>
> >  Layering on the abstract flow above, this document standardizes
> >  enhanced security options for OAuth 2.0 utilizing client certificate
> >  based mutual TLS.
>
> Nit: "client-certificate-based"
>

Mr. Kaduk beat you to this one. Will fix.


>  OAuth 2.0 defines a shared secret method of client authentication but
>
> Nit: "shared-secret"
>

Will fix.


>
> ---------------------------------------------------------------------------
> §1:
>
> >  This document describes an additional
> >  mechanism of client authentication utilizing mutual TLS certificate-
> >  based authentication
>
> Nit: "mutual-TLS"
>
> >  Mutual TLS certificate-bound access tokens ensure that only the party
>
> Nit: "Mutual-TLS"
>
> >  Mutual TLS certificate-bound access tokens and mutual TLS client
>
> Nit: "Mutual-TLS... mutual-TLS"
>
> >  Additional client metadata parameters are introduced by this document
> >  in support of certificate-bound access tokens and mutual TLS client
> >  authentication.
>
> Nit: "mutual-TLS"
>
> The remainder of the document has several other uses of the phrase "mutual
> TLS" as an adjective; they should be similarly hyphenated. I will not call
> them out individually. (Non-adjectival uses should not contain hyphens, so
> this isn't a simple find-and-replace operation.)
>

Understood. In theory anyway.  I'll take a pass thought the whole document
and endeavor to find and hyphenate all the places that "mutual TLS" is used
as an adjective.



>
> ---------------------------------------------------------------------------
>
> §5:
>
> >  Authorization servers supporting both clients using mutual TLS and
> >  conventional clients MAY chose to isolate the server side mutual TLS
> >  behaviour to only clients intending to do mutual TLS, thus avoiding
>
> Nit: "behavior" (or adjust other spellings in the document to be
> consistently
> British).
>

 Ugh. I'm surprised my jingoistic spellcheck didn't flag that one. Will
fix.

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