From nobody Fri Sep 1 15:04:03 2017 Return-Path: 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 68D11132DF5 for ; Fri, 1 Sep 2017 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 A1rspJk2WFvi for ; Fri, 1 Sep 2017 15:04:00 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 E039B13315F for ; Fri, 1 Sep 2017 15:03:59 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id u11so6551409qtu.1 for ; Fri, 01 Sep 2017 15:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ao4l96CW/DMn1pIItnKEhs4Kp/FwlTBIN2HTXYr3HNg=; b=AXPoRGpRF5XFMhNvYFzg1+JukPK9/H0aogPkkRSPmSmMH/QfTdNNrZCb2sD4sS32G/ oOW+I1v5u2Ga4zVz3BZHIUtC49tPnz5t+zPIRB6e3W26f7FhbhEeZ7OJVkbnI5V8kwQj +Pen/1z6HHgkd1yA4p08iz4e9WhTp8qQX78/vMeHyNrBDuiauZV0viQoyBiSsedqE2tm M3M1+cUIr8r5knJQpwW+2IVieXLgJLuC6lqxvKGgdtNcLISigUNNP+YBSouDmBOA3xPb W4Y89nJqc6PnnjLp0Z98twnamx+4umk5dYaxtSj3Egs8EA9mEoHxWgY/pmwEHUKi3WSW gl2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ao4l96CW/DMn1pIItnKEhs4Kp/FwlTBIN2HTXYr3HNg=; b=aHnUQO47H0cxK19tjEPQUdGbMOFOl52+ArjL5sq6vba7nkuooludFlhOimBhZa8Kwv suSQIk/Tk+ywGrl6US7CrJVm2wzW8YlDjnBcS56MCUk2+ZOrSn3gPHgNGqugp84xlQoX tyLczcvYNDE6BtnKJS59hwPKT631lqEmMpu4/bnvLIDNbYAGtVQ19Ex9uyIH4dd+e2u+ YL2ZG7ukKT4Sjxzrg4OFm41ROw4VWzhGyXVzs5trIPIBDskxYIHah+BatW/d0ws6z4il +orCXHMCu7DREy1blxdRn1+sFLnPsjSotqrRPGs600LFb0uYQhIkFgUZ2xg7ugO+djqf Cf8w== X-Gm-Message-State: AHPjjUjzkG7UOBVI/oD02u6g2TADgFw6S+vDsE/ylS8O0LID1CRAGGzk YKAu1macfd6s5OosavzpYSTzuwc7IL2b9xE= X-Google-Smtp-Source: ADKCNb4b/Hg2am45yxoRfZoxep6+0VhYTI5pbYQKpyAbNNV6eTfNNu+2eCepA7sKMrMicsOlOws8cknW45NaEAw7eew= X-Received: by 10.237.37.189 with SMTP id x58mr4890927qtc.230.1504303437681; Fri, 01 Sep 2017 15:03:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.36.152 with HTTP; Fri, 1 Sep 2017 15:03:37 -0700 (PDT) From: Nick Harper Date: Fri, 1 Sep 2017 15:03:37 -0700 Message-ID: To: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Unbearable] Possible attack on Token Binding with RSA key exchange 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 22:04:01 -0000 I came across an attack on Token Binding today, which I think is worth addressing in TBPROTO in some fashion (likely another paragraph in Security Considerations). This attack involves an adversary with the private key of a server it wishes to impersonate, and was mentioned in draft-balfanz-tls-channelid in the last paragraph of its Security Considerations. In brief, if an attacker has possession of a server's private key, it can hijack a TLS connection between client and server if the connection uses RSA key exchange instead of (EC)DHE key exchange, which allows the attacker to exercise the bound token without possession of the Token Binding private key. I realize that we're past WGLC at this point, but I think this should be addressed. On one end, we could require forward-secret key exchange modes with Token Binding. We could also describe this specific attack in the Security Considerations, or we could expand the Security Considerations to describe what attacks are and aren't in the Token Binding threat model, to say that attacks where the adversary has the server's private key are out of scope. From nobody Fri Sep 1 15:25:02 2017 Return-Path: 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 7BCE0132E6B for ; Fri, 1 Sep 2017 15:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=pYUqThA+; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=EBb4oJ2j 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 sDMqslSeLuCd for ; Fri, 1 Sep 2017 15:24:58 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 A7860133169 for ; Fri, 1 Sep 2017 15:24:58 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v81MOf4u032099; Fri, 1 Sep 2017 15:24:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=ANE1kIvGnc42/1aC39xXNKSXDtWQsYCG5IRQutCHiYg=; b=pYUqThA+uW8guXHPoVDARX3623kHHQ3OMu74YETO2SFwSGRpf2J0JJrCpsKJXdaNG6yR Y/HycEx8FC7vawPX1otmwNC3xlPuUcq5dBKNVjWSinox/RbWKCufp3tJVhAfYURIEaHq k+EQwgi0DwjCGYlxmWrUwR4evNy8KNylIpY= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cqeh58du6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 01 Sep 2017 15:24:56 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 1 Sep 2017 15:24:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ANE1kIvGnc42/1aC39xXNKSXDtWQsYCG5IRQutCHiYg=; b=EBb4oJ2jt4tadXUw0UgAZGgZxnz2g0ToB0++K5gEyLiRlDtPVyk0b+M/Mi3ImHRtepQ3366gZ2TgvWUwS1MOgFrbHUhr8ggEA65D44owQ0CURwDW6ORcFujzZ23chR6SC4XEMjNZu6+odWakcyDOF7SabmLqHCwKtx5KwnNeCOU= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1165.namprd15.prod.outlook.com (10.175.2.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Fri, 1 Sep 2017 22:24:53 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0013.014; Fri, 1 Sep 2017 22:24:53 +0000 From: Subodh Iyengar To: Nick Harper , IETF Tokbind WG Thread-Topic: [Unbearable] Possible attack on Token Binding with RSA key exchange Thread-Index: AQHTI25JlXppjsf+6EaqZMtSSVKoZKKgl2Ce Date: Fri, 1 Sep 2017 22:24:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::1:304a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1165; 20:Zb7mNWAbnvGnwCqywMvNEcYGf4oV9Y1pl3aUqthbwaw7ryKVsGVSWB4K+wNd1pl8miVBFTaOacLB1/OomgrVzYW73hORGjjFmQFVF1VKvgKooz9tXsO+5qKcYcEgONxGwV0C2cYfvDcEvpXmY2lpLcnyJOuwZvWnoMv6MBQxcoA= x-ms-office365-filtering-correlation-id: 7721f8d1-5483-49b7-7b24-08d4f1884484 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1165; x-ms-traffictypediagnostic: MWHPR15MB1165: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(920507026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1165; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1165; x-forefront-prvs: 0417A3FFD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(105586002)(606006)(966005)(8936002)(99286003)(2900100001)(55016002)(50986999)(76176999)(478600001)(54356999)(81166006)(81156014)(5660300001)(106356001)(14454004)(7696004)(101416001)(33656002)(9686003)(68736007)(53546010)(6306002)(236005)(6436002)(25786009)(3280700002)(2950100002)(97736004)(6666003)(8676002)(189998001)(54896002)(2906002)(34040400001)(6246003)(86362001)(575784001)(7736002)(74316002)(229853002)(6116002)(102836003)(6506006)(53936002)(77096006)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1165; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14559C4298AF55C40193F405B6920MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2017 22:24:25.4709 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1165 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_06:, , signatures=0 Archived-At: Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 22:25:00 -0000 --_000_MWHPR15MB14559C4298AF55C40193F405B6920MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 to requiring that token binding only be used with forward secure cipher = suites. I believe the extended master secret requirement of token binding prevents = the attack on forward secure suites, i.e. an attacker cannot change the DH = share advertised by the real server and thus needs to get the private key f= or it. Subodh ________________________________ From: Unbearable on behalf of Nick Harper Sent: Friday, September 1, 2017 3:03:37 PM To: IETF Tokbind WG Subject: [Unbearable] Possible attack on Token Binding with RSA key exchang= e I came across an attack on Token Binding today, which I think is worth addressing in TBPROTO in some fashion (likely another paragraph in Security Considerations). This attack involves an adversary with the private key of a server it wishes to impersonate, and was mentioned in draft-balfanz-tls-channelid in the last paragraph of its Security Considerations. In brief, if an attacker has possession of a server's private key, it can hijack a TLS connection between client and server if the connection uses RSA key exchange instead of (EC)DHE key exchange, which allows the attacker to exercise the bound token without possession of the Token Binding private key. I realize that we're past WGLC at this point, but I think this should be addressed. On one end, we could require forward-secret key exchange modes with Token Binding. We could also describe this specific attack in the Security Considerations, or we could expand the Security Considerations to describe what attacks are and aren't in the Token Binding threat model, to say that attacks where the adversary has the server's private key are out of scope. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_unbearable&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHt= wg-wAyN7fQ&m=3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=3DB0sKQEO8i8hD= pLizsh7X8ins9EGGwOwcckYqZku7zEE&e=3D --_000_MWHPR15MB14559C4298AF55C40193F405B6920MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 to requiring that token binding only be used with forward secure = cipher suites.

I believe the extended master secret requirement of token binding prevents = the attack on forward secure suites, i.e. an attacker cannot change the DH = share advertised by the real server and thus needs to get the private key f= or it.

Subodh

From: Unbearable <unbe= arable-bounces@ietf.org> on behalf of Nick Harper <nharper@google.com= >
Sent: Friday, September 1, 2017 3:03:37 PM
To: IETF Tokbind WG
Subject: [Unbearable] Possible attack on Token Binding with RSA key = exchange
 
I came across an attack on Token Binding today, wh= ich I think is worth
addressing in TBPROTO in some fashion (likely another paragraph in
Security Considerations). This attack involves an adversary with the
private key of a server it wishes to impersonate, and was mentioned in
draft-balfanz-tls-channelid in the last paragraph of its Security
Considerations.

In brief, if an attacker has possession of a server's private key, it
can hijack a TLS connection between client and server if the
connection uses RSA key exchange instead of (EC)DHE key exchange,
which allows the attacker to exercise the bound token without
possession of the Token Binding private key.

I realize that we're past WGLC at this point, but I think this should
be addressed. On one end, we could require forward-secret key exchange
modes with Token Binding. We could also describe this specific attack
in the Security Considerations, or we could expand the Security
Considerations to describe what attacks are and aren't in the Token
Binding threat model, to say that attacks where the adversary has the
server's private key are out of scope.

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
ht= tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_l= istinfo_unbearable&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3= Ju9EBS7mHtwg-wAyN7fQ&m=3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&am= p;s=3DB0sKQEO8i8hDpLizsh7X8ins9EGGwOwcckYqZku7zEE&e=3D
--_000_MWHPR15MB14559C4298AF55C40193F405B6920MWHPR15MB1455namp_-- From nobody Fri Sep 1 15:28:17 2017 Return-Path: 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 98CD713304F for ; Fri, 1 Sep 2017 15:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=rdWPFRNc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=PBcuWpN7 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 ZxBh9PJYUh55 for ; Fri, 1 Sep 2017 15:28:15 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 2A603132FD0 for ; Fri, 1 Sep 2017 15:28:15 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.21/8.16.0.21) with SMTP id v81MNuoq016423; Fri, 1 Sep 2017 15:28:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=dAdkntssiguEe8KDzGGoMKdI2lNa/X0Gf7T9sJ/aJco=; b=rdWPFRNcpLisdOmjYDiNsPCpckDXpjroZF5iarOkXYerL+tjE9Ir+BbSdCDlgk6zco24 DRj1znGTbumgO1odedKHdHSxEQehDMXAAeb/Wq6QkCvH6v5vsYs84rYY1CBs4xGERlGv ygiBRrqJw1YtGDj4rSjLGODDQQfkIr1oid0= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2cqd7agnm3-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 01 Sep 2017 15:28:11 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 1 Sep 2017 15:28:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dAdkntssiguEe8KDzGGoMKdI2lNa/X0Gf7T9sJ/aJco=; b=PBcuWpN7BQyvizrDxcLxiHCx7CmB8trzY3gyHPqNn9pC7USD7qVEKZ46oZVe9VN9phGerCkmnzhr6ZnewpTXCFrWTQFq9PSlQfF5KH/Yem4OEWyUh+TtUSa854mnRpCgHvFnjxX3H+Rlmmk7QpgSZoFfGw+yxFeEZ+K8A5tPTkE= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1165.namprd15.prod.outlook.com (10.175.2.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Fri, 1 Sep 2017 22:28:08 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0013.014; Fri, 1 Sep 2017 22:28:08 +0000 From: Subodh Iyengar To: Nick Harper , IETF Tokbind WG Thread-Topic: [Unbearable] Possible attack on Token Binding with RSA key exchange Thread-Index: AQHTI25JlXppjsf+6EaqZMtSSVKoZKKgl2CegAAEEsI= Date: Fri, 1 Sep 2017 22:28:08 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::1:304a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1165; 20:+xsQ059ZfxzAxMZ5eyLK5QlRxXtT0HY8Z/cPFjTT0E6sptT8VQ3cAZ7+QFY8937sJ0rVwHMBCWEXx8EwsOlSo62n/IqfPOA+7SMUGCSrUhF4khVNyVE01H0olMOgub2/l+DeI/TuT2hR6eSHBQRqudtOey1VG5wpkHiw0g2hzzA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0a1031f4-145a-40cf-55fd-08d4f188b8bf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1165; x-ms-traffictypediagnostic: MWHPR15MB1165: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(920507026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1165; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1165; x-forefront-prvs: 0417A3FFD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(97736004)(8676002)(2950100002)(54896002)(2906002)(189998001)(236005)(6306002)(25786009)(3280700002)(6436002)(6506006)(53936002)(102836003)(229853002)(6116002)(77096006)(3660700001)(34040400001)(6246003)(7736002)(74316002)(86362001)(575784001)(478600001)(76176999)(50986999)(54356999)(55016002)(81166006)(19627405001)(81156014)(2900100001)(606006)(966005)(105586002)(2940100002)(99286003)(8936002)(53546010)(14454004)(106356001)(7696004)(5660300001)(68736007)(33656002)(101416001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1165; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14556750C654628F47186232B6920MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2017 22:28:08.1132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1165 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_06:, , signatures=0 Archived-At: Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 22:28:16 -0000 --_000_MWHPR15MB14556750C654628F47186232B6920MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having said that, even if we only support forward secure ciphers, I do not = think we can reasonably claim that we are secure against the threat of stol= en private keys. I like the the carrot opportunity this brings to encourage adoption of forw= ard secure cipher suites. Subodh ________________________________ From: Subodh Iyengar Sent: Friday, September 1, 2017 3:24:25 PM To: Nick Harper; IETF Tokbind WG Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exc= hange +1 to requiring that token binding only be used with forward secure cipher = suites. I believe the extended master secret requirement of token binding prevents = the attack on forward secure suites, i.e. an attacker cannot change the DH = share advertised by the real server and thus needs to get the private key f= or it. Subodh ________________________________ From: Unbearable on behalf of Nick Harper Sent: Friday, September 1, 2017 3:03:37 PM To: IETF Tokbind WG Subject: [Unbearable] Possible attack on Token Binding with RSA key exchang= e I came across an attack on Token Binding today, which I think is worth addressing in TBPROTO in some fashion (likely another paragraph in Security Considerations). This attack involves an adversary with the private key of a server it wishes to impersonate, and was mentioned in draft-balfanz-tls-channelid in the last paragraph of its Security Considerations. In brief, if an attacker has possession of a server's private key, it can hijack a TLS connection between client and server if the connection uses RSA key exchange instead of (EC)DHE key exchange, which allows the attacker to exercise the bound token without possession of the Token Binding private key. I realize that we're past WGLC at this point, but I think this should be addressed. On one end, we could require forward-secret key exchange modes with Token Binding. We could also describe this specific attack in the Security Considerations, or we could expand the Security Considerations to describe what attacks are and aren't in the Token Binding threat model, to say that attacks where the adversary has the server's private key are out of scope. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_unbearable&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHt= wg-wAyN7fQ&m=3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=3DB0sKQEO8i8hD= pLizsh7X8ins9EGGwOwcckYqZku7zEE&e=3D --_000_MWHPR15MB14556750C654628F47186232B6920MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having said that, even if we only support forward secure ciphers, = I do not think we can reasonably claim that we are secure against the threat of sto= len private keys.

I like the the carrot opportunity this brings to encourage adoption of forw= ard secure cipher suites.


Subodh

From: Subodh Iyengar
Sent: Friday, September 1, 2017 3:24:25 PM
To: Nick Harper; IETF Tokbind WG
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA = key exchange
 

+1 to requiring that token binding only be used with forward secure = cipher suites.

I believe the extended master secret requirement of token binding prevents = the attack on forward secure suites, i.e. an attacker cannot change the DH = share advertised by the real server and thus needs to get the private key f= or it.

Subodh

From: Unbearable <unbe= arable-bounces@ietf.org> on behalf of Nick Harper <nharper@google.com= >
Sent: Friday, September 1, 2017 3:03:37 PM
To: IETF Tokbind WG
Subject: [Unbearable] Possible attack on Token Binding with RSA key = exchange
 
I came across an attack on Token Binding today, wh= ich I think is worth
addressing in TBPROTO in some fashion (likely another paragraph in
Security Considerations). This attack involves an adversary with the
private key of a server it wishes to impersonate, and was mentioned in
draft-balfanz-tls-channelid in the last paragraph of its Security
Considerations.

In brief, if an attacker has possession of a server's private key, it
can hijack a TLS connection between client and server if the
connection uses RSA key exchange instead of (EC)DHE key exchange,
which allows the attacker to exercise the bound token without
possession of the Token Binding private key.

I realize that we're past WGLC at this point, but I think this should
be addressed. On one end, we could require forward-secret key exchange
modes with Token Binding. We could also describe this specific attack
in the Security Considerations, or we could expand the Security
Considerations to describe what attacks are and aren't in the Token
Binding threat model, to say that attacks where the adversary has the
server's private key are out of scope.

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
ht= tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_l= istinfo_unbearable&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3= Ju9EBS7mHtwg-wAyN7fQ&m=3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&am= p;s=3DB0sKQEO8i8hDpLizsh7X8ins9EGGwOwcckYqZku7zEE&e=3D
--_000_MWHPR15MB14556750C654628F47186232B6920MWHPR15MB1455namp_-- From nobody Mon Sep 4 15:59:36 2017 Return-Path: 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 3F9C6132193 for ; Mon, 4 Sep 2017 15:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 uWJfdvXX6sgT for ; Mon, 4 Sep 2017 15:59:32 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94E8132192 for ; Mon, 4 Sep 2017 15:59:32 -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=OCNTMZt0/Kl9RoABxQfCybHBd0u2x0ZtVAgvmJlPr/k=; b=EpzPfpdzZlYjnTcdY8XGrPK4EOOm8SNg7sEdWpuR70AuGx3cMidaPbWfBj7+mnUUUJg5FS5mphtt0RAHIFsMzTiEslgHSDNRvST+f95dzUFdWArG4OcVMw8RATJaVSg0Pe7wT29hre2Ir9tvu7Teo0QZ+Dd/g2GoTA949TuWNFE= Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0136.namprd21.prod.outlook.com (10.173.189.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.0; Mon, 4 Sep 2017 22:59:31 +0000 Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0056.000; Mon, 4 Sep 2017 22:59:31 +0000 From: Andrei Popov To: Subodh Iyengar , Nick Harper , "IETF Tokbind WG" Thread-Topic: [Unbearable] Possible attack on Token Binding with RSA key exchange Thread-Index: AQHTI248h15PeY9U802Z73g90LEOZ6Kgm0WAgAABCgCABLlR4A== Date: Mon, 4 Sep 2017 22:59:30 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:1::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0136; 6:zS9MUu2jMG55dVI2v0IEZAHFWKw3yqvziKY/K9ZQDgYi7AHeuQ8CuXnpUYZMvSVOFAFf44dXHEZ/YUNlJx0TMiSDUn0A+yYQ6GciK5sInyKdwzqKkSHXNI2kw85RAGjOvKNZY/G7tYIdJNgehsKTZtamsz/3MXeiTS0T2r08bCIDmPI304E319NZQP+wMaLbmbbDWWqIpz/nq2LmQezCUhPb0GYKBU/hKh52Sh0LLmPtAEWUh307ny+bX4DpB/B0yqm/sHUlKzqvJfOQF9gqeZYj1w2xXHLmfV9kWhQhIi3uh6qNnJpFpZf8th//T4wg2Dk2BIaybidbcMzzmnrr/w==; 5:HwpQ886OQn6JAG6rv3BprtXhZR6d5Gfb6mOr5r/THAEtwOMKE7IXGm0LAG+xXOj0e9iXPnAZ8/NWtcjuT2fEhC8PXA3dnhI8gXNWkXr3Uaz8eSPMMq9tHIl+uSqTmnbDyoRFujvsXRvybwQlydBOyw==; 24:zDa/yf25rGqfA1ArzGhupHOGDNjkBM8XRAFtUKndrF0z4MbBvUzEK8NiVE/ufYl1HJeQnJXIi2+ac/7QwBc5FkA86Hz2yYCjn4oZ8hoMdX0=; 7:i4xIMuHeN7nxs16/q9jv/L2LC6kCdtUo4iBdBhS4jPXHH02kYFkNbLcuPGUV7UCPDRcsMMLxVqhiZCM1P4qFgyPFnrNfI6zNvASGviBV3xuiidiWN4gGa3j4Uobq6wI91yO2xM/h5QwCepr2gymkr2yatJPA7eDhqA+vzFXbJLbCP6G74sPtnq5drRDA+48hyRUEZgT132rE+bWmN9nu/a+1aKvRTGSBpsuZJ8n2TMM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 86ce12ac-0473-4f6e-ed4f-08d4f3e89a22 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0136; x-ms-traffictypediagnostic: CY4PR21MB0136: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705)(189930954265078)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0136; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0136; x-forefront-prvs: 0420213CCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(47760400005)(377454003)(189002)(199003)(105586002)(106356001)(7696004)(53546010)(54356999)(575784001)(606006)(72206003)(229853002)(8936002)(966005)(86612001)(81166006)(81156014)(8676002)(68736007)(19609705001)(76176999)(97736004)(5660300001)(10090500001)(50986999)(33656002)(86362001)(14454004)(6506006)(6436002)(6306002)(99286003)(54896002)(6246003)(77096006)(2950100002)(6116002)(790700001)(102836003)(478600001)(2906002)(34040400001)(3660700001)(25786009)(74316002)(7736002)(5005710100001)(9686003)(189998001)(101416001)(10290500003)(8990500004)(236005)(53936002)(3280700002)(2900100001)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0136; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0120ED0B8619A2960F3462368C910CY4PR21MB0120namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2017 22:59:30.8931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0136 Archived-At: Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 22:59:35 -0000 --_000_CY4PR21MB0120ED0B8619A2960F3462368C910CY4PR21MB0120namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems clear that binding tokens to broken TLS channels does one no good,= but I don't mind adding some statements to this effect in the security con= siderations. The statements would need to be general enough to cover TLS client and serv= er compromise, PFS and non-PFS. Nick, please feel free to author a PR. If we get to IESG review someday, th= ere will be more edits, and we can incorporate this as well. I don't think it makes sense to limit TB to (EC)DHE, especially if we're go= ing to allow TB in combination with TLS 1.3 0-RTT mode. Cheers, Andrei From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Subodh I= yengar Sent: Friday, September 1, 2017 3:28 PM To: Nick Harper ; IETF Tokbind WG Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exc= hange Having said that, even if we only support forward secure ciphers, I do not = think we can reasonably claim that we are secure against the threat of stol= en private keys. I like the the carrot opportunity this brings to encourage adoption of forw= ard secure cipher suites. Subodh ________________________________ From: Subodh Iyengar Sent: Friday, September 1, 2017 3:24:25 PM To: Nick Harper; IETF Tokbind WG Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exc= hange +1 to requiring that token binding only be used with forward secure cipher = suites. I believe the extended master secret requirement of token binding prevents = the attack on forward secure suites, i.e. an attacker cannot change the DH = share advertised by the real server and thus needs to get the private key f= or it. Subodh ________________________________ From: Unbearable > on behalf of Nick Harper > Sent: Friday, September 1, 2017 3:03:37 PM To: IETF Tokbind WG Subject: [Unbearable] Possible attack on Token Binding with RSA key exchang= e I came across an attack on Token Binding today, which I think is worth addressing in TBPROTO in some fashion (likely another paragraph in Security Considerations). This attack involves an adversary with the private key of a server it wishes to impersonate, and was mentioned in draft-balfanz-tls-channelid in the last paragraph of its Security Considerations. In brief, if an attacker has possession of a server's private key, it can hijack a TLS connection between client and server if the connection uses RSA key exchange instead of (EC)DHE key exchange, which allows the attacker to exercise the bound token without possession of the Token Binding private key. I realize that we're past WGLC at this point, but I think this should be addressed. On one end, we could require forward-secret key exchange modes with Token Binding. We could also describe this specific attack in the Security Considerations, or we could expand the Security Considerations to describe what attacks are and aren't in the Token Binding threat model, to say that attacks where the adversary has the server's private key are out of scope. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_unbearable&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHt= wg-wAyN7fQ&m=3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=3DB0sKQEO8i8hD= pLizsh7X8ins9EGGwOwcckYqZku7zEE&e=3D --_000_CY4PR21MB0120ED0B8619A2960F3462368C910CY4PR21MB0120namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems clear that binding tokens to broken TLS cha= nnels does one no good, but I don’t mind adding some statements to th= is effect in the security considerations.

The statements would need to be general enough to co= ver TLS client and server compromise, PFS and non—PFS.

 

Nick, please feel free to author a PR. If we get to = IESG review someday, there will be more edits, and we can incorporate this = as well.

 

I don’t think it makes sense to limit TB to (E= C)DHE, especially if we’re going to allow TB in combination with TLS = 1.3 0-RTT mode.

 

Cheers,

 

Andrei

 

From: Unbearable [mailto:unbearable-bounces@i= etf.org] On Behalf Of Subodh Iyengar
Sent: Friday, September 1, 2017 3:28 PM
To: Nick Harper <nharper@google.com>; IETF Tokbind WG <unbe= arable@ietf.org>
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA = key exchange

 

Having said that, even if w= e only support forward secure ciphers, I do not think we can reasonably cla= im that we are secure against the threat of stolen private keys.

I like the the carrot opportunity this brings to encourage adoption of forw= ard secure cipher suites.

 

Subodh

From: Subodh Iyengar
Sent: Friday, September 1, 2017 3:24:25 PM
To: Nick Harper; IETF Tokbind WG
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA = key exchange

 

+1 to requiring that to= ken binding only be used with forward secure cipher suites.

I believe the extended master secret requirement of token binding prevents = the attack on forward secure suites, i.e. an attacker cannot change the DH = share advertised by the real server and thus needs to get the private key f= or it.

Subodh

From: Unbearable <unbearable-bounces@ietf.org> on behalf of Nick Harper <= ;nharper@google.com>
Sent: Friday, September 1, 2017 3:03:37 PM
To: IETF Tokbind WG
Subject: [Unbearable] Possible attack on Token Binding with RSA key = exchange

 

I came across an at= tack on Token Binding today, which I think is worth
addressing in TBPROTO in some fashion (likely another paragraph in
Security Considerations). This attack involves an adversary with the
private key of a server it wishes to impersonate, and was mentioned in
draft-balfanz-tls-channelid in the last paragraph of its Security
Considerations.

In brief, if an attacker has possession of a server's private key, it
can hijack a TLS connection between client and server if the
connection uses RSA key exchange instead of (EC)DHE key exchange,
which allows the attacker to exercise the bound token without
possession of the Token Binding private key.

I realize that we're past WGLC at this point, but I think this should
be addressed. On one end, we could require forward-secret key exchange
modes with Token Binding. We could also describe this specific attack
in the Security Considerations, or we could expand the Security
Considerations to describe what attacks are and aren't in the Token
Binding threat model, to say that attacks where the adversary has the
server's private key are out of scope.

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://urldefense.proof= point.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_unbearable&= ;d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN7fQ&a= mp;m=3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=3DB0sKQEO8i8hDpLiz= sh7X8ins9EGGwOwcckYqZku7zEE&e=3D

--_000_CY4PR21MB0120ED0B8619A2960F3462368C910CY4PR21MB0120namp_-- From nobody Tue Sep 5 17:23:13 2017 Return-Path: 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 E3FEB1321A0 for ; Tue, 5 Sep 2017 17:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 syE6LtMZhsRn for ; Tue, 5 Sep 2017 17:23:09 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 AE4391321A4 for ; Tue, 5 Sep 2017 17:23:09 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id r141so15919308qke.2 for ; Tue, 05 Sep 2017 17:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CSxrzGIbyFkr9c2YvbRgQ4lnFz+kEis6i7nNM0QtzQk=; b=TuKomkVzftJ1K92sWsVQr1T6yvq/DXTEHIoYZwHoV9gvtPfWaUGRb9s2IDH1wSqLHF K3eLmsmYhGeYxW8as4SuiK49GBAYfpt+rLEideR2V06BLBCXMfA+xch9PlmDa7MRUqsb YOeKhCAGg8ZeFzbDmQmQvyLauggPkBdJGF8rzV5/osa3RoyxD5/CDUX31EZjVshi2qtX P9piq4JtWe1krmYqbuejDWrmcHcYfOVDodhxB5zA/WwoqpUJbOcL9kR+1YMWC/9PYvbn 6Zf8b4DyAeF1XGWSwfGsm1vEnocRM33ROcRccR8j5HfLmMxaqwrrtmK/1LeY2Dd87oJc DUNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CSxrzGIbyFkr9c2YvbRgQ4lnFz+kEis6i7nNM0QtzQk=; b=mCbk/ZiNCJSSYeNVw7IfcIC2UiJKK4VybxSCLcFEXD+7dZmHJbDqAvzYgBMUTBdxNK akE/UaafoaH56jI5m2Mew77kKIIBCOH0hDBFi4km1l6n3KFWXbPQNSrJB5w90r5jWyIB 8LJQPbXHDtYWs235iOxzBosaqMK+pOw9o+tJzsRkNCHA6K11qWgYwgSyDz0+BCqCcfG4 rAtkSef8LyDyeGpY3wPvVIh3tReDkFhI2dUEGbkMJX6nJELrrVA65pkCxzzl7d8BBoB7 Mru8tGvk1Nzwr7eyV7ngItZWeUQo4pbnd6/tr006KP/Rb2nsv//2tecAYqw57yZPCIjL nlYA== X-Gm-Message-State: AHPjjUjSXaeGMWvRZiPAvV94Gvj/EilY0ZC0+AS9DgBt/788I4bUseGF +1geo8Gk6LtwdkL1TdjHLC+9LPoUCZVsEEA= X-Google-Smtp-Source: ADKCNb622bZQB+V8YkX6zj0pC9NtivYKXsn9aw9tcBM+vSAEmusq33QKLQLz9QJQDm9Uv6l0V37C49qWmJZrDfnKzpc= X-Received: by 10.55.165.202 with SMTP id o193mr1128852qke.291.1504657388487; Tue, 05 Sep 2017 17:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.36.138 with HTTP; Tue, 5 Sep 2017 17:22:47 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Tue, 5 Sep 2017 17:22:47 -0700 Message-ID: To: Andrei Popov Cc: Subodh Iyengar , IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 00:23:12 -0000 I agree that at this point it doesn't make sense to limit TB to (EC)DHE. I'm fine with writing a PR to cover this, but I'm unsure what to put in it. I liked how draft-balfanz-tls-channelid started its security considerations by describing 4 classes of network attackers, and I'd like to do something similar here. However, it's unclear to me which of those classes of network attackers are considered as part of the threat model for Token Binding. Would it be reasonable to say that defending against attackers with possession of a server's private key is outside of the scope of Token Binding? On Mon, Sep 4, 2017 at 3:59 PM, Andrei Popov w= rote: > It seems clear that binding tokens to broken TLS channels does one no goo= d, > but I don=E2=80=99t mind adding some statements to this effect in the sec= urity > considerations. > > The statements would need to be general enough to cover TLS client and > server compromise, PFS and non=E2=80=94PFS. > > > > Nick, please feel free to author a PR. If we get to IESG review someday, > there will be more edits, and we can incorporate this as well. > > > > I don=E2=80=99t think it makes sense to limit TB to (EC)DHE, especially i= f we=E2=80=99re > going to allow TB in combination with TLS 1.3 0-RTT mode. > > > > Cheers, > > > > Andrei > > > > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Subodh > Iyengar > Sent: Friday, September 1, 2017 3:28 PM > To: Nick Harper ; IETF Tokbind WG > > > Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key > exchange > > > > Having said that, even if we only support forward secure ciphers, I do no= t > think we can reasonably claim that we are secure against the threat of > stolen private keys. > > I like the the carrot opportunity this brings to encourage adoption of > forward secure cipher suites. > > > > Subodh > > ________________________________ > > From: Subodh Iyengar > Sent: Friday, September 1, 2017 3:24:25 PM > To: Nick Harper; IETF Tokbind WG > Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key > exchange > > > > +1 to requiring that token binding only be used with forward secure ciphe= r > suites. > > I believe the extended master secret requirement of token binding prevent= s > the attack on forward secure suites, i.e. an attacker cannot change the D= H > share advertised by the real server and thus needs to get the private key > for it. > > Subodh > > ________________________________ > > From: Unbearable on behalf of Nick Harper > > Sent: Friday, September 1, 2017 3:03:37 PM > To: IETF Tokbind WG > Subject: [Unbearable] Possible attack on Token Binding with RSA key excha= nge > > > > I came across an attack on Token Binding today, which I think is worth > addressing in TBPROTO in some fashion (likely another paragraph in > Security Considerations). This attack involves an adversary with the > private key of a server it wishes to impersonate, and was mentioned in > draft-balfanz-tls-channelid in the last paragraph of its Security > Considerations. > > In brief, if an attacker has possession of a server's private key, it > can hijack a TLS connection between client and server if the > connection uses RSA key exchange instead of (EC)DHE key exchange, > which allows the attacker to exercise the bound token without > possession of the Token Binding private key. > > I realize that we're past WGLC at this point, but I think this should > be addressed. On one end, we could require forward-secret key exchange > modes with Token Binding. We could also describe this specific attack > in the Security Considerations, or we could expand the Security > Considerations to describe what attacks are and aren't in the Token > Binding threat model, to say that attacks where the adversary has the > server's private key are out of scope. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_unbearable&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7m= Htwg-wAyN7fQ&m=3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=3DB0sKQEO8i8= hDpLizsh7X8ins9EGGwOwcckYqZku7zEE&e=3D From nobody Tue Sep 5 17:33:32 2017 Return-Path: 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 78E661321A4 for ; Tue, 5 Sep 2017 17:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 HcOxLamvbXRC for ; Tue, 5 Sep 2017 17:33:28 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0094.outbound.protection.outlook.com [104.47.37.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D578A1321A0 for ; Tue, 5 Sep 2017 17:33:28 -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=HSx+uyXViHB+5/b8cp2wF+ygPdGo/IHWWZDzX7FwIKQ=; b=QlHWTEInGCFX5F9I7bQw5SSnL73QzGyNKmSab7FBrdcOOG7SfFwfwMTyEWojjD3zIAYV2Ucxf4pE+LCVdxWX6oyS+DtAaRxars/CPwFcn9I/9e4xKD1s9yZV2cF6FIwphDBcHBj186yEgW1VEBLgASX/FuFgtNnsugGsw0lFrfA= Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0134.namprd21.prod.outlook.com (10.173.189.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.0; Wed, 6 Sep 2017 00:33:26 +0000 Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0056.000; Wed, 6 Sep 2017 00:33:26 +0000 From: Andrei Popov To: Nick Harper CC: Subodh Iyengar , IETF Tokbind WG Thread-Topic: [Unbearable] Possible attack on Token Binding with RSA key exchange Thread-Index: AQHTI248h15PeY9U802Z73g90LEOZ6Kgm0WAgAABCgCABLlR4IABsAuAgAAAa2A= Date: Wed, 6 Sep 2017 00:33:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:1::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0134; 6:dvOM4aQPlVg87+AvFDSFFNIvuqYYQjAlZ9JCB6Ha23FQIyZraCydtIiVTyCQqnxHibU34TWloCXwegtJo74rocigncM5oeZs0HlD4Q19EHCSCUxqqyEAf548hy+8VEfM8dgtRPLeuIo9aMw2shI5AVEaH4FvtdfTbkooE9BmrWGdfxOF0sYpC687Nmd1qIJDBAVPmlEG+lJ6GTySVrez4X+QZAYxj06iYPux4wvthqWnF6D3dLgY27DTmRxAp8NvCIvkNdDeFlvk2CtYN+pNn/dPvWgKPBpyVwrcOAt2OdhUDp06eO0zOdE3PRkCk+/LHXGfeIRoWERujXXp/ut09g==; 5:SyFb5CtwHqpM8WFC4ScCIZgrzF8XEbRy4Mvx+KRfOfKEESKV+FgW3d3uixBmynctAN9jWuWlpQEJ5M2v+xr4srlZhgaudcqfC3RcgBvgXGsAYQvhFhzifXxG6a+N2ZT6CcNcGjtFZSIOw/4jmzU7Fw==; 24:4Cf4VajtBASfuEePtUle6+w1rxH0qMMUVopg3QISHZB/fIcgz9XQKOdLD/sU/TiU0ZHR/hMqUcUpTyaJQLm8ViWJ+1vHKxU0fiDVfDZVBFw=; 7:HWC4DS+09HtjrbLFCAoVHYXvI7dLkID3sBcO27f5tE6fM3MWb5OyK5imNEJCJbNIrTTBwOOWY3aLA0yLA9E7x3C0A2DW2rml/WfIM+C3Hqs7CW123xst6TjoE0aZ1Y0Q80c0prm/J315v7a3ibRRUHW4LC8HFFpcW5r1lJorZ1zv44vZszqZg7PXSy+JJ/qUQQ6rZG2uQ6i5xb0TLB7U0Lzle++S6SV3VHeyPuRjQ/U= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 67526286-9d03-4c0a-f2f1-08d4f4bee3bc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0134; x-ms-traffictypediagnostic: CY4PR21MB0134: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(192374486261705)(189930954265078)(67672495146484)(211936372134217)(153496737603132)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0134; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0134; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(189002)(13464003)(199003)(24454002)(377454003)(55016002)(189998001)(6306002)(8936002)(33656002)(97736004)(575784001)(8676002)(99286003)(101416001)(86362001)(54356999)(50986999)(76176999)(7696004)(34040400001)(54906002)(966005)(68736007)(2950100002)(2906002)(86612001)(3280700002)(6506006)(3660700001)(6436002)(74316002)(81156014)(93886005)(2900100001)(5660300001)(81166006)(7736002)(8990500004)(106356001)(105586002)(305945005)(6916009)(4326008)(10090500001)(77096006)(6246003)(10290500003)(9686003)(102836003)(14454004)(6116002)(53546010)(229853002)(72206003)(110136004)(5005710100001)(25786009)(53936002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0134; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 00:33:26.6763 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0134 Archived-At: Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 00:33:31 -0000 PiBXb3VsZCBpdCBiZSByZWFzb25hYmxlIHRvIHNheSB0aGF0IGRlZmVuZGluZyBhZ2FpbnN0IGF0 dGFja2VycyB3aXRoIHBvc3Nlc3Npb24gb2YgYSBzZXJ2ZXIncyBwcml2YXRlIGtleSBpcyBvdXRz aWRlIG9mIHRoZSBzY29wZSBvZiBUb2tlbiBCaW5kaW5nPw0KU2VydmVyJ3MgcHJpdmF0ZSBrZXks IGFuZC9vciBjbGllbnQgcHJpdmF0ZSBrZXksIGFuZC9vciBtYXN0ZXIgc2VjcmV0Li4uIGFueXRo aW5nIHRoYXQgZW5hYmxlcyB0aGUgYXR0YWNrZXIgdG8gTUlUTSBhIHVzZXIncyBUTFMgc2Vzc2lv biwgb3IgdG8gZHVwbGljYXRlIGEgdXNlcidzIEVLTSBvbiB0aGUgYXR0YWNrZXIncyBUTFMgY29u bmVjdGlvbiwgd2lsbCBicmVhayBUQi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IE5pY2sgSGFycGVyIFttYWlsdG86bmhhcnBlckBnb29nbGUuY29tXSANClNlbnQ6IFR1ZXNk YXksIFNlcHRlbWJlciA1LCAyMDE3IDU6MjMgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IFN1Ym9kaCBJeWVuZ2FyIDxzdWJvZGhAZmIuY29tPjsg SUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJl YXJhYmxlXSBQb3NzaWJsZSBhdHRhY2sgb24gVG9rZW4gQmluZGluZyB3aXRoIFJTQSBrZXkgZXhj aGFuZ2UNCg0KSSBhZ3JlZSB0aGF0IGF0IHRoaXMgcG9pbnQgaXQgZG9lc24ndCBtYWtlIHNlbnNl IHRvIGxpbWl0IFRCIHRvIChFQylESEUuDQoNCkknbSBmaW5lIHdpdGggd3JpdGluZyBhIFBSIHRv IGNvdmVyIHRoaXMsIGJ1dCBJJ20gdW5zdXJlIHdoYXQgdG8gcHV0IGluIGl0LiBJIGxpa2VkIGhv dyBkcmFmdC1iYWxmYW56LXRscy1jaGFubmVsaWQgc3RhcnRlZCBpdHMgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgYnkgZGVzY3JpYmluZyA0IGNsYXNzZXMgb2YgbmV0d29yayBhdHRhY2tlcnMsIGFu ZCBJJ2QgbGlrZSB0byBkbyBzb21ldGhpbmcgc2ltaWxhciBoZXJlLiBIb3dldmVyLCBpdCdzIHVu Y2xlYXIgdG8gbWUgd2hpY2ggb2YgdGhvc2UgY2xhc3NlcyBvZiBuZXR3b3JrIGF0dGFja2VycyBh cmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mIHRoZSB0aHJlYXQgbW9kZWwgZm9yIFRva2VuIEJpbmRp bmcuIFdvdWxkIGl0IGJlIHJlYXNvbmFibGUgdG8gc2F5IHRoYXQgZGVmZW5kaW5nIGFnYWluc3Qg YXR0YWNrZXJzIHdpdGggcG9zc2Vzc2lvbiBvZiBhIHNlcnZlcidzIHByaXZhdGUga2V5IGlzIG91 dHNpZGUgb2YgdGhlIHNjb3BlIG9mIFRva2VuIEJpbmRpbmc/DQoNCk9uIE1vbiwgU2VwIDQsIDIw MTcgYXQgMzo1OSBQTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4g d3JvdGU6DQo+IEl0IHNlZW1zIGNsZWFyIHRoYXQgYmluZGluZyB0b2tlbnMgdG8gYnJva2VuIFRM UyBjaGFubmVscyBkb2VzIG9uZSBubyANCj4gZ29vZCwgYnV0IEkgZG9u4oCZdCBtaW5kIGFkZGlu ZyBzb21lIHN0YXRlbWVudHMgdG8gdGhpcyBlZmZlY3QgaW4gdGhlIA0KPiBzZWN1cml0eSBjb25z aWRlcmF0aW9ucy4NCj4NCj4gVGhlIHN0YXRlbWVudHMgd291bGQgbmVlZCB0byBiZSBnZW5lcmFs IGVub3VnaCB0byBjb3ZlciBUTFMgY2xpZW50IGFuZCANCj4gc2VydmVyIGNvbXByb21pc2UsIFBG UyBhbmQgbm9u4oCUUEZTLg0KPg0KPg0KPg0KPiBOaWNrLCBwbGVhc2UgZmVlbCBmcmVlIHRvIGF1 dGhvciBhIFBSLiBJZiB3ZSBnZXQgdG8gSUVTRyByZXZpZXcgDQo+IHNvbWVkYXksIHRoZXJlIHdp bGwgYmUgbW9yZSBlZGl0cywgYW5kIHdlIGNhbiBpbmNvcnBvcmF0ZSB0aGlzIGFzIHdlbGwuDQo+ DQo+DQo+DQo+IEkgZG9u4oCZdCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBsaW1pdCBUQiB0byAo RUMpREhFLCBlc3BlY2lhbGx5IGlmIA0KPiB3ZeKAmXJlIGdvaW5nIHRvIGFsbG93IFRCIGluIGNv bWJpbmF0aW9uIHdpdGggVExTIDEuMyAwLVJUVCBtb2RlLg0KPg0KPg0KPg0KPiBDaGVlcnMsDQo+ DQo+DQo+DQo+IEFuZHJlaQ0KPg0KPg0KPg0KPiBGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5i ZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+IFN1Ym9kaCBJeWVuZ2Fy DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEsIDIwMTcgMzoyOCBQTQ0KPiBUbzogTmljayBI YXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT47IElFVEYgVG9rYmluZCBXRyANCj4gPHVuYmVhcmFi bGVAaWV0Zi5vcmc+DQo+DQo+DQo+IFN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gUG9zc2libGUg YXR0YWNrIG9uIFRva2VuIEJpbmRpbmcgd2l0aCBSU0EgDQo+IGtleSBleGNoYW5nZQ0KPg0KPg0K Pg0KPiBIYXZpbmcgc2FpZCB0aGF0LCBldmVuIGlmIHdlIG9ubHkgc3VwcG9ydCBmb3J3YXJkIHNl Y3VyZSBjaXBoZXJzLCBJIGRvIA0KPiBub3QgdGhpbmsgd2UgY2FuIHJlYXNvbmFibHkgY2xhaW0g dGhhdCB3ZSBhcmUgc2VjdXJlIGFnYWluc3QgdGhlIA0KPiB0aHJlYXQgb2Ygc3RvbGVuIHByaXZh dGUga2V5cy4NCj4NCj4gSSBsaWtlIHRoZSB0aGUgY2Fycm90IG9wcG9ydHVuaXR5IHRoaXMgYnJp bmdzIHRvIGVuY291cmFnZSBhZG9wdGlvbiBvZiANCj4gZm9yd2FyZCBzZWN1cmUgY2lwaGVyIHN1 aXRlcy4NCj4NCj4NCj4NCj4gU3Vib2RoDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+DQo+IEZyb206IFN1Ym9kaCBJeWVuZ2FyDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVt YmVyIDEsIDIwMTcgMzoyNDoyNSBQTQ0KPiBUbzogTmljayBIYXJwZXI7IElFVEYgVG9rYmluZCBX Rw0KPiBTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFBvc3NpYmxlIGF0dGFjayBvbiBUb2tlbiBC aW5kaW5nIHdpdGggUlNBIA0KPiBrZXkgZXhjaGFuZ2UNCj4NCj4NCj4NCj4gKzEgdG8gcmVxdWly aW5nIHRoYXQgdG9rZW4gYmluZGluZyBvbmx5IGJlIHVzZWQgd2l0aCBmb3J3YXJkIHNlY3VyZSAN Cj4gK2NpcGhlcg0KPiBzdWl0ZXMuDQo+DQo+IEkgYmVsaWV2ZSB0aGUgZXh0ZW5kZWQgbWFzdGVy IHNlY3JldCByZXF1aXJlbWVudCBvZiB0b2tlbiBiaW5kaW5nIA0KPiBwcmV2ZW50cyB0aGUgYXR0 YWNrIG9uIGZvcndhcmQgc2VjdXJlIHN1aXRlcywgaS5lLiBhbiBhdHRhY2tlciBjYW5ub3QgDQo+ IGNoYW5nZSB0aGUgREggc2hhcmUgYWR2ZXJ0aXNlZCBieSB0aGUgcmVhbCBzZXJ2ZXIgYW5kIHRo dXMgbmVlZHMgdG8gDQo+IGdldCB0aGUgcHJpdmF0ZSBrZXkgZm9yIGl0Lg0KPg0KPiBTdWJvZGgN Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gRnJvbTogVW5iZWFy YWJsZSA8dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTmljayANCj4g SGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEs IDIwMTcgMzowMzozNyBQTQ0KPiBUbzogSUVURiBUb2tiaW5kIFdHDQo+IFN1YmplY3Q6IFtVbmJl YXJhYmxlXSBQb3NzaWJsZSBhdHRhY2sgb24gVG9rZW4gQmluZGluZyB3aXRoIFJTQSBrZXkgDQo+ IGV4Y2hhbmdlDQo+DQo+DQo+DQo+IEkgY2FtZSBhY3Jvc3MgYW4gYXR0YWNrIG9uIFRva2VuIEJp bmRpbmcgdG9kYXksIHdoaWNoIEkgdGhpbmsgaXMgd29ydGggDQo+IGFkZHJlc3NpbmcgaW4gVEJQ Uk9UTyBpbiBzb21lIGZhc2hpb24gKGxpa2VseSBhbm90aGVyIHBhcmFncmFwaCBpbiANCj4gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMpLiBUaGlzIGF0dGFjayBpbnZvbHZlcyBhbiBhZHZlcnNhcnkg d2l0aCB0aGUgDQo+IHByaXZhdGUga2V5IG9mIGEgc2VydmVyIGl0IHdpc2hlcyB0byBpbXBlcnNv bmF0ZSwgYW5kIHdhcyBtZW50aW9uZWQgaW4gDQo+IGRyYWZ0LWJhbGZhbnotdGxzLWNoYW5uZWxp ZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgaXRzIFNlY3VyaXR5IA0KPiBDb25zaWRlcmF0aW9u cy4NCj4NCj4gSW4gYnJpZWYsIGlmIGFuIGF0dGFja2VyIGhhcyBwb3NzZXNzaW9uIG9mIGEgc2Vy dmVyJ3MgcHJpdmF0ZSBrZXksIGl0IA0KPiBjYW4gaGlqYWNrIGEgVExTIGNvbm5lY3Rpb24gYmV0 d2VlbiBjbGllbnQgYW5kIHNlcnZlciBpZiB0aGUgDQo+IGNvbm5lY3Rpb24gdXNlcyBSU0Ega2V5 IGV4Y2hhbmdlIGluc3RlYWQgb2YgKEVDKURIRSBrZXkgZXhjaGFuZ2UsIA0KPiB3aGljaCBhbGxv d3MgdGhlIGF0dGFja2VyIHRvIGV4ZXJjaXNlIHRoZSBib3VuZCB0b2tlbiB3aXRob3V0IA0KPiBw b3NzZXNzaW9uIG9mIHRoZSBUb2tlbiBCaW5kaW5nIHByaXZhdGUga2V5Lg0KPg0KPiBJIHJlYWxp emUgdGhhdCB3ZSdyZSBwYXN0IFdHTEMgYXQgdGhpcyBwb2ludCwgYnV0IEkgdGhpbmsgdGhpcyBz aG91bGQgDQo+IGJlIGFkZHJlc3NlZC4gT24gb25lIGVuZCwgd2UgY291bGQgcmVxdWlyZSBmb3J3 YXJkLXNlY3JldCBrZXkgZXhjaGFuZ2UgDQo+IG1vZGVzIHdpdGggVG9rZW4gQmluZGluZy4gV2Ug Y291bGQgYWxzbyBkZXNjcmliZSB0aGlzIHNwZWNpZmljIGF0dGFjayANCj4gaW4gdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zLCBvciB3ZSBjb3VsZCBleHBhbmQgdGhlIFNlY3VyaXR5IA0KPiBD b25zaWRlcmF0aW9ucyB0byBkZXNjcmliZSB3aGF0IGF0dGFja3MgYXJlIGFuZCBhcmVuJ3QgaW4g dGhlIFRva2VuIA0KPiBCaW5kaW5nIHRocmVhdCBtb2RlbCwgdG8gc2F5IHRoYXQgYXR0YWNrcyB3 aGVyZSB0aGUgYWR2ZXJzYXJ5IGhhcyB0aGUgDQo+IHNlcnZlcidzIHByaXZhdGUga2V5IGFyZSBv dXQgb2Ygc2NvcGUuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IFVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQo+IFVuYmVhcmFibGVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ1cmxkZQ0KPiBmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNG dSUzRGh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9sDQo+IGlzdGluZm9fdW5iZWFyYWJs ZSUyNmQlM0REd0lDQWclMjZjJTNENVZEMFJUdE5sVGgzeWNkNDFiM01VdyUyNnIlM0RoM0oNCj4g dTlFQlM3bUh0d2ctd0F5TjdmUSUyNm0lM0RhS184RE1tb1dXaWlRSm1GdDNKdmhWTFQ2ZWg3UW0z bmYzV3VNaE1DN3ZNJQ0KPiAyNnMlM0RCMHNLUUVPOGk4aERwTGl6c2g3WDhpbnM5RUdHd093Y2Nr WXFaa3U3ekVFJTI2ZSZkYXRhPTAyJTdDMDElN0NBDQo+IG5kcmVpLlBvcG92JTQwbWljcm9zb2Z0 LmNvbSU3Q2M0Mzc3YTQwZTg3MzRiMjhlNzE4MDhkNGY0YmQ3M2VhJTdDNzJmOTgNCj4gOGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY0MDI1NDE5MDYwNzg4NTgmc2RhdGE9 bDRISHJYNg0KPiA3VDREbjFGVmZCSGx3MXhWVXYlMkIzQlNKODY3UGY1ZXpHRjMlMkIwJTNEJnJl c2VydmVkPTA9DQo= From nobody Tue Sep 5 18:28:19 2017 Return-Path: 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 3BB39132192 for ; Tue, 5 Sep 2017 18:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 KspciVvdRCoy for ; Tue, 5 Sep 2017 18:28:16 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 7ED441252BA for ; Tue, 5 Sep 2017 18:28:16 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f145so14007018wme.0 for ; Tue, 05 Sep 2017 18:28:16 -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=/GDdwklIImBMrZ6ZswmzG1xfQsr3AmLmlRMpkgjLz4s=; b=usRbPwRhUgksb+8vzUm7KUzslz4ZgYtuKUUZbFQ22yj1mkNFzrd+8nwYxONlDvHrD/ 2yCLRhBcO/gRBbGP4YI5iO8Gz4cYSvHCKt5NA2PRct2wELcYH8/KtXB8rahdHvRpF6IQ 3+xPOvz7yulL83RStYkAvYN0C1nTxIkEXpBULMFkG7PDamLMWG2HX4/qHhYaa3kMgaYQ /1E6SO1ZFsw3iSTCboc0JNcoFsmyCBVZo8WJAxF1bKZX5Dn7a2aU3weN/mbesZ7RrEyq n4Zofu34CFtQkcfR6bukMQMnDfk+730xyzsoyop2Y91nN4YgJFi3fQKg2dTvZCzATVFP UIMA== 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=/GDdwklIImBMrZ6ZswmzG1xfQsr3AmLmlRMpkgjLz4s=; b=Owauj+B6mEGGOY4/8F0UxM3y1T87loKbS/m2bHFJpQyoOwUOgiSF+zhbtPaEo5C7+S bI0bRBiWMGXLS6EZbkKZT+BSbv0DWfICMbhZNqcXgExQ5bDI6EbFOPjCFKoC1fv4cAbR 5ZIXlnVMFrrP/XiO3cTwycNTC33Em1nK6RKvrXK0GdrA/w3lRF72/cnxf7+7w0lpWsnV ea6ZE0zNlSXx4GAFrVrRH6UBenK+UPTQxiDXxnecrkX71WQISYnNBh+55XlwbRaN9FDG vvFFEYHAszDi/b/KhV4XBuf8IYoaqVb+dWi/Em5Hc1wsjCM47BUiQHbFVPPDZ7CBM/4T ittQ== X-Gm-Message-State: AHPjjUiNQX5zuPTOmFVTBoCmD6199Wj4QR5g2Y9nrX6qLVOJuDRRxRMj +Mv21mdtbI6atrrkhiiqq/B9Ctr4Ww== X-Google-Smtp-Source: ADKCNb47UReg9fn7dN21qBy4tv2IM/rSXUXIqaAB/NEH8a3wnVJfQH1Cp1A3Wg2zbG+mpa+3fX06sP5EEUZkXAXBb6E= X-Received: by 10.80.184.28 with SMTP id j28mr4801681ede.300.1504661295095; Tue, 05 Sep 2017 18:28:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lanlan Pan Date: Wed, 06 Sep 2017 01:28:04 +0000 Message-ID: To: Nick Harper Cc: unbearable@ietf.org Content-Type: multipart/alternative; boundary="f403045c53f600674905587b42be" Archived-At: Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 01:28:18 -0000 --f403045c53f600674905587b42be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 out of scope encourage using (EC)DHE key exchange in the security consideration ? Nick Harper =E4=BA=8E2017=E5=B9=B49=E6=9C=882=E6=97=A5= =E5=91=A8=E5=85=AD =E4=B8=8A=E5=8D=886:11=E5=86=99=E9=81=93=EF=BC=9A > I came across an attack on Token Binding today, which I think is worth > addressing in TBPROTO in some fashion (likely another paragraph in > Security Considerations). This attack involves an adversary with the > private key of a server it wishes to impersonate, and was mentioned in > draft-balfanz-tls-channelid in the last paragraph of its Security > Considerations. > > In brief, if an attacker has possession of a server's private key, it > can hijack a TLS connection between client and server if the > connection uses RSA key exchange instead of (EC)DHE key exchange, > which allows the attacker to exercise the bound token without > possession of the Token Binding private key. > > I realize that we're past WGLC at this point, but I think this should > be addressed. On one end, we could require forward-secret key exchange > modes with Token Binding. We could also describe this specific attack > in the Security Considerations, or we could expand the Security > Considerations to describe what attacks are and aren't in the Token > Binding threat model, to say that attacks where the adversary has the > server's private key are out of scope. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c53f600674905587b42be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1=C2=A0 out of scope

encourage using (EC)DHE key e= xchange in the security consideration ?

<= div dir=3D"ltr">Nick Harper <nharp= er@google.com>=E4=BA=8E2017=E5=B9=B49=E6=9C=882=E6=97=A5=E5=91=A8=E5= =85=AD =E4=B8=8A=E5=8D=886:11=E5=86=99=E9=81=93=EF=BC=9A
I came across an attack on Token Binding today, which= I think is worth
addressing in TBPROTO in some fashion (likely another paragraph in
Security Considerations). This attack involves an adversary with the
private key of a server it wishes to impersonate, and was mentioned in
draft-balfanz-tls-channelid in the last paragraph of its Security
Considerations.

In brief, if an attacker has possession of a server's private key, it can hijack a TLS connection between client and server if the
connection uses RSA key exchange instead of (EC)DHE key exchange,
which allows the attacker to exercise the bound token without
possession of the Token Binding private key.

I realize that we're past WGLC at this point, but I think this should be addressed. On one end, we could require forward-secret key exchange
modes with Token Binding. We could also describe this specific attack
in the Security Considerations, or we could expand the Security
Considerations to describe what attacks are and aren't in the Token
Binding threat model, to say that attacks where the adversary has the
server's private key are out of scope.

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--f403045c53f600674905587b42be-- From nobody Mon Sep 25 04:24:22 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9B1342D3; Mon, 25 Sep 2017 04:24:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: unbearable@ietf.org, tokbind-chairs@ietf.org, ekr@rtfm.com, leifj@sunet.se X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150633866028.27403.5430825054207288498.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 04:24:20 -0700 Archived-At: Subject: [Unbearable] tokbind - New Meeting Session Request for IETF 100 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:24:20 -0000 A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ace tls oauth secevent People who must be present: Eric Rescorla Stephen Farrell Leif Johansson Dirk Balfanz John Bradley Andrey Popov Mike Jones Resources Requested: Special Requests: Key contributors are unable to attend on Friday. Please if possible avoid Friday scheduling. --------------------------------------------------------- From nobody Tue Sep 26 00:02:50 2017 Return-Path: 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 E79321321D8 for ; Tue, 26 Sep 2017 00:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 TkkIPJ0nigKb for ; Tue, 26 Sep 2017 00:02:46 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 1BF4B132620 for ; Tue, 26 Sep 2017 00:02:45 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m123so1932501ita.3 for ; Tue, 26 Sep 2017 00:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=CI4hojbrM8yrteiwV/l0V66Op5jCpOlaP9d4ZBODwkU=; b=XrIFZFUymQPVBdVrTGycqKU+cg5awXv0s+R1nzH/oy4gCc20XW8BveZA5+xc5UADVo ICYCyne89+Lb7CxM87Vb6fKhO0nWbp+1y4Izk+khJs2HgBZ9yyXTCNze+z3jb7TBhQVa RWAAHBFBpj/MoSOqzZc74zrc1o3XwFWBCj+2q60PON2UKdrIxiyrJRhcjMpt1JOtpJdN s5HsBlbx0w4+on85mB6aEZ+Pufr8ld4vOIFIZ07zocP6Kev0B5LPciQaE0Q10u7LeosP Ojqg0wyfkOupMjMa9wJhSYbM+AB0S9n4LQEeUFtVgZLS5mrwl8eO2WZK82ANipXGa76R DDtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=CI4hojbrM8yrteiwV/l0V66Op5jCpOlaP9d4ZBODwkU=; b=KwnGaapQ90gOCZ53DJDbb+cSlP/+bPn3Ll/0Pt/ZDYB9JiAAZab80ocTxchp9ZgVFu B/xFdrFaDH36WqvntWflmxXFhmGinNYS5K1L5u5Jr0Gznqunh+lDmeBWWSRFOVqdotil AZCXJMBsTB6h609lxJqWl9FfiiE0imiYWJx3K79hFtKW0oXKJRn/W5qC2xVWQBDeZUql HT8hnLnkke5Gwqs8O/n9RvsKeYEMH91BbvMdPW8mCy35iHZZz4Nv1KmQOqx1D+tDzW+s 4FiAV0wtEeUirIr5XNbe39qmmuS32rJ80iGkU4oJKhPDR/FeSbAbYUhqysTNI0OA1iIb 11Hw== X-Gm-Message-State: AHPjjUhsbs1xiKisCIIcOrNwIgyyhTqdizuMdawwa97Wqbl3SCjJgUNH fcEgY4/Iye+wS1E72X+ofIczEqmxcSk= X-Google-Smtp-Source: AOwi7QB/zWMmfAtB8MTX+GPuMq0XoFdTzaVH28/O+WMvpknnJ/eWuCMc35MiaD3X+VqBC85GIG12FQ== X-Received: by 10.36.250.5 with SMTP id v5mr4475849ith.24.1506409363873; Tue, 26 Sep 2017 00:02:43 -0700 (PDT) Received: from ?IPv6:::ffff:172.20.11.193? ([123.254.126.131]) by smtp.gmail.com with ESMTPSA id y6sm4086261ioy.54.2017.09.26.00.02.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Sep 2017 00:02:42 -0700 (PDT) Message-ID: <59c9fb92.06326b0a.d6b88.6c90@mx.google.com> MIME-Version: 1.0 To: IETF TokBind WG Cc: "draft-ietf-tokbind-https@ietf.org" , Nick Harper From: John Bradley Date: Tue, 26 Sep 2017 00:02:41 -0700 Importance: normal X-Priority: 3 In-Reply-To: <634F056D-5B5F-4570-AE30-9F3F6F6AE3A5@ve7jtb.com> References: <634F056D-5B5F-4570-AE30-9F3F6F6AE3A5@ve7jtb.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c034f520e5336055a124330" Archived-At: Subject: Re: [Unbearable] IPR for draft-ietf-tokbind-https 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:02:48 -0000 --94eb2c034f520e5336055a124330 Content-Type: multipart/alternative; boundary="_59FB345E-7912-49F8-A5F0-78B54538107C_" --_59FB345E-7912-49F8-A5F0-78B54538107C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Nick I don=E2=80=99t have your IPR declaration. Can you reply to the list. John B. Sent from Mail for Windows 10 From: John Bradley Sent: Sunday, June 18, 2017 6:27 PM To: IETF TokBind WG Cc: draft-ietf-tokbind-https@ietf.org Subject: IPR for draft-ietf-tokbind-https I am working on the shepherd writeup for the=C2=A0Token Binding over HTTP= =C2=A0document: https://tools.ietf.org/html/draft-ietf-tokbind-https-09 One item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Could each of you please confirm? Magnus Nystroem Microsoft Corp. USA Email: mnystrom@microsoft.com Dirk Balfanz (editor) Google Inc. USA Email: balfanz@google.com Adam Langley Google Inc. USA Email: agl@google.com Jeff Hodges PayPal USA Email: Jeff.Hodges@paypal.com --_59FB345E-7912-49F8-A5F0-78B54538107C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Nick I don=E2=80=99t have your IPR d= eclaration.=C2=A0 Can you reply to the list.

&= nbsp;

John B.

&n= bsp;

Sent from Mail for Windows 10

 

From: John Bradley
Sent: Sunday, June 18, 2017 6:2= 7 PM
To: IETF TokBind WG
Cc: draft= -ietf-tokbind-https@ietf.org
Subject: IPR for draft-ietf-tokb= ind-https

 



I am working on the shepherd writeup for the Token Binding over HT= TP document:
https://tools.ietf.org/html/draft-ietf-tokbind-https-09
One item in the template requires me to indicate whether each documen= t
author has confirmed that any and all appropriate IPR disclosures
r= equired for full conformance with the provisions of BCP 78 and BCP 79
ha= ve already been filed.

Could each of you please confirm?<= /span>

 

<= pre style=3D'break-before: page;font-variant-ligatures: normal'>=C2=A0=C2=A0 Magnus Nystroem<= pre>=C2=A0=C2=A0 Microsoft Corp.
=C2=A0=C2=A0 USA
 
=C2=A0=C2=A0 Email: mnystrom@microsoft.com
 
 
=C2=A0=C2=A0 Dirk Balfanz (editor)
=C2=A0=C2=A0 Google =
Inc.
=C2=A0=C2=
=A0 USA
&=
nbsp;
=C2=A0=C2=A0 =
Email: balfanz@google.com
 
 
=C2=A0=C2=A0 Adam Langley
=C2=A0=C2=A0 Google Inc=
.
=C2=A0=C2=A0=
 USA
&nbs=
p;
=C2=A0=C2=A0 Ema=
il: agl@google.com<=
/pre>
 
 
=C2=A0=C2=A0 Jeff Hodges
=C2=A0=C2=A0 PayPal
=C2=A0=C2=A0 USA
 
=C2=A0=C2=A0 Email: Jeff.Hodges@paypal.com

 

 

= --_59FB345E-7912-49F8-A5F0-78B54538107C_-- --94eb2c034f520e5336055a124330 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEII+fBdsvicWcYX9Bl933Dkw38TGw +CiUJtoyvw/zWFkdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDkyNjA3MDI0NFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQC7TbnD3psH7bOZaD0Kd3dds85rPXjx4o4VQioE5g+Ce50d L6yavRgD7rxUpl6bayV9A85Qn2UZ2Woqq9lds47EqZ/o65EHcAyheru7cuJG3UbCkeW0irafNozE Gy07+cnQ3JDJm29H4cLInK0Te7k60Kj4P3mpAOMqQFt9ZmzybPEoTCeNT+WzUcTCBPDdAtc+YWKt xPGnH51N6BhhTcvjanW0SC5Xs+5KQqLSdIoaAMnZSP7zppHTxDH7DDey8GTZymjF2zgV3HNd0SpZ V7lKg8LIS49Jr+pVLWaIefRswNEGSiuR3VxnjDgzWKYV8Va9w55zO2AySyFKTonBFE/6 --94eb2c034f520e5336055a124330-- From nobody Tue Sep 26 00:24:38 2017 Return-Path: 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 D2B29132D4B for ; Tue, 26 Sep 2017 00:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xMqtmDReY-DM for ; Tue, 26 Sep 2017 00:24:35 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 1A46C132620 for ; Tue, 26 Sep 2017 00:24:35 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id c69so9147257qke.8 for ; Tue, 26 Sep 2017 00:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=txNSCIKi5IwrLM+ujJwd/G8TaN3N/EPnPYcc4ZBjMSg=; b=JGLFy1AN85J+SkB4lQAvjpQ6QAaKhz5wKMegCNfEOdMawo1z/UHopLPrhZq/b6rVAl xUqb8t3Oc1HdUTMNMedoHKh3FCqsYA6N/0ULD1DoQVqMLgXe+DubywC/o5MXBn8gFh6C uNjYfT+FsIxmzb7O1zwiC9IfxvwSMtKVKKhHFNRLadEwaMwd0+MFcQyNwkouL1B9tugi ouOMdQrAmTj47vni311UP6BzD99/2fP53Z+sI/lYSEaRYqtd+lATjty+3SQKDAiEwgnB JBwUtOmK8OB6rQYoJwtGbcQLqHDVovlepwm8qL3wEsMfFMy8lZ0WPdSAx8JK46RnSlch RLKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=txNSCIKi5IwrLM+ujJwd/G8TaN3N/EPnPYcc4ZBjMSg=; b=XzNPw/jddLZSox1BPyCoGY40u2tJ7Y70kIf7+0fFK3E6iiVdEBB6G8wyqvpZL3+HOw k2KJa2Sun1R39IHdZZBY5ViUM2R6zoWo5//7X8de8Gpky6hnCwCcggaDHnm6A44+XQKG bTkhZfhZcHn78TQjTNMwicJE2AK/NVVqO8SmwzWn/DQIt8VX+Rq6PGhsskLhmis+v3uj 1fCZM/tUcmoG9qbpzBs/oZItnXYKOv1J55cGa/UpOoUHBqOlSOLyQfk3FimjVX6EmkEh WW0AcHXalxbjMhoB90uOkGtjTnriNFW1DODsD3o8tlINp279XL4nWjSZU40vb+KY/poi CA1g== X-Gm-Message-State: AHPjjUgrT7JHwHGl5Gep2zHNfeVs1G7zKDoWPHYgqNL6T6eO1yzPgLGx DIWFxCrAuzzMzF29I7m5Q4czx5NhSQCIhUcXNY6cpKi0 X-Google-Smtp-Source: AOwi7QBI5UFYgbDC4EzfHYOiLNeB/XqxyI9AII1vX7QmGLpjA8ljedHuihlSfV/TNnPy3HKOK4JYIqOY0cp3Y3njcms= X-Received: by 10.55.52.207 with SMTP id b198mr14302869qka.60.1506410673867; Tue, 26 Sep 2017 00:24:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.36.138 with HTTP; Tue, 26 Sep 2017 00:24:13 -0700 (PDT) In-Reply-To: <59c9fb92.06326b0a.d6b88.6c90@mx.google.com> References: <634F056D-5B5F-4570-AE30-9F3F6F6AE3A5@ve7jtb.com> <59c9fb92.06326b0a.d6b88.6c90@mx.google.com> From: Nick Harper Date: Tue, 26 Sep 2017 00:24:13 -0700 Message-ID: To: John Bradley Cc: IETF TokBind WG , "draft-ietf-tokbind-https@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Unbearable] IPR for draft-ietf-tokbind-https 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:24:37 -0000 I am not aware of any IPR pertaining to HTTPSTB. On Tue, Sep 26, 2017 at 12:02 AM, John Bradley wrote: > Nick I don=E2=80=99t have your IPR declaration. Can you reply to the lis= t. > > > > John B. > > > > Sent from Mail for Windows 10 > > > > From: John Bradley > Sent: Sunday, June 18, 2017 6:27 PM > To: IETF TokBind WG > Cc: draft-ietf-tokbind-https@ietf.org > Subject: IPR for draft-ietf-tokbind-https > > > > > > I am working on the shepherd writeup for the Token Binding over HTTP > document: > https://tools.ietf.org/html/draft-ietf-tokbind-https-09 > > One item in the template requires me to indicate whether each document > author has confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 > have already been filed. > > Could each of you please confirm? > > > > Magnus Nystroem > > Microsoft Corp. > > USA > > > > Email: mnystrom@microsoft.com > > > > > > Dirk Balfanz (editor) > > Google Inc. > > USA > > > > Email: balfanz@google.com > > > > > > Adam Langley > > Google Inc. > > USA > > > > Email: agl@google.com > > > > > > Jeff Hodges > > PayPal > > USA > > > > Email: Jeff.Hodges@paypal.com > > > >