Dean, More in-line.
John > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: 08 November 2007 15:10 > To: Elwell, John > Cc: Dan Wing; IETF SIP List > Subject: Re: [Sip] media-security-requirements and lawful intercept > > > On Nov 8, 2007, at 3:41 AM, Elwell, John wrote: > > > Dean, > > > > Yes, I tend to agree that key disclosure to an authority on > all calls > > passing through a domain with LI capability might be the > way to go, > > but > > even then I see problems. > > > > No doubt. > > > A UA has home domain A that is not required to do LI (an enterprise, > > say). On a call by call basis, the UA does not know whether the call > > will be routed (directly or indirectly) to a particular > domain B that > > does LI (a carrier, say), so how does the UA find out that > it needs to > > report its key to carrier B (or C or D....)? > > The domain would have to get (and submit) the key for every > call sent > out through a regulated carrier. > > I believe it's OK for a user to know whether a given call is being > routed over a private network/Internet or is going through a > regulated carrier, and therefore to know that any call being sent > over the regulated carrier may be subject to LI. [JRE] He would need to be made aware of this somehow. Often he can't tell in advance whether a call is to be routed via a carrier or not. > > > Also, by doing this, any notion of end-to-end security has > gone out of > > the window. If the key is disclosed to a third party, can the call > > really be used for sending banking details etc.? Surely the business > > world needs end-to-end security (or at least > end-domain-to-end-domain > > security), as we have with HTTPS? > > Banks take calls over the PSTN every day with less assurance of > integrity and privacy. The proposed approach provides much better > security -- with "how much better" being limited by the scope of the > key distribution. Optionally, one could propose the use of > public-key > or identity based crypto to further defend the session key, for > example only sending it after encrypting it with the public key of > the intended recipient. [JRE] Yes, of course any key disclosure would itself need to be protected. I guess I am reasonably happy with submitting a key to a known law enforcement authority (or perhaps to my enterprise, which then forwards it to a known law enforcement authority), but I am far less happy about having to send it to any carrier that happens to get involved in the routing of that outgoing or incoming call. > > Many financial and legal operations record every call, and therefore > need a recorder that is either "in the session with a key" or on a > second session that gets a twinning of the media. Some courts might > argue that the second-session recording is inadmissible because it > might have been undetectably altered (it wasn't exactly the same > packets as received by the other end), so there are business legal > reasons to have the recorder in the main media path. > Eventually we're > going to have media-level non-repudiation issues, so if you're > looking for a Ph. D. project, that would be a good place to look. > > I'm sure the auditing organizations will require record keeping on > where the key goes and which systems have access to it, just as they > are beginning to require around all credit-card transactions. > > Sure, I want my calls to be as secure as possible. But there are > operational environments where end-to-end crypto just isn't going to > work. [JRE] I agree with most of what you say above, and within an enterprise this is OK. After all, an RFC 4474 signature by example.com only guarantees the integrity of the message from the example.com domain onwards, and what happens in that domain, such as recording for auditing purposes, is fair game. What I don't want to do is have some intermediate domain getting in and decrypting the media, unless there is some assurance that it is for authorised law enforcement purposes only. > > We're at a decision point here -- do we follow RFC 1984 to the > fullest extent and design a secure protocol that will have limited > applicability, or do we design a protocol with broader applicability > that has explicitly negotiated key sharing? [JRE] I think we have to do the latter, but we should be very careful what mechanism we select. > > -- > Dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
