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. John > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: 06 November 2007 17:51 > To: 'IETF SIP List' > Subject: [Sip] media-security-requirements and lawful intercept > > Other SDOs have lawful intercept requirements, which are currently > captured in requirement R24 in > draft-ietf-sip-media-security-requirements-00: > > "R24: The media security key management protocol SHOULD > NOT allow end users to determine whether their > end-to-end interaction is subject to lawful > interception." > > DTLS-SRTP was selected by IETF as the IETF's preferred mechanism > to establish SRTP keys for unicast, point-to-point SRTP sessions. > > There appear to be two methods to meet R24 with DTLS-SRTP. They > are: > > a. provide a network element on every SRTP call which relays > media, performs a DTLS handshake, and decrypts and re-encrypts > SRTP, or; > > b. have endpoints perform key disclosure for every call (using a > technique similar to draft-wing-sipping-srtp-key), and perform > validation of that disclosed key on every call. > > If these methods to meet R24 are deemed acceptable to other SDOs, > we don't find any reason for those SDOs to reject IETF's decision > to use DTLS-SRTP as the preferred mechanism to establish SRTP > keys for unicast, point-to-point SRTP sessions. > > Comments welcome. > -d > > > _______________________________________________ > 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
