IETF Logo Mail Archive

Re: [Unbearable] ramifications of longer EKMs

John Bradley <ve7jtb@ve7jtb.com> Fri, 24 February 2017 01:00 UTC

Return-Path: <ve7jtb@ve7jtb.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 3E2FF1293F4 for <unbearable@ietfa.amsl.com>; Thu, 23 Feb 2017 17:00:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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] 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 n_HVyKRIp9-O for <unbearable@ietfa.amsl.com>; Thu, 23 Feb 2017 17:00:24 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 DE752127076 for <unbearable@ietf.org>; Thu, 23 Feb 2017 17:00:23 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id u188so7354741qkc.2 for <unbearable@ietf.org>; Thu, 23 Feb 2017 17:00:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6JdGmunRGc1HYz81cAC8rJNIz92FtulFe1ZjQOAQohg=; b=wD3KuL9sb9mG0o3sdnIX9AP/eldM+J+e6BNvUksCYByNkIsbVvidAFvgaL+p+jaj6G cH79tSwJJJAzUWqEA9t/p7g2hxQIHbsuqMoiuXOobvPTC8oDCypx2IgJ9H6oStMUsqsE OFMJyjU5zw5Mj/NQrnLX1Lfpit2WxEWxdolXm3RUwIc4Hk4lCDSO1PvpE5+0mR5j2xoG PlfXfTa59u92yHKSJhexcxb8qDB4lLauwBRtDTLPJPW4bpiaN+H1Su7TNyXaYYo8D2kV aw4voiXbLVb0Uj6FglUN5+vH/+2kAasV7j+Z+sc3bjmI78RrVCr8/1rgrC5eUnY5hBQ3 JMdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6JdGmunRGc1HYz81cAC8rJNIz92FtulFe1ZjQOAQohg=; b=f5TEej4PxgVywJVafmjd46xz56gL/P5oxyyu4qhry78mevloAmRQBBzZtwq/cXDf4t DflQHV/kgeRNUq68i7UlLvTSlMFM1s/4aH/ioqJhwvKwKy+NAza8HaC16Z3iyrfQ4mQY h1wT/mGi8I/34AFrPVMFzkz83daRTNEkkWNXnv7gRNeT8S790g+WfRAZoFdZayRiEeid 20mXg65Q/FBYU+PiN+f8qypauLiYWQvlMAQlwdlTESdw/Ja4860o9fYLjkBBRmhujvcx KmXkVGTg0ir5UOsUrqD0SLAs6/VdRe6t02MMQMxg60J4jdW1K5/Bb02yy5yGVdvLF+e7 QYqg==
X-Gm-Message-State: AMke39lle0dSzmEt0JSghK6qc6pJ5nKHJriHI0AsRIavaPHTaIlp/wqWoGnaxzUu4X1zu6xU
X-Received: by 10.55.177.133 with SMTP id a127mr37947493qkf.301.1487898022839; Thu, 23 Feb 2017 17:00:22 -0800 (PST)
Received: from [192.168.8.100] ([181.201.193.82]) by smtp.gmail.com with ESMTPSA id g15sm2416640qte.58.2017.02.23.17.00.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 17:00:22 -0800 (PST)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <4E2A8068-E76C-4A06-9FCB-3F18775C7E96@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 23 Feb 2017 22:00:18 -0300
In-Reply-To: <CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520@CY1PR0301MB0842.namprd03.prod.outlook.com>
To: Andrei Popov <Andrei.Popov@microsoft.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> <CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520@CY1PR0301MB0842.namprd03.prod.outlook.com>
X-Mailer: Apple Mail (2.3259)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="94eb2c064c7c20051105493c41f9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/cV2AooGqpRhfSkNbZA5Ep_TMBZ0>
Cc: IETF Tokbind WG <unbearable@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>
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 01:00:26 -0000

I think in the federated case having the IDP support the same or a superset of the RP algorithms is not unreasonable.  
It might be worth reminding people in a implementation note to have logging for unsupported alg ekm size errors so that when a RP updates before the server it is easier to figure out what happened.
RP implementations should also allow disabling algs to allow for IDP servers to be updated first.

The idea of always using the EKM size negotiated for the provided Token binding seems like people are more likely to get that wrong in the clients by having multiple possible EKM size per alg.

It might be simpler for the server, but  if it supports the alg it will support the EKM size, so I don’t think it is a big advantage for the server. 

It may have advantages for the reverse proxy processing.

John B.
> On Feb 23, 2017, at 9:07 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> 
> Ø  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…
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org <mailto:Unbearable@ietf.org>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>

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