Hi Dick,
Welcome back! My comments inline:
Dick Hardt wrote:
On 30-Jun-09, at 9:23 PM, Allen Tom wrote:
Another case is where the RP specified max_auth_age=999999999999. The
PAPE spec requires the OP to respond back with the the time the user
last authenticated, if the max_auth_age is greater than the duration
of the user's current session with the OP. This effectively gives the
RP a way to find out when the user last signed in, which potentially
violates the user's privacy.
Rather then return the time the user last authenticated, the OP return
the max_auth_age value the RP sent. This lets the RP know the OP
honored the RP's max)_auth_age request.
Well, if the RP is deliberately violating the user's privacy to find out
when the user authenticated at the OP, it could send multiple
checkid_immediate requests, decrementing the max_auth_age value each
time, until it found the real value.
What are you looking for in this use case where the IP address changes?
Sites that force the password to be re-verified before entering a
sensitive flow often require that the user's IP address remain fixed
throughout the flow, or else they'll require the user to re-authenticate.
If the OP authenticates the user and generates the assertion in two
separate screens (as appears to be the most common case), there is an
edge case where the user's IP address could have changed after the user
authenticated. For instance, the user is on wifi, and enters their
password while on one wifi network, and then and then roams to a new
wifi network while on the OP's approval screen. If the RP was not using
OpenID, and instead authenticated the using a local password, this IP
address change would invalidate the user's session. It would be nice to
keep this functionality in OpenID.
Allen
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security