Re: Proposal for lc87 and lc55

Hi Marc.

* Marc Hadley <Marc.Hadley@Sun.COM> [2005-06-20 14:12-0400]
> In fulfillment of my action item to make a concrete proposal for  
> issue lc87[1], please find attached replacement text for section 4 of  
> WS-Addr Core and section 6 of WS-Addr SOAP Binding. This was  
> developed in collaboration with Gudge and Jonathan.
[…]

Please find comments and questions below.

> -- cut here --
> 
> X. Security Considerations (Core)
[…]
> 
> (ii) Users of EPRs should only use EPRs from sources they trust. The  
> required trust has two aspects:
> 
> (a) that the EPR was obtained from a trusted source

This seems circular: "Users of EPRs should only use EPRs from sources
they trust. […] (a) that the EPR was obtained from a trusted source"

How about:

  (ii) Users of EPRs should validate the trustworthiness of an EPR
  before using it, considering the two following aspects:

> (b) that it was obtained from a source with authority to represent  
> the [destination] of that EPR.

EPRs don't have a [destination] property. Did you mean [address]? Did
you mean the (physical) destination of the message, considering that
[address] may be a logical address?

Note that there are other instances of "[destination] of that EPR"
below, too.

[…]
> X.X Establishing EPR Trust
> 
> There are many mechanisms that could be used to supply proof that a  
> message sender has authority to represent the [destination] of EPRs  
> supplied within the message. This section defines one such mechanism  
> that SHOULD be supported.

Until now, the proposed text was written in casual English, and all of
a sudden there's an uppercase SHOULD. This seems to be a problem as…

> When using this mechanism, a message MUST include a WS-Security[WS- 
> Security] header that contains XML digital signatures binding the  
> wsa:ReplyTo and wsa:FaultTo elements to the SOAP message using an X. 
> 509 certificate issued by a mutually trusted certificate authority  
> (establishment of certificate authority trust is outside the scope of  
> this specification) for the domain addressed by the [destination] of  
> the EPR. Possession of a certificate signed by a trusted certificate  
> authority for the domain addressed by the [destination] of the EPR  
> provides a level of confidence that the message sender has authority  
> to represent the [destination].

… two sentences to define a mechanism that is recommended seem very
light.

Some arbitrary choices have been made, such as the use of X.509. Why
is that?

It also calls for questions like (having received some help from my
colleague Thomas Roessler, copied on this email; note that this list
is not exhaustive):
- how is the domain matching done? A reference to PKIX should be added
  as there seem to be several ways of establishing this, e.g.
  subjectAltName extension from PKIX vs. Common Name part of the
  Subject, I am being told.
- does this mean a certificate that refers to the exact domain name,
  or do you want to apply certificates to arbitrary subdomains?
- why does the certificate need to be mutually trusted? Only the EPR
  user should need to trust the signature.

Therefore, I believe that this mechanism should be presented as an
example of how to establish trust rather than as a recommended
technique.

Here is a concrete proposal to address this:
- replace "This section defines one such mechanism that SHOULD be
  supported" by "Below is an example of such a mechanism"
- replace "When using this mechanism, a message MUST include a
  WS-Security header" by "Use a WS-Security header"
- remove "mutually" (see comment above)

> X.X Additional Security Considerations
> 
> The wsa:isReferenceParameter attribute is only meaningful on SOAP
> headers. Message processors should consider its appearance elsewhere in
> a SOAP message as a possible attack.
> 
> Message processors should consider elements from the soap11 and soap12
> namespace appearing as reference parameters in an EPR as a possible
> attack.
> 
> <ednote>We should discuss whether WS-Addr elements as reference  
> parameters also pose a risk. Certainly being able to include an  
> Action, ReplyTo or FaultTo as a ref param seems to open up some  
> interesting avenues for attack.</ednote>

How about the text used for LC77[2]?

Regards,

Hugo

  2. http://www.w3.org/2002/ws/addr/lc-issues/#lc77
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/