Re: [Unbearable] Binding tokens to scope in HTTP
Andrei Popov <Andrei.Popov@microsoft.com> Mon, 03 April 2017 19:48 UTC
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42E129519 for <unbearable@ietfa.amsl.com>; Mon, 3 Apr 2017 12:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 v_l0KM6dNh4z for <unbearable@ietfa.amsl.com>; Mon, 3 Apr 2017 12:48:11 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0123.outbound.protection.outlook.com [104.47.32.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCB712951E for <unbearable@ietf.org>; Mon, 3 Apr 2017 12:48:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LowR5CnfqI9hafKM/Fa8z9mFP3IQ8Al05FhjjAhv40M=; b=fzfUSMwXU3vdbFdLAYQLCtbkelrViBirEEumT4BzfxfCHQGgxk5eHA74cZUn1xrlRQUQWYR0wNkwCWa1nw7ETuv9TqUw4KTFesQiDPfubT4kZgIftGo+s5D5dZZ53MT5JjbjVefUptFS9bkdNGSCPUOpbtTqsX3uV2L+Dy0uxfo=
Received: from SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) by SN1PR21MB0093.namprd21.prod.outlook.com (10.161.254.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.0; Mon, 3 Apr 2017 19:48:09 +0000
Received: from SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) by SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) with mapi id 15.01.1019.015; Mon, 3 Apr 2017 19:48:09 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Bill Cox <waywardgeek@google.com>, Nick Sullivan <nicholas.sullivan@gmail.com>
CC: "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: [Unbearable] Binding tokens to scope in HTTP
Thread-Index: AQHSrJoOJcT6z0eA3UmiRYUmB69ibKGz5QCAgAAlP5A=
Date: Mon, 03 Apr 2017 19:48:09 +0000
Message-ID: <SN1PR21MB0096465FDA68EB982F457CC08C080@SN1PR21MB0096.namprd21.prod.outlook.com>
References: <CAOjisRx2iixVWb_-jNVrSM9VpjeEOoQ+WDb9H=POg=VOAHzGkQ@mail.gmail.com> <CAH9QtQGvCx37f0KG+H0rqfYo8_cGMANdDiqZyuG1yzJxHxPeMA@mail.gmail.com>
In-Reply-To: <CAH9QtQGvCx37f0KG+H0rqfYo8_cGMANdDiqZyuG1yzJxHxPeMA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:1::4ca]
x-microsoft-exchange-diagnostics: 1; SN1PR21MB0093; 7:h7wDRuJQkLasCN1Tz60rjR5P7oYAFZUS99fsc9NO6MoflQ+hctB/KoaYLpd9vvAuAIWIib8XXBckBntctUYXQEVo8XId5c50h1zgLpdNyuQt3/m0MT6mwkoVznQfJgS/jOfCfYBA/lfrbgULUktBwLfgSAjSG3jJaPws7lstZ7XXLhXUfCGCFevV3GEQ/m04QfQJOXEs51HMgc0EPsLNkNdpO9CfJVVCkWy8DUHYd2ViPs92Ih9GiwPDzsfmS3C9gqhYHZIg641ZXDxj+fJ+4OCFr5VKemtSbPKv3cxg3jeVtlKrgjTdFXNbRZQDgJ289bDnKIQNCzKE4eBgGyk/TnE9GUg9fTkmmPThmr+zoFs=
x-ms-office365-filtering-correlation-id: cd9a3511-13cf-45cf-9901-08d47aca5b1e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR21MB0093;
x-microsoft-antispam-prvs: <SN1PR21MB00933EA2D1C29FFE4A42C5AF8C080@SN1PR21MB0093.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(192374486261705)(100405760836317)(254730959083279)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:SN1PR21MB0093; BCL:0; PCL:0; RULEID:; SRVR:SN1PR21MB0093;
x-forefront-prvs: 0266491E90
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(24454002)(377454003)(102836003)(790700001)(6116002)(77096006)(8990500004)(7696004)(19609705001)(5005710100001)(54356999)(6506006)(76176999)(229853002)(5660300001)(50986999)(6246003)(10290500002)(122556002)(236005)(8936002)(2950100002)(2900100001)(189998001)(74316002)(86612001)(4326008)(33656002)(81166006)(39060400002)(53936002)(6436002)(86362001)(38730400002)(8676002)(53386004)(7736002)(25786009)(7906003)(606005)(53546009)(54896002)(9686003)(6306002)(2906002)(1680700002)(99286003)(55016002)(10090500001)(3280700002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0093; H:SN1PR21MB0096.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR21MB0096465FDA68EB982F457CC08C080SN1PR21MB0096namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 19:48:09.4134 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0093
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/SPkYEwHN_MYgq-cblgIycGhm_KU>
Subject: Re: [Unbearable] Binding tokens to scope in HTTP
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 19:48:17 -0000
The idea of signing TB extensions has been discussed multiple times over the years. Not signing extensions allows an extension to sign the TB message, which is what could be used for handy things like key attestation. It is likely also possible to do key attestation without signing the entire TB message, so if the WG wants to change this prior consensus, we can do so. The reason TB keys are scoped to eTLD+1 (in the case of HTTPS) is that the cookies these TB keys protect are scoped to eTLD+1. Per IETF98 discussion, the next revision of the I-Ds will clarify that browsers cannot exceed the scope of eTLD+1. If cookies are scoped more narrowly, the same can be done with TB keys. Cheers, Andrei From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Bill Cox Sent: Monday, April 3, 2017 10:24 AM To: Nick Sullivan <nicholas.sullivan@gmail.com> Cc: unbearable@ietf.org Subject: Re: [Unbearable] Binding tokens to scope in HTTP The extensions used to be covered in earlier drafts. I forget why this was dropped, but IIRC, it was discussed on this list. In any case, it sounds like there are a number of people who would prefer to change TB extension numbers and effectively be a new extension rather than use the header's extension capability. Your example has a minor error: eTLD+1 for example.com<http://example.com> is example.com<http://example.com>, so a.example.com<http://a.example.com> would have the same TB key as b.example.com<http://b.example.com>. However, the idea for the attack is valid. eTLD+1 based security seems to be a kludge. I felt that binding to the sites covered by a certificate might make sense, but it does not work out. For example, we have certs for gmail.com<http://gmail.com> and youtube.com<http://youtube.com>, and certificates covering both, IIRC. We could use the same TB sig, bound to that certificate, for a lot of sites, reducing TB signature overhead. It also makes sense to me from a security perspective: the server has proven ownership of a collection of domains, so just bind to that. This would eliminate all the eTLD+1 security issues. However, we can't count on seeing the same certificate all the time. Sometimes a server will present a login.example.com<http://login.example.com> certificate on one connection, and *.example.com<http://example.com> on another. Most likely, the cookie that is used for auth would be bound to login.example.com<http://login.example.com>, and would be rejected for all other *.example.com<http://example.com> domains. I like the idea of signing extensions and also the host name from the host header. Bill On Mon, Apr 3, 2017 at 9:47 AM, Nick Sullivan <nicholas.sullivan@gmail.com<mailto:nicholas.sullivan@gmail.com>> wrote: The token binding header does not have any identity bound to it. This is potentially problematic because it makes it much more likely that this protocol is vulnerable to unknown key share issues. Unknown key share attacks happen when a public key is used without binding it to an identity by a signature. For example, Richard Barnes recently published a draft describing how DANE with raw keys was vulnerable to this style of: https://tools.ietf.org/html/draft-barnes-dane-uks-00. In section 2.1. of draft-ietf-tokbind-https, the key pair scoping is defined to be eTLD+1. Depending on the threat model, this requirement can be subverted. Consider an attacker who has access to read and modify headers, but not private keys. Imagine a buggy/malicious service worker or something else of this sort. Now imagine a site with a.example.com<http://a.example.com> and b.example.com<http://b.example.com> and a wildcard *.example.com<http://example.com> certificate. The attacker can take token binding headers from a.example.com<http://a.example.com> and put them on requests to b.example.com<http://b.example.com> and the cookies set on b.example.com<http://b.example.com> will be bound to a.example.com<http://a.example.com>'s key. This doesn't sound like a large issue, but it's indicative of the type of subtle problems not binding the key to a context can cause. If the token context was bound to the scope by including the eTLD+1 in the (or the origin if the browser intends to use stricter token scoping), *and* this scope was covered by the signature then this would not be possible. The server could check the host header against the token context and then refuse the token binding for new cookies. A logical place to put this would be in the extensions of the token binding structure, but unfortunately the extensions is not signed and so can be modified. Is there a reason the extensions field of the TokenBinding structure is not signed by the private key? Nick _______________________________________________ Unbearable mailing list Unbearable@ietf.org<mailto:Unbearable@ietf.org> https://www.ietf.org/mailman/listinfo/unbearable
- [Unbearable] Binding tokens to scope in HTTP Nick Sullivan
- Re: [Unbearable] Binding tokens to scope in HTTP Bill Cox
- Re: [Unbearable] Binding tokens to scope in HTTP Andrei Popov