Dumb mode question

[Brad Fitzpatrick]

On Wed, 6 Jul 2005, meepbear * wrote:

> > > If a server receives an invalidate_handle it does know about then it
> > > should be not answer the check_authentication but simply return an error
> > > as well.
> >
> >No!  The whole point of invalidate_handle was for when servers forgot
> >their secrets.  If you send a server a gibberish invalidate_handle, it has
> >to confirm that it knows nothing about it.
> I suggested the opposite though.
>
> An "attacker" has three (easy) choices to tamper with an invalidate_handle:

Your last email made sense, and addressed a concrete problem, but this one
I can't make heads or tails of.

What do you mean "tamper" with?

> 1) make one up and neither will know about it,

So?  An attacker can tell a consumer (along with an id_res) about a fake
invalidate_handle and the consumer won't actually remove it from its cache
unless it finds out from the the server that it's unknown.

> 2) use one the server knows about but the consumer doesn't,

So?

> 3) use one that both the consumer and server know about.

Then the server already won't reply and say it's unknown.


> With the normal flow of the protocol, none of the above should ever occur
> "naturally". The only way a "regular mode" consumer could fallback to "dumb
> mode" is when the server forgets about the handle and then the consumer is
> the only one that knows about it.

Yes.

> On the consumer side: it sees an invalidate_handle it doesn't know about so
> it returns an error (elminates 1 and 2).

Eliminates a non-problematic 1 and 2, as far as I see.  I think this can
occur naturally, with the right timing:  an OpenID consumer sends a handle
that expires in 2 seconds.  The server is slow, so doesn't reply for 4
seconds.  Because it's no longer valid, the server now replies with a new
assoc_handle and invalidate_handle of the now-expired one.  The consumer,
being conformant, has also lost knowledge of that handle from its cache.

You're saying the consumer should error now, even though it could keep
recovering using the server-created assoc_handle.

I argue that's unnecessary.

You raised a good point that check_authentication should only validate
assoc_handles who secret has never been given out, but I don't see your
argument here.

> On the server side: it knows it would never return an invalidate_handle on
> an handle it knows about (and hasn't expired yet) so it can safely return an
> error without breaking anything when it sees one, eliminating 3.

That's fine.  But it's already not going to include the invalidate_handle
parameter in the check_authentication response if it knows about it, so
why break at all, instead of just answering the check_authentication
request with only the lifetime parameter?

In summary, tell me the real problem here.  Or are you still talking about
the one you already raised, which has an easy solution, even though it
wasn't obvious?

- Brad