Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

John Bradley <ve7jtb@ve7jtb.com> Thu, 27 July 2017 21:40 UTC

Return-Path: <ve7jtb@ve7jtb.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 55274131DA4 for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 14:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 stjjDaXFgh50 for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 14:40:12 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 C15EA131CEB for <oauth@ietf.org>; Thu, 27 Jul 2017 14:40:11 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id s6so80096783qtc.1 for <oauth@ietf.org>; Thu, 27 Jul 2017 14:40:11 -0700 (PDT)
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=lRqINnBfSDKOYnRH/pIecXdzOUPgrVS7Wtps9cq/gWo=; b=X/yXZ9qF5YraVfFWXAcUxeYtutbPOYYr6pA23PqzjzVpdgxh0aBHxAkV2HftLpaQQZ GLjrzUzx2lKxPLi2jW6CwvIMX8VH1CXDM7kC2mBnJBx10vyq4xrMLuQ76tLAQkLsWLga lkTLdG8fYGkR3cwh9x8BELAjCKGV3tQ+ZfBcLXGsfRrv/2kwTSVs0H9dv0EWCcZNBhMj nVM3AWjxuUoMP7ovKNIJbnPiSKPWapEjC8yKnFU97T3AIFUw5CSssRLgWnMm8wD4KlRb f8zR6wkkW07DHSp9kffABnPqgkFZrmOevRwyfw+eZfX+evl92cU2wOQIg4Dn+7ZCNXqC c6cA==
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=lRqINnBfSDKOYnRH/pIecXdzOUPgrVS7Wtps9cq/gWo=; b=J2xNz9G7mBWFoGrfcuuf9TACZXUeSMfSeZq58Ps5b0/Dhst+UhbH2+RHwMaGUDkdJ3 6iF/nPhWJ5zg7v5J4NpTBNiF+xwtQHdlQyhPuvbNA5ASRcrZJ9BG401LPAzg5XbGUZtT nn4Z4ET39fjBIXjpKXoNWPXT1yms4SMpeOrT/SU3gswszkYeYfYkW4D097logYAnW6uT fXeUtb/WCn/mhUT9D6ib9oBkPZ76j+FAxFfL2C1ZBIymgjyeFKWA+K37qKkpTQNFAdq+ 99MSeHxIu9Q1IYwVUuaG89ZBti1+t3i0oL6j7WtrDAnHTr8TkomjHOVs1PWkWDqHJD7T LTew==
X-Gm-Message-State: AIVw110RD0Ol3i4L1o45gtP7b5r+sK2NOjPMNqEKbEDp0em2FcBVOGbL o9OkwLjnA635DQ5VOARdOw==
X-Received: by 10.200.3.135 with SMTP id t7mr7593721qtg.216.1501191610483; Thu, 27 Jul 2017 14:40:10 -0700 (PDT)
Received: from [192.168.86.103] ([191.115.36.222]) by smtp.gmail.com with ESMTPSA id m123sm13847245qke.12.2017.07.27.14.40.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 14:40:09 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 27 Jul 2017 17:40:02 -0400
In-Reply-To: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>, oauth <oauth@ietf.org>, "jose@ietf.org" <jose@ietf.org>
To: Phil Hunt <phil.hunt@oracle.com>
References: <CA+k3eCRT_iuLHYrLxz+tf1MT9L9XG2jV0D0anC0h5w7A_ujEdQ@mail.gmail.com> <CAOASepOjYBYoKYEVvCLMzZgsdyGhr2LOB-dNqekxsKFm_gxixg@mail.gmail.com> <CA+k3eCS-Va2AvzRhWia_ETqSDYUMBOoi=sY3jg7TbJFhhuVnZA@mail.gmail.com> <CAOASepMaeS8WrCMb+WHV0FC2_w3f0KnY5XuDsuWJhAW2ayfryQ@mail.gmail.com> <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f4030435c300b6249e05555368f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/agwTPeym3vUFIFFCHruLzHFwEhU>
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 27 Jul 2017 21:40:17 -0000

Not that I am against the general desire for JWT not to be confused, but the attack surface for someone to take a sec event from one context and replay it as a id_token to login is very small and if the client is correctly configured would not work as it is now.

The only way you could replay the sec event JWT is via the implicit flow.   The other flows would require a malicious AS and at that point you have bigger problems with a compromised token endpoint.

If you were to create a implicit response with the sec event token that has the correct issuer and aud, connect requires that nonce value from the request be present in the id_token.   This would require that the attacker somehow get the AS to put not only the claim but the correct value from the request into the token.

All in all I think that it is more likely (not 100% I admit) that a client will do that rather than checking the typ or a new crit JWT header parameter.

I am all for a general solution for this but I think the issue with Connect is overstated sometimes.

John B.
 
