From nobody Wed Aug 2 11:47:48 2017 Return-Path: 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 0428913178D for ; Wed, 2 Aug 2017 11:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Kljao5d62WTC for ; Wed, 2 Aug 2017 11:47:43 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E74312009C for ; Wed, 2 Aug 2017 11:47:42 -0700 (PDT) X-AuditID: 12074424-27bff700000046b0-c6-59821e4d914a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2F.52.18096.D4E12895; Wed, 2 Aug 2017 14:47:41 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v72Ilejt028113 for ; Wed, 2 Aug 2017 14:47:41 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v72Ildw0018726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Aug 2017 14:47:40 -0400 To: jose@ietf.org References: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> From: Justin Richer Message-ID: <0b4ad735-ce1e-c0b6-480c-1a3121ff0335@mit.edu> Date: Wed, 2 Aug 2017 14:47:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> Content-Type: multipart/alternative; boundary="------------BB56CD873B7A362571AB5EF8" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixG6nrusr1xRpsHiansWaNd1MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWDjzLWPB01eMFasaP7M2MF6fwdjFyMkhIWAi8XVqL3sXIxeH kMBiJolzSz8xQThHGCXuTn8O5bxjktj+eQlzFyMHh7BAiMSqGREg3SICghJvFk9hg6i5ySTx 9cwbFpAEm4CqxPQ1LUwgNq+AlcS0s/eYQWwWARWJTZ2v2UFsUYEYiWsz77BC1AhKnJz5BKyX U8BO4tbnPWwgNrNAmMSFnnZ2CFtc4taT+UwTGPlnIWmZhaRsFpIyCNtMYt7mh8wQtrxE89bZ QDYHkK0msaxVCVl4ASP7KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJNjOAAd1HZ wdjd432IUYCDUYmHt+NGY6QQa2JZcWXuIUZJDiYlUV7FnvpIIb6k/JTKjMTijPii0pzU4kOM EhzMSiK8Z1mbIoV4UxIrq1KL8mFS0hwsSuK84hqNEUIC6YklqdmpqQWpRTBZGQ4OJQnehbJA jYJFqempFWmZOSUIaSYOTpDhPEDDn4HU8BYXJOYWZ6ZD5E8xWnIc+n3iOxPHMTDZ9P3jdyYh lrz8vFQpcd5/MkANAiANGaV5cDNBCSvh7WHTV4ziQC8K83KBjOUBJju4qa+AFjIBLfxT1wiy sCQRISXVwKj1sn/zlkU7umXO3mVvE3N+FT6xt09+k+WrKYobWndfZt/+xdnm8a8M3yd6pmoK KhcK+brWbtIs6NCw3NjjaKCRs5lrM8upywWqkrUvjZjv+jjGCoVc4u678quqOf82e87XdZ9d k+q2rygSXaVUKhMwp/L/X866P4pORZeeci265+7K0utwWYmlOCPRUIu5qDgRAHZXIUEzAwAA Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:47:46 -0000 This is a multi-part message in MIME format. --------------BB56CD873B7A362571AB5EF8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'd like to point out once again that this would all be solved by keeping all the semantics of the event, like the issuer and subject of logout, inside the event{} object itself. *shrug* -- Justin On 7/27/2017 5:19 PM, Phil Hunt 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 > phil.hunt@oracle.com > >> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum >> > 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 >> > 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= >>> >>> >>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum >>> > >>> 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 >>>> > 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 >>>>> 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 >> 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= >> > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------BB56CD873B7A362571AB5EF8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I'd like to point out once again that this would all be solved by keeping all the semantics of the event, like the issuer and subject of logout, inside the event{} object itself.

*shrug*

 -- Justin


On 7/27/2017 5:19 PM, Phil Hunt 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
phil.hunt@oracle.com

On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <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> 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=

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <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> 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
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
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= 



_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--------------BB56CD873B7A362571AB5EF8--