inline:
Paul Kyzivat wrote:
Eric Rescorla wrote:
At Tue, 24 Jun 2008 12:48:20 -0700,
Eric Rescorla wrote:
Dean,
This sounds like an excellent way to proceed. I'll generate some
candidate text
and send it to the list in the next few days.
As promised, here's my proposed text:
Because DTLS-SRTP uses RFC 4474 to bind the media keying material to
the SIP signalling, the assurances about the provenance and security
of the media are only as good as those for the signalling. There are
two important cases to note here:
o RFC 4474 assumes that the proxy with the certificate "example.com"
controls the namespace "example.com". Therefore the RFC 4474
authentication service which is authoritative for a given
namespace can control which user is assigned each name. Thus, the
authentication service can take an address formerly assigned to
Alice and transfer it to Bob. This is an intentional design
feature of RFC 4474 and a direct consequence of the SIP namespace
architecture.
o When phone number URIs (e.g.,
'sip:[EMAIL PROTECTED]') are used, there is no
structural reason to trust that the domain name is authoritative
for a given phone number, although individual proxies and UAs may
have private arrangements that allow them to trust other domains.
This is a structural issue in that PSTN elements are trusted to
assert their phone number correctly and that there is no real
concept of a given entity being authoritative for some number
space.
In both of these cases, the assurances of DTLS-SRTP provides in
terms of data origin integrity and confidentiality are necessarily
no better than SIP provides for signalling integrity when RFC 4474
is used. Implementors should therefore take care not to indicate
misleading peer identity information in the user interface.
e.g. If the peer's identity is
sip:[EMAIL PROTECTED], it is not sufficient to
display that the identity of the peer is +17005551008. In cases
where the UA can determine that the peer identity is clearly an
E.164 number, it may be less confusing to simply identify the call
as encrypted but to an unknown peer.
While I understand the logic above, it isn't very satisfying.
People are constructing sip based phone systems that must compete with
traditional phone systems. If the sip based system shows no identity
when a traditional system can display the identity of the same caller,
then the sip system will be perceived and broken and non-competitive.
Its not just a UI problem - the problem is that the identity really IS
just +17005551008 - without the domain. I don't need the domain to dial
it from a phone. So even if the UI could render a domain, I don't think
it makes sense to do so.
That said, another possible approach here is to more loosely couple
DTLS-SRTP to 4474. It is my understanding that what DTLS-SRTP needs is
integrity of the signaling to protect the fingerprint from modification.
Any mechanism which provides message integrity would do. RFC4474 is one
way, but there are others. HBH TLS, for example, would also provide
integrity services, though not against rogue servers. Of course, we
don't have protection against rogue servers with 4474 either in cases
where phone numbers are used...
So my suggestion is to have DTLS-SRTP just state that it requires some
form of integrity services from signaling, to list some choices in what
that can be. I think its also really important to point out that, even
in the absence of any message integrity mechanisms at all, it requires
an ACTIVE attack in order for a third party to eavesdrop or modify
media. Whereas with sdescriptions, passive attacks can be launched if an
attacker can observe the keying material at some point along the
signaling path. That alone is a big improvement IMHO.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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
