cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: HTTP Basic Authentication Is there hope?
Date Tue, 13 Feb 2007 13:50:59 GMT

> -----Original Message-----
> From: Polar Humenn [] 
> Sent: 12 February 2007 17:57
> To:
> Subject: Re: HTTP Basic Authentication Is there hope?
> Hi Eoghan,
> I'm just going to clear up a few points below.

Thanks Polar for your patience in explaining this ...

However, I'm still a bit confused.

You correctly point out that the transitive nature of trust established
via signed certs is sometimes less than ideal, because some CAs are a
bit promiscuous. 

So even if we're prepared to allow the TLS handshake to suceed and share
all sorts of other information with the endpoint, we draw the line at
exposing our Basic auth creds, unless some extra scrutiny is applied to
the TLS connection before reponding to the 401.

But the 401 may arrive for any request (not just the first one), so its
sortta orthogonal to the trust implicit in invoking individual
operations on the endpoint.

Say the client invokes on stock trading service that exposes two

  placeOrder(String symbol, int volume, boolean sell, String account,
int PIN)

  getQuote(String symbol)

Also the relevant port is HTTPS-based, and the client "trusts" the CA
signing the server's cert.

Now, consider the following sequence of events:

1. client establishes TLS connection, TLS handshake suceeds

2. client needs to submit a sell trade, so it invokes placeOrder()
passing all sorts of sensitive information, i.e. its account number, PIN

3. later the client wants to check how the market reacted to its stock
sale, so it invokes getQuote() passing only innocuous info, i.e. the
ticker symbol its interested in.

4. the endpoint reacts to the getQuote with a 401, challenging the
client to provide its Basic auth creds

5. now the client applies an extra level of scrutiny before providing
its creds

Obviously this is a pathological example, but you see where I'm going
with it. The server is free to challenge at any time, and the timing of
the challenge is not necessarily related to the true sensitivity of the
operations being invoked.

So it seems to me that if extra scrutiny is to be applied by the client,
it only makes sense not to wait for the 401 but instead to apply this
scrutiny from the get-go in the TLS handshake (e.g. via a programmatic
CertValidator, or even simpler by imposing constraints on the crypto via
the CipherSuiteFilters config item). That way the client can be sure
that *any* sensitive info to passes to the endpoint (whether in the form
of Basic auth creds or normal operation parameters) is protected by the
extra check.

Does this make sense?


> Glynn, Eoghan wrote:
> > Just configure a truststore (via the SSLClientPolicy TrustStore 
> > element) that includes only the CAs that the client trusts. 
> Isn't that 
> > the basis of all cert-based auth?
> >   
> Cert-based Auth means that you merely trust the key-id 
> association provided by a trusted CA. It doesn't mean you 
> trust the id. George Bush may have a driver's license signed 
> from the State of Texas (CA), and I'll accept that that he is 
> George, his picture matches his face, and that Texas 
> certifies him to drive. However, I don't have trust him with 
> my car. The guy can't even navigate a coffee table. :)
> >> There may also be cases in which, say, for some authenticated 
> >> endpoints, you are willing to disclose a password (it has a key 
> >> signed by Zeus), whereas others you don't.  So yeah, some details 
> >> into the security features of the target could definitely 
> be of use.
> >>     
> >
> > Now I'm confused. When would you accept a endpoint's "strong auth" 
> > creds (i.e. the signed cert provided in the TLS handshake) and 
> > possibly expose your own cert (if the endpoint requests it 
> during the 
> > TLS handshake), but not be prepared to expose your own "weak auth" 
> > creds (i.e. Basic auth username/passwd) to that endpoint?
> With TLS you are "exposing" a piece of seemingly public 
> information, which is *not*, in the general case, sensitive 
> information. A certificate contains a name (DN) of the 
> Certificate Authority (CA), and the DN of the principal in 
> question, and the *public* key of that principal. Each end 
> can verify signatures, and authenticate each other without 
> exposing private keys, which is the sensitive information. 
> So, exposing your cert is merely like saying, "Hi, I'm Bob" 
> in a crowed room.
> > If the endpoint isn't worthy of
> > trust, why would it have a cert signed by a CA we trust. 
> >   
> We don't always have control over what CA's do with their signatures. 
> For example, a lot of bank server certificates are signed by 
> Verisign, but you don't have to trust them all. That is why 
> we have certificate cross-certification with certificate 
> constraints, but because of the complexity, nobody really 
> uses those. But, still, even so, that only gets you half-way there.
> > Or is it a question of degrees of trust? But if so, surely 
> accepting 
> > the endpoint's cert is the bigger leap of faith than 
> handing out your 
> > Basic auth username/passwd?
> >   
> Before you hand out a sensitive username/password, you 
> authenticate the server through TLS with the analysis of the 
> certification chain, and also the quality of the "tunnel" 
> parameters: encryption algorithm, key length. Then separately 
> you evaluate the trust in the principal identified by the 
> certificate authentication. In this case you want to trust 
> the principal on the other end before you hand it sensitive 
> information.
> > Well the trust policy in effect is encoded in the 
> truststore, which is 
> > in the client's domain and therefore under their control. So why 
> > replicate this checking in the runtime?
> >   
> The trust store only authenticates who is "speaking", so that 
> there is no (less probability of) impersonation. But then you 
> still must make a trust decision on whether to give that 
> principal what it asks for.
> [snip]
> > That pretty much sums it up. And my (admittedly layperson's, and 
> > perhaps
> > simplistic) notion was the following would give us all or 
> most of what 
> > we need:
> >
> > 1. Extend AuthorizationPolicy to allow multiple per-realm/targetURI 
> > username/password pairs to be configured.
> >   
> This could be an acceptable approach, but shouldn't be the 
> only approach as you allude to in the following.
> > 2. Allow (optional) programmatic retrieval of creds via 
> callback into 
> > the app.
> >   
> This is probably the most viable solution as it may allow for 
> prompting a user for authentication information, or going off 
> to some other trusted source for the information, a protected 
> file, trusted password service, etc, which is solely at the 
> discretion of the deployment.
> > 3. Ensure the http client (either or 
> > commons
> > HTTPClient) can handle the 401 properly and associate it with the 
> > appropriate creds.
> >   
> This is a must for HTTP/S protocol, as this is the only way 
> to get the realm information. That part of the protocol is 
> required, so it must be supported when it comes about, i.e. 401.
> > 4. Advise users that Basic auth should only be used over 
> HTTPS, unless 
> > they don't care about creds being stolen or have reason to 
> trust HTTP 
> > (e.g. the VPN case).
> >   
> Agreed.
> > 5. Require that users take responsibility for configuring 
> their trust 
> > policies directly via their truststore.
> >   
> This is always the case. I don't know how to *require* them 
> to do so, but we should not preclude them from doing the 
> thing that is right for them. The purpose is to give them to 
> tools to do a job that is suitable and is able to support the 
> security scrutiny, especially when it is mandated by certain 
> US laws, like HIPAA, FERPA, Sarbanes-Oxley and the privacy 
> laws of many European nations in the users' endeavors, and 
> maybe even write a value-added Common Criteria Protection 
> Profile, which may give their services some leverage in the 
> markets requiring security.
> So, I believe this effort would take a number of tasks.
> 1. Building the callback mechanism.
> 2. Interface Framework to assign the call back mechanism  
> programatically.
> 3. Configuration to use a particular callback mechanism.
> 4. Configuration of realm/username/password combinations.
>      (My initial reaction is that #4 is configuration of 
> specialized default 3.)
> Cheers,
> -Polar
> > Cheers,
> > Eoghan
> >
> >   

View raw message