Dean Willis wrote:
On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote:
I'm worried this is only a wishful thinking. While perfectly
logical, still even in such constrained setups some bizzar
ALGs do in my experience appear in the middle, change SDP
and make thus the identity worthless.
If they change the SDP, they've changed the identity assertion. They
need to re-assert. There might reasonably be a need to have a stack of
assertions with diffs, so one could go back and see the original SDP,
with its original key fingerprint and original verifiable signature, but
just changing stuff and pretending the associated identity assertion
hasn't changed is fundamentally bogus.
Hi Dean,
My argument has been that including SDP's IP address and port numbers
in message integrity check is not an identity assertion, but a protocol
shortcoming (certainly well-meant, but making things hard to deploy).
I really think that identity and integrity of SDP are two different things.
Or do you think that these elements somehow belong to identity assertion?
The MAIN reason, it seems to me, to want to change the SDP (and
especially the key fingerprint) undetectably is to enable intercept
(lawful or otherwise) without detectability. That just won't do.
In the field, the desire to change SDP I have witnessed is due to NATs.
We don't have TURN & ICE in the field and I'm quite worried that very
few care today. In fact, SDP rewriting has been in use for so long, that
I consider TURN's success chances very marginal. Other I have witnessed
is transcoding.
To make it clear: I'm not opposed to all sorts of integrity protection.
I'm just worried that if we try to solve identity in a single package
with integrity of ever changing SDP, we will unlikely succeed.
Perhaps we only need are two different identity assertions; one on the
original SDP with fingerprint, and one on whatever has resulted
post-modification by the MITM attackers. Intermediate manipulations by
yet more MITN attackers might well be worthless.
Let's put it another way: One of the very important things that RFC 4474
does is protect the DTLS/SRTP key fingerprint. Arguably, its protection
of the other stuff in the SDP, such as the port numbers and IP addresses
used for media, is just a side effect. Of course, changing the codec
(transcoding) is going to break DTLS/SRTP quite horribly, so the codec
information might as well be protected by Identity.
Would we be willing to accept a model where the fingerprint is preserved
across SBCs but the IP address/port number information is not? I'm not
saying that would be easy to produce; it would seem to require a very
complex modification to RFC 4474's handling of SDP, or complementary
fundamental changes to RFC 4474 and the DTLS draft family. But would it
get us past this this stone wall?
Logically yes, integrity of some pieces that are known not to be useful
to be rewritten would be ok.
The practicability is of course another question, on which many may have
different opinions. Should mine be asked, I would be in favor of using
confidentiality protocols that do not have dependencies in general,
and dependencies on protocols with unenforceable identity in particular:
zRTP.
If not, why not? And you're going to have to convince me that you're not
just building a phone-tapper protocol here . . .
I haven't been working on a phone-tapper, even though a media-relay or
transcoder could be labeled so for marketing purposes :-) zRTP actually
makes it gracefuly through media relay while confidentiality remains
preserved.
-jiri
--
Dean
_______________________________________________
Sip mailing list https://www.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
