[PROPOSAL] request nonce and name
Dick Hardt
dick at sxip.com
Fri Oct 13 00:12:31 UTC 2006
I am ok with this as long as the return_to parameter continues to be
signed, otherwise it is open to reuse attacks. (An RP can take a
response it got, change the return_to parameter and use it at another
site. The return_to allows the RP to know that the response was
intended for it)
I think that Hans had issues with the IdP signing arbitrary data,
which is possible since anything could be stuck in the return_to
parameter
Another advantage of having the request_nonce being a separate value
is the IdP can make sure it is not processing requests multiple
times, but this is only useful when the request is signed -- perhaps
this parameter is best left to the highly anticipated, upcoming RP
Identity extension? ;-)
-- Dick
On 12-Oct-06, at 12:10 PM, Recordon, David wrote:
> Josh and I chatted a good deal about this and don't believe a
> request nonce is actually needed. The main motivation for a
> request nonce is allowing a RP to retain state within the transaction.
>
> A stateful RP however already has the means to store the needed
> data for the response, which really isn't more than the association
> handle to validate the returned signature. All other "state"
> decisions by an RP are made from the data returned in the response
> from the IdP.
>
> A stateless RP is then unable to validate a nonce it generated
> since it wouldn't have been able to retain information about its
> own nonce.
>
> We thought about having the RP generate a nonce in the request for
> the IdP to verify it hasn't received the request previously, though
> do not see security implications with a request being replayed. As
> the protocol depends on browser redirections, there is not unique
> information within the request which should not be replayed. This
> is seen today if a RP redirects you to your IdP, you go to login,
> but refresh the page instead which works flawlessly. Adding a
> request nonce would break this with no anticipated benefit.
>
> We thus believe that any state tracking needed by a stateless RP
> must be maintained as GET parameters within the return_to
> argument. In the case of a stateful RP, it can either do the same
> thing, or store state via other means such as using a session id
> within a cookie to reference database data.
>
> --David
>
>
> -----Original Message-----
> From: specs-bounces at openid.net on behalf of Dick Hardt
> Sent: Sat 9/30/2006 4:57 PM
> To: specs at openid.net
> Subject: [PROPOSAL] request nonce and name
>
> Motivating Use Case
> ----------------------------
> It is useful for an RP to know that a response to a request has
> already been processed and is not stale.
> A standard way to do this that can be incorporated into the Libraries
> would simplify things for the RP implementor
>
>
> Proposed Implementation
> -----------------------------------
> 1) Allow the RP to OPTIONALLY include a nonce in the request. The
> nonce would be of the same format as the nonce in the response from
> the IdP. The IdP will include the nonce from the RP in its response.
>
> 2) rename openid.nonce to openid.response_id and name the request
> nonce openid.request_id
>
> Alternate: call them openid.response_stamp and openid.request_stamp
>
> naming comments:
> + openid.nonce is not in use at this time, so easy to rename
> + id or stamp may make more sense to the average developer (mainly
> crypto and security people know what a nonce is, I have to explain to
> most developers)
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>
More information about the specs
mailing list