Dialback authentication/archive

This is an outline for a dialback authentication mechanism for HTTP. It provides a method of authentication for server-to-server communications to associate HTTP client calls with a Host name or Webfinger account.

Use cases

• For pubsubhubbub, to associate a subscription with a particular user
• For OAuth client registration, to associate a client key with a user or domain

New Authorization type

This spec adds a new Authorization type, "Dialback". The header has the following optional elements:

• host The host authorizing the request
• webfinger The webfinger account authorizing the request
• nonce An opaque value used to confirm the request authorization

Exactly one of "host" or "webfinger" is required.

"nonce" is always required.

Replay prevention

To prevent replay attacks, the server has to reject the request if it's already seen the same (host | webfinger, nonce, date) tuple.

To keep from having to save billions of tuples until the end of time, it's reasonable to reject requests with a Date: outside a fixed window. +/- 5 minutes from server time is what's recommended for OAuth.

Discovery

The server receiving the request uses hostmeta (for hosts) or webfinger (for webfingers) to discover a link with type "dialback".

This link is an URL that can handle dialback requests.

Dialback request

To confirm, the server makes an HTTP POST request to the dialback endpoint with the following arguments:

• host: The host value provided in the original Authorization header.
• webfinger: The webfinger value provided in the original Authorization header.
• nonce: The nonce provided in the original Authorization header.
• url: The URL that the original request was made to.
• date: The Date header on the original request. If there was no Date header, this should be omitted.

One of "host" or "webfinger" is required. "nonce" and "url" are required.

Examples

Host authentication

• The client sends an HTTP request with an Authorization header:

POST /some/endpoint HTTP/1.1
Host: photo.example
Date: Tue, 28 Aug 2012 09:41:21 -0400
Content-Type: application/x-www-url-form-encoded
Authorization: Dialback host="checkin.example" nonce="4430086dedf5b9143c66"

arg1=186&arg2=50

• The server checks that the Date: header is within an acceptable window (+/- 5 minutes recommended).
• The server checks that it hasn't seen this (host, nonce, date) tuple before.
• The server discovers a dialback confirmation endpoint at checkin.example. Its rel type is "dialback".
• The server posts an HTTP request to confirm the nonce:

POST /dialback HTTP/1.1
Host: checkin.example
Date: Tue, 28 Aug 2012 09:41:43 -0400
Content-Type: application/x-www-url-form-encoded

host=checkin.example&nonce=4430086dedf5b9143c66&url=http://photo.example/some/endpoint&date=Tue%2C%2028%20Aug%202012%2009%3A41%3A21%20-0400

• checkin.example returns 200 OK for a confirmation, 4xx for confirmation failure, 5xx for server failure.

Webfinger authentication

• The client sends an HTTP request with an Authorization header:

GET /some/resource HTTP/1.1
Host: photo.example
Date: Tue, 28 Aug 2012 09:41:21 -0400
Authorization: Dialback webfinger="alice@checkin.example" nonce="b3265cd56bf7b0dd5a26"

• The server checks that the Date: header is within an acceptable window (+/- 5 minutes recommended).
• The server checks that it hasn't seen this (webfinger, nonce, date) tuple before.
• The server discovers a dialback confirmation endpoint for alice@checkin.example. Its rel type is "dialback".
• The server posts an HTTP request to confirm the nonce:

POST /dialback HTTP/1.1
Host: checkin.example
Date: Tue, 28 Aug 2012 09:41:43 -0400
Content-Type: application/x-www-url-form-encoded

webfinger=alice@checkin.example&nonce=b3265cd56bf7b0dd5a26&url=http://photo.example/some/resource&date=Tue%2C%2028%20Aug%202012%2009%3A41%3A21%20-0400

• checkin.example returns 200 OK for a confirmation, 4xx for confirmation failure, 5xx for server failure.

Notes

• The "host" or "webfinger" parameters in the dialback request allow a single dialback endpoint to handle multiple domains or accounts.
• The "nonce" is absolutely required.
• This mechanism should work for all HTTP methods (GET, POST, HEAD, OPTIONS, PUT, ...).

Implementation

• The client can store request data in a database, keeping tuples like (host, url, date, long-random-nonce). At dialback time, it can check that it has such a record stored.
• The client can use nonces that are a digital signature of a known format, like signature(host, url, date, secret-key). At dialback time, it can re-sign the arguments with its secret key and make sure the result matches the passed-in nonce.

Concerns

• This can only confirm that "checkin.example" is responsible for the request.
• There is no confirmation that the user "alice@checkin.example" has authorized the request independently from checkin.example.
• Arguments aren't included in the dialback. Do they need to be?
• Does anything need to be digitally signed? If so, why?
• Is URL parameter OK? Does it need to be "URI" or "IRI" or something more politically correct?
• Is the URL parameter required? Will this work without an URL parameter?
• Is the date parameter required? Will this work without a date parameter?
• There are lots of extra HTTP requests required to authenticate the original HTTP request. I think caching the results of host-meta and webfinger requests should make this more manageable, but each request will still require at least one dialback request.
• It would probably be possible to have just a single parameter to replace "host" and "webfinger" -- "principal" or "subject"? But you'd have to be able to tell the difference between a host and a Webfinger address to know which one to do discovery on.

References

• RFC 2069 - An Extension to HTTP : Digest Access Authentication