[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