cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: HTTP Basic Authentication Is there hope?
Date Tue, 13 Feb 2007 15:46:28 GMT

Yep, getting clearer :), I like the role reversal analogy of the server
requesting sensitive info from the client.

However, I still think the default should be to impose the tightest
level of scrunity up-front on TLS handshake itself, rather than the app
making a different decision for each "request" from the server.

Say we provide a programmatic hook for this scrutiny, and the user codes
it up thusly:

if (isBasicAuthChallenge()) {
    return strongestCheckOnServerCert();
} else if (operationName.equals("placeOrder")) {
    return strongCheckOnServerCert();
} else if (operationName.startsWith("get")) {
    return weakCheckOnServerCert();
} 

Totally contrived example I know, but you can see how this sort of thing
could be vulnerable to versioning issues. For example say the endpoint's
interface is extended to add two new operations, say
getFinalBalanceAndTransferFundsOffshore() and getHistoricalQuote().

Unless the scrutiny code is also updated in lock-step, we end up with
too weak a constraint on getFinalBalanceAndTransferFundsOffshore(). 

If the scrutiny code was a bit more sensible to being with, i.e.
operationName.equals("getQuote") instead of
operationName.startsWith("get"), then we end up with too strong a
constraint on getHistoricalQuote().

On the other hand, the client is a bit more future-proofed if it applied
the strongest check upfront to the TLS handshake (i.e. appropriate for
the *most* sensitive info the server may "request") ... then we're done,
any "request" from the server side is treated with the same strong
constraints.

Less flexible surely, but probably more solid in the long run.

Of course we could provide the programmatic hook also, but with clear
caveats as to the versioning issue etc.

Cheers,
Eoghan

> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com] 
> Sent: 13 February 2007 15:02
> To: cxf-dev@incubator.apache.org
> Subject: Re: HTTP Basic Authentication Is there hope?
> 
> Hi Eoghan,
> 
> Great example. I hope I can clear up your confusion. In-line.
> 
> Glynn, Eoghan wrote:
> >
> >   
> >> -----Original Message-----
> >> From: Polar Humenn [mailto:phumenn@iona.com]
> >> Sent: 12 February 2007 17:57
> >> To: cxf-dev@incubator.apache.org
> >> 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
> > operations:
> >
> >   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
> >   
> Okay, so here we not only have a successful TLS handshake, 
> which means we have "trusted" the CA that signed the 
> certificate. Before the application should do step 2 below, 
> it must be able to look up the servers credentials (its 
> Certificate) and decide whether to trust the server with the 
> "placeOrder" request. Trust in the authentication need not be 
> the same as trust in the server.
> > 2. client needs to submit a sell trade, so it invokes placeOrder() 
> > passing all sorts of sensitive information, i.e. its 
> account number, 
> > PIN etc.
> >   
> Presumably, the client has done a trust evaluation and trusts 
> the authenticated server at this point.
> > 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.
> >
> >   
> Now, I'm not sure what you mean by "later". 2 Scenarios:
> 3a. Using HTTP/S connection has not dropped.
>        The application has decided to trust the server with 
> placeOrder info,
>        so it assumes giving it a getQuote is okay.
>       Using HTTP/S connection has been reestablished
>         The application looks up the servers credentials, and 
> makes another trust
>         determination. If its the same server, sure. If not, 
> it may or may not
>         place the getQuote() depending on its trust 
> evaluation for getQuote information.
> 3b. Using HTTP
>        The application may assume since it's only innocuous 
> information,
>         it will do the getQuote operation passing along 
> innocuous information.
> > 4. the endpoint reacts to the getQuote with a 401, challenging the 
> > client to provide its Basic auth creds
> >
> >   
> No problem here. If the server requires username/password, 
> the client better have one, or the service is denied, TLS or 
> no TLS. Plain and simple. 
> What's the client going to do? Complain to the Queen? :)
> 
> > 5. now the client applies an extra level of scrutiny before 
> providing 
> > its creds
> >
> >   
> You are correct. I'm the client, and *me*, *myself*, and *I* happen
> *value* that information because the handbook on security 
> said not to give my username and password combination to 
> anybody, not to write it down, etc except to that particular 
> service. So, you bet your boots cowboy, I'm going to check 
> that server out before I give away the jewels. :) just as I 
> wouldn't have did a placeOrder() if the server didn't pass my 
> trust evaluation.
> > 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.
> >
> >   
> That's okay. Think of it as a kind of an access control 
> scenario placed in reverse.
> What happens in access control?
> 
> A client makes a request on a server. That server checks out 
> the client's credentials before it will let the request 
> succeed, allowing access to certain resources, data, etc.
> 
> Okay, now turn the scenario around. The server is sort of a 
> client in this way. The server advertises a Service. That 
> service in a sense is "requesting" access to the client's 
> resources, data, information. The client makes an access 
> control decision on that request.
> 
> The placeOrder operation requests sensitive information from 
> the client. 
> The client makes an access control decision of whether to 
> give that information to the server.
> 
> The 401 response code requests sensitive information from the client. 
> The client makes an access control decision of whether to 
> give that information to the server.
> 
> It's the same thing. The server is "requesting" information, 
> and the client must make an access control decision on that request.
> > 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.
> >   
> I agree. It is best to only use TLS and make a trust decision 
> based on authentication. You run into some limitations:
>     1. The server does not use TLS.
>              You don't use its services.
>     2. The server issues a 401 over HTTP only.
>              You don't use its services.
> 
> Although, it can be said the above is "good" practice, it's 
> not realistic, and not practical. Furthermore, if CXF 
> replaced remedies to 1 and 2 with "Not Supported", CXF users 
> would probably go elsewhere (instead of conform).
> 
> What would be preferable, is to provide the application 
> developer with hooks, interfaces, tools, to get at the 
> authentication information (if any), so that an application 
> may make an informed decision about whether to trust the 
> target object, endpoint, port, whatever you call it.
> 
> In Adiron's ORBAsec SL3 (Secure CORBA) there is an operation 
> on a security manager interface:
> 
>             TargetCredentials 
> getTargetCredentials(CORBA::Object target);
> 
> The application uses the TargetCredentials interface to query 
> information about the channel (authenticated or not) set up 
> to that target object.
> 
> Did I help, or did I make it worse? :-[
> 
> Cheers,
> -Polar
> > Does this make sense?
> >
> > Cheers,
> > Eoghan
> >
> >  
> >   
> >> 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 java.net.HttpUrlConnection 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
> >>>
> >>>   
> >>>       
> >>     
> 
> 

Mime
View raw message