cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Re: Ideas for 2.2
Date Sun, 22 Jun 2008 20:06:24 GMT
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:

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.


View raw message