IETF Logo Mail Archive

Re: [Unbearable] ramifications of longer EKMs

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 23 February 2017 01:13 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 04A5412949A for <unbearable@ietfa.amsl.com>; Wed, 22 Feb 2017 17:13:09 -0800 (PST)
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=unavailable 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 lOtaKGA-nJmO for <unbearable@ietfa.amsl.com>; Wed, 22 Feb 2017 17:13:07 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0098.outbound.protection.outlook.com [104.47.32.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269DF12948D for <unbearable@ietf.org>; Wed, 22 Feb 2017 17:04:01 -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=3EXQYHKbrGSWZ7SJ3J98rmGmClSUCTSl+SndASKUhA8=; b=Oef/jiJ8WXFuT3bs4abc6LayuyBWkPNOjDlAMb/Ljww9pu8CbmZTHtu+5TxR2ErzndKCPRQLdzv6BGBa4i6u8pq5b1FF/4KxA/20zIqm9DeIU+IXEIfp64b0Z2ep/Vre1BjQxwkzzenIsOf4nwgVi5Uzfdina4DFsljrfPIVCP4=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 01:03:59 +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; Thu, 23 Feb 2017 01:03:59 +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+0qEZ9BqF1ncIggAAZn4CAAACqsIAADg1Q
Date: Thu, 23 Feb 2017 01:03:59 +0000
Message-ID: <CY1PR0301MB0842026E974F75CE28AA264C8C530@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>
In-Reply-To: <CY1PR0301MB0842C76A829D345AAC18FB988C530@CY1PR0301MB0842.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:8::1d2]
x-ms-office365-filtering-correlation-id: 03b07b83-5e78-4aa3-8e36-08d45b87d994
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843;
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:VNbB4ZYwUld5yHYPbA1x0+WuwujRkZUannaC6Yq+UgttbOKiItpay7ugu451EVIhxKxORqkbGHieRr19I7eQzGBKWRNFNSswNNs6Kw82ni7KSo4RYKujc8BQxn2OH7xScWm3lPKZ7/26BSIKpJeEWm80aFmEM8hJ1dabQ4SYByOkR7xqcnbRkbda8wpeRa+KE7nACD/Q4HtMclrNEKX0EL+xVi7oQjASNAIgvqXXRSA5fQJwFUS9Pgm3IKEOn/zVFGk3YlRBt3G3l5MieSOJrLC3SpNwn91SeYwyCbTgnB/P2xRu+bMVz/+bG4sde7QZPCKoRTCwlWXls4sj2J3Y7JMoL+wMK0VmkDYYWcV+EIk=
x-microsoft-antispam-prvs: <CY1PR0301MB0843387173E51A49D087E6878C530@CY1PR0301MB0843.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(377454003)(54356999)(76176999)(10090500001)(2950100002)(2906002)(92566002)(106116001)(50986999)(3280700002)(4326007)(7696004)(33656002)(8676002)(2900100001)(6116002)(790700001)(3660700001)(93886004)(5660300001)(102836003)(9686003)(54896002)(110136004)(25786008)(189998001)(38730400002)(6246003)(99286003)(229853002)(122556002)(55016002)(10290500002)(6306002)(53936002)(8990500004)(53546006)(8936002)(6436002)(74316002)(6506006)(86612001)(77096006)(5005710100001)(81166006)(6916009)(19609705001)(7736002)(86362001)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:nspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842026E974F75CE28AA264C8C530CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 01:03:59.3780 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/RdQCWB0hOIZxpVATHAs414CIiWs>
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: Thu, 23 Feb 2017 01:13:09 -0000

Correction inline☺.

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Andrei Popov
Sent: Wednesday, February 22, 2017 4:39 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] ramifications of longer EKMs


Ø  I'm not sure I follow this?

Ø  I'd think, if this kind of model was used, a TTRP could do all the TB validation work and just expose the TB ID(s) to the backend where they can bind to whatever tokens/cookies they are issuing.
Sure, this design would work. My point is that the tokbind-tls-term document cannot require one particular model of TB processing, because if this one model does not meet a data center’s requirements/architecture, the document is easily ignored. And it would be particularly undesirable to lose the “dumb/slim” TTRP model.

Ø  The backend apps would only be able to use TB key parameters that the TTRP supports but that's pretty much true of the other model too - the TTRP still is the one negotiating.
Backend could pass the TB key parameters to the TTRP, or these could be part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is TB protocol version and a prioritized list of TB key parameter IDs.

Ø  It only defeats the purpose of having per-signature-scheme EKM lengths in the case of a refereed TB using a longer EKM than the provided.
Let’s say a client negotiates signature scheme A with the RP, and signature scheme A calls for a 64-byte EKM. Then the client negotiates a signature scheme B with the IDP, and signature scheme B calls for a 32-byte EKM. The client sends Provided and Referred bindings to this IDP, and the Referred binding uses signature scheme A in combination with an EKM length 32 (which does not agree with the signature scheme definition). Is this what you’re proposing as option 4), or did I get it wrong?

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