I have been watching this discussion and getting confused. (I tried asking one person off list, and while I understand that person's perspective, I am still confused about the discussion.) I went back and re-read the document.
I also went back and re-read RFC 1984. IETF policy is very clearly stated. We are not to weaken security mechanisms in order to enable interception. So, as I read it, R24 seems to say that if you provide interception in the protocol, then the presence or absence of such interception must not be visible to the end user. That by itself does not say we must provide LI. It certainly constrains any solution that claims to support LI. Do folks read either R24 or some other requirement as mandating that the IETF standardize an LI supporting solution? Yes, I am aware that operators are required to provide LI. And that if the operator is providing and mandating the cell phone, and the SIP software on the cell phone, then one can argue that the operator must provide meaningful LI (not just a trace of encrypted packets.) But that seems to me to be a choice the of the operator's deployment model. If the operator were not mandating the SIP stack, then they would not have this issue. (One can argue that we want the mechanism that they deploy to be interoperable with the rest of the world. But I think that has to be done by the operator community chosing to constrain what they do, not by constraining the internet secure RTP to be interoperable with an LI regime. There was some mention that the media recording requirement is relevant to LI. By my reading, that is an end-point recording capability requirement that we want to have. I doubt that the operators would consider "ask the customer for the recording" an acceptable LI mechanism. And asking the customer for the key on every call is clearly a non-starter as a real-world solution to any of this. Yours, Joel M. Halpern 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. > > 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....)? > > 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? > > John > >> -----Original Message----- >> From: Dean Willis [mailto:[EMAIL PROTECTED] >> Sent: 07 November 2007 15:59 >> To: Elwell, John >> Cc: Dan Wing; IETF SIP List >> Subject: Re: [Sip] media-security-requirements and lawful intercept >> >> >> On Nov 7, 2007, at 5:17 AM, Elwell, John wrote: >> >>> Dan, >>> >>> Speaking as an individual (not on behalf of another SDO), I don't >>> believe it is possible to satisfy R24. >>> >>> With method a, the network element will not be able to provide >>> appropriate credentials to satisfy a user that he is in >> communication >>> with the remote user. Assuming RFC 4474 is used as the basis for >>> authentication, the certificate provided by the >> Authentication Service >>> acting on behalf of user A will sign the request and any self-signed >>> certificate from UA that will be used in the DTLS handshake. Any >>> substitution of that certificate by a network element would >> break the >>> signature. Any attempt at changing the From URI and Identity header >>> field by an Authentication Service acting on behalf of the network >>> element would presumably use a certificate for that domain, not a >>> certificate for user A's domain, so it would be clear to user B >>> that the >>> call has come via that middle domain and is encrypted only as far as >>> that middle domain. >>> >>> With method b, as already stated one of the users has to agree to >>> disclose its key. >> Right. I think R24 is awkwardly worded, and should be something like: >> >> R24: The media security key management protocol SHOULD NOT allow >> end users to determine whether a specific end-to-end >> interaction is being or will be lawfully intercepted. >> >> We know that all calls in a 3GPP-type network are subject to lawful >> interception. The question is "Is this specific call being >> intercepted or is it more likely to be intercepted than any >> other call?" >> >> This means that any visible mechanism (keys have to be >> disclosed or a >> decrypting relay agent) must be exercised for every call, otherwise >> the act of asking for a key on a specific would reveal that there is >> unusual interest in intercepting that specific call. >> >> So, if we (IETF) were to define a mechanism whereby a caller could >> electively disclose session keys to a 3rd party (such as a >> recorder), >> and some service provider (or national regulator) were to >> make use of >> this mechanism mandatory for all calls over specific infrastructure, >> I think everybody would be as satisfied as they're going to get. >> >> This does raise all sorts of questions like "What happens when two >> nodes cheat and report invalid session keys to the LI mechanism?", >> something that is obviously doable. But if you ponder it awhile, you >> realize that there's really nothing that can prevent two colluding >> nodes from applying a secondary encryption, just as there is no real >> way to prevent two speakers from talking in code. I once used a >> scrambler that clamped over a regular analog handpiece, did a A to D >> conversion, encrypted, converted the stream into FSK (sounded like >> fax), and inversed the process at the other end. That's why some >> countries made it illegal to use unlicensed fax machines and modems >> for a while -- anybody who was communicating securely needed to be >> investigated. It may also be why some countries originally >> refused to >> upgrade their filters and echo cancelers to support 14.4 modems. But >> that cat has long since gotten out of the bag and wandered off >> someplace. So the best the LI community can hope for is that the >> majority of nodes will cooperate and that auditing mechanisms will >> have some chance of detecting those that don't. >> >> -- >> 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 > _______________________________________________ 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
