Hi Glen,
Thanks for the comments. Some responses in-line, though these are
more ramblings, than anything else. Please excuse any straw-man
arguments I make, as you may have already considered a lot of this.
On Jun 20, 2008, at 5:05 PM, Glen Mazza wrote:
As for WS-SecureConversation, AFAICT it is just a generalization of
WS-Security[1]--the tokens (of whatever type, Kerberos, SAML,
UsernameToken,
or whatever) are not continually regenerated/resent for each reply/
request.
It's primarily a performance issue--WS-SC makes things faster.
Well I suspect it does that, but WS-SecConv is really capable of more
than that (IMO). I think part of what you're saying is that the WS-
SecConv "protocol" (if you will) lets you set up security contexts, so
that you don't have to replay the same token over and over, and
instead you can maintain some sort of state between a client and
server. This makes perfect sense, and it's definitely something you'd
want to be able to do.
The question then becomes, okay, so now you have this session
identifier you can use, instead of a "real" credential. How do you
protect this session identifier, so that someone listening in can't
steal it and use it on your behalf?
Your answer might be, "just use SSL", but I submit while that's a
workable answer for some scenarios, it's actually a fairly weak story,
in the general case.
Here are a few reasons why I think this.
1. Your session/state management code is going to have to track
session ids against client identities; otherwise, you've really got no
guarantee that the client is really the client you think s/he is. You
might try to "wing it", and reason, "Hey, we're using SSL here, so
there's a good chance that the session identifiers have not been
disclosed". But that's putting a lot of trust in a system, not trust
inherent in the infrastructure, itself. I personally try to steer
clear of systems like that (knowing full well it's the kind of systems
our banking infrastructure is built on :)
2. If you're associating session ids with client identities, your
client identities are going to have to be based on some non-
repudiatable credential, and if we're talking SSL, then you're forced
to use client certificates for all your clients. Unfortunately, this
can get pretty expensive, if you're contraction out your certificate
management. It also means you have a real key distribution problem on
your hands (assuming lots of clients to relatively few servers).
There's a reason SSL defaults to server authentication only -- client
certs are simply a PITA, and no one I've worked with likes to deal
with them.
(It may be that for some narrowly constrained cases, like middle-tiers
talking to back-end services, that client certs makes sense, but in
general I would submit that SSL does not scale well, when it comes to
client certificates, despite the fact that public key crypto has been
billed as a scalable solution to symmetric key distribution)
3. SSL is point to point, not end to end. So if you have an
intermediate in your mix, like a JMS broker, then forget about client
and certificate authentication, all together. You can authenticate
your broker, but from a skeptical security professional's point of
view, BFD. That and a nickel will get you a cuppa joe.
4. Some transports simply don't support SSL. So, we have HTTP and
IIOP support, but CXF is supposed to be "oh so much more than that".
What happens if you have a protocol that just hasn't been implemented
over SSL? Then we're kinda stuck.
(Again, if the above is a straw-man, from your point of view, I
apologize, and let's just shelve the arguments as common understanding)
So, a nice alternative approach is to use WS-Security, itself, to do
what SSL would otherwise do, viz., to provide encryption
(confidentiality) and signing (integrity) support, at the SOAP layer,
rather than down at the transport. The nice thing about that is that
it's truly end-to-end, sort of like using GPG for email -- screw the
bloody MTAs and the NSA in between -- they can't crack the crypto in
the playload.
The problem then becomes, WS-Security typically is deployed (and CXF
uses it this way) as a public-key crypto engine (WSS4J is capable of
symmetric-key crypto -- more on that below); senders sign with private
keys and encrypt with public keys, and receivers verify with public
keys and decrypt with private keys. It works, but it's /painfully/
slow and inefficient.
So I think the other part of WS-SecConv is to allow session key
derivation from sent tokens (a password, for example). From these /
symmetric/ session keys, clients and servers can then exchange
messages in a manner that is a lot more efficient that they would
using public keys.
The question then becomes, what material is sufficient for the
generation of a session key? Must it be a secret (e.g., a password)?
If so, how does one protect its transmission?
There are clearly answers to this, but my personal feeling is, they
are more or less reinventions of what's already been done with
Kerberos, and don't make any significant contributions to the level of
protection already provided by it.
So I'm not
exactly clear when you write "I think the right way to tackle that
is to
integrate with Kerberos and the GSS-API"--I think, whatever you do
WS-SC-wise, would need to be generalized for *all* token profiles,
not just
Kerberos. But I'm hardly the most knowledgable on this stuff.
The kerberos token profile, in WS-Security, provdies a standardized
slot for a GSS-Kerberos AP_REQ token to get sent through as WS-
Security header. The GSS-API is an API, combined with a specific
security mechanism, (like Kerberos -- though Kerberos is one of many),
for creating tokens appropriate for security context negotiation, and
the eventual creation of a security context (as a logical
abstraction), which in turn can be used to sign, encrypt, and
authenticate messages sent between two entities (a client and server,
for example).
So while I agree that most seem to think of a kerberos token as just
another kind of security token, to be used as evidence of client
identity, I think that approach severely overlooks and diminishes the
true power of the Needham-Shroeder authentication protocol. The
tokens you send through the WS-Security token profile are actually the
kinds of token that can and should be used as part of security context
establishment between clients and servers, per the WS-
SecureConversation spec.
It turns out that IBM has a paper on exactly how to do this:
http://www.ibm.com/developerworks/library/specification/ws-seckerb/
and IMO this is an incredibly powerful way to leverage the WS-
SecureConversation spec; you'd essentially achieve single sign-on into
your web services tier, based solely on your OS (or windows domain)
login, and not based on possession or even submission of a secret (to
wit, a password), and we all know how much passwords suck.
So, perhaps that's too a lofty goal for the CXF community -- perhaps
CXF developers are after smaller game, like leveraging WS-SecConv to
do key derivation, and symmetric key crypto from there. And that's
fine. But I personally think the value of that, while very good for
some scenarios, is still likely to be password-based, and therefore
weak, from a security point of view. Not bad. And maybe people will
even use it. But it's not as compelling a story as you could
otherwise tell.
-Fred
