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
