The Gap Between Reliability and Security Eric Gravengaard

The Gap Between Reliability and Security Eric Gravengaard Reactivity slide 1

A Fully Secure and Reliable Message Exchange • Request – Response Message Exchange Pattern • Both parties must require of the other: • Strong Authentication - Is this message from the right system? • Cryptographic Proof of Message Integrity - Has this message been tampered with? • Acknowledgement of Message Delivery - Did they get my message? • And the requesting party Must require: • Strong Correlation between Request and Response 2

Why is Correlation Important? • Example: • • Alice wants to ask Bob to add two numbers using his calculator creates a SOAP message and signs it: Add(1, 3) sends the message to Bob receives a response signed by Bob: 5 • Questions: • Is there a simple and secure way to know that Add(1, 3) = 5? • Did Bob receive Add(1, 3) or did Charlie intercept the message and send Add(1, 4)? • Did Charlie intercept the response and substitute an old copy of a signed response from Bob? • Can Alice trust that Bob really checked her signature? • Can she prove it? 3

The Gap • OASIS Web Services Security: SOAP Message Security • Defines Use of Digital Signatures to prove Integrity of Message - Signature Proves Message was not Altered • OASIS WS-Reliability • Guaranteed Delivery with Acknowledgement • Combining the Two • Responder Proves to Requester That A Message was Delivered • Not what was in the message • The Gap – No Receipts • No standardized mechanism for requesting delivery acknowledgements that include information about the message 4

How can receipts be used? In a simple client/server request/response system: • The Client • Composes a request • Signs the request with its private key • The Server John: my review Please a opy of draft c f tion o declara dence. indepen lin n Frank Benjami BF • Composes a response and attaches a receipt • Signs the response and receipt with its private key • Both Parties • Validate signatures • Write logs at each step Ben: r ved you I recei e r a e Her draft. my some of. s t n comme ncock John Ha JH 5

What can we prove? • The secure logs prove: • That a transaction occurred • That our record of the transaction has not been altered • The signatures prove: • Server can prove that someone with the client’s private key sent the request • Client can prove that someone with the server’s private key returned the response and the receipt together • The receipt proves: • Client can prove that someone with the sender’s private key received their request and that the response message is in response to the original request 6

How is this Done Outside of Web Services? • Enhanced Security Services for S/MIME • RFC 2634 • Defines Signed Receipts • Allows Originator to demonstrate to a Third Party that the Recipient was able to verify the signature of the original message • The Receipt itself is Signed by the Recipient • Secure Data Network System: Message Security Protocol • SDN. 701 • Also defines signed receipts as a mechanism for verifying that the receiver has validated a signature 7

Web Services Security: Receipt Token Profile • WSS: SOAP Message Security does not provide a mechanism for receipts WSS: RTP is Reactivity’s proposed extension to WSS that: • Creates a new security token for requesting receipts • Creates a new security token for receipts • Defines both signed and unsigned receipts • Works alongside Guaranteed Delivery: WS-Reliability 8

RTP receipt mechanism • Provide a general purpose receipt request mechanism • <wsnr: Receipt. Request> provides: • • • /Receipt. Request/@Receipt. Format : signed or unsigned request /Receipt. Request/@Correlation. Id : UUID for tracking receipts /Receipt. Request/Receipt. To : how to send receipt /Receipt. Request/Signature. Request : what elements to be signed /Receipt. Request/wsu: Time. Stamp : when this request was made • <wsnr: Receipt> provides: • • 9 /Receipt/@Receipt. Format : signed or unsigned receipt /Receipt/@Correlation. Id : same UUID as request /Receipt/Signature. Response : signature of receipt generator /Receipt/wsu: Time. Stamp : when this receipt was generated

Receipt example Request <wsse: Security> <Receipt. Request Receipt. Format="general. Receipt" Correlation. Id="33485"> <Receipt. To Required="true" Target="response"/> <wsu: Timestamp> <wsu: Created>2003 -03 -11 T 16: 30: 17 Z</wsu: Created> </wsu: Timestamp> </Receipt. Request> </wsse: Security> <Receipt. Format="general. Receipt" Correlation. Id="33485"> <wsu: Timestamp> <wsu: Received>2003 -03 -11 T 16: 33: 43 Z</wsu: Received> </wsu: Timestamp> </Receipt> </wsse: Security> 10 Response

Signed receipts • Main concept: Split the <ds: Signature> into two pieces • Requestor specifies a <wsnr: Signature. Request> element: • /Signature. Request/ds: Signed. Info : specifies algorithms and data to be signed by receipt generator • /Signature. Request/ds: Object : allows other data to be included in the signature • Responder returns a <wsnr: Signature. Response> element: • /Signature. Response/ds: Signature. Value : cryptographic signature that covers the <ds: Signed. Info> of the request • /Signature. Response/ds: Key. Info : specifies information about the key used to generate the signature 11

Bringing it all together: an example <S: Envelope xmlns: S=". . . "> <S: Header> <wsse: Security> <wsnr: Receipt. Request Receipt. Format="signed. Receipt" Role="ultimate. Receiver" Correlation. ID="the. ID“ S: must. Understand="1"> <wsnr: Receipt. To Target="response"> <wsnr: Signature. Request> <ds: Signed. Info> <ds: Canonicalization. Method Algorithm="#c 14 n"/> <ds: Signature. Method Algorithm="#hmac-sha 1"/> <ds: Reference URI="#body"> <ds: Digest. Method Algorithm="#sha 1"/> </ds: Reference> <ds: Reference URI="#timestamp"> <ds: Digest. Method Algorithm="#sha 1"/> </ds: Reference> </ds: Signed. Info> </wsnr: Signature. Request> </wsnr: Receipt. To> <wsu: Timestamp wsu: Id="timestamp"> <wsu: Created>2003 -03 -11 T 08: 42: 00 Z</wsu: Created> </wsu: Timestamp> </wsnr: Receipt. Request> </wsse: Security> </S: Header> <S: Body> <My. Request wsu: Id="body"/> </S: Body> </S: Envelope> 12 <S: Envelope xmlns: S=". . . "> <S: Header> <wsse: Security S: Role="ultimate. Receiver"> <wsse: Binary. Security. Token wsu: Id="#the. Cert“ Encoding. Type="Base 64 Binary"> MIIEZz. CCA 9 Cg. AWIQEmt. JZco. . . </wsse: Binary. Security. Token> <wsnr: Receipt. Format="signed. Receipt“ Correlation. ID="the. ID"> <wsnr: Signature. Response> <ds: Signature. Value> ABCDEFG 1234567890. . . </ds: Signature. Value> <ds: Key. Info> <wsse: Security. Token. Reference> <wsse: Reference URI="#the. Cert"/> </wsse: Security. Token. Reference> </ds: Key. Info> </wsnr: Signature. Response> <wsu: Timestamp> <wsu: Received>2003 -03 -11 T 08: 42: 12 Z</wsu: Received> </wsu: Timestamp> </wsnr: Receipt> </wsse: Security> </S: Header> <S: Body> <My. Response/> </S: Body> </S: Envelope>

Questions • If you have further questions or would like to read the proposed profile document: • Email: eric@reactivity. com • Web: www. reactivity. com 13