> On Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> We have the use case in SECEVENTS where a logout event (e.g. OIDF backchannel logout) is extremely close to an ID_TOKEN. 
> 
> Older relying parties who are do not yet support logout could be tricked into accepting a logout assertion as an ID_TOKEN since they are too similar, and  because a valid ID_TOKEN parser is in theory allowed to ignore claims it does not understand (e.g. “events”) - leading to a possible erroneous acceptance of the logout event AS and ID_TOKEN.
> 
> Because of this the issue of distinguishing classes or types of JWTs emerged.
> 
> We discussed a number of differentiators like “aud”, “typ”, “crit", etc that would help.  But that really lead to the idea there there should be some best practices in the JWT BCP covering the issue(s).
> 
> Phil
> 
> Oracle Corporation, Identity Cloud Services Architect & Standards
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com <mailto:npmccallum@redhat.com>> wrote:
>> 
>> Even after reading the whole section, I still don't understand the
>> problem. Yes, a class of attack could exist where an attacker
>> substitutes a valid JWT from one security context into another
>> context. But isn't this resolved by audience validation?
>> 
>> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>> <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
>>> The draft describes it in
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=> 
>>> 
>>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.com <mailto:npmccallum@redhat.com>>
>>> wrote:
>>>> 
>>>> What class of attacks is this trying to prevent? I frankly don't see a
>>>> problem with confusing different types of JWT. But I may just be
>>>> ignorant.
>>>> 
>>>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>>>> <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
>>>>> During the first WG meeting last week I asked if use of the JOSE "crit"
>>>>> (Critical) Header Parameter had been considered as a recommendation for
>>>>> preventing confusion of one kind of JWT for another. Time was running
>>>>> short
>>>>> in the meeting so there wasn't much discussion and it was requested that
>>>>> I
>>>>> take the question to the list. And so here on the list is that.
>>>>> 
>>>>> Section 3.9 of the JWT BCP draft now recommends explicit typing using
>>>>> the
>>>>> "typ" JWS/JWE header parameter but does concede that 'the use of
>>>>> explicit
>>>>> typing may not achieve disambiguation from existing kinds of JWTs, as
>>>>> the
>>>>> validation rules for existing kinds JWTs often do not use the "typ"
>>>>> header
>>>>> parameter value.'  And the recommendations for how to use the Type
>>>>> Header
>>>>> Parameter in JWT strongly suggest that it's not currently being used for
>>>>> any
>>>>> validation.
>>>>> 
>>>>> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
>>>>> signal
>>>>> the type/intent/profile/application of a JWT could achieve
>>>>> disambiguation
>>>>> even in validation of existing kinds of JWTs. The critical header lists
>>>>> other headers which must be understood and processed by the receiver and
>>>>> that the JWS/JWE is invalid if those listed aren't understood. So a new
>>>>> type/profile of JWT that uses the "crit" header would produce JWTs that
>>>>> would be rejected even by existing applications of JWT validation (that
>>>>> actually implement "crit" properly anyway).
>>>>> 
>>>>> The JWT BCP could suggest the use of "crit" in conjunction with a
>>>>> profile/application/type specific header. Or it could provide a bit more
>>>>> of
>>>>> a framework like defining a registering a new JOSE header "p" (strawman
>>>>> of p
>>>>> as a very short name for profile) and create a registry for its values.
>>>>> A
>>>>> JWT header using that approach might look like the following where the
>>>>> value
>>>>> 1 is registered as some cool new JWT profile/application. The consumer
>>>>> of
>>>>> such a JWT would have to understand and process the "p" header, which
>>>>> would
>>>>> mean checking that it had the value expected.
>>>>> 
>>>>>     {
>>>>>      "alg":"ES256",
>>>>>      "crit":["p"],
>>>>>      "p":1
>>>>>     }
>>>>> 
>>>>> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
>>>>> access token or OIDC id_token because the "p" header isn't known or
>>>>> understood but is marked as critical.
>>>>> 
>>>>> To me, that seems like an approach to preventing confusion that has more
>>>>> teeth than the "typ" header. Which is why I asked about it last week and
>>>>> am
>>>>> now bringing it to the list.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged
>>>>> material for the sole use of the intended recipient(s). Any review, use,
>>>>> distribution or disclosure by others is strictly prohibited.  If you
>>>>> have
>>>>> received this communication in error, please notify the sender
>>>>> immediately
>>>>> by e-mail and delete the message and any file attachments from your
>>>>> computer. Thank you.
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org <mailto:jose@ietf.org>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e= 
>>>>> 
>>> 
>>> 
>>> 
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>>> material for the sole use of the intended recipient(s). Any review, use,
>>> distribution or disclosure by others is strictly prohibited.  If you have
>>> received this communication in error, please notify the sender immediately
>>> by e-mail and delete the message and any file attachments from your
>>> computer. Thank you.
>> 
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org <mailto:jose@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e= 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth