[Sip] Re: Review of draft-ietf-sip-media-security-requirements-00
Richard Barnes <rbarnes@bbn.com> Tue, 06 November 2007 16:51 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRea-0003YF-J9; Tue, 06 Nov 2007 11:51:52 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IpReZ-0003V0-A2 for sip-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 11:51:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpReY-0003Ts-V0 for sip@ietf.org; Tue, 06 Nov 2007 11:51:51 -0500
Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpReY-0004XB-G8 for sip@ietf.org; Tue, 06 Nov 2007 11:51:50 -0500
Received: from dommiel.bbn.com ([192.1.122.15] helo=localhost.localdomain) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <rbarnes@bbn.com>) id 1IpReV-0002SQ-5I; Tue, 06 Nov 2007 11:51:47 -0500
Message-ID: <47309BA1.7090405@bbn.com>
Date: Tue, 06 Nov 2007 11:51:45 -0500
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.5 (X11/20070727)
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <47080AF8.9060303@bbn.com> <033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
In-Reply-To: <033c01c81fe7$cffe11e0$c4f0200a@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 'IETF SIP List' <sip@ietf.org>, 'Francois Audet' <audet@nortel.com>, "'Fries, Steffen'" <steffen.fries@siemens.com>
Subject: [Sip] Re: Review of draft-ietf-sip-media-security-requirements-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Dan, I agree that R23 and R25 aren't necessarily related to lawful intercept, but all three requirements are related to third parties having access to plain-text media -- and the whole point of encrypting data is to protect it against access by unauthorized third parties. In order to provide access to these parties (quality of service, law enforcement, or middleboxes) and still provide security, either (1) the protocol needs to have some mechanism for explicitly authorizing these users, or (2) there needs to be an out-of-band mechanism like draft-wing-sipping-srtp-key. Option (1) (explicit authorization) is (IMO) the much less appealing option: 1. It directly conflicts with R24, since it enables the endpoints to be aware that another party is being given access. 2. It means that the requirements can only be satisfied by a multi-party / multicast keying protocol (since it has to assume that there are at least three parties to a call). 3. It adds hard authentication requirements (so that not just anyone can be the listening party), which will hinder deployment Option (2), on the other hand, requires no text in the media security requirements. It provides the same functionality, with two caveats: 1. One endpoint has to be willing to transmit the keys to the listener. In a enterprise network, this isn't a problem, since endpoints are tightly controlled. A VSP that wants to provide lawful intercept can just block SRTP calls that don't provide a key. 2. The listener has to be willing to tolerate the delay induced by routing the keys through SIP. AFAIK, there are no requirements for real-time recording or lawful intercept, but this may be a small problem for middleboxes. So on the whole, it seems to me like option (2) covers at least two of the three use cases you've proposed. --Richard > R23 refers only to recording of media. This is necessary in many > business environments such as banks, stock brokers, catalog ordering call > centers, and so on. This is a requirement for many businesses. It > is not yet clear if draft-wing-sipping-srtp-key (or something like it) > meets requirement R23. It seems like does, provided that (1) endpoints are willing to send key to authorized listeners, and (2) the delay induced by SIP is tolerable. Both of these would seem to be true in the enterprise environments you describe. > I agree R24 refers to lawful intercept. This is a requirement from > other SDOs that need to provide lawful intercept with their solutions. > > Another email on R24 lawful intercept will be forthcoming shortly. > R25 reference to 'intermediate nodes' is to transcoders and SBCs which > handle signaling and media traffic. It seems important that any keying > mechanism work with such intermediate nodes, as those intermediate nodes > are common on many SIP networks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Review of draft-ietf-sip-media-security-req… Richard Barnes
- RE: [Sip] Review of draft-ietf-sip-media-security… Fries, Steffen
- [Sip] RE: Review of draft-ietf-sip-media-security… Dan Wing
- Re: [Sip] RE: Review of draft-ietf-sip-media-secu… Matt Lepinski
- RE: [Sip] RE: Review of draft-ietf-sip-media-secu… Dan Wing
- [Sip] Re: Review of draft-ietf-sip-media-security… Richard Barnes
- [Sip] RE: Review of draft-ietf-sip-media-security… Dan Wing
- [Sip] Re: Review of draft-ietf-sip-media-security… Richard Barnes