[security] Comment on the use of nonces in OpenID Authentcation 2.0/d12

[Johnny Bufu]

On 23-Nov-07, at 10:23 AM, Jose Kahan wrote:
> In OpenId 2.0/d12, a positive assertion reply from the OP
> include an OP-generated nonce (openid.response_nonce, defined in
> section 10.1). Furthermore, section 11.3 states that "the agent
> checking the signature keeps track of the nonce values included in
> positive assertions and never accepts the same value more than once
> for the same OP Endpoint URL".
>
> I'm concerned as to how well the use of these nonces will scale
> on a highly demanded Relying Party. The RP will need to store all
> those nonces for an indeterminate amount of time.

That's not a requirement. Nonces have a timestamp embedded in them,  
so the RPs can have a policy to discard assertions with nonces older  
that X minutes. Associations have an expiry time (also set by the  
OP), so the RPs can have a good idea about what X should be.

> In addition,
> RP becomes dependent on the OP's clock values and may need
> to require some rough clock synchronization.

Not required either. Even though the timestamp is based on the OP's  
clock, all the RP needs to do is write down the difference against  
it's own clock, not actually synchronize with the OP's clock.

> This also opens the
> door to OPs that change their clock value, malicious or not.

If it's the authoritative OP, then there's no real issue; only the RP
s nonce verifier time window may be a bit skewed. If the OP does more  
than "a bit" of time change, then I think it's okay for the  
transactions that are in progress to fail and the user to retry them.  
Hopefully OP's won't do something like this without a really good  
reason.

If it's a malicious OP, the nonce must be signed and the signature  
verification will fail.

> Finally, let's suppose we have a configuration with mirrored
> RPs, selected, say, by DNS round-robin (I'm not taking into account
> how the association could be handled there). We don't know which
> of the RPs would end storing the OP nonce sent in the reply to
> the checkid_setup message; if you replay the protocol, you may be
> lucky and end getting access to one of the mirror RPs that didn't
> store the nonce.

In protocol's terms "the RP" is the collection of the load balanced  
servers, not just one of them. A correct implementation will have to  
provide a shared nonce store to both of them. This is a RP  
deployment, not a protocol issue.

> With all due respect, this seems to be a misuse of nonces to avoid
> replays. Traditionally, party A includes a nonce in a message
> sent to party B. Party B includes party's A nonce in its signed reply.
> This allows party A to know that its message has not been replayed.
> The value of this nonce is considered to be opaque to all except to
> party A.

This is exactly the stateless mode flow used in OpenID as well (when  
"the agent checking the signature" is the OP).

If an association has been established, the process is optimized by  
having the RP do the signature and nonce verifications (the nonce is  
signed by the OP with a shared secret known only to the RP the  
message is addressed to).

> OpenId 2.0/d12 is using the nonce differently: Party B generates
> a nonce that Party A must verify. Is there a document or note
> available saying why this was specified as such?

The same reasoning applies as for associations: an extra call to the  
OP is avoided.

> From the implementation point of view, I think it would be make
> much more sense if the Relying Party generated the nonce and have
> the OP returns this nonce in its message. More precisely,
> this means including the RP generated nonce in the request parameters
> specified in Section 9.1. The RP needs to memorize it too, until
> the OP replies. The OP needs to include this nonce
> in the Positive Assertion reply message specified in Section 10.1;
> the nonce also has to be part of the signed fields. Once the RP
> verifies the nonce, it can discard it.

The RP can do this by including a RP nonce the return_to, which is  
then required to be signed by the OP (and without any changes to the  
specification).

Arguments for having the OP generate the nonce:
- unsolicited positive assertions do not have a corresponding request
- the OP generates the assertion, so it makes sense for it to  
generate the nonce as well


Johnny