Kirk Evans Blog

.NET From a Markup Perspective

RE: Thoughts on repudiation and surreptitious forwarding

Very cool post by Keith Brown on surreptitious forwarding and why WS-Addressing headers are signed in WS-Security messages.

Consider this scenario: Alice signs the message, “I love you“, encrypts it with Chris’s public key, and sends it to Chris. She loves Chris and wants to let him know. Chris, the villian in this story, decrypts the message, and decides to set up Bob for some embarrassment by reencrypting it with Bob’s public key and sending it to Bob. When Bob receives “I love you“, signed by Alice and encrypted so only he can read it, he will very likely be fooled! Now, if Alice had thought ahead and instead signed the message, “Chris, I love you“, this “surreptitious forwarding“ attack would have been prevented.

. . .

Soooo, what does this have to do with anything? One interesting place where these ideas are applied is in WS-Security implementations. If you’ve ever used WSE to secure a web service, you may have wondered why all those headers are included in the XML signature and not just the body of the message itself. In particular, the WS-Addressing header – why would the sender take the time to sign that? Well, now you know at least one reason why that fragment is signed. That’s the equivalent of including “To: Bob“ as part of the signed message. It helps prevent surreptitious forwarding.

[Via Pluralsight Blogs]

I hadn’t heard about this concept until about a year ago when I was doing a 3-day WSE class. Someone posed a question like, “Suppose if you tear off the encryption and leave the signature… then encrypt it again with a different token?” There are valid reasons where this might occur when you consider routing messages across multiple intermediaries with different security requirements, and security contexts that span endpoints with an intermediary in the middle. This is why WS-Addressing and WS-Security exist. But this also poses the possibility for the forwarding problem that Keith describes.

The best I could come up with on the spot was to reverse the operations using Policy… first encrypt the document, THEN sign it.