[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] media-security-requirements and lawful intercept
Jon,
I go along with your explanation, but I still think it leaves the
following problem. User A in domain A (e.g., an enterprise) makes a call
to/from user B in domain B, via carrier domain C. What you describe
works if domain A or domain B needs to apply LI (or record the call for
any other reason - there are plenty of legitimate business reasons). I
think we don't regard domains A and B as MitM. After all, we rely on
domains A and B to provide the Authentication Service for RFC 4474. The
issue is when domain C tries to interfere with end-to-end security in
order to support LI. I do have a problem with this, because I think it
undermines legitimate business security needs.
If domain C intervenes only when a LI warrant exists for one of the
users, I don't personally have a problem. But this violates R24, which
some people seem to think is important.
If domain C intervenes all the time (either by terminating encryption in
domain C, so that user A and user B see the source of security keying
material as domain C, or by demanding submission of the key to domain C
before admitting the call), I think this is of real concern. It means
businesses cannot have the security they need when, for various reasons,
they are forced to go via a domain C.
So I don't think we should do anything special towards meeting R24 at a
domain C. Although not the IETF's job, those concerned should work with
carriers and regulators to avoid situations where a domain C can prevent
normal end-to-end security on calls not subject to an LI warrant.
Concerning the engineering problem to be solved, there probably isn't
one if we agree that R24 does not apply to a domain C.
John
> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson at neustar.biz]
> Sent: 08 November 2007 21:18
> To: Paul Kyzivat; Ted Hardie
> Cc: IETF SIP List; Elwell, John; Dan Wing; Dean Willis
> Subject: RE: [Sip] media-security-requirements and lawful intercept
>
> > I would prefer a world where all the communications were e2e
> > encrypted with no possibility of interception, in spite of
> the class of
> > problems that enables.
> >
> > But I think that we are on the losing end of that argument,
> and that
> > doing nothing about it is comparable to the ietf history of doing
> > nothing about NAT. Better the evil we understand than the one that
> > evolves without us.
>
> If our work here becomes irrelevant, it will be because it
> doesn't do what end users want, not because we've been
> insufficiently obsequious to the tyrant-of-the-month.
> Carriers, however broadly the definition of that term may be
> creeping in some principalities, have certain obligations
> which are not at all intrinsic to the operation of a protocol
> like SIP, and we cannot assume that SIP's fate is determined
> by its success in that arena alone.
>
> > Suppose we refused to bend here. Then the carriers that are
> subject to
> > LI will either switch to a non-standard variant of our
> protocols that
> > supports the key access, or will use some entirely
> different protocol.
>
> As has been already pointed out in this thread, RFC4474 (and
> any larger security architecture relying on it) invests the
> domain responsible for your AoR with significant trust and
> responsibility. That domain can insert men-in-the-middle
> willy-nilly. This seemed architecturally reasonable because
> you need to trust them anyway, for example, to route calls to
> you and so on; the sorts of entities to whom LI requirements
> apply would tend to be the operators of such domains,
> incidentally. The truly paranoid can of course operate their
> own domains, personally administer every device, and as such
> need only trust themselves to make use of RFC4474. This casts
> the problem exactly how it should be, I think - as an
> administrative problem. How you deploy and use these tools
> determines who you need to trust and where there are
> potential avenues for adversaries to interfere with your security.
>
> Any attempt to cast this as an engineering problem, something
> that can be fixed or broken at a protocol level, is in my
> opinion misguided.
>
> Speaking more specifically to R24, my opinion is that a SIP
> user should be able to ascertain whether or not a certain set
> of security features have been invoked. If those features
> have been invoked, then the user might draw the conclusion
> that it is unlikely, barring some breakthrough in higher
> mathematics, that someone is able to listen in on their
> conversation. This is entirely orthogonal to whether or not
> someone might be intercepting and recording ciphertext media
> (something the user cannot hope to ascertain), nor whether or
> not his administrative domain has been compromised (also
> something the user probably cannot ascertain, even if he runs
> his own server in a sealed bunker in Montana, given the
> potential capabilities of adversaries) and his keys
> plundered. The protocol, and consequently the end user,
> cannot hope to be privy those lapses. As such it's hard for
> me to see what the problem is with R24.
>
> If, of course, that set of security features cannot be
> invoked, the user might draw the conclusion that it is quite
> likely that someone is listening in on his conversation, and
> R24-types might find that worrisome. But it is no more likely
> that the baleful eye of surveillance is scrutinizing the user
> in this case, really. Inability to invoke those features
> cannot be said to inform the user that this interaction is
> "subject to lawful interception" or whatever. Lack of the
> support for the security features is a much more likely culprit.
>
> So, my question is, what's the engineering problem?
>
> Jon Peterson
> NeuStar, Inc.
>
>
> _______________________________________________
> 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