RP generated nonce for stateful mode.
NISHITANI Masaki
m-nishitani at nri.co.jp
Fri Nov 30 10:02:26 UTC 2007
It is suggestive to me.
OP can deliver sensitive information such as end-user's
street address securely via sreg or AX, if RP passes its own
public key embedding into return_to.
Mr. Manger, James H wrote
> The RP could put its own nonce in the openid.return_to URI. The signature from the OP covers this field.
> I don’t think different return_to URIs for each request can have any negative consequences -- as long as an unchanging openid.realm is also included in the authentication requests.
>
> -----Original Message-----
> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of NISHITANI Masaki
> Sent: Tuesday, 20 November 2007 3:19 PM
> To: specs at openid.net
> Subject: RP generated nonce for stateful mode.
>
> Hi everyone.
>
> OpenID 2.0 uses nonce generated by OP to identify the
> transaction. This seems very reasonable for stateless mode
> authentication, because OP is the entity which is
> responsible for protecting the stateless mode transaction
> from replay-attacks. In this case, it is not so difficult
> for OP to control nonce not to be used twice.
>
> On the other hand, for stateful mode, OP generated nonce is
> also used and RP assures the nonce should be uses only once
> this time.
> In general, it costs more for someone other than the
> generator to ensure using nonce once, than the genetator
> itself does it. Also in this case, RP should remenber every
> nonces during certain time referring timestamp on each nonce.
>
> Using RP generated nonce could simplify this. For example,
> RP only caliculate a hash value for the end-users session-id
> and send this to OP in auth_req. Then OP signs to the
> RP-genetated-nonce and send it back in auth_res, now RP can
> verify the sign with the session-id very easily. RP and OP
> do not need to remember nonces.
>
> Of cource this is not a nonce in strict meaning, and can be
> used more than once. But that parameter is valid only in the
> end-user's session. So if someone want to use the value for
> replay-attack, it should hijacks the session beforehand.
>
> So I wonder if this kind of idea has been discussed before
> or not, and if it has.
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
More information about the specs
mailing list