Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12

Nat Sakimura <sakimura@gmail.com> Thu, 01 November 2018 15:21 UTC

Return-Path: <sakimura@gmail.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 E9D111298C5 for <oauth@ietfa.amsl.com>; Thu, 1 Nov 2018 08:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5w0340uBMLzJ for <oauth@ietfa.amsl.com>; Thu, 1 Nov 2018 08:21:41 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 12DE412872C for <oauth@ietf.org>; Thu, 1 Nov 2018 08:21:41 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id b203-v6so1644391wme.5 for <oauth@ietf.org>; Thu, 01 Nov 2018 08:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tVXb4QmU6vZWcSCXZnFbZgXQScRP5pqPmaXkue4J+L8=; b=M06OkuZCNJlkFcd0jSNYIBjF5GQ9fbBPPeGpfpQRVGF9jozhDIOPbVAhMtDb0QKT0I x7I1SplpdzBIAdD4FZQLdKqxj3gO1e3n05Gxm8p4yxuTfwcy0Tdbhm9CrCiojqx2WFhG RYANxJzBiu6fb3qzIcCMiX8O3QmN+S6GkFRD3AGYerL4zN1ItzOduzYHVS0nABbf2DZn yi+C6Xgcs+DDyx2NYGJduToi4v7brQJZWZ4PEWSrTJMrBkxxf6WH8ngB4Js25u31kvxE yvPYSvf6Hwbnt9m8ivPy8SiZKmMzuR1DPfzOsveaykZ5V2LBX2cmKif5cwYdfRVVmZVJ aPDw==
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=tVXb4QmU6vZWcSCXZnFbZgXQScRP5pqPmaXkue4J+L8=; b=LZNuLIzbYEcIxEQuZDUEeykhRstFYggaryyPKF4RHD4hUS4eBCsynH9yFPRrhIHyOZ aE3WoZL0RUS0IJFwOYK1cgAkAKkjcKUkIX54LlW1L6SsMn8xoqrjSeJDEH3CdHKqqkQU 6fanznTYHVCs1CZ6cAaB6sBKt/+slXwXlGNdHp8WpO8ZBusKbMaDoxiZkaEemP3w7td8 RnqwwCqgLHJ3lA9Yh+GEAsEggPyJJHw2cKn/fALevsjh5Avdd77MfALQ0FSTIjKBBf9A pmEhPWO81yPer4IGMXGp1EZAGTgm9YduuQqkyIsu6fyxhdU54F7Ozm5FoA08yx8rqPU/ SF3A==
X-Gm-Message-State: AGRZ1gJKs4yZ4iR5l9QP2TWwYorWt8sk3IbBsrqM7fsZgu/N84BooKnT BYi/WXw4oIXsnnJgdhrvX8y7gB27vRE0/+Fr8pc=
X-Google-Smtp-Source: AJdET5eqRfksjS32TJKaQEs056NQ8DXse/kHqpIzuV3lc66YrrAFOMI6JcSloyxn7eUpNHGByAPuoBCb/z3BACFkVMo=
X-Received: by 2002:a1c:1984:: with SMTP id 126-v6mr5827855wmz.7.1541085699141; Thu, 01 Nov 2018 08:21:39 -0700 (PDT)
MIME-Version: 1.0
References: <CALgdmdsoj9uaVyha5x7anxt4iU_0f8FqyfjNH00Syd-MKSQ_UQ@mail.gmail.com> <CA+k3eCT78Vszyh4Ue+yZ+5pK22yxrhHMwEGty=sXTDs5ttOvVg@mail.gmail.com> <E3A46223-AA0E-4364-9CD1-C5A7F2F37A9D@forgerock.com>
In-Reply-To: <E3A46223-AA0E-4364-9CD1-C5A7F2F37A9D@forgerock.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Fri, 02 Nov 2018 00:21:26 +0900
Message-ID: <CABzCy2DLYneto8uK--px79E3qAkk97uGX_7+3c0501j85GU2Bw@mail.gmail.com>
To: neil.madden@forgerock.com
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aa79c505799bf9ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6DvrrITGmDYzGj50BwKo1KpmwSM>
Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12
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: Thu, 01 Nov 2018 15:21:44 -0000

Adding to it, in OAuth MTLS setting, the client cert is that of the OAuth
client, which is typically a web server and not of a natural person. The
content of the certs should be well publicized so that the natural person
and the OAuth Authorization Server involved should become aware of what
this client is, so I am not sure if there is much privacy impact in this
setting. Yes, if the client is a dedicated client for the natural person,
then there is going to be additional privacy impact, but for something like
that, we were talking of token binding instead.

On Thu, Nov 1, 2018 at 11:55 PM Neil Madden <neil.madden@forgerock.com>
wrote:

> I believe the standard approach to this is to only prompt for a client
> certificate in a renegotiation handshake rather than in the initial
> handshake. Renegotiations are encrypted under the existing TLS session.
>
> — Neil
>
> > On 1 Nov 2018, at 14:37, Brian Campbell <bcampbell=
> 40pingidentity.com@dmarc.ietf.org> wrote:
> >
> > To be honest, I thought that was a relatively well known aspect of TLS
> 1.2 (and prior) and a noted difference of the new features in TLS 1.3.
> Also, I'd note that we're well past WGCL for this document. But, with that
> said, I suppose adding some privacy considerations text on the subject is
> worthwhile. Would you propose some text for the WG to consider, John-Mark?
> Bearing in mind that the implications of a certificate presented by, and
> representing, an OAuth client are somewhat different than for an end-user
> doing client cert authentication.
> >
> >
> >
> >
> > On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney <
> jmg+oauth@newcontext.com> wrote:
> > I would suggest that the security considerations section of
> > draft-ietf-oauth-mtls-12 be expanded to include the privacy
> > implications of using this on versions of TLS before 1.3.  On all
> > versions of TLS before 1.3, the client cert is not encrypted and can
> > be used by third parties to monitor and track users.  I recently
> > posted a blog entry about this:
> >
> https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.html
> >
> > Thanks.
> >
> > John-Mark Gurney
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > 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._______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en