Re: Dialback authentication

On 09/04/2012 09:00 AM, Evan Prodromou wrote:

> On 12-08-29 05:08 PM, Martin Atkins wrote:
>> In other forums before I've shared my earlier attempt at a similar idea:
>> http://specs.mart.me.uk/dfp
 >
> Really sorry that I didn't reference this better. I had read the DFP
> proposal, and although it wasn't at the top of my mind when writing this
> dialback wiki page, it clearly has left its psychic residue, since there
> are so many parallels.
 >

No worries. I'm happy to see a different take on the idea, with 
different assumptions/tradeoffs.

>> I made the dialback association step distinct from the request that is
>> to be authenticated.
 >
> I think this is a good idea /iff/ the protocol is standalone. My
> intention with dialback is that it should bootstrap more permanent
> relationships.
 >
 > Two important ones for me are:
 >
 >   * PubSubHubbub subscription (so we can associate a subscription with a
 >     Webfinger or host)
 >   * OAuth client registration
 >     <http://openid.net/specs/openid-connect-registration-1_0.html>

My intent *almost* aligns with that; I was thinking of it as a 
*temporary*, ad-hoc relationship, assuming that in a truly decentralized 
world there may be entities you interact with once and then never talk 
to again.

Of course, that's not to say you can't use the temporary ad-hoc 
relationship to establish a longer-term one: OAuth client registration 
seems like exactly that.

>
> Your Twitter-to-Facebook example works best if Twitter gets an OAuth
> client id using client registration and Dialback authentication, then
> uses OAuth authentication for all future calls.

This sort of persistent association is handled in my proposal by the 
ability to obtain an association via a client id and secret obtained out 
of band, the implication being that in that case there is some business 
relationship (even if it's just a TOS clickthrough) between the two 
entities.

I'd figured that service providers wouldn't want to do this without a 
TOS roadblock and so didn't design an automatic mechanism, letting the 
temporary association represent the ad-hoc case.

>> 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.
 >
> My weak dev-exp idea is that if it makes more sense for protocol to
> think of a request coming from an account, then there's no reason not to
> represent that, even if it's functionally equivalent.
>
> My weak technical idea is that "someone might want to" (four most
> dangerous words in software!) designate a /different/ dialback server
> than the default one for their account. But that seems so ludicrous I'm
> ashamed I even brought it up.

It's worth comparing this to SMTP and XMPP, which have a very similar 
architectural style:

* SMTP doesn't provide a mechanism to override the MX for a particular 
user in a domain, only the domain as a whole.
* XMPP connections represent a temporary association between two 
domains, and allow the servers representing those domains to act as any 
user from the domain without any further auth.

I convinced myself this is the right design by reasoning that even if we 
did allow a per-user override, it would still be ultimately under the 
control of the domain "owner" and therefore they already have the 
ability to act as any user.

>>
>> * 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.
> My read on RFC 5785 <http://tools.ietf.org/html/rfc5785#section-1.1> is
> that having functional endpoints in /.well-known/ isn't in the spirit of
> that definition. From the RFC:
>
>     /well-known URIs are not intended for general information retrieval
>     or establishment of large URI namespaces on the Web. Rather, they
>     are designed to facilitate discovery of information on a site when
>     it isn't practical to use other mechanisms/
>

Fair enough. I ended up making a similar determination in my proposal 
and created a /.well-known/federation endpoint... however, practically 
speaking there isn't much difference between an endpoint that returns a 
URL in its payload and an endpoint that returns a redirect to a URL, so 
you could define it such that the dialback endpoint is allowed to redirect.

Not a big deal in the end, though.

>> * 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?
 >
> Rough idea being that nobody's obligated to keep a log of all requests
> made for all time. If the "date" parameter is outside a certain window
> (+/- 5 min, say) of the current time, it's OK to just give a 4xx response.

I think I'd just let the implementer bake that into the validation token 
if they want. In practice I think you'd have to include the date in the 
validation token somehow anyway, or else you'd just be trusting the 
client not to lie to you.

>> * 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.)
 >
> Yes, using SSL on the dialback endpoint is a good SHOULD requirement.
>
> I assume you're not talking about client-side certs, which make the
> whole thing unnecessary.

No, certainly not. Just server certs as an extra level of protection.

> I think the next step with the dialback proposal is to submit an
> experimental internet draft; I wonder if you'd be interested in
> co-authoring?
>

I think there are a few architectural details we'd need to resolve 
first, but sure, I'd like to help craft a draft.

I'll also offer any prose/structure from my DFP proposal that you think 
is useful as a starting-point.
https://github.com/apparentlymart/domain-federation-protocol-specs

Received on Tuesday, 4 September 2012 17:43:39 UTC