[Openid-specs-ab] Questions about multiple audiences for ID Tokens using MAC algorithms

Tim Bray tbray at textuality.com
Mon Oct 28 21:02:51 UTC 2013


D’oh, thanks.  For a second I thought we were looking at dupe keys.


On Mon, Oct 28, 2013 at 1:44 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  Yes, in the general case, the “aud” Claim value is a list of audiences.
> As a special case, it can (and typically is) single-valued.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Tim Bray [mailto:tbray at textuality.com]
> *Sent:* Monday, October 28, 2013 1:18 PM
> *To:* George Fletcher
> *Cc:* John Bradley; Mike Jones; openid-specs-ab at lists.openid.net
>
> *Subject:* Re: [Openid-specs-ab] Questions about multiple audiences for
> ID Tokens using MAC algorithms****
>
> ** **
>
> Hold on, you said “mulitple 'aud' values”.  In the same ID Token... is
> that allowed?!?****
>
> ** **
>
> On Mon, Oct 28, 2013 at 12:52 PM, George Fletcher <gffletch at aol.com>
> wrote:****
>
> Thanks for the clarifications! What about combining what John and Mike
> said into something like...
>
> ID Tokens containing a 'azp' value SHOULD be signed with an asymmetric
> key. The verification steps for ID Tokens signed with a MAC based algorithm
> containing either mulitple 'aud' values and/or an 'azp' value are
> unspecified and out-of-scope for this document.
>
> Thanks,
> George****
>
> On 10/28/13 2:33 PM, John Bradley wrote:****
>
> I think the point of signing is so that the audience can verify it.  In
> the case that the azp is different from the audience the azp the token
> should be treated as opaque to the azp party. ****
>
> I appreciate that clients may do content sniffing as they do in SAML in
> some cases.****
>
> ** **
>
> In general it is best for the AS to use a asymmetric signature all the
> time to get around these issues.****
>
> ** **
>
> The simple rule for symmetric keys is you is the one shared with the
> audience,  the use of azp should not impact that.  ****
>
> If that is to confusing I am OK with saying tokens containing azp MUST be
> signed with a asymmetric key and forget this corner case.****
>
> ** **
>
> I don't consider a token with azp one that necessarily has multiple
> audiences.  It is possible to have two or more audiences where one is also
> the azp, that defiantly needs asymmetric signing.****
>
> ** **
>
> John B.****
>
> ** **
>
> On Oct 25, 2013, at 6:04 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:****
>
>
>
> ****
>
> John, your reply didn’t answer the question about which Client ID would be
> used if the “aud” and “azp” values refer to different parties.  I could see
> arguments for either.****
>
>  ****
>
> Partly for that reason, I’m prone to have us say that the behavior is
> unspecified if a MAC algorithm is used and the “aud” is multi-valued or if
> an “azp” value is present that is different than the “aud” value.****
>
>  ****
>
> That would leave the door open to specify it later, but avoids us making
> important decisions about use cases we have no experience with now.****
>
>  ****
>
>                                                                 -- Mike***
> *
>
>  ****
>
> *From:* Torsten Lodderstedt [mailto:torsten at lodderstedt.net<torsten at lodderstedt.net>
> ]
> *Sent:* Friday, October 25, 2013 1:59 PM
> *To:* John Bradley
> *Cc:* Mike Jones; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Questions about multiple audiences for
> ID Tokens using MAC algorithms****
>
>  ****
>
>  ****
>
>
> Am 25.10.2013 um 21:40 schrieb John Bradley <ve7jtb at ve7jtb.com>:****
>
>  A token with a single audience that is different from the AZP is fine to
> integrity protect with mac as long as there the AZP is not expected to
> validate the token.  ****
>
>   ****
>
> I think this is only possible for id tokens issued via code grant type,
> right?****
>
> ** **
>
>  ****
>
> I personally think symmetric key management argues that it is not
> scalable.  However we should not preclude that use.
>
> Sent from my iPhone****
>
>
> On Oct 24, 2013, at 10:32 PM, Torsten Lodderstedt <torsten at lodderstedt.net>
> wrote:****
>
> Hi all,
>
> MAC as symmetric alg only makes sense (from a security perspective) for
> two parties. I consider sharing a symmetric key among more than two parties
> a bad design. So in my opinion this restriction makes sense.
>
> Wrt 5. Yes, we should tighten it.
>
> Regards,
> Torsten.****
>
>
>
> Mike Jones <Michael.Jones at microsoft.com> schrieb:****
>
> http://openid.bitbucket.org/openid-connect-core-1_0.html#IDTokenValidationcontains
> this text that George asked about in his review:****
>
> 7.  If the alg parameter of the JWT header is a MAC based algorithm such
> as HS256, HS384, or HS512, the octets of the UTF-8 representation of the
> client_secret corresponding to the client_id contained in theaud (audience)
> Claim are used as the key to validate the signature.Multiple audiences
> are not supported for MAC based algorithms.****
>
>  ****
>
> George wrote:****
>
> “Why not? Wouldn't the secret associated with the azp work for the client
> to validate the id_token?  If we want interoperability across the use of
> audience and azp we are going to need to describe how it works in an
> extension document. It is not clear from this spec how it is to work and I
> was on most of the calls:)”****
>
>  ****
>
> These questions arise:****
>
> 1.       Does anyone remember the history behind the highlighted
> sentence?  I’m pretty sure that this was written before we had an “azp”
> claim.****
>
> 2.       If there’s an “azp” claim and an “aud” claim and the values are
> different, which Client Secret would be the right one to use as the key
> value?  (George seems to be suggesting that it’s the one associated with
> the Client ID in the “azp” value.)****
>
> 3.       If we did want to relax the restriction prohibiting multiple
> audiences, which value would be used for the key?  And would all the
> parties that need to valid the ID Token signature actually have access to
> this value?****
>
> 4.       Or should we leave the text above as-is for now, and deal with
> this case as an extension later, if a need for it ever comes up?****
>
> 5.       If we’re not defining how multi-valued audiences would work with
> MAC signatures for now, should we also tighten this be requiring that any
> “azp” value that is include have the same value as the single-valued
> audience value?****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> ------------------------------
>
> 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****
>
>    ** **
>
> ** **
>
> _______________________________________________****
>
> Openid-specs-ab mailing list****
>
> Openid-specs-ab at lists.openid.net****
>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>  ** **
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>****
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131028/1cde8a24/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 80878 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131028/1cde8a24/attachment-0001.png>


More information about the Openid-specs-ab mailing list