To paraphrase Tim / 33.106, the entities are only required to provide
decryption in the following cases:
1. The encryption was provided by NWOs/APs/SvPs AND the NWOs/APs/SvPs
possesses the information necessary to decrypt the communication.
2. NWOs/APs/SvPs provides the encryption keys but does not provide the
encryption itself
It seems like neither of these is necessarily the case when the
endpoints use an end-to-end secure key negotiation mechanism: Since the
endpoints are agreeing on keys between themselves, you're never in case
(2). With regard to case (1), even if the provider builds the
encryption system into the terminal, without some additional key
disclosure mechanism, they won't have the information necessary to
decrypt the communication.
So it doesn't seem like there's any technical issue at all, based on
this requirement. The service provider is just required to provide
access to what he has access to, even if that's just encrypted traffic
with no keys.
--Richard
Dan Wing wrote:
...
1. It's not clear to me that people are correctly parsing LI
requirements. I'm not an expert on CALEA, let alone laws in other
countries, but it's not my understanding that there is any
regulatory requirement that forces carriers of voice or data
traffic to arrange for disclosure of plaintext when they
don't have
the keys. I.e., if I buy data service from Comcast and choose to
run a VPN, there is no requirement that Comcast somehow
obtain the
keys to deliver them to the FBI.
It's less clear to me what the requirements are for 3G-style
carriers when the endpoints are doing the crypto. I.e., I'm quite
certain that if AT&T terminates the crypto they need to
provide the
plaintext on request, but a lot less certain that they need to
provide the plaintext if the crypto is end-to-end.
Timothy Dwight posted a followup on 3GPP's requirement that should
be helpful on those points. What remains unsaid in that quoted text
is crypto performed by the endpoint itself (as with DTLS-SRTP).
Tim mentioned to me privately that his posting to SIP is being held
up; here is the content:
From: Dwight, Timothy M (Tim) <[EMAIL PROTECTED]>
To: Eric Rescorla; Dan Wing
Cc: IETF SIP List
Subject: RE: [Sip] media-security-requirements and lawful intercept
On point #1, 3GPP 33.106 says under "Security of Processes":
"NWOs/APs/SvPs shall not be responsible for decrypting, or
ensuring the LEA's ability to decrypt, any communication
encrypted by a subscriber or customer, unless the encryption
was provided by the NWOs/APs/SvPs and the NWOs/APs/SvPs
possesses the information necessary to decrypt the
communication or the NWOs/ APs/SvPs provides encryption keys
but does not provide the encryption itself. In the case that
the NWOs/ APs/SvPs provides encryption keys to the subscriber
or customer but does not provide the encryption itself, the
NWOs/ APs/SvPs shall provide the keys to the LEA if required
by national regulations."
The same text is found in ETSI TISPAN TS 133 106.
tim
-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
