Re: Dialback authentication

On 12-09-07 01:55 AM, Michiel de Jong wrote:
> Cool stuff! some remarks -
>
> 1) The Date field seems to introduce a one-second granularity which
> seems quite arbitrary. For instance, if a client is continuously
> sending one request every 10ms with the same token, then this would
> cause the server to have to check its validity once every 100
> requests. Also the other way around, if a client sends a request every
> 10s, then each request needs to trigger a check, even though maybe you
> would want the token to have a validity of say 5 minutes.
The "token" field makes it possible to send as many requests as you 
want. You can only have one request with the same (host | webfinger, 
endpoint URL, token, date) tuple.

This makes the token carry the weight both for sub-second granularity 
/and/ for sufficient randomness to provide brute-force attacks, but it 
seems to work OK for OAuth, so I think it should be OK here. Since it's 
of arbitrary size, you can fine-tune as needed.
> 2) about 7.6 DoS, you mention caching of host-meta and webfinger, but
> what if the client sends many different tokens? then the server would
> still have to do many requests to the third party, right? the client
> would still have the same work to attack the third party, but it would
> be harder for the third party to block the attacker (other than taking
> down its whole dialback auth service for any IP address, which was the
> presumed purpose of the attack anyway). i don't see how a sysadmin
> could defend against that, other than making sure it has a lightweight
> method to distinguish its own tokens from the attacker's tokens, and
> then just try to sustain the attack by adding enough server power
> while it lasts.
Right. I think that the correct way to handle this, on the server side, 
is to do exponential backoff if you're getting too many errors from a 
dialback endpoint.

I think the typical thing to say in specifications is "take appropriate 
action" or "consider very seriously the ramifications". I think this is 
an issue, but it can be dealt with.
>
> 3) the client's original http request stays open while verification is
> taking place, right? so maybe an extra remark about timeouts would be
> in place. If the verification service takes longer than say 3000ms to
> answer, then the server is allowed to treat that as a 'no', even if a
> 'yes' would still have arrived after waiting longer.
Hmm.
>
> 4) on that note, say i vote up some blogpost. it's not vital to know
> whether my vote counts, i just want my client to get a quick response
> from the server. Could the server respond with a 202 Accepted and deal
> with the decision (e.g. whether to publish a comment that was posted
> or discard it) afterwards? just a thought in the 'someone might want
> to' category. ;)
I think that makes total sense.
>
> 5) does this deprecate the From: header in a way? (section 14.22 of rfc2616)
I'm going to punt on this. The From: header is pretty rarely used, and 
it's explicitly not for authentication (" It SHOULD NOT be used as an 
insecure form of access protection."). That said, Blaine's an advocate.
> 6) the big open issue now seems to be per-host vs per-user. You
> started by saying webfinger but Mart argued a good point that per-user
> granularity is maybe not so useful, and Blaine also mentioned (iiuc)
> separating the question of which hosts trust each other in
> server-to-server comms from the question of which user can do what
> where.

> I think the important point to make is that this protocol only
> introduces a sort of trustable From: header, and what the server does
> with that verified information is i think out of scope. So even if
> announcing the verification service can probably be announced
> per-host, i think we would typically use it to send verifiable
> webfinger identities along with our http requests. Being able to do
> that is a really cool feature with many possible applications.
>
I agree.

Thanks for the feedback! I'm going to try to capture these on the Github 
page,

https://github.com/evanp/dialback/issues

-Evan