Re: [secdir] Secdir review of draft-ietf-siprec-req

[Leon Portman <[e-mail]>]

Tobias Hello

Thank you very much for the review.

Is the adding the  following paragraph to the security section can clarify better your point below:

"A malicious or corrupt SRC can tamper with media and metadata relating to a CS before sending to an SRS. Also CS media and signaling can be tampered with in the network prior to reaching an SRC, unless proper means are provided to ensure integrity protection during transmission on the CS. Means for ensuring the integrity and correctness of media and metadata emitted by an SRC are outside the scope of this work. Other organizational and technical controls will need to be used to prevent tampering."

Regarding your personal note below, currently this issue is out of scope for SIPREC working group, however we definitely should give some thought regarding it.

Thank you very much again

Leon

-----Original Message-----
From: Tobias Gondrom [mailto:[e-mail]] 
Sent: Sunday, April 17, 2011 12:12 AM
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; Leon Portman; [e-mail]; [e-mail]
Subject: Secdir review of draft-ietf-siprec-req

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


http://www.ietf.org/id/draft-ietf-siprec-req-09.txt

The document is informational and describes use cases and requirements for SIP-based Media Recording.
Overall I agree with the stated requirements in the document and consider the Privacy and Security Considerations sufficient.

Privacy and Security sections could be enhanced by clarifying that the integrity and correctness of the recorded data is not ensured by
(cryptographic) means to ensure that the CS has not been tampered with (also see below). At least AFAIK. This would have to be done by organizational and technical controls that prevent tampering with the recording UA and the data stream between end point UA and SRC.

Best regards, Tobias



Ps.: On a personal note a small suggestion/idea for the authors:

- it seem the non-repudiation, authenticity and completeness (no dropped
packets) of recorded CS linked to individual participants is basically unproven (if not impossible to prove in this setting?). I.e. an evil recording entity might twist incoming streams from participants to re-align given answers to different points in the stream or re-align its own statements.
E.g. actual dialogue:
1. participant A "Do you want to buy this product?" 
2. participant B: "No."
3. participant A "Do you want to abort this operation?"
4. participant B: "Yes."

Could be twisted to:
1. participant A "Do you want to buy this product?" 
4. participant B: "Yes."
3. participant A "Do you want to abort this operation?"
2. participant B: "No."

or with only control of your own recorded data-stream:
3. participant A "Do you want to abort this operation?"
2. participant B: "No."
1. participant A "Do you want to buy this product?" 
4. participant B: "Yes."

I wonder whether authentication means (like signing) your session stream with a personal key and chronology integrity ensuring mechanisms (reliably linking messages to timestamps or previous messages from the other party) would be worth consideration and could prevent such an attack.