Well, we had this problem in CORBA versioning as well, not only in
security, but just in applications. Geez, what happens if the server
adds (or even worse) changes operations?
What if you didn't update the client? There was a service that took
care of all this and provided answers, it came from
resolve_initial_references("CrystalBall"). (I'm joking). :-)
From your example, I think I have have figured out why we are
misunderstanding each other.
My goal is NOT to decouple the security from the application.
I am looking to give the application developer the tools make security
an *integral* part of the application being developed. Therefore, I do
not see the versioning to be more of a problem than the application
itself, the security code must be developed "lock step" with it, as you say.
The client may make all kinds of trust decisions, not only based on the
operation, but the data it wants to give the target.
makeSureServiceIsTrusted(service);
if (patient.isCelebrity()) {
makeSureServiceIsSufficientlyEncrypted(service);
service.submitMedicalData(patient);
} else {
// We don't care if it's encrypted or not.
service.submitMedicalData(patient);
}
The same goes for the server side. For instance, you may deny some
clients the ability to "placeOrder" over 10,000 Euros based on their
certificate, etc.
Cheers,
-Polar
Glynn, Eoghan wrote:
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:[EMAIL PROTECTED]
Sent: 13 February 2007 15:02
To: [email protected]
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:[EMAIL PROTECTED]
Sent: 12 February 2007 17:57
To: [email protected]
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
