IETF Logo Mail Archive

Re: [Unbearable] ramifications of longer EKMs

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 24 February 2017 00:07 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 50D12129A8F for <unbearable@ietfa.amsl.com>; Thu, 23 Feb 2017 16:07:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LER6i18R5Z3 for <unbearable@ietfa.amsl.com>; Thu, 23 Feb 2017 16:07:29 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0106.outbound.protection.outlook.com [104.47.36.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682FE1293D9 for <unbearable@ietf.org>; Thu, 23 Feb 2017 16:07:29 -0800 (PST)
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=PUZNuTl/AG2p8uNE7HQPj+RSDGloOsEkAQyJFuA/L5U=; b=J5e6kgzfEMlUu+Yrdja3UgOSyYcDCeuUP5wHr/UBg+DgL6/zGfENJoK5Vs3DiNhdqOW4jfttjxeqkS8YUBwecVCdyFryfjTsxro6KDp4i9iK4sIGyoXzscZHnwaGVr/SDzU7y5HjeSFYOTAvKya+zIgi8cClFH76oeErTBe1u0o=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 24 Feb 2017 00:07:28 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Fri, 24 Feb 2017 00:07:28 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Thread-Topic: [Unbearable] ramifications of longer EKMs
Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIggAAZn4CAAACqsIAADg1QgADNxwCAAG9TYIAAQPSAgAAAk1A=
Date: Fri, 24 Feb 2017 00:07:27 +0000
Message-ID: <CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <CA+k3eCTRAdwW9xj2JRcs7LwgXJtWj=zDFrZVGJVLmV-vHuYstw@mail.gmail.com> <CY1PR0301MB0842D765811AA4C37AE332938C500@CY1PR0301MB0842.namprd03.prod.outlook.com> <CA+k3eCQw4KErXHrQWx=uEmf6OKvp9nGQYiC2nWk4+exorxjDCg@mail.gmail.com> <CY1PR0301MB0842C76A829D345AAC18FB988C530@CY1PR0301MB0842.namprd03.prod.outlook.com> <CY1PR0301MB0842026E974F75CE28AA264C8C530@CY1PR0301MB0842.namprd03.prod.outlook.com> <CA+k3eCQZKAf7BOWKBDQqBDR63OBKOogyuDT+j1JCqSDU3EUuQg@mail.gmail.com> <CY1PR0301MB08427EB93E5E942C662AF06B8C530@CY1PR0301MB0842.namprd03.prod.outlook.com> <CA+k3eCTwP0pyKbm=1Lxsdq=BucApD8ezmyJBajLzAAVoTkcAXg@mail.gmail.com>
In-Reply-To: <CA+k3eCTwP0pyKbm=1Lxsdq=BucApD8ezmyJBajLzAAVoTkcAXg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:8::1d2]
x-ms-office365-filtering-correlation-id: 8b310779-f7d1-4f02-4d4d-08d45c491e8b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841;
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:DzMR0cT9PW2vev0b6bu7iWETuShgoEya3We5ST9HXjDOlm4rrVhJ0aR02q6kR8ZiLO4cspMBUxgJjlsTl/pCjY0eHBcaJck+h6tbwTWIqoE4D6kB4cnmVZ52XjGUZh+7+EMMbhZXhmZRfpPDqmeKUf/GQ2rgxE4s5gFY6HOFVPBipcxXhziS3YvRJAHpWO1HbsyQuLHV23VTSBJwyEZdMbYyBVVftUZLUnoMMylckIBDNYcCuoiJWWISg8VPwdHdXl00MFRxbmcfB6GGMI1Nta827D/hlJsk/ZQ342RHRqf2fB2W2gU9o0i/MWWIvuvLMxvqMccCBt31kqcCha5ZpchGtmAM+0Dlu5UAeA7P97k=
x-microsoft-antispam-prvs: <CY1PR0301MB0841AD9D3F62356F369A12538C520@CY1PR0301MB0841.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(189002)(199003)(110136004)(6246003)(189998001)(81156014)(8676002)(101416001)(8936002)(74316002)(105586002)(106356001)(81166006)(106116001)(93886004)(6436002)(38730400002)(8990500004)(7736002)(7696004)(33656002)(97736004)(2950100002)(6916009)(6116002)(10290500002)(10090500001)(5005710100001)(2900100001)(229853002)(5660300001)(77096006)(3660700001)(790700001)(122556002)(4326007)(50986999)(54356999)(92566002)(86362001)(3280700002)(102836003)(25786008)(2906002)(86612001)(9686003)(99286003)(55016002)(76176999)(6306002)(6506006)(54896002)(53936002)(68736007)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.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)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 00:07:27.8083 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/CLwCcUeM1wZ0yqwNRMUy1L7FfWw>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] ramifications of longer EKMs
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 24 Feb 2017 00:07:31 -0000

Ø  I wouldn't characterize it as misconfiguration but rather just different domains supporting different sets of TB key params.
An RP negotiating TB key parameters that the corresponding IDP does not support makes it impossible for the IDP to bind the token, therefore I think of it as a misconfiguration. Unfortunately, RPs are limited in their TB options by their IDP’s capabilities…


Ø  And could happen even if the sets were the same but prioritized differently.
If the TB key parameter sets are the same, but prioritized differently, then there is no problem: the IDP can handle the EKM length required by the signature scheme used in the Referred binding, correct? I think the issue only exists when the IDP does not support the signature scheme that an RP negotiates.


Ø  But I guess, at this point, I'd lean towards 3) as well. It simplifies the TTRP case as well as server processing logic (assuming the logic would be generalized to accommodate future TB key params with a longer EKM).
Great. Let’s see if someone else cares one way or another. This would be a trivial change to make, following WGLC…

v2.30.2 | Report a Bug | By Email | System Status