Re: Authentication workflow draft.

On 12 Apr 2011, at 18:14, peter williams wrote:

> 
> What's the point of step 4?
> 
> (a) It’s a self-signed certificate, in concept, so I can stick any date in, I want. Its self-asserted, and thus rather meaningless. This goes to the heart of another issue below (see extensions).

I think we had the notion that it would be useful to have short lived certs when working on less reliable machiens, so that they would be released if needed. It's not because it's self signed that one should not take my desire for my cert to be short lived lightly.

> (b) there was no step to check the self-signature on the cert (or any signature on the cert). Do not assume TLS server implementations do in the SSL stream handling, during client authn!

The signature of the cert is not important right here (though it could be, if we have certificate chains). 
What is important is that the TLS has verified that the privte key matches the public key in the cert.


> In most cert designs, its up to local policy to decide whether or not elementary validation failure are to be treated as authentication failures; There is no standard policy on the topic. There is a comparison with a date offset locally, to see if the cert expiry is "beyond tolerance". Similarly, there is a policy that says: if cert is missing certain extensions (e.g. ClientAuthn) even in a critical extension, don't worry.

I am trying to build a cert tester to help work out at least which would be important things missing in a certificte.

> 
> Step 6 says that all referenced URIs are resolved to a card, looking for any 1 that has any RSA public key. It doesn’t matter which one. Assuming async APIs, this test is satisfied by one card having any key. The first  card wins, it seems to assert ( even if it will turn out it has no pubkey matching the claim from SSL client authn.)

yes, the wording of 6 here is weak. It is stronger in the spec. The public key has to be tied via cert:identity to the webid.

> 
> It seems to imply that if no card is found, that’s fine.
> 
> If the cert points to whitehouse.gov, one pints whitehouse.gov as a server. If the cert is presented a million times a day, and has 10 URIs to whitehouse.gov, one pings whitehouse.gov 10 million times a day (which may get the operator "a little visit").

yes, caching is of course built into the web, and should be done. We will need tests to check for cache errors though.


> 
> Step 7 is ambiguous. I think its saying that one should first collect all RSA pubkeys from all files, build a local array of them, and then do query looking for a match against the input cert claim. Pulling one referenced card at a time (and finding a match) is NOT correct behavior. One must pull all resource, before attempting a match.
> 
> This is relevant to me, as it means for each URI in the SAN, I do a uriburner query, which (remotely) looks for a cert:identity match for 1 card at a time.
> 
> Can sparql have multiple FROM lines? Perhaps? Can the query be modified so Id know which URI matched, if one could specify multiple matches?
> 
> I note that it fails to discuss critical extensions, including key usage extensions. If the cert (self-signed even) has a critical extension called key usage that OMITS the digitalSignature bit, is the authentication valid?


> 
> There are n other extension questions, similarly. What is the party line? Is the webid validator supposed to enforce PKIX extensions? Is it supposed to enforce the ISO semantics of criticality? (guarantee to enforce the extension semantics correctly, or not process the cert at all).

This is the tedious bit we will need to look into. 
that is why we are building tests.

> 
> Can I use a v1 format certificate (with no extensions, therefore)?

If there is no extension where do you put the SAN?

> 
> 
> -----Original Message-----
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
> Sent: Tuesday, April 12, 2011 6:37 AM
> To: WebID XG
> Subject: Authentication workflow draft.
> 
> After a chat with Henry today, we decided to draft a "workflow" to describe how the authentication process takes place from the moment a user is accessing the service.
> 
> We are assuming the user possesses a client certificate which is installed in his browser, as well as a publicly accessible WebID on the web. The URI of the webid is found in the certificate's subjectAltName. 
> 
> Note: GOTO is used for the sake of simplicity and should not be generally used! :-)
> 
> Feel free to comment/add/change stuff if you consider it important.
> 
> -----------
> 
> Step 0. Init / no authentication / authentication failed (implementation
> independent)
> 
> Step 1. The user connects to the authentication server (service) and is asked to provide a certificate. 
> 
> Step 2. The user selects the certificate and clicks the submit button.
> If the user does not provide a certificate, GOTO Step 0.
> 
> Step 3. Using TLS, the server verifies that the public key found in the certificate matches the user's private key. If the keys do not match, (print an error maybe) GOTO Step 0.
> 
> Step 4. The server verifies the validity date of the certificate. If the certificate has expired, GOTO Step 0.
> 
> Step 5. The server extracts any URI found in the certificate's subjectAltName field, ignoring everything else (like email, etc.). If no URIs are found, (print an error maybe) GOTO Step 0.
> 
> Step 6. For each URI found, the server fetches and parses the profile file located at that particular URI, looking for resources pointing to a public key (i.e. rsa#RSAPublicKey?). If no resources are found, (print an error maybe) GOTO Step 0.
> 
> Step 7. If a public key resource is found, the server will try to check if the contents of "cert:identity" match the WebID's owner. If no match is found for any URI, then GOTO Step 0.
> 
> Step 8. If the identity matches the WebID, the server will try to match the WebID's modulus and exponent values to the ones provided by the user's certificate. It is possible to have multiple modulus values (belonging to several keys) therefore the server should cycle through all of them. If no match is found for any modulus/exponent of any URI, GOTO Step 0.
> 
> Step 9. If the modulus values match, the client is authenticated.
> 
> ---------------
> 
> Andrei
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 12 April 2011 16:34:13 UTC