OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Issue 84 followup question on wss header blocks, intermediaries, and interleaving


Dale,

> The implicit model does not seem general enough to formulate cases that
> eventually need consideration for SOAP security situations.
>
> In the attachment, a model with more general assumptions is presented
> and an example of "interleaving" case is mentioned. These seem to me to
> be worth treating in SOAP security with intermediaries. I have not seen
> how these cases are to be dealt with. I think I agree with you that the
> XML decryption transform would not help in its present form, though.

Sorry I have been so slow in responding to this.

I don't think >3 Roles or interleaving fundamentally changes the issues. To
review, I believe we have established the following:

1. Ambiguity about the order of operations will never cause a vulnerability.
(That is to say, allow signed data to be modified or encrypted data to be
read. Routine failure of signature verification could lead to a
vulnerability if relying parties chose to ignore the failure.
[Boy-who-cried-wolf syndrome. See the movie "How to Steal a Million".])

2. Non-overlapping signatures or encryptions may be processed in any order.

3. Overlapping signatures may be processed in any order.

4. When encryptions overlap with signatures or other encryptions, the
decryptions and verifications must be applied in the reverse order that the
encryptions and signatures were performed or else spurious failures will
occur.

5. The correct order of operations indicated by a single Security header can
be determined by  the order of the elements in that header.

6. Since SOAP provides no means of specifying the order in which differently
targeted headers will be processed, the ordering of overlapped operations
specified in different headers can only be disambiguated by private
agreement or non-standard schema extensions.

7. While PK signatures can be verified by any party in possession of the
appropriate trust roots, decryption and MAC verification can only be
performed by parties in possession of the appropriate secrets. This may
limit the order in which nodes can perform processing, even in cases where
the correct order can be determined.

Comment: Sharing long term secrets between nodes in a distributed
environment (other than special cases like a KDC) is not only Bad Security
Practice, but generally not useful in practice in dealing with the issues of
overlapped operations.

I believe these points apply equally well independent of the number of
intermediaries or operations. I don't see any additional points which apply
in the interleaved case.

Hal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]