Re: [Unbearable] Review by Michael Jones of draft-ietf-tokbind-protocol-13
Mike Jones <Michael.Jones@microsoft.com> Wed, 15 March 2017 21:32 UTC
Return-Path: <Michael.Jones@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 0A9D9129C25 for <unbearable@ietfa.amsl.com>; Wed, 15 Mar 2017 14:32:58 -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 Vp0-mJN3-OPI for <unbearable@ietfa.amsl.com>; Wed, 15 Mar 2017 14:32:43 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0104.outbound.protection.outlook.com [104.47.41.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4872E131853 for <unbearable@ietf.org>; Wed, 15 Mar 2017 14:32:27 -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=ppOpZhgV9lEcfJ7UnSD3eK0tMVP2acM/7zzXozvN3YU=; b=msPsYXKN77wI4ZoYf4nm3qSyl40/ldJvwL7KMoDnF2yupFpjLpwfEYyCFmCoBDQzfLJ0+m0UqtmFjmx5OvYex9IAQ2bpBHG1pVXPCBNiT8adeF+ISdFpTLLZSiHekreIN1GE1VonjR8eVck9JqzBP8DFKRiq6RzD+bD5+ctNZck=
Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by DM2PR21MB0089.namprd21.prod.outlook.com (10.161.141.13) 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 21:32:25 +0000
Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0991.003; Wed, 15 Mar 2017 21:32:25 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>, "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: Review by Michael Jones of draft-ietf-tokbind-protocol-13
Thread-Index: AdKdJC3da0UJKpiTQlStgqnLoFBybAABFl4QACpQinA=
Date: Wed, 15 Mar 2017 21:32:24 +0000
Message-ID: <CY4PR21MB050430A28E2ECD9BE99F4B04F5270@CY4PR21MB0504.namprd21.prod.outlook.com>
References: <CY4PR21MB0504FFA50FD3E98B90AAEC71F5270@CY4PR21MB0504.namprd21.prod.outlook.com> <DM2PR21MB0091F6D7990F56BA7D423DCA8C270@DM2PR21MB0091.namprd21.prod.outlook.com>
In-Reply-To: <DM2PR21MB0091F6D7990F56BA7D423DCA8C270@DM2PR21MB0091.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:4::36]
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0089; 7:Mvlw4rY50yC62+K0EAea00/eviUPjctNHpiP481qZtACtdGKCWxJ5qaCnYwo46m+7AWAQKKCvXE0SewKPK19jZwAvHQ022FSwgFiB34F/w0zi/+rJRdszRO90EimiUrsMoGbqQTROGu4d7zZ3gjqQg3hJssYji36U90XiHSMpD7YIPB1nhNakNTlmASDspK3v2qwO7vmY6r5/cvWUXc72shkLvuugINDhQE+0Rp8Qlf7t68ZgS7QM1LueKKZtrkAng9WLluYhNdc2pkKrPYLF1Vd/FeC6Z7JIB6QGPAVZoUP/BNhho6ggfuCErNY5CRfGrB+Pynz40Ui1qogasyAwmQyAM+S0CbbfLlM/wDUILI=
x-ms-office365-filtering-correlation-id: c03261dc-e2c4-4e2e-d138-08d46beac5d9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254025)(48565401081); SRVR:DM2PR21MB0089;
x-microsoft-antispam-prvs: <DM2PR21MB0089548D9F7A86128F833A41F5270@DM2PR21MB0089.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)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(6072148); SRVR:DM2PR21MB0089; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0089;
x-forefront-prvs: 02475B2A01
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39850400002)(39410400002)(377454003)(38730400002)(81166006)(8676002)(2501003)(5660300001)(6116002)(790700001)(1511001)(2421001)(77096006)(2900100001)(99286003)(102836003)(53546007)(53376002)(54356999)(74316002)(53936002)(76176999)(33656002)(50986999)(10290500002)(3660700001)(5005710100001)(6306002)(55016002)(3280700002)(189998001)(6506006)(8936002)(7696004)(966004)(25786008)(7906003)(7736002)(54896002)(8990500004)(236005)(9686003)(6436002)(606005)(2950100002)(229853002)(86362001)(10090500001)(2906002)(230783001)(6246003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0089; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB050430A28E2ECD9BE99F4B04F5270CY4PR21MB0504namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 21:32:24.9826 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0089
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/B-AdbpY5bQlbpOvUZ9KfVMbAGkA>
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 21:32:58 -0000
Thinking about this a bit more, the statement that I think is missing about rejection semantics is that rejecting mismatching token bound communications (and unbound communications that should have been bound) is *always* an application-level action - not something done by the TLS or Token Binding layers. I think that this should be said somewhere in the introduction. Then it will be clear what party is doing the rejecting when phrases like "rejects the binding" are used. I'm fine adding the hashed TBID language in Section 5. One other nit I ran into: Add a comma after "Otherwise" in "Otherwise the Token Binding is successfully established". -- Mike From: Andrei Popov Sent: Tuesday, March 14, 2017 6:20 PM To: Mike Jones <Michael.Jones@microsoft.com>; unbearable@ietf.org Subject: RE: Review by Michael Jones of draft-ietf-tokbind-protocol-13 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<mailto: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