Re: [OAUTH-WG] regarding nested JWTs and security
Mike Jones <Michael.Jones@microsoft.com> Sat, 16 March 2013 03:17 UTC
Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4408A1F0D26 for <oauth@ietfa.amsl.com>; Fri, 15 Mar 2013 20:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiyOhpkiZ+6f for <oauth@ietfa.amsl.com>; Fri, 15 Mar 2013 20:17:57 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9091F0C74 for <oauth@ietf.org>; Fri, 15 Mar 2013 20:17:56 -0700 (PDT)
Received: from BL2FFO11FD001.protection.gbl (10.173.161.204) by BL2FFO11HUB011.protection.gbl (10.173.161.117) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sat, 16 Mar 2013 03:17:49 +0000
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sat, 16 Mar 2013 03:17:49 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sat, 16 Mar 2013 03:17:48 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: IETF oauth WG <oauth@ietf.org>, Jeff Hodges <Jeff.Hodges@KingsMountain.com>
Thread-Topic: [OAUTH-WG] regarding nested JWTs and security
Thread-Index: Ac4h9NW8GeA4NUyhwUWvRyDR+5HaGg==
Date: Sat, 16 Mar 2013 03:17:48 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367530168@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367530168TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(46102001)(47736001)(63696002)(51856001)(59766001)(54356001)(55846006)(5343635001)(44976002)(56776001)(31966008)(74502001)(50986001)(47446002)(47976001)(53806001)(77982001)(20776003)(80022001)(79102001)(4396001)(54316002)(56816002)(33656001)(76482001)(74662001)(49866001)(512874001)(65816001)(16406001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB011; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0787459938
Subject: Re: [OAUTH-WG] regarding nested JWTs and security
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Mar 2013 03:17:59 -0000
Thanks again for the thorough and useful feedback, Jeff. I’ll work on incorporating it in the next JWT draft. It was great seeing you in Orlando! -- Mike From: =JeffH Sent: March 15, 2013 10:11 AM To: IETF oauth WG Subject: Re: [OAUTH-WG] regarding nested JWTs and security During the OAuth 2nd session at IETF-86 orlando, after I mentioned the sign-then-encrypt considerations at the mic, Brad Hill pointed out that the below paper is perhaps an even more fundamental reference for the sigh-then-encrypt composition than the Davis paper I pointed to in the below attached message back in Dec-2012.. Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm (2007) Bellare & Namprempre http://eprint.iacr.org/2000/025.pdf After having talked with Mike Jones f2f earlier in the week about this stuff, during which he indicated he believed that these issues are addressed in the JWT spec, I looked at draft-ietf-oauth-json-web-token-06 and note that the last paragraph of the security considerations says.. While syntactically, the signing and encryption operations for Nested JWTs may be applied in any order, normally senders should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions. ..which certainly touches upon the issue(s), but could arguably contain more rationale. Though, if you wish the spec to be terse (as above) you should probably at least reference Davis (which is resonably approachable) and Bellare & Namprempre (which is a formal proof). Also, in terms of linkages between signing and encrypting wrappers, it seems that if one includes at least an audience claim in the JWT Claims Set, in a signed & encrypted JWT (aka "Nested JWT"), and the receiver of the JWT checks the audience and does not rely on the JWT if it does not identify them, then you are arguably in ok shape. If the JWT includes both subject and audience claims, that would be best. It may be a good idea to note this, since in the JWT spec all claims are optional, and incorporation of (and reliance on) JWT claims is left to JWT profiles. I.e., there arguably should be advice to JWT profile authors regarding security properties resulting from incorporation (or not) of various JWT claims. HTH, =JeffH ------ https://www.ietf.org/mail-archive/web/oauth/current/msg10326.html [OAUTH-WG] regarding nested JWTs and security From: =JeffH <Jeff.Hodges@KingsMountain.com> Date: Fri, 21 Dec 2012 15:07:35 -0800 To: IETF oauth WG <oauth@ietf.org> "nested JWTs" are only nominally defined in draft-ietf-oauth-json-web-token-05 (and the term is missing from the terminology section). the JWT spec implies that "signing and then encrypting" and "encrypting and then signing" are equivalent. however they aren't in various ways. Axel already raised this point in.. Re: [jose] encrypting AND signing a token https://www.ietf.org/mail-archive/web/jose/current/msg01269.html ..and cited this paper (worth citing again).. Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML Don Davis http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.7379&rep=rep1&type=pdf One has to carefully compose signing and encryption in order to avoid various vulnerabilities detailed in the latter. I agree with Axel that there should be one carefully designed way to craft a signed and encrypted JW*. Note that in the JSMS draft (draft-rescorla-jsms-00; an early input into what became the JOSE WG), sign & encrypt composition is declared.. > 4.6. Composition > > This document does not specify a combination signed and encrypted > mode. However, because the contents of a message can be arbitrary, > and encryption and data origin authentication can be provided by > recursively encapsulating multiple JSMS messages. In general, > senders SHOULD sign the message and then encrypt the result (thus > encrypting the signature). This prevents attacks in which the > signature is stripped, leaving just an encrypted message, as well as > providing privacy for the signer. ..tho that's a drafty draft and I didn't review carefully enough to determine whether it addresses the need for sign and encrypt to cross-refer (see S4.3 in the paper). HTH, =JeffH _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth