RE: Passwords in the Clear

> I believe that the TAG should not suggest that the use of SOAP equates
> or implies to the use of WS-Security, XML Sig or XML Encrypt. The
> evaluation of need or worth in using these technologies involves
> concrete analysis of threats in an economic context, and cannot be
> satisifed by ex-cathedra TAG-level pronouncements.

The draft TAG finding already points to a document [1] that suggests doing just the kind of threat analysis you are asking for.  I suggested that the TAG add this reference in my message [2].

If you review the referenced document I think you will find that it fairly treats the tradeoff between using TLS and message level security as alternatives to meet various threats.

/paulc

[1] http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf
[2] http://lists.w3.org/Archives/Public/www-tag/2006Oct/0023.html

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:Paul.Cotton@microsoft.com





> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
> Alastair.Green@barclayscapital.com
> Sent: December 12, 2006 7:29 AM
> To: www-tag@w3.org
> Cc: alastair.green@choreology.com
> Subject: Passwords in the Clear
>
>
> I have two comments on
>
> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html
>
> Can I first make it clear that these opinions are personal, and in no
> way should be considered as representing or stemming from Barclays
> Capital, where I am only acting as a temporary consultant.
>
> 1. While Digest Auth and Basic Auth/HTTPS satisfy the criterion: don't
> send passwords in the clear, they are not the only authentication
> mechanisms that fulfil that criterion. Most obviously, NTLM is used very
> widely (a fact attested to by its support in Firefox). There are many
> other secure protocols for authentication (Kerberios, SRP, for example),
> and ones that may not have yet been invented, that could be used (or
> adapted for use with) HTTP.
>
> Conclusion: I think that the architectural statement should be something
> like:
>
> "In the [previously defined] normal case, passwords MUST be
> significantly protected from unauthorized observation. This can be
> achieved either a) by ensuring that insecure authentication protocol
> (e.g Basic Authentication) exchanges are encrypted either at the
> transport level (e.g. by use of SSL/TLS), or by message-level
> encryption, or b) by using an authentication protocol that hashes (and
> does not simply encode) the password on the wire (e.g. Digest
> Authentication, NTLM Authentication)."
>
> This approach is more realistic (reflects practice better), less
> prescriptive, and more future-proof.
>
> 2. The statement about SOAP is misguided. There is a vendor-induced push
> to get users into the world of message-level security. WS-Security and
> its many allied specs, incarnate that push. However, for end users it is
> far from clear that transport-level security should be disdained, or
> that TLS has truly run its course.
>
> There is nothing magical or unique about SOAP's relationship to HTTP.
> Any protocol that is logically layered on HTTP may involved the use of
> intermediaries. For that matter, HTTP is used with intermediaries
> (proxies, reverse-proxies/gateways) all the time. Real-world topologies
> involve multiple barrier (firewall, load-balancer, specialized gateway)
> processors in the chain from application endpoint A to applicaton
> endpoint B. It is unclear that the cost-risk balance of using MLS is
> justified in all or even most cases where traffic is carried from an
> edge endpoint (which could act as a TLS termination endpoint) to
> internal systems which serve applications. And, if that requirement were
> real, then it would apply equally to all traffic to web/app servers,
> irrespective of the super-HTTP protocol being employed (SOAP, bespoke
> app exchanges etc). If the intermediaries are internal to an
> organization then it is even less clear that they should not be trusted.
>
>
> I believe that the TAG should not suggest that the use of SOAP equates
> or implies to the use of WS-Security, XML Sig or XML Encrypt. The
> evaluation of need or worth in using these technologies involves
> concrete analysis of threats in an economic context, and cannot be
> satisifed by ex-cathedra TAG-level pronouncements. Any mention of
> WS-Security and its friends should simultaneously invite consideration
> of the use of TLS, and the notion of message-level security should not
> be tied to SOAP (perhaps not even to XML).
>
> Contrariwise,  a ukase against passwords in the clear seems appropriate
> because a) it's a gross and inarguable security violation, and b)
> everyone has the equipment to implement the solution, even when using
> free software. Cost = 0, benefit > 0 => no-brainer.
>
> Alastair Green
> ------------------------------------------------------------------------
> For more information about Barclays Capital, please visit our web site at
> http://www.barcap.com.
>
> Internet communications are not secure and therefore the Barclays Group
> does not accept legal responsibility for the contents of this message.
> Although the Barclays Group operates anti-virus programmes, it does not
> accept responsibility for any damage whatsoever that is caused by viruses
> being passed.  Any views or opinions presented are solely those of the
> author and do not necessarily represent those of the Barclays Group.
> Replies to this email may be monitored by the Barclays Group for
> operational or business reasons.
> ------------------------------------------------------------------------
>

Received on Thursday, 14 December 2006 00:46:17 UTC