I think there is an additional issue that should be discussed in the
security considerations section.
The draft relies heavily on sip identity to provide integrity over the
fingerprint. The underlying assumption is that a MITM downstream would
need to modify the fingerprint and thus would also need to modify the
identity since it couldn't resign with the original domain.
This assumption is a good one in deployments that use [EMAIL PROTECTED]
identifiers - [EMAIL PROTECTED] However, the unfortunate reality is that
the majority of sip deployments today use phone numbers. These are often
represented in sip URI form - sip:[EMAIL PROTECTED] However, when
phone numbers are used, the domain part is often ignored and most of the
time not even rendered to the user. Even if it were, its not a
"significant" part of the identifier, in that a user won't normally know
or care what the domain part is.
What this means is that when phone numbers are in use, a MITM can easily
rewrite the From field. So if it was sip:[EMAIL PROTECTED] they can
rewrite to sip:[EMAIL PROTECTED], insert a media intermediary
and new fingerprint and resign. The called UA or terminating proxy will
verify that the identity is valid (which it is) and the called party is
presented with the caller ID, which is JUST the phone number. So they
don't notice a problem at all.
Thus, in practice, I fear dtls-srtp will easily allow proxies and SBCs
on the chain to intercept and modify the media stream, similar to what
they could do with sdescriptions. This is really a problem with sip
identity itself that carries over here. But I think this issue needs to
be mentioned and discussed. The draft makes itself out to be
substantially more secure than sdescriptions or MIKEY because of its e2e
nature but in practice I don't think it will be as effective.
Other minor comments:
[RFC4572]. The Real-Time Protocol (RTP) [RFC3550] is used to
transmit real time media on top of UDP, TCP [RFC4571], and TLS
[RFC4572].
actually this isn't true; rfc4572 says it does not apply to RTP. From
rfc4572:
This document does not define any mechanism for securely transporting
RTP and RTP Control Protocol (RTCP) packets over a
connection-oriented channel. There was no consensus in the working
group as to whether it would be better to send Secure RTP packets
[23] over a connection-oriented transport [24], or whether it would
be better to send standard unsecured RTP packets over TLS using the
mechanisms described in this document. The group consensus was to
wait until a use-case requiring secure connection-oriented RTP was
presented.
This draft provides guidelines on how to use and to
support for (a) transmission of media over DTLS and (b) to establish
SRTP security using extensions to DTLS (see
[I-D.ietf-avt-dtls-srtp]).
something is missing in this sentence. Maybe, "this draft provides
guidelines on how to use and support DTLS for transmission of media and
how to establish SRTP secureity using...."
The media is transported over a mutually authenticated DTLS session
where both sides have certificates. The certificate fingerprints are
sent in SDP over SIP as part of the offer/answer exchange. The SIP
Identity mechanism [RFC4474] is used to provide integrity for the
fingerprints. It is very important to note that certificates are
being used purely as a carrier for the public keys of the peers.
This is required because DTLS does not have a mode for carrying bare
keys, but it is purely an issue of formatting. The certificates can
be self-signed and completely self-generated. All major TLS stacks
have the capability to generate such certificates on demand.
However, third party certificates MAY also be used for extra
security.
suggest that the statements on self-signing get moved up to immediately
after the first sentence. Otherwise, the reader is immediately confused,
since most folks equate certificates with PKI, and the previous
paragraph just said that no PKI is required.
This approach differs from previous attempts to secure media traffic
where the authentication and key exchange protocol (e.g., MIKEY
[RFC3830]) is piggybacked in the signaling message exchange. With
this approach, establishing the protection of the media traffic
between the endpoints is done by the media endpoints without
involving the SIP/SDP communication.
should be clear that "this appraoch" is referring to dtls-srtp and NOT
mikey/sdesciptions. Also you might want to include a reference to
sdescriptions here also.
Figure 1: the figure shows bidirectional arrows between elements, but
the notations around authentication information indicate that this is
really talking about an initial INVITE from alice to bob. Suggest that
the arrows face right only in this flow.
Also, I think using the term, "signaling traffic" for the dtls handshake
is confusing. Since folks equate, "signaling traffic" with sip. Suggest
using a different term, perhaps "key management traffic" and use a
different line style.
Alice sends an SDP offer to Bob over SIP. If Alice uses only self-
signed certificates for the communication with Bob, a fingerprint is
included in the SDP offer/answer exchange. This fingerprint is
integrity protected using the identity mechanism defined in
Enhancements for Authenticated Identity Management in SIP [RFC4474].
When Bob receives the offer, Bob establishes a mutually authenticated
DTLS connection with Alice. At this point Bob can begin sending
media to Alice. Once Bob accepts Alice's offer and sends an SDP
answer to Alice, Alice can begin sending confidential media to Bob.
this is lacking from an overview of operations perspective. I suggest
also mentioning that alice and bob will verify the fingerprints from the
certs received over the dtls handshakes with those in the sip signaling,
providing a correlation function. Mention that this provides the
security property that you know your media traffic is going to the
person you called, without necessarily providing a secure version of the
identity of that person. This is the key idea of dtls-srtp that needs to
be in here.
DTLS/TLS uses the term "session" to refer to a long-lived set of
keying material that spans associations. In this document,
consistent with SIP/SDP usage, we use it to refer to a multimedia
session and use the term "TLS session" to refer to the TLS construct.
We use the term "association" to refer to a particular DTLS
ciphersuite and keying material set.
association and session both claim to use a single keying set. So its
not clear what the difference is. Maybe associations use keys derived
from the session keys? SHould clarify here.
6.1. Anonymous Calls
When making anonymous calls, a new self-signed certificate SHOULD be
used for each call so that the calls can not be correlated as to
being from the same caller.
this is not even close to sufficient for anonymity. The IP address will
be the same. So this needs to be called out that this is just referring
to the DTLS part or else the rest of anonymity needs to be defined.
Note that in the situation where a request forks to multiple
endpoints that all share the same certificate, there is no way for
the caller to correlate the DTLS associations with the SIP dialogs.
Practically, this is not a problem, since the callees will terminate
the unused associations.
the issue isn't just which ones to keep; its correlating for UI
purposes. For example, talking indicators or media hold. Each side needs
to know which stream is associated with each dialog. Isn't a better
solution to just have a unique certificate per device? Or else rely on
something else for correlation (i.e., ice).
Indeed the draft should call out that when ice is used, ice itself will
provide this correlation and it happens even prior to the start of dtls.
be able to demultiplex STUN packets from DTLS packets. STUN
[RFC3489] packets MUST NOT be sent over DTLS.
should reference 3489bis.
Thanks,
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://www1.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
