[Openid-specs-ab] Nonce value suggestion for the Implicit Flow
George Fletcher
gffletch at aol.com
Wed Nov 13 18:35:41 UTC 2013
I'll let John quibble over the specifics :) ... but it looks good to
me. Thanks, George
On 11/13/13 1:30 PM, Mike Jones wrote:
>
> Please review the new text at
> http://openid.bitbucket.org/openid-connect-core-1_0.html#NonceNotes,
> which is where the implementation suggestions for the nonce parameter
> have been moved.
>
> -- Mike
>
> *From:*openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Brian
> Campbell
> *Sent:* Wednesday, October 30, 2013 9:00 AM
> *To:* John Bradley
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Nonce value suggestion for the
> Implicit Flow
>
> The nonce is a different approach to protecting against things like
> replay prevention but doesn't have the same scaling implications as
> tracking token ids. Which is nice.
>
> On Wed, Oct 30, 2013 at 4:13 AM, John Bradley <ve7jtb at ve7jtb.com
> <mailto:ve7jtb at ve7jtb.com>> wrote:
>
> The nonce is opaque to the AS, it is sent by the client and validated
> by the client. It binds the signed id_token to something in the
> user's browser session. This is critical to prevent attacks on the
> implicit flow, where the redirect_uri is not sent to the token
> endpoint for validation. It is not required for the "code" flow. In
> the hybrid flows it needs to be used to validate the id_token
> presented in the front channel as well, as the client may be using
> the id_token before exchanging code at the token endpoint, and
> discovering an attack.
>
> I think it also prevents some attacks against code interception that
> checking the redirect_uri wouldn't so in a high loa deployment I would
> check both nonce and the redirect_uri.
>
> Are you asking about "jti" in the assertion used to authenticate the
> client to the token endpoint?
>
> On Oct 30, 2013, at 1:44 AM, Anthony Nadalin <tonynad at microsoft.com
> <mailto:tonynad at microsoft.com>> wrote:
>
>
>
> I’m not seeing how you are dealing with duplicate nonces as this can
> be a scaling issue when dealing with millions of requests, the nonces
> need better advice
>
> *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] *On Behalf Of *John
> Bradley
> *Sent:* Tuesday, October 29, 2013 7:33 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
>
> You want to store the random value and send the hash. Saving the
> hash is not secure unless it is signed.
>
> The idea is to force an attacker to compute a plaintext for the hash
> (hard to impossible depending on length) in order to be able to
> present the response from the AS.
>
> For case 1: The Client can generate a random value with
> sufficient entropy and store that value in local storage. This
> value is then hashed to produce a nonce value. The hashed value
> could optionally be truncated to a sufficient number of bits
> (such as 128) before use.
>
> On Oct 29, 2013, at 9:40 PM, Mike Jones <Michael.Jones at microsoft.com
> <mailto:Michael.Jones at microsoft.com>> wrote:
>
> 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
> <mailto: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
>
>
> _______________________________________________
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
--
George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131113/b1cc32a3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 80878 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131113/b1cc32a3/attachment.png>
More information about the Openid-specs-ab
mailing list