Re: [jose] encrypting AND signing a token
Dick Hardt <dick.hardt@gmail.com> Tue, 06 November 2012 17:14 UTC
Return-Path: <dick.hardt@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E1521F8522 for <jose@ietfa.amsl.com>; Tue, 6 Nov 2012 09:14:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level:
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3w9dtAFIYqT for <jose@ietfa.amsl.com>; Tue, 6 Nov 2012 09:14:23 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95EA821F88A3 for <jose@ietf.org>; Tue, 6 Nov 2012 09:14:22 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id d4so469902eek.31 for <jose@ietf.org>; Tue, 06 Nov 2012 09:14:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=HERORWSWbV1Ylzr1Q4rwU07p2W4Sx2BBRUL8tC0U1ZY=; b=QNHamZ9DhB6SEC5Esmbgru00gnP0ssvlj285zcsAeHt8wL+m/KDHIEUfGrJ0rxa6Fp 9UxLKnhG9ltTiiQ9TxDivzY40pgFeMQa2Ey1aNaGV/o3MIOA2BbPzt3/wWjNcT9AMQO/ eB7orYNC27r4szZyjczEtj5ENcoAgUH1+wm9Mhm5hvdEh++dJuoqG6tT8RGYJhQcN+Tt BVdY3ZqHQI49TlLlo5RQttLRm9TdxnndL1qFJskhNHcfvAZ+RyCQfdz2qZY91TRiYCWd wA+sKBhAJtCfbFdgHWlxCGMfj7JJzNdW8TbzFSjiZ1o+tsMTlviKwlnqjdxbEa7p2i/7 fwpw==
Received: by 10.14.225.71 with SMTP id y47mr5730224eep.0.1352222061424; Tue, 06 Nov 2012 09:14:21 -0800 (PST)
References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <E73A223A-6546-4A3A-A839-8627B3DBCB8F@gmail.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> <8A51F18A-9598-43EA-95DE-DB79029C305B@ve7jtb.com>
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <8A51F18A-9598-43EA-95DE-DB79029C305B@ve7jtb.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 06 Nov 2012 09:19:25 -0800
Message-ID: <8933406288859862861@unknownmsgid>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Jim Schaad <ietf@augustcellars.com>, Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] encrypting AND signing a token
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2012 17:14:24 -0000
John, do you have any comments on the original post? Telling me I can do what I already described is not useful. -- Dick On 2012-11-06, at 8:58 AM, John Bradley <ve7jtb@ve7jtb.com> wrote: > I take your point, but there are a number of cases where people are creating security tokens using a pre-shared key. > > Given that a JWE using KeyWrap & Encryption with integrity and a JWS using HS256 provide the same level of verification of the sender. > They are equivalent , though nether of them are signatures. > > If HS256 is good for you then perhaps A256KW + A128CBC+HS256 might be good if you need to add encryption based on the same key. > > John > On 2012-11-06, at 10:54 AM, "Jim Schaad" <ietf@augustcellars.com> wrote: > >> <personal> >> >> Only if you have a really loose definition of signing - it gives you an >> integrity check but not origination which is usually implied by the term >> signing >> >> Jim >> >> >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Tuesday, November 06, 2012 10:50 AM >>> To: Dick Hardt >>> Cc: Jim Schaad; 'Mike Jones'; jose@ietf.org >>> Subject: Re: [jose] encrypting AND signing a token >>> >>> I should also note that with symmetric keys, the alg option of A128KW with >>> an enc of A128CBC+HS256 effectively gives you signing and encryption in a >>> single JWE. >>> >>> That doesn't solve the asymmetric signing case, but may work for some >>> people . >>> >>> John B. >>> On 2012-11-06, at 10:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote: >>> >>>> SAML performs this as separate operations. >>>> >>>> Now in some cases the assertion is signed then encrypted and then the >>> message signed to deal with the AESCBC padding oracle attack. >>>> >>>> There is non technical issue around the use of qualified signatures in >> cases >>> where non repudiation is required. >>>> Signing a encrypted object has different connotations than signing a >>> unencrypted one. >>>> >>>> I don't know what the status of a combined operation would be. It is >>> probably not relevant to your use case. >>>> >>>> At IETF #83 I presented including ECDH-SS as an encryption option as it >>> provides sender verification. >>>> I think that would answer your use case, depending on how you feel about >>> EC. >>>> >>>> The work group rejected adding that algorithm at the time on the grounds >>> that it is not used in places where it is supported. >>>> ECDH-ES is defined and is considered more secure than ECDH-SS mostly >>> because it is harder to get wrong. >>>> >>>> I am not recommending revisiting the issue, but it would be a way to >>> address the composite use case. >>>> >>>> Despite being a Canadian I am not shilling for certicom. Just saying. >>>> >>>> John B. >>>> On 2012-11-04, at 2:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote: >>>> >>>>> Thanks Jim. An interesting historical reference. >>>>> >>>>> In my use case, who signed or who the token is for is not a secret. The >>> payload needs to be kept a secret. >>>>> >>>>> Does no one sign and encrypt SAML tokens? >>>>> Is this not a common use case? >>>>> >>>>> If it does need to be solved, it would seem to me that a standards body >>> would be the place to have lots of eyes look at how to sign and encrypt a >>> token so that people do not do naive sign and encrypt. >>>>> >>>>> Q: does anyone else need to sign and encrypt? >>>>> >>>>> -- Dick >>>>> >>>>> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" <ietf@augustcellars.com> >>> wrote: >>>>> >>>>>> <personal> >>>>>> >>>>>> I would note that the original PKCS#7 specifications had a mode that >>>>>> provided a similar sign and encrypt as a single operation mode. >>>>>> When the >>>>>> PKCS#7 specifications where adopted by the IETF as part of the CMS >>>>>> work, this mode was discussed and very deliberately dropped because >>>>>> of numerous security problems that had been found. These included >>>>>> (but are not limited >>>>>> to) the fact that it was signed or who signed it was sometimes a >>>>>> security leak. Also there were attacks where the signed and >>>>>> encrypted mode could be converted to just an encrypted mode. >>>>>> >>>>>> I would think that there would be a need for a very detailed >>>>>> security analysis that we are not prepared to do in order to support >>>>>> a signed and encrypted mode. >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>> Behalf Of Dick Hardt >>>>>>> Sent: Friday, November 02, 2012 12:30 PM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] encrypting AND signing a token >>>>>>> >>>>>>> Not only is my original token increasing in size by 4/3, I am also >>>>>>> adding another header, payload and signature. >>>>>>> >>>>>>> One of the objectives of JWT was to enabled compact tokens. It >>>>>>> would seem that we should be able to support both signing and >>>>>>> encryption of the same token. >>>>>>> >>>>>>> All the encryption use cases I can think of involving asymmetric >>>>>>> keys >>>>>> would >>>>>>> also require signing with the senders private key. >>>>>>> >>>>>>> My suggestion is to be explicit in what the algorithm etc. is used >> for: >>>>>>> >>>>>>> Rather than "alg" and "enc", we have: >>>>>>> >>>>>>> "algs" - algorithm for token signing "algk" - algorithm for content >>>>>>> management key encryption "alge" - >>>>>> algorithm >>>>>>> for payload encryption >>>>>>> >>>>>>> Similiarly, >>>>>>> >>>>>>> "kids" - key id for signing >>>>>>> "kidk" - key id for content managment key encryption >>>>>>> >>>>>>> We could probably make these three or even two letter codes if you >>>>>>> want to save a couple bytes. >>>>>>> >>>>>>> -- Dick >>>>>>> >>>>>>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>>>>>> <Michael.Jones@microsoft.com> >>>>>>> wrote: >>>>>>> >>>>>>>> The way you put it brings one straightforward solution to mind. >>>>>>>> Solve >>>>>> 1-3 >>>>>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>>>>> >>>>>>>> I do understand that the 4/3 space blowup-of double base64url >>>>>>>> encoding >>>>>>> the JWE motivates your earlier proposal about nested signing. (See >>>>>>> Dick's >>>>>>> 10/29/12 message "[jose] signing an existing JWT".) I also >>>>>>> understand >>>>>> that if >>>>>>> you could do integrity with the asymmetric signature then the >>>>>>> integrity provided by the JWE itself may be redundant. I don't >>>>>>> have a specific >>>>>> proposal >>>>>>> on how to do that. >>>>>>>> >>>>>>>> -- Mike >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>>> Behalf Of Dick Hardt >>>>>>>> Sent: Friday, November 02, 2012 8:22 AM >>>>>>>> To: jose@ietf.org >>>>>>>> Subject: [jose] encrypting AND signing a token >>>>>>>> >>>>>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a >>>>>>>> real >>>>>>> world problem. >>>>>>>> >>>>>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from >>>>>>>> Bob and then Alice gives token to Charlie) >>>>>>>> 2) Alice must be prevented from reading the token. (token needs to >>>>>>>> be >>>>>>>> encrypted) >>>>>>>> 3) Bob and Charlie can share a symmetric key. >>>>>>>> >>>>>>>> I can solve this with JWE. >>>>>>>> >>>>>>>> Now let's add another condition. >>>>>>>> >>>>>>>> 4) Charlie wants non-repuditation that Bob created the token. >>>>>>>> 5) Bob has a private key and a public key >>>>>>>> >>>>>>>> I don't see how to do this using JWE. It seems I have to sign the >>>>>>>> same >>>>>> token >>>>>>> I had previously with JWS. This seems inefficient since I should be >>>>>>> able >>>>>> to >>>>>>> replace the JWE integrity computation done with the symmetric key >>>>>>> with the private key -- but the "alg" parameter is the same in both >>>>>>> encrypting and signing. >>>>>>>> >>>>>>>> Now let's expand this to replacing the symmetric key with a >>>>>> public/private >>>>>>> key pair for encryption. Bob encrypts with Charlies public key and >>>>>>> signs >>>>>> with >>>>>>> Bob's private key (we also need to make sure we are not doing naive >>>>>>> encryption and signing here, would be a really useful to specify >>>>>>> what >>>>>> needs >>>>>>> to be done there). Now we need to have parameters for both >>>>>>> public/private key pairs in the header. >>>>>>>> >>>>>>>> Am I missing something here? >>>>>>>> >>>>>>>> Seems like we can do this if we change the header parameters to >>>>>>>> specify >>>>>> if >>>>>>> they ("alg", "kid", et.c) are for token signing, payload encryption >>>>>>> or >>>>>> content >>>>>>> key encryption. >>>>>>>> >>>>>>>> -- Dick >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>> >> >
- [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Mike Jones
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Jim Schaad
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Jim Schaad
- Re: [jose] encrypting AND signing a token Mike Scott
- Re: [jose] encrypting AND signing a token Axel.Nennker
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Axel.Nennker
- Re: [jose] encrypting AND signing a token Axel.Nennker
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token Jim Schaad
- Re: [jose] encrypting AND signing a token Richard L. Barnes
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Dick Hardt