[Openid-specs-ab] Nonce value suggestion for the Implicit Flow

Mike Jones Michael.Jones at microsoft.com
Wed Oct 30 00:40:41 UTC 2013


Here's an attempt at simplifying George's text.
For case 1:  The Client can generate a random value with sufficient entropy and store a cryptographic hash (such as SHA-256) of that value in local storage.  The hashed value could optionally be truncated to a sufficient number of bits (such as 128) before use.  The stored value is used as the nonce value.
For case 2:  The Client can generate a random value with sufficient entropy and store that value as an HttpOnly session cookie.  A cryptographic hash (such as SHA-256) of the cookie value (or a truncation of the hash value to a sufficient number of bits) is used as the nonce value.

Am I correct that the cryptographic hash function is used to spread the entropy present in the random value generated throughout the nonce value in both cases?

Comments?

                                                                -- Mike

From: Richer, Justin P. [mailto:jricher at mitre.org]
Sent: Saturday, October 26, 2013 11:33 AM
To: George Fletcher
Cc: John Bradley; Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Nonce value suggestion for the Implicit Flow

I don't know where the best place is to provide this guidance. If we have a "validating the ID Token" sub-section in the new ID Token section, then maybe it would best fit there.

+1 to this idea with a cross link from the nonce definition.

 -- Justin


On Oct 25, 2013, at 6:17 AM, George Fletcher <gffletch at aol.com<mailto:gffletch at aol.com>> wrote:


If we are going to give guidance, then we really need to give guidance for two different use cases...

1. The "client" will validate the response locally in the browser
2. The "client" will validate the response at it's server (even though it's using the implicit flow)

For use case 1: One method to achieve this is for the client to generate a random string with sufficient entropy and store a SHA-1 hash of the string in local storage. Then use the SHA-1 hash of the random string as the value of the nonce parameter. To validate the nonce on receipt of the ID Token, extract the nonce from the ID Token and compare it to the stored SHA-1 hash in local storage.

For use case 2: One method to achieve this is for the backend server to use a SHA-1 hash of the "clients" protected session cookie as the value of the nonce parameter when constructing the AuthorizationRequest. Note that the Session cookie SHOULD be protected (restricted to SSL and not readable by JavaScript) for this method. To validate the ID Token at the server, the server calculates a SHA-1 hash of the Session cookie value and compares that to the nonce value in the ID Token.

I don't know where the best place is to provide this guidance. If we have a "validating the ID Token" sub-section in the new ID Token section, then maybe it would best fit there.

Thanks,
George
On 10/24/13 7:16 PM, John Bradley wrote:
We want the implicit flow to validate nonce,  it would be better to have some reasonable advice for using HTML local storage rather than session cookies.

On 2013-10-24, at 3:44 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:


We could drop it from the Implicit Flow, as it's already present in the Code Flow.  Does that work for people?

                                                            -- Mike

From: Richer, Justin P. [mailto:jricher at mitre.org<http://mitre.org/>]
Sent: Thursday, October 24, 2013 12:56 PM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Nonce value suggestion for the Implicit Flow

I'm actually in favor of dropping this example, or else providing it in a list of alternatives. The important thing is that the client can validate the exact value of the nonce parameter on its way back through, the mechanics of how that happens are client specific (but we can provide simple guidance).

 -- Justin

On Oct 24, 2013, at 11:44 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>
 wrote:



For the Implicit Flow, the "nonce" description contains this text athttp://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest:
Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values. One method to achieve this is to store a random value as a signed session cookie, and pass the value in thenonce parameter. In that case, the nonce in the returned ID Token can be compared to the signed session cookie to detect ID Token replay by third parties.

George wrote this about the suggestion in his review:
"I'm not sure this suggestion makes sense for the implicit flow. The client would need to write a cookie value on the domain of the redirect_uri and the attempt to read it on the return of the implicit flow. Wondering if a local storage example would make more sense."

Do people agree with him?  If so, does someone want to supply specific alternative text to use?

                                                            -- Mike

_______________________________________________
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





_______________________________________________

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

--
<XeC.png><http://connect.me/gffletch>
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/cb2fd00a/attachment-0001.html>


More information about the Openid-specs-ab mailing list