[Openid-specs-ab] jku and x5u

John Bradley ve7jtb at ve7jtb.com
Thu May 30 11:49:33 UTC 2013


We can add a security consideration later about why trusting x5c, x5u or jwk can be dangerous without verification.

On 2013-05-30, at 6:05 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:

> It turns out we’d already addressed the issue raised by this thread in the specs a good while ago.  Messages, Basic, and Implicit all say:
>  
> ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk header parameter fields. Instead, key values and key references used for ID Tokens are communicated in advance using Discovery and Registration parameters.
>  
> I’m prone to leave that text as-is and call it good.
>  
>                                                             -- Mike
>  
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Tuesday, May 28, 2013 4:59 PM
> To: Breno de Medeiros
> Cc: Mike Jones; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] jku and x5u
>  
> How about:
>  
> "The jku (JWK Set URL) header parameter is a URI [RFC3986] that refers to a resource for a set of JSON-encoded public keys, one of which corresponds to the key used to digitally sign the JWS. The keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The protocol used to acquire the resource MUST provide integrity protection and source authenticity; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be validated, as per Section 3.1 of HTTP Over TLS [RFC2818].  Key sets are configured out of band.  The sender SHOULD NOT include the jku header parameter unless it is required by a non Connect recipient.  Connect recipients MUST ignore the jku header parameter, and only use trusted key material.  Use of this header parameter is OPTIONAL."
>  
>  
> On 2013-04-03, at 4:01 PM, Breno de Medeiros <breno at google.com> wrote:
> 
> 
>  
>  
> 
> On Wed, Apr 3, 2013 at 12:30 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> The “issuer” language is overly specific for the JOSE specs because “issuer” is a JWT concept – not a JOSE one.  Do you want to suggest a generalization of the language for the JOSE specs that doesn’t assume that the signed/encrypted content is a JWT?
>  
> We will need to introduce the concept of signer/holder of keys there then. I don't think JOSE should talk about keys w/o talking about how to establish beliefs about who owns those keys.
>  
>  
> Suggesting language for the JWT spec and/or Connect specs is also OK.
>  
>                                                                 -- Mike
>  
> From: Breno de Medeiros [mailto:breno at google.com] 
> Sent: Wednesday, April 03, 2013 10:48 AM
> 
> To: Mike Jones
> Cc: John Bradley; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] jku and x5u
>  
>  
> Sorry, pressed 'send' too soon. Ignore the recommendation part for 'remove the 'The protocol used to acquire ...' -- I realize now that it address non-HTTP response mechanisms. The recommended text changes (in bold) already reflect that understanding.
>  
> 
> On Wed, Apr 3, 2013 at 10:47 AM, Breno de Medeiros <breno at google.com> wrote:
> Today the language is:
> 
> "The jku (JWK Set URL) header parameter is a URI [RFC3986] that refers to a resource for a set of JSON-encoded public keys, one of which corresponds to the key used to digitally sign the JWS. The keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. Use of this header parameter is OPTIONAL."
> 
> I recommend removing the "The protocol used to acquire the resource MUST provide integrity protection;" since it's redundant w/ " an HTTP GET request to retrieve the certificate MUST use TLS" and doesn't address the threat of binding it.
> 
> "The jku (JWK Set URL) header parameter is a URI [RFC3986] that refers to a resource for a set of JSON-encoded public keys, one of which corresponds to the key used to digitally sign the JWS. The keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The protocol used to acquire the resource MUST provide integrity protection and source authenticity; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. In addition, the client MUST validate that the Issuer of the JWT (indicated by the 'iss' in the JWS envelope) is also the Issuer of the retrieved JWK Set. The mechanism for performing this validation is specified by application, but a compliant library MUST support at least the following: [Well-Known Location Method, PKI method], described below.Use of this header parameter is OPTIONAL."
>  
> 
> On Wed, Apr 3, 2013 at 10:32 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> Is there specific language that you'd like to suggest be added to the JOSE specs in that regard?
> 
>                                 -- Mike
> 
> -----Original Message-----
> From: Breno de Medeiros [mailto:breno at google.com]
> Sent: Wednesday, April 03, 2013 10:29 AM
> To: Mike Jones
> Cc: John Bradley; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] jku and x5u
> 
> On Wed, Apr 3, 2013 at 10:26 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> > I think people have already agreed that, for Connect, we can say that
> > key locators aren't to be used in the tokens.  Is there an additional
> > change beyond that that you were advocating, Breno?
> 
> No. I am worried, however, that the JOSE specs introduce the field w/o clear prescriptions about when safe to process it. If someone layers an OpenIDConnect library on top of a JWT/JWS/... whatever substrate, will the caller have a simple way to _deterministically_ infer how the keys were bound to the issuer?
> 
> >
> > -- Mike
> >
> > From: Breno de Medeiros
> > Sent: Wednesday, April 3, 2013 10:23 AM
> > To: John Bradley
> > Cc: openid-specs-ab at lists.openid.net
> >
> > On Wed, Apr 3, 2013 at 10:17 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> >> I wasn't recommending changing the discovery mechanism.   We support out
> >> of band configuration.   There are a number of ways to do that, including
> >> typing it in.
> >>
> >> One possible way is to use some sort of meta data from a federation.
> >> That would require an extension document ad is out of scope.
> >>
> >> We decided not to support discovery for domains without web servers on the
> >> top level.   I think Tim was the main proponent of dropping discovery
> >> support for other issuers.
> >>
> >> For self issued there is no discovery the assertion is self contained.
> >
> > Right. The problem here is not OOB. This is always possible in a
> > federation. The problem is the prescription to parse jku in the
> > absence of PKI trust. That's a recipe for generalized insecurity.
> >
> >>
> >> John B.
> >> On 2013-04-03, at 2:06 PM, Breno de Medeiros <breno at google.com> wrote:
> >>
> >>> On Wed, Apr 3, 2013 at 10:03 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> >>>> self issued is a special case where the public key is provided in
> >>>> the envelope directly and validated against the sig the sub is
> >>>> derived from the public key.
> >>>>
> >>>> I don't think that is a problem.
> >>>>
> >>>> For IdP that publish a discovery document that is authoritative
> >>>> that specifies the jku url not the JWT.
> >>>>
> >>>> For idp who can't publish a discovery document RP will need to
> >>>> manually configure out of band as they do now for facebook and
> >>>> others, or there needs to be a trusted source of meta-data for those small IdP.
> >>>
> >>> I disagree that the benefit of creating a complex and likely
> >>> security-challenged discovery mechanism is worth the cost.
> >>>
> >>>>
> >>>> John
> >>>>
> >>>> On 2013-04-03, at 1:58 PM, Breno de Medeiros <breno at google.com> wrote:
> >>>>
> >>>>> On Wed, Apr 3, 2013 at 9:56 AM, Breno de Medeiros
> >>>>> <breno at google.com>
> >>>>> wrote:
> >>>>>> On Wed, Apr 3, 2013 at 1:54 AM,  <Axel.Nennker at telekom.de> wrote:
> >>>>>>> Here are two use cases that would not work under the
> >>>>>>> "${issuer}/.well-known/openid-configuration" assumption.
> >>>>>>>
> >>>>>>> 1)      The issuer has no control over the top level domain's files
> >>>>>>> e.g. you rented some hosting space at
> >>>>>>> https://geocities.yahoo.co.jp/KafkaTamura and this is the iss.
> >>>>>>> Kafka can not change the top level openid-configuration only
> >>>>>>>
> >>>>>>> https://geocities.yahoo.co.jp/KafkaTamura/.well-known/openid-con
> >>>>>>> figuration
> >>>>>>>
> >>>>>>> 2)      A self-issued OP on a phone
> >>>>>>> The issuer could dynamically register its keys or provide the
> >>>>>>> public key with the first token. The consumer would then ensure
> >>>>>>> that the key is the same in subsequent tokens.
> >>>>>>
> >>>>>> I am not interested in supporting either of these cases if it
> >>>>>> comes at the expense of generalized insecurity on the common
> >>>>>> case. If the spec wants to support these cases, it needs to be
> >>>>>> very careful on how to coach the language.
> >>>>>
> >>>>> And why can't _both_ of these cases be achieved though PKI-based means?
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> From: openid-specs-ab-bounces at lists.openid.net
> >>>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of
> >>>>>>> Tim Bray
> >>>>>>> Sent: Tuesday, April 02, 2013 11:55 PM
> >>>>>>> To: Hannes Tschofenig
> >>>>>>> Cc: <openid-specs-ab at lists.openid.net>
> >>>>>>>
> >>>>>>>
> >>>>>>> Subject: Re: [Openid-specs-ab] jku and x5u
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> From where I sit, the most obvious thing to do is look at the
> >>>>>>> issuer claim, resolve
> >>>>>>> ${issuer}/.well-known/openid-configuration, extract the jwk-url
> >>>>>>> claim, fetch the jwk, and validate using that.  For the kind of
> >>>>>>> consumer/internet stuff we do, wouldn't that nearly always be
> >>>>>>> the right choice?
> >>>>>>>
> >>>>>>> -T
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Apr 2, 2013 at 11:48 AM, Hannes Tschofenig
> >>>>>>> <hannes.tschofenig at gmx.net> wrote:
> >>>>>>>
> >>>>>>> Hi Tim,
> >>>>>>>
> >>>>>>> There are three ways to shuffle keys around:
> >>>>>>>
> >>>>>>> * per value: you include the key in the message
> >>>>>>> * per reference: you include a pointer to the key (e.g., a URL)
> >>>>>>> * out-of-band: here you just give the key a name without telling
> >>>>>>> where to
> >>>>>>> find it.
> >>>>>>>
> >>>>>>> Needless to say that you have to be careful with all three mechanisms
> >>>>>>> when
> >>>>>>> it comes to security.
> >>>>>>>
> >>>>>>> You are already thinking about a complete use case that goes beyond
> >>>>>>> what
> >>>>>>> these header parameters by itself are able to answer.
> >>>>>>>
> >>>>>>> Ciao
> >>>>>>> Hannes
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 04/02/2013 09:35 PM, Tim Bray wrote:
> >>>>>>>
> >>>>>>> Sorry, I'm probably failing to understand because I'm a crypto moron,
> >>>>>>> but if I want to use keys to validate a JWT allegedly from
> >>>>>>> example.com
> >>>>>>>
> >>>>>>> <http://example.com>, I'm not going to believe anything in the JWT
> >>>>>>> until
> >>>>>>> I've checked using example.com <http://example.com>'s keys, so why
> >>>>>>>
> >>>>>>>
> >>>>>>> should I believe the JWT's assertion about where to get the keys to
> >>>>>>> validate it?  -T
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Apr 2, 2013 at 11:27 AM, Mike Jones
> >>>>>>> <Michael.Jones at microsoft.com
> >>>>>>>
> >>>>>>> <mailto:Michael.Jones at microsoft.com>> wrote:
> >>>>>>>
> >>>>>>>   Yes, that's exactly it.  If you already know where the keys are or
> >>>>>>>   what they are (for instance, if you've established that information
> >>>>>>>   at registration time), there's no need to use these parameters.
> >>>>>>> But
> >>>>>>>   for some use cases, this is valuable information that can be
> >>>>>>>   dynamically provided.  (The Key ID ("kid") can also be dynamically
> >>>>>>>
> >>>>>>>   provided, if appropriate to the use case.)____
> >>>>>>>
> >>>>>>>   __ __
> >>>>>>>
> >>>>>>>                                                                    --
> >>>>>>>   Mike____
> >>>>>>>
> >>>>>>>   __ __
> >>>>>>>
> >>>>>>>   *From:*openid-specs-ab-bounces at lists.openid.net
> >>>>>>>   <mailto:openid-specs-ab-bounces at lists.openid.net>
> >>>>>>>   [mailto:openid-specs-ab-bounces at lists.openid.net
> >>>>>>>   <mailto:openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of
> >>>>>>>   *Tim Bray
> >>>>>>>   *Sent:* Tuesday, April 02, 2013 11:19 AM
> >>>>>>>   *To:* <openid-specs-ab at lists.openid.net
> >>>>>>>   <mailto:openid-specs-ab at lists.openid.net>>
> >>>>>>>   *Subject:* [Openid-specs-ab] jku and x5u____
> >>>>>>>
> >>>>>>>   __ __
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>   Almost certainly I'm just missing something obvious, but I'm having
> >>>>>>>   trouble understanding why the jku and x5u header claims exist.  The
> >>>>>>>   idea is I get a message and believe the message's assertion about
> >>>>>>>
> >>>>>>>   where I should go to get the cert to validate the message?  -T____
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Openid-specs-ab mailing list
> >>>>>>> Openid-specs-ab at lists.openid.net
> >>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Openid-specs-ab mailing list
> >>>>>>> Openid-specs-ab at lists.openid.net
> >>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> --Breno
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> --Breno
> >>>>> _______________________________________________
> >>>>> Openid-specs-ab mailing list
> >>>>> Openid-specs-ab at lists.openid.net
> >>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> --Breno
> >>
> >
> >
> >
> > --
> > --Breno
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> 
> --
> --Breno
> 
> 
>  
> -- 
> --Breno
> 
> 
>  
> -- 
> --Breno
> 
> 
>  
> -- 
> --Breno

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130530/025d7e04/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130530/025d7e04/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list