Re: Dialback authentication

On 08/28/2012 07:52 AM, Evan Prodromou wrote:
> Folks,
>
> We've talked before about mechanisms to authenticate HTTP requests using
> dialback.
>
> I've written up a general method using the HTTP Authorization header,
> similar to Basic or Digest authentication.
>
> http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/Dialback_authentication
>
> I'd appreciate your feedback here or on the talk page of the wiki.
>

I'm happy to see this avenue being explored. I think it's a nice 
compromise between strongly-coupled services and a free-for-all system, 
notwithstanding some implications for security.

I apologize in advance for this potpourri of a message and am happy to 
discuss different parts of this separately if you prefer.

-------------------------------------

In other forums before I've shared my earlier attempt at a similar idea:
http://specs.mart.me.uk/dfp

I would like to first draw attention to a difference in my design vs. 
yours and explain the reasons behind the decision. In practice I think 
the "best" solution (assuming that such a thing exists) lies somewhere 
in between our two designs.

I made the dialback association step distinct from the request that is 
to be authenticated. This was for two reasons:

  * It allows the up-front cost of establishing the association to be 
amortized across potentially-many requests that follow, for the duration 
of validity of the bearer token.

  * It accommodates other mechanisms for establishing a domain 
association while using the same protocol for the authenticated requests 
themselves. For example, two domains with a pre-existing relationship 
may prefer to use a pre-shared secret for authentication in place of 
dialback.

I'd concede that the latter of these can be handled by using different 
Authorization schemes if you accept a slightly different separation of 
concerns. The former I think is the bigger concern, and something 
touched on in your "Concerns" section. For a particularly "chatty" pair 
of domains (imagine, for an extreme example, Facebook sending 
notifications to Twitter) I think this optimization is important.

Of course, the trade-off here is that the dialback request can't "see" 
the resource that's will subsequently requested and act based upon it. 
In effect that is mixing authentication (who is this caller?) with 
authorization (what is this caller allowed to do?) and I'd argue that 
the latter is better handled by the target resource itself rather than 
the dialback endpoint acting on the resource's behalf.

-------------------------------------

With the domain association factored out into a separate step, I then 
assert for my proposal that a client that we know to represent 
example.com is then allowed to act as any user in that domain without 
having to do dialback for each user individually.

This is why my proposal lacks an equivalent to your "Webfinger" mode, 
instead handling that by simply allowing the client to just name any 
user in the Authorization header. This is another optimization aimed at 
scalability: a domain can gain more users without having to scale up the 
number of dialback requests it has to deal with. Instead, associations 
scale by number of domains.

(Of course, in an "indie web" scenario where each domain has exactly one 
user this is a moot point. I considered a one-user domain to be an edge 
case for my design, just as it is for XMPP and SMTP.)

I think this speaks a little to your comment that you could combine 
"host" and "webfinger" into a different mode: you suggested that you'd 
have to be able to distinguish the two, but I'd argue that you don't and 
that "host" mode is the only one required on the dialback request.

-------------------------------------

Other, smaller feedback not related to my proposal:

* Perhaps an extra round-trip can be avoided by simply defining a 
/.well-known/dialback endpoint for doing dialback, rather than requiring 
host-meta. This is of course a trade-off that shifts if the same client 
will need other information in host-meta later and can thus fetch it 
once and cache it for many purposes.

* I didn't quite follow what the "date" paramter is for. Is this in 
anticipation of the dialback endpoint checking that the date is 
sufficiently recent before returning in the affirmative? Why would this 
be a problem?

* For an extra layer of assurance against DNS poisoning and similar 
attacks, you could advise or require clients to verify that the SSL cert 
matches for the given domain on the dialback request. This is of course 
still not a hard guarantee, but it can add an extra layer of complexity 
to an attack. (I weaseled around this in my proposal by mentioning it 
Security Considerations rather than in the normative prose.)

-------------------------------------

I think that's all I have for now! Thanks for writing this up and 
sharing it.

Received on Wednesday, 29 August 2012 21:09:03 UTC