Re: [http-auth] Web Keys and HTTP Signatures

HI Manu,

Thanks for the thorough review. Some good points and
defo a bunch of things to check out... but not today:-)

I'll take a better look at this Monday,
Cheers,
S.

On 04/21/2013 04:19 AM, Manu Sporny wrote:
> On 04/19/2013 06:58 AM, Stephen Farrell wrote:
>>> HTTP Origin-Bound Authentication (HOBA) 
>>> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt
>>>
>>> We had considered signatures in the URL in the second approach to
>>> the problem in the Web Keys spec. We eventually rejected the
>>> solution because of limitations in the URL length in some browsers
>>> and because we wanted the semantics of the HTTP headers to be able
>>> to be a part of the digital signature. We also didn't want large
>>> signed messages being dumped to the webserver logs (the request
>>> line is typically included). So, while HOBA does solve the problem,
>>> it doesn't solve it in a way that is acceptable to us.
>>
>> I think you're misreading the spec a little, or we've written it
>> badly:-)
> 
> I did misread the spec a bit, confusing some of the features in other
> HTTP Auth specs with some of the HOBA features. So, I took tonight to do
> a thorough review of the spec and outline the issues that we have with
> the current HOBA spec located at:
> 
> http://tools.ietf.org/html/draft-farrell-httpbis-hoba-02
> 
> I do agree that we should chat a bit more deeply about HOBA, Web Keys,
> Persona, and HTTP Signatures. So, please take this not as negative
> feedback, but constructive criticism and the first exchange toward
> attempting to map out a way forward for these specs.
> 
> Here's the HOBA spec review from a Web Keys / Web Payments perspective:
> 
> 1.  Introduction
> ----------------
> 
>> HOBA also defines some services that are required for modern HTTP 
>> authentication:
>>
>> o  Servers can bind a CPK with an identifier, such as an account 
>> name.  HOBA allows servers to define their own policies for binding
>> CPKs with accounts during account registration.
> 
> While a bit vague, we want to ensure that there is a well-defined way to
> do this. We're currently in the process of discussing how this should
> happen with the Mozilla Persona team. Ideally, the CPKs are setup or
> transmitted to the server when a Persona-like login exchange happens.
> We'd like to provide CPKs via some sort of identity expressed as Linked
> Data, like the sort that's defined in the Web Keys spec:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu
> 
>> o  Users are likely to use more than one device or user agent (UA) 
>> for the same HTTP based service, so HOBA gives a way to associate 
>> more than one CPK to the same account, but without having to register
>> for each separately.
> 
> +1, the approach above is how we accomplish this for Web Keys.
> 
>> o  Users are also likely to lose a private key, or the client's 
>> memory of which key pair is associated with which origin.  For 
>> example if a user loses the computer or mobile device in which state
>> is stored.  HOBA allows for clients to tell servers to delete the
>> association between a CPK and an account.
> 
> We took this approach 3+ years ago and quickly found that it would be a
> nightmare to have to contact every server that you've performed a login
> on to delete the association. Even worse, if you don't do this and the
> key is compromised, you enable the attacker to gain access to the server
> without your knowledge.
> 
> Instead, the server should track an "identity" and that identity will
> have keys that are currently valid, or that have been revoked (like the
> following):
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3
> 
> The server MUST check the validity of a key before allowing login. There
> could be cache values / E-Tags associated with keys to make sure that
> they're being properly cached via HTTP proxies.
> 
>> o  Logout features can be useful for user agents, so HOBA defines a 
>> way to close a current HTTP "session", and also a way to close all 
>> current sessions, even if more than one session is currently active
>> from different user agents for the same account.
> 
> Session management absolutely should not be a part of the base
> specification on HTTP Signatures. It should be layered on top of HTTP
> signatures. I realize that HOBA might be doing this to "solve" the
> session login problem on the Web via HTTP Auth once and for all, but
> this is at the wrong level of abstraction. You can implement sessions on
> top of HTTP Signatures any way that you would like (session cookies,
> HTTP headers carrying session information, URL query parameters with
> session information, etc.).
> 
> There should be a separation between HTTP Signatures and HTTP session
> management.
> 
> 1.2.  Terminology
> -----------------
> 
>> also optionally include an HTTP "realm" as defined in the HTTP 
>> authentication specification.
> 
> We don't use realm as most Access Control List (ACL) systems require far
> more complicated forms of specifying what the client can and cannot do
> with a particular CPK.
> 
> For example, look at the way OAuth is used in Twitter. When you provide
> a website with a particular OAuth token, you can grant them a number of
> privileges wrt. your account: let them see my e-mail address, let them
> tweet on my behalf, let them see my followers, let them see my profile
> information, etc. These sorts of access grants rarely fit nicely into a
> "realm" field. We think ACL should be a completely separate spec that is
> layered on top of HTTP Signatures or HOBA. We don't think it is a good
> idea to solve the problem at this level.
> 
> 2.  HOBA for Both HTTP Authentication and JavaScript
> ----------------------------------------------------
> 
>> On receipt of a challenge from a server, the client marshals a
>> to-be- signed blob that includes the web-origin name, the realm, and
>> the challenge string; and signs that hashed blob using the hash
>> algorithm identified with the challenge and the private key
>> corresponding to the CPK for that web-origin.
> 
> Yikes, this stomps all over the work that Mozilla is doing on Persona
> (and not in a good way). They seem to have a good solution for this, we
> should build off of that. The Javascript implementation of HOBA is also
> a hack in that it shoves authentication parameters into the URL and we
> /definitely/ don't want a Web where that becomes the norm. If this stuff
> is going to be integrated into the browser, we should not create a
> solution that makes it difficult for that to happen.
> 
> The solution shouldn't have a JavaScript-version and an HTTP-version. It
> should all run over HTTP, especially since the very large majority of
> JavaScript environments are capable of accessing and writing HTTP headers.
> 
> 3.  HOBA HTTP Authentication Mechanism
> --------------------------------------
> 
>> On receipt of a challenge from a server, the client marshals a
>> to-be- signed blob that includes the web-origin name, the realm, and
>> the challenge string; and signs that hashed blob using the hash
>> algorithm identified with the challenge and the private key
>> corresponding to the CPK for that web-origin.
> 
> This challenge-response-session approach is a tried and true design, but
> one that's fairly inefficient in that it requires multiple round-trips
> in the common case between server and client to perform a single
> authenticated operation.
> 
> The Web Keys specification takes a different approach in that the server
> does not need to provide a challenge because the client includes a
> client-specific time-boxed nonce. The nonce is guaranteed to increment
> so replay attacks are prevented as long as the server tracks the nonces
> correctly, which is the same requirement that TLS has. Only the latest
> nonce per client needs to be tracked for a certain period of time, e.g.
> 5 minutes, which greatly reduces memory overhead on the server.
> 
> The downside is that both client and server must have their clocks
> fairly closely aligned, which is not necessarily a terrible requirement
> given the state of modern timekeeping technology on the Internet. In the
> very worst case, the protocol could be expanded such that the server
> provides a clock timestamp that the client can use to calculate it's own
> clock skew based on the server's current clock.
> 
> Using a Linked Data-based identity coupled with an HTTP Signature and a
> time-boxed nonce allows a client to make a direct signed request to a
> server in 1 HTTP exchange instead of 2.
> 
> This is a fairly sharp deviation between the Web Keys + HTTP Signatures
> spec and the HOBA spec.
> 
> 4.  Using HOBA-http
> -------------------
> 
>> 4.1.  CPK Preparation Phase
>>
>> In the CPK preparation phase, the client determines if it already
>> has a CPK for the web-origin it is going to.  If the has a CPK, the 
>> client will use it; if the client does not have a CPK, it generates 
>> one in anticipation of the server asking for one.
> 
> With Web Keys, the client does not create a new CPK for every
> web-origin. It creates a single CPK for each identity associated with
> the client.
> 
> With HOBA, providing a new key for every website that the client visits
> is overkill and would result in a key management nightmare for the
> person using a browser. Dialogs would include dozens of keys in the
> average case, which would be a bit of a usability nightmare.
> 
> The Web Keys approach is to provide every identity on each device a key.
> So, if you visit google.com and you have one personal identity and one
> professional identity, and you use both on your home computer, then your
> home computer would have two keys regardless of the number of websites
> that you visit. Those keys would be tied to each public Linked Data
> identity.
> 
>> 4.2.  Signing Phase
>>
>> The user agent tries to access a protected resource on the server. 
>> The server sends the HOBA WWW-Authenticate challenge.  The user
>> agent receives the challenge and signs the challenge using the CPK
>> it either already had or just generated.  The server validates the 
>> signature.  If validation fails, the server aborts the transaction.
> 
> As explained above, the Web Keys + HTTP Signature approach is to not
> utilize a challenge-response approach, but rather a Linked Data identity
> coupled with a client-specific time-boxed nonce to achieve the same
> level of protection.
> 
> There /could/ be a Web Keys WWW-Authenticate message, but all that would
> do would be to notify the client that a Web Keys-based authentication
> should be performed when communicating with the server.
> 
>> 4.3.  Authentication Phase
>>
>> In the authentication phase, the server extracts the CPK from the 
>> signing phase and decides if it recognizes the CPK.  If the server 
>> recognizes the CPK, the server may finish the client authentication 
>> process.
> 
> Since the Web Keys specification uses a URL to express the key used for
> the digital signature, a server can discover the identity associated
> with the key pretty easily. For example, if this key was specified in
> the HTTP Signature: https://dev.payswarm.com/i/manu/keys/3
> 
> The server would get the key:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3
> 
> look for the owner of the key in the data, which would be:
> 
> https://dev.payswarm.com/i/manu
> 
> fetch that profile:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu
> 
> and then see if it has that identity on record as having an account on
> the server. If it does, then it would verify that the key is owned by
> the profile and check the validity of the signature.
> 
> 4.3.  Authentication Phase
> --------------------------
> 
> The last part of the first paragraph and the last 3 paragraphs should
> just say that each topic covered is out of scope. The vast majority of
> this section deals with things that are out of scope for HOBA (and most
> HTTP Auth schemes).
> 
> 4.4.  Logging in on a New User Agent
> ------------------------------------
> 
> The vast majority of this section is out of scope for this spec as well.
> 
> 5.  Using HOBA-js
> -----------------
> 
> I don't understand why HOBA-http cannot be accomplished via JavaScript
> and XHR? Why do you need an entirely different way of encoding the HOBA
> protocol using only URL-based parameters?
> 
> Unless I'm missing something, the entirety of this section is at the
> wrong level of abstraction and unnecessary.
> 
> 6.1.  Registration
> ------------------
> 
> This section is interesting because we've been struggling to figure out
> a way to have UAs automatically (or semi-automatically) create accounts
> on new web-origins. That said, Mozilla Persona is far ahead of us here,
> so we should probably just fall in line w/ what they're doing.
> 
> 6.2.  Associating Additional Keys to an Exiting Account
> -------------------------------------------------------
> 
> As explained above, this is unnecessary if you use a Linked Data
> identity like Web Keys does. You never have to add additional keys to an
> existing account because the person accessing the site has already
> paired their device with a key using their Identity Provider. When they
> hit a web-origin, that association is already complete, therefore there
> is nothing for the web-origin to do except lookup the key and the
> identity. In effect, that key is automatically picked up by every
> website that accesses the Linked Data identity.
> 
> 6.3.  Logging Out
> -----------------
> 
> Again, this is at the wrong level of abstraction, at least as far as Web
> Keys and HTTP Signatures are concerned. If HOBA is to become a standard
> way of doing HTTP session management, then this would be fine. That
> said, I think you'll be competing with Mozilla Persona at that point.
> 
> -----------------------------------------------------------------------
> 
> Hopefully this is helpful to the HOBA editors. I'm having a chat with
> one of the editors next week and I wanted to make sure to get this out
> there so he has time to review the comments before our chat.
> 
> Again, this was just a friendly review of the spec before we try to
> figure out how we can coordinate this activity between W3C and IETF.
> 
> -- manu
>

Received on Sunday, 21 April 2013 18:14:09 UTC