I think that seem to highlight all the problems so I can live with
that if we can just get this done.
Cullen <with my individual contributor hat on>
On Jul 1, 2008, at 7:32 PM, 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.
In addition, some middleboxes (B2BUAs and Session Border
Controllers) are known to modify portions of the SIP message which
are included in the RFC 4474 signature computation, thus breaking
the signature. This sort of man-in-the-middle operation is
precisely the sort of message modification that 4474 is intended to
detect. In cases where the middlebox is itself permitted to
generate valid RFC 4474 signatures (e.g., it is within the same
administrative domain as the RFC 4474 authentication service), then
it may generate a new signature on the modified
message. Alternately, the middlebox may be able to sign with some
other identity that it is permitted to assert. Otherwise, the
recipient cannot rely on the RFC 4474 Identity assertion, and the
DTLS-SRTP call set up will fail or be marked as a call with an
unknown peer.
-Ekr
_______________________________________________
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
_______________________________________________
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
