[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