& XSLT >  You have mentioned this before, but is there anything 
>  which stops you from using TLS/SSL on all the hops
>  *after* the firewall?

No, but you lose the ability to authenticate the original client with 
SSL client certs. It also requires the server to have complete trust in 
the operation and bug-free-ness of any intermediate SSL hops.  In 
essence, you have to trust the SSL intermediary as much as you trust the 
server itself.  But if you do that, then why is it in the DMZ? :)

>  That first GET is for the hypertext that contains the POE link, correct.

So the first part of using POE to make HTTP reliable is to double the 
number of HTTP interactions.  And then, of course, you have the issue of 
the unreliability of the initial GET.  I'm not saying that to be cute, 
but if the GET-POE-link fails, the server could possible have "stranded" 
URL's waiting for the client to GET the POST response.  (Er, that 
wording's a bit muddled, but I hope you see what I mean.)

>  What I don't understand is the underlying assumption that 
>  Basic and Digest are the end of the line for HTTP authentication.

Probably because there's been effectively no work done in the past 
decade.  The two mechanisms you mention -- WS-Security UserName profile, 
and Atom authentication -- are the same thing as Digest or BasicAuth in 
that they require a shared secret between the client and server.  (And 
is it really true that the second mechanism only exists because of a 
mis-feature in Apache CGI?)

User-chosen passwords are notoriously easy to guess.  The WS-Security 
UserName profile puts the password at the end of the digest, meaning an 
attacker can pre-compute the first part of the SHA based solely on the 
plaintext.  It's done that way on purpose, but understand the 
trade-offs.  It's also unfortunate that Atom WSSE didn't include any of 
the countermeasures described in the standard.  (See lines 132-154 of 
the standard.)

Like Digest and BasicAuth, the two you mentioned require both parties to 
use that shared secret on every interaction.  It's just like having to 
type your password into the shell after every command.

	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>