Re: [Unbearable] Review by Michael Jones of draft-ietf-tokbind-protocol-13
Andrei Popov <Andrei.Popov@microsoft.com> Wed, 15 March 2017 01:20 UTC
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284A8129401 for <unbearable@ietfa.amsl.com>; Tue, 14 Mar 2017 18:20:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tyqgxy2S3uyo for <unbearable@ietfa.amsl.com>; Tue, 14 Mar 2017 18:20:06 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0103.outbound.protection.outlook.com [104.47.40.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70E212896F for <unbearable@ietf.org>; Tue, 14 Mar 2017 18:20:06 -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=reaLOX5l0J1BO6RRd2/thBtPhcJn94Lni2lYMaW+ovc=; b=KlYtbkXHyNV5MtAR38rlE6sFsXTdIk6ky7Zx2wReJH5ePBwMzG24n/gDUT5TeG6DkpePLsodDxQWhMo157cBqkoiMoZdy7076jCxXC3Y2hvzSI+uk4y5efhZcp7HNxUkKPddmt5i7JXyyo5X7s0CeDcr3P03eTuJEd0c1NxsOYk=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM5PR21MB0506.namprd21.prod.outlook.com (10.172.91.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Wed, 15 Mar 2017 01:20:05 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.0991.002; Wed, 15 Mar 2017 01:20:05 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>, "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: Review by Michael Jones of draft-ietf-tokbind-protocol-13
Thread-Index: AdKdJC3da0UJKpiTQlStgqnLoFBybAABFl4Q
Date: Wed, 15 Mar 2017 01:20:05 +0000
Message-ID: <DM2PR21MB0091F6D7990F56BA7D423DCA8C270@DM2PR21MB0091.namprd21.prod.outlook.com>
References: <CY4PR21MB0504FFA50FD3E98B90AAEC71F5270@CY4PR21MB0504.namprd21.prod.outlook.com>
In-Reply-To: <CY4PR21MB0504FFA50FD3E98B90AAEC71F5270@CY4PR21MB0504.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:5::1d2]
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0506; 7:6Wbi1W0xXRxLxfde9GgF8iKBKMRCIywefiY1Evl2I5UhXXNcNGfQojzzJibMw5zkmTUwIgT+Y9Iv+hUiVypJiP2vVUYamrzJpbMnqv8LI6TLN8kuN62fbAbPflJum3lvz9yDVS9BU7STE/HOOrFsxJGljDUyFX5S7G/XNtjDuG2xCOwfEsZ3cDGSgUS8iMvSP5aDFSzwxHeb5r5UiGE7jYsHJMqs1us1g7p0aTz/D+epRo+hO1MEz/i0RLXS+/kZ9umlAXh4bF3mPrXYlEAg3ntXuMxp+yo0lX/Z/UKPatZ93G5lRQ+DKs9txbz2nFIumHZTpgLuIjbIiadDMr2Q1ETBW4DVeihgz6j+DBMTvV8=
x-ms-office365-filtering-correlation-id: 302f31a5-0daf-4f4e-965c-08d46b416973
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254019)(48565401081); SRVR:DM5PR21MB0506;
x-microsoft-antispam-prvs: <DM5PR21MB0506BE4C0AB7C37DFE5630998C270@DM5PR21MB0506.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155)(21532816269658);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:DM5PR21MB0506; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0506;
x-forefront-prvs: 02475B2A01
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39410400002)(39450400003)(39850400002)(39840400002)(377454003)(86612001)(86362001)(2950100002)(33656002)(229853002)(3280700002)(5005710100001)(7906003)(10290500002)(6116002)(2421001)(2501003)(7736002)(10090500001)(8990500004)(790700001)(76176999)(54356999)(50986999)(74316002)(102836003)(2906002)(81166006)(5660300001)(230783001)(236005)(8676002)(9686003)(53936002)(38730400002)(53376002)(122556002)(8936002)(6246003)(966004)(606005)(189998001)(9326002)(6436002)(25786008)(7696004)(77096006)(3660700001)(6506006)(2561002)(55016002)(54896002)(99286003)(6306002)(2900100001)(53546007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0506; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0091F6D7990F56BA7D423DCA8C270DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 01:20:05.1530 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0506
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/sw6_1nduePzoHRBFl1jiWcWLwWA>
Subject: Re: [Unbearable] Review by Michael Jones of draft-ietf-tokbind-protocol-13
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 01:20:09 -0000
Hi Mike, Thanks for your comments. ? MOST IMPORTANT - FULLY DEFINE REJECTION SEMANTICS: ? Likewise, in places where it says things like "any associated bound tokens MUST also be rejected by the server" it should probably be said that the application must discard the entire contents of any communications using a bound security token not matching the token binding I think the language in Section 4.2 is better: "If a Token Binding is rejected, any associated bound tokens MUST also be rejected by the server. The effect of this is application- specific, e.g. failing requests, a requirement for the client to re- authenticate and present a different token, or connection termination." In the Token Binding protocol spec, we can't define one way of handling rejected tokens for all possible applications. ? ACKNOLWEDGE THAT HASHES OF TBIDs CAN BE USED: Per Section 5, we are explicitly allowing any method of binding tokens: "The specific method of generating bound security tokens is application-defined and beyond the scope of this document." I don't mind mentioning the hash of the TB ID in section 5, which is dedicated to this question. It is probably better to keep the Introduction concise. Cheers, Andrei From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, March 14, 2017 6:06 PM To: unbearable@ietf.org Subject: [Unbearable] Review by Michael Jones of draft-ietf-tokbind-protocol-13 I read draft-ietf-tokbind-protocol-13 cover-to-cover today and identified these issues with the text. MOST IMPORTANT - FULLY DEFINE REJECTION SEMANTICS: There are lots of places in the draft where it says things like "the server rejects the binding" (e.g., Section 2, paragraph 3). What the text does not say is something along the lines of "the server rejects the binding and discards all data sent along with the rejected Token Binding message". People may be assuming that discarding the data associated with a failed token binding is obvious, but I think it needs to be explicitly stated. One could easily read the current text and think that "rejects the binding" just means ignoring the Token Binding message and continuing processing and delivering TLS the data as if the Token Binding extension were not used. Likewise, in places where it says things like "any associated bound tokens MUST also be rejected by the server" it should probably be said that the application must discard the entire contents of any communications using a bound security token not matching the token binding. "Rejecting the token" doesn't seem like a thorough enough description of the intent. Please look at all the occurrences of "reject" in the draft and consider beefing up the rejection descriptions. ACKNOLWEDGE THAT HASHES OF TBIDs CAN BE USED: In the sentence in the Introduction "When issuing a security token to a client that supports Token Binding, a server includes the client's Token Binding ID in the token", please add "(or a cryptographic hash of it)" after "the client's Token Binding ID". Note that both OAuth Token Binding https://tools.ietf.org/html/draft-ietf-oauth-token-binding-02 and OpenID Connect Token Binding http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html use a hash of the Token Binding ID in security tokens, rather than the Token Binding ID itself, for space reasons. This common technique should be explicitly allowed. NITS: Change "Paypal" to "PayPal". Change "associeted" to "associated". Other than that, looks good! -- Mike