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

Leon Portman <> Wed, 27 April 2011 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85BE9E0813; Wed, 27 Apr 2011 12:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.436
X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PupPOdgyRJu1; Wed, 27 Apr 2011 12:23:26 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 75A6DE081D; Wed, 27 Apr 2011 12:23:26 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Wed, 27 Apr 2011 22:23:25 +0300
From: Leon Portman <>
To: Tobias Gondrom <>, "" <>, "" <>, "" <>, "Elwell, John" <>
Date: Wed, 27 Apr 2011 22:23:24 +0300
Thread-Topic: Secdir review of draft-ietf-siprec-req
Thread-Index: Acv8euVMl1LykO0rTty0WyAVR/HTFgIh1B4A
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, he-IL
Content-Language: en-US
acceptlanguage: en-US, he-IL
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 29 Apr 2011 03:03:00 -0700
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-siprec-req
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Apr 2011 19:23:27 -0000

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


-----Original Message-----
From: Tobias Gondrom [] 
Sent: Sunday, April 17, 2011 12:12 AM
Cc:; Leon Portman;;
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.

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.