Fwd: Last call issue with ReplyTo and security

Resending due to archive problems.

Begin forwarded message:

> Resent-From: public-ws-addressing-comments@w3.org
> From: "Tim Ewald" <tim@mindreef.com>
> Date: April 18, 2005 1:51:25 PM PDT
> To: <public-ws-addressing-comments@w3.org>
> Subject: Last call issue with ReplyTo and security
> Reply-To: <tim@mindreef.com>
> Organization: MindReef
> X-Archived-At: http://www.w3.org/mid/
>
>
> As I read the spec, a compliant WS-Addressing based endpoint MUST use 
> the
> value in the ReplyTo header as the place to send a reply message. 
> Further,
> when a reply is expected, the ReplyTo header must be present. Because 
> of
> this, the section on security recommends that a service SHOULD only 
> use EPRs
> from trusted sources.
>
> My issue with this is that it isn't enough to trust the source, I have 
> to
> trust that source that it's okay to send reply messages to the 
> requested
> endpoint. I may trust one source enough to send messages to a specific,
> prearranged domain, but it is unlikely that I trust a source enough to 
> send
> messages anywhere. In the absence of that very specific trust, it seems
> reasonable that a service would trust a client enough to process the 
> request
> and to send the response back to the client on the same connection 
> (sort of
> the inverse of the Java applet sandboxing model).
>
> To implement that, a service would check for a ReplyTo header - which 
> must
> be present in the case of a reply - and check to see whether the 
> address was
> the anonymous URI. If the address is anything else, the service should 
> raise
> a fault. As I read the spec, however, that is not allowed.
>
> In short, if a ReplyTo is required and MUST be honored, then I have no
> choice but to ensure that I trust sources of EPRs enough to let them 
> tell me
> to send messages to an arbitrary address (which is a lot of trust 
> indeed!).
> If I can't do that, I have to either violate the protocol or just not 
> use
> WS-Addressing.
>
> I faced this precise issue when I worked at MSDN. We considered using 
> WSE to
> implement our services, but it honored the ReplyTo header. Since MSDN 
> offers
> services that are used by the public (indirectly via VS.NET), we didn't
> trust callers enough to get us to pummel arbitrary URIs with messages. 
> As a
> result, WSE added a feature to disable ReplyTo/FaultTo processing, and 
> they
> are disabled by default.
>
> Given the importance of security, I believe the WS-Addressing spec must
> address this issue. Simply saying that services SHOULD only use 
> endpoints
> from trusted sources is NOT sufficient.
>
> Thanks,
> Tim-
>
> _______________________
> Tim Ewald
> http://www.mindreef.com
>
>
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Monday, 25 April 2005 19:31:32 UTC