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

["Shawn Sharp" <ssharp@cyclonecommerce.com>]

Hi Hal, 

Thanks for the response. Residual concerns expressed in-line.


> 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.

DaleMoberg> Well, I was really worried about the "wsse header block 
DaleMoberg> greater than 1" aspect of the models.

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".])

DaleMoberg>> I think this seems to be putting a happy face on a less 
DaleMoberg>> than happy situation. Interleaving style problems combining

DaleMoberg>> XMLEncryption, XMLDsig, and SOAP intermediaries are not 
DaleMoberg>> problems of somebody getting away with something. They are 
DaleMoberg>> problems of what should have been able to work reliably 
DaleMoberg>> having unexpected breakages sometimes. That does not seem, 
DaleMoberg>> to me, a very satisfying situation to leave the situation 
DaleMoberg>> in. People should at least be warned of the down side here,

DaleMoberg>> and get the usual spec writer's wisdom: "Bad things happen 
DaleMoberg>> to you when you interleave wsse header blocks? Then don't 
DaleMoberg>> do it."


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

Not at issue.

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.

DaleMoberg> OK, but I was hoping that I would have some basis for 
DaleMoberg> telling when I have multiple wsse: header blocks what the 
DaleMoberg> order was. That was the critical part of the model that I 
DaleMoberg> was urging you to review, cardinality of wsse header blocks 
DaleMoberg> greater than one, and how I determine the correct order. I 
DaleMoberg> guess we could leave it as a matter of bilateral agreement 
DaleMoberg> if participants plan to have it work reliably.

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

Dale> Worried about more than one block...

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.

Dale> OK are the editors including this explicitly? I think that is 
Dale> important to state.



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.

Dale> OK, I guess I had missed point 6 previously. As long as this is 
Dale> stated quite clearly, mission accomplished.


Thanks,
Dale Moberg

-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com] 
Sent: Wednesday, August 13, 2003 7:14 AM
To: Dale Moberg
Cc: Shawn Sharp; wss@lists.oasis-open.org
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