[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] media-security-requirements and lawful intercept
> > Method 'a' could be achieved if the interception (and DTLS
> > handshake)
> > occurred within the originating domain, prior to the RFC4474
> > signature. This can allow inserting the man in the middle at that
> > point. This would need to be done for every call (not just
> > calls being intercepted).
>
> [JRE] This wouldn't work if LI is not being done in the originating
> domain. Enterprise UA issues INVITE request, enterprise proxy addes
> Identity header field and forwards to public service provider, which
> needs the possibility to intercept.
Good point; I had only been considering handsets in IMS (3GPP)
networks. I'll give that some more thought.
> > > 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.
> >
> > I agree that after the RFC4474 signature is created, other domains
> > can't become a man in the middle.
> >
> > > With method b, as already stated one of the users has to agree to
> > > disclose its key.
> >
> > The network can enforce that by blocking SRTP until the key is
> > disclosed. Some networks that block RTP until 200 Ok for fraud
> > prevention, and those same networks have LI requirements placed
> > on them by their government. Those networks could, similarly, block
> > SRTP until the key is disclosed, and could validate that the
> > supplied key does decrypt SRTP (especially SRTP that is protected
> > with an authentication tag).
>
> [JRE] I don't see how it could verify a key if the
> authentication tag is not used. Maybe it is easier for SRTCP than for SRTP,
> but that might
> involve some unacceptable delay before the first SRTCP packet arrives.
> Having said that, I would have thought the authentication tag would
> normally be used, since otherwise the security provided is rather
> dubious.
Agreed. And, today, all of the SRTP crypto suites in RFC3711 have an
authentication tag and as far as I know everyone is using it.
However, it is my understanding that SRTP with Galois/Counter Mode (GCM)
would not need (or use) an authentication tag. I don't know how a GCM
key would be validated. That was my concern there.
-d
> >
> > -d
> >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Dan Wing [mailto:dwing at cisco.com]
> > > > 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 sip-implementors at cs.columbia.edu for questions on
> current sip
> > > > Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> > > Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip