Jon, I go along with your explanation, but I still think it leaves the following problem. User A in domain A (e.g., an enterprise) makes a call to/from user B in domain B, via carrier domain C. What you describe works if domain A or domain B needs to apply LI (or record the call for any other reason - there are plenty of legitimate business reasons). I think we don't regard domains A and B as MitM. After all, we rely on domains A and B to provide the Authentication Service for RFC 4474. The issue is when domain C tries to interfere with end-to-end security in order to support LI. I do have a problem with this, because I think it undermines legitimate business security needs.
If domain C intervenes only when a LI warrant exists for one of the users, I don't personally have a problem. But this violates R24, which some people seem to think is important. If domain C intervenes all the time (either by terminating encryption in domain C, so that user A and user B see the source of security keying material as domain C, or by demanding submission of the key to domain C before admitting the call), I think this is of real concern. It means businesses cannot have the security they need when, for various reasons, they are forced to go via a domain C. So I don't think we should do anything special towards meeting R24 at a domain C. Although not the IETF's job, those concerned should work with carriers and regulators to avoid situations where a domain C can prevent normal end-to-end security on calls not subject to an LI warrant. Concerning the engineering problem to be solved, there probably isn't one if we agree that R24 does not apply to a domain C. John > -----Original Message----- > From: Peterson, Jon [mailto:[EMAIL PROTECTED] > Sent: 08 November 2007 21:18 > To: Paul Kyzivat; Ted Hardie > Cc: IETF SIP List; Elwell, John; Dan Wing; Dean Willis > Subject: RE: [Sip] media-security-requirements and lawful intercept > > > I would prefer a world where all the communications were e2e > > encrypted with no possibility of interception, in spite of > the class of > > problems that enables. > > > > But I think that we are on the losing end of that argument, > and that > > doing nothing about it is comparable to the ietf history of doing > > nothing about NAT. Better the evil we understand than the one that > > evolves without us. > > If our work here becomes irrelevant, it will be because it > doesn't do what end users want, not because we've been > insufficiently obsequious to the tyrant-of-the-month. > Carriers, however broadly the definition of that term may be > creeping in some principalities, have certain obligations > which are not at all intrinsic to the operation of a protocol > like SIP, and we cannot assume that SIP's fate is determined > by its success in that arena alone. > > > Suppose we refused to bend here. Then the carriers that are > subject to > > LI will either switch to a non-standard variant of our > protocols that > > supports the key access, or will use some entirely > different protocol. > > As has been already pointed out in this thread, RFC4474 (and > any larger security architecture relying on it) invests the > domain responsible for your AoR with significant trust and > responsibility. That domain can insert men-in-the-middle > willy-nilly. This seemed architecturally reasonable because > you need to trust them anyway, for example, to route calls to > you and so on; the sorts of entities to whom LI requirements > apply would tend to be the operators of such domains, > incidentally. The truly paranoid can of course operate their > own domains, personally administer every device, and as such > need only trust themselves to make use of RFC4474. This casts > the problem exactly how it should be, I think - as an > administrative problem. How you deploy and use these tools > determines who you need to trust and where there are > potential avenues for adversaries to interfere with your security. > > Any attempt to cast this as an engineering problem, something > that can be fixed or broken at a protocol level, is in my > opinion misguided. > > Speaking more specifically to R24, my opinion is that a SIP > user should be able to ascertain whether or not a certain set > of security features have been invoked. If those features > have been invoked, then the user might draw the conclusion > that it is unlikely, barring some breakthrough in higher > mathematics, that someone is able to listen in on their > conversation. This is entirely orthogonal to whether or not > someone might be intercepting and recording ciphertext media > (something the user cannot hope to ascertain), nor whether or > not his administrative domain has been compromised (also > something the user probably cannot ascertain, even if he runs > his own server in a sealed bunker in Montana, given the > potential capabilities of adversaries) and his keys > plundered. The protocol, and consequently the end user, > cannot hope to be privy those lapses. As such it's hard for > me to see what the problem is with R24. > > If, of course, that set of security features cannot be > invoked, the user might draw the conclusion that it is quite > likely that someone is listening in on his conversation, and > R24-types might find that worrisome. But it is no more likely > that the baleful eye of surveillance is scrutinizing the user > in this case, really. Inability to invoke those features > cannot be said to inform the user that this interaction is > "subject to lawful interception" or whatever. Lack of the > support for the security features is a much more likely culprit. > > So, my question is, what's the engineering problem? > > Jon Peterson > NeuStar, Inc. > > > _______________________________________________ > 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 > _______________________________________________ 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
