[Openid-specs-ab] backchannel logout: nonce and key

Mike Jones Michael.Jones at microsoft.com
Sat Mar 25 20:50:48 UTC 2017


I’d been thinking about the audience change suggestion and I’m not sure it’s a good idea for multi-tenant deployments.  Many clients potentially share common endpoints, and in some cases, they can be distinguished by Client ID but not by endpoints.

The multi-key proposal creates actual complexity, in that there are more keys to manage and roll-over and more code to test.  You can easily imagine site administrators remembering to roll over signing keys but not logout keys.  Given that the issuer of both ID Tokens and logout tokens is really the same entity, it only makes sense to keep the issuer and subject the same.

Finally, as discussed on the id-event list, there’s not an actual problem to solve:
“For all response_types except for “code”, the ID Token must have a “nonce” claim matching the request in order to be validated.  SETs won’t have this claim.  For response_type=code, the ID Token must be retrieved from the Token Endpoint to be valid.  But SETs aren’t returned as the id_token value from the Token Endpoint.  There isn’t a channel in which an attacker can successfully substitute a SET for an ID Token and have it validate as an ID Token.”

Frankly, I hope people will stop arguing from the premise that logout tokens and SETs will be confused with ID Tokens, because starting with a false premise isn’t a good way to further meaningful discussion.

                                                       -- Mike

From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura via Openid-specs-ab
Sent: Saturday, March 25, 2017 12:24 PM
To: Axel.Nennker at telekom.de; ve7jtb at ve7jtb.com; jricher at mit.edu
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] backchannel logout: nonce and key

So, Axel, what do you think about " use the URI that the client publishes for its backchannel endpoint as the audience rather than the client ID."?

On Wed, Mar 22, 2017 at 4:21 AM Axel Nennker via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
If the issuer has a id_token_signing_key and a logout_command_signing_key then the receiver knows that the JWS is not a valid signed logout_command-JSON, right?
If somebody tries to push an id_token into the logout endpoint then it would not validate because the wrong key is used.

I am not saying that different signing keys are the best solution but the proposed “solution” is hacky.

//Axel



From: John Bradley [mailto:ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>]
Sent: Friday, March 17, 2017 4:55 PM
To: Justin Richer
Cc: Nennker, Axel; Michael Jones; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] backchannel logout: nonce and key

A diffrent signing key won’t help unless the issuer is different.

It is a double edged thing you want the issuer to be the same to know the logout source is the same as the login, however you don’t want the issuer to be the same to prevent the token from being mistaken as a id_token for login.

Logically it would be better to have a different logout audience for the client and change that.

One option would be to use the URI that the client publishes for its backchannel endpoint as the audience rather then the client ID.

I think William made a proposal along those lines.

John B.

On Mar 16, 2017, at 11:16 AM, Justin Richer <jricher at MIT.EDU<mailto:jricher at MIT.EDU>> wrote:

+1

On 3/16/2017 7:58 AM, Axel Nennker via Openid-specs-ab wrote:
Hi,
Nonce in the logout JWT is prohibited to make a Logout Token syntactically invalid compared to an id_token.
Wouldn’t it be more secure to use another signing key than the id_token signing key?
Prohibiting nonce is a hack.
Kind regards
Axel

The following Claim MUST NOT be used within the Logout Token:
nonce
PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to make a Logout Token syntactically invalid if used in a forged Authentication Response in place of an ID Token.
Logout Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored.
A Logout Token MUST be signed and MAY also be encrypted. The same keys are used to sign and encrypt Logout Tokens as are used for ID Tokens. NOTE: The Logout Token is compatible with Security Event Token (SET)<http://openid.net/specs/openid-connect-backchannel-1_0.html#I-D.ietf-secevent-token> [I‑D.ietf‑secevent‑token] draft -00.


From: Nennker, Axel
Sent: Thursday, March 16, 2017 12:49 PM
To: Mike Jones (Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>); John Bradley (ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>)
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: backchannel logout: events

Hi,

Regarding https://openid.net/specs/openid-connect-backchannel-1_0.html

I am wondering what the reason behind events is:
events
REQUIRED. Claim whose value is a JSON object containing the member name http://schemas.openid.net/event/backchannel-logout. This declares that the JWT is a Logout Token. The corresponding member value MUST be a JSON object and SHOULD be the empty JSON object {}.

The reason, I think, to have “events” is to make the logout JWT compatible to SET: https://tools.ietf.org/html/draft-ietf-secevent-token-01
But SET states: “Security Events are not commands issued between parties”
While openid-connect-backchannel-1_0.html JWT is a command.

If we want SET compatibility wouldn’t it make more sense to have a SET compatible response to the logout command?

Why is SET compatibility important? Is it important enough to justify this really strange type specifier?

"events": {

     "http://schemas.openid.net/event/backchannel-logout"<http://schemas.openid.net/event/backchannel-logout>: {}

     }

Kind regards
Axel







DEUTSCHE TELEKOM AG
T-Labs (Research & Innovation)
Dipl.-Inform. Axel Nennker
Winterfeldtstr. 21, 10781 Berlin
+491702275312<tel:+49%20170%202275312> (Mobile)
E-Mail: axel.nennker at telekom.de<mailto:axel.nennker at telekom.de>




_______________________________________________

Openid-specs-ab mailing list

Openid-specs-ab at lists.openid.net<mailto: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<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
--

Nat Sakimura

Chairman of the Board, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170325/67c8f236/attachment-0001.html>


More information about the Openid-specs-ab mailing list