To: SIP IETF Subject: [Sip] WGLC comments on draft-ietf-sip-dtls-srtp-framework-02 From: "Elwell, John" X-Original-To: ekr@networkresonance.com Delivered-To: ekr@networkresonance.com X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Date: Fri, 08 Aug 2008 18:05:05 +0100 Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0F8D412@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: WGLC comments on draft-ietf-sip-dtls-srtp-framework-02 Thread-Index: Acj5eOdUgdqYw3W1QqOmsc5MdWk4Jg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > This is in good shape - just a bunch of minor comments. > > 1. "The Real-time Transport Protocol (RTP) [RFC3550] is used > to transmit real time media on top of UDP and TCP [RFC4571]. > Datagram TLS [RFC4347] was introduced to allow TLS functionality to > be applied to datagram transport protocols, such as UDP and DCCP. > This draft provides guidelines on how to establish SRTP [RFC3711] > security using an extension to DTLS (see [I-D.ietf-avt-dtls-srtp])." > This first says that RTP can be used on top of UDP and TCP, but then > says that this draft addresses the use of DTLS for establishing SRTP. > DTLS is applicable only when SRTP is carried over UDP, not TCP. This > should be made clear, e.g., > "...guidelines on how to establish SRTP [RFC3711] security over UDP..." Done. > 2. "S/MIME > signatures, as described in RFC 3261, or SIP Identity, as described > in [RFC4474] provides the highest level of security because they are > not susceptible to modification by malicious intermediaries." > Also there are other places in the draft that mention S/MIME, including > section 8.3. In the SIP session at IETF72 there was discussion about > deprecating S/MIME in SIP. If this is the intent of the WG, is it wise > to mention the technique in new RFCs? I think I'd prefer to leave this in here. S/MIME hasn't been deprecated yet, and it's add to not mention something that after all is in RFC 3261 and would get the job done. > 3. "The SIP message > containing the offer SHOULD be sent to the offerer's sip proxy over > an integrity protected channel which SHOULD add an identity header > according to the procedures outlined in [RFC4474]. " > It is the proxy, not the channel, that should add the Identity header > field. Also some other nits. Change to: > "The endpoint SHOULD send the SIP message > containing the offer to the offerer's sip proxy over > an integrity protected channel. The proxy SHOULD add an Identity > header field > according to the procedures outlined in [RFC4474]." Done. > 4. "The far endpoint (answerer) may now establish a mutually > authenticated DTLS association to the offerer." > This assumes that the far endpoint will play the active role. However, > that is not necessarily so, and will depend what is negotiated in SDP. Fixed. > 5. "DTLS-SRTP does not provide anonymous calling." > Should this say: > "DTLS-SRTP does not prevent anonymous calling."? No, but I agree it's unclear. I rewrote as The use of DTLS-SRTP does not provide anonymous calling, however it also does not prevent it. > 6. "Additionally, it MUST be ensured that the Privacy header [RFC3325] > is > used in conjunction with the SIP identity mechanism to ensure that > the identity of the user is not asserted when enabling anonymous > calls." > In fact 3325 does not define the Privacy header field - it only defines > the additional value 'id'. Suggest we say: > "Additionally, it MUST be ensured that the Privacy header field with > value 'id' [RFC3325]...." > I don't know whether we also need a reference to RFC 3323, in which case > it would become: > "Additionally, it MUST be ensured that the Privacy header field > [RFC3323] with value 'id' [RFC3325]....". Fixed. > 7. Should section 6.1 on anonymous calls have an informative reference > to the ua-privacy draft? Added. > 8. "Each answerer will create a DTLS association with > the offerer." > It is not necessarily the case that the answerer will create the > association - it could also be the offerer. s/create/form/ > 9. "Once the answer is received, the active endpoint > will either reuse the existing association or establish a new one, > tearing down the existing association as soon as the offer/answer > exchange is completed." > If the answerer is the active endpoint, how can it determine that the > offer/answer exchange is completed, i.e., how does it know the offerer > has received the answer? Yeeah, that is weird. I think I fixed that. > 10. "Note > that this may mean adjusting the endpoint IP addresses if the > selected candidate pair shifts, just as if the DTLS packets were an > ordinary media stream." > What is the impact on the in-progress or completed DTLS handshake if > there is a shift of IP address? None. DTLS does not care about IP addresses as long as it gets the data it needs. > 11. "Implementations of this specification SHOULD support DTLS-SRTP > [I-D.ietf-avt-dtls-srtp]." > I thought the whole draft was about DTLS-SRTP. Therefore why is this > only SHOULD strength? Under what circumstances are exceptions allowed? > What are the alternatives to be used in these exceptional circumstances? It should say MUST. It does now. > 12. "Also note > that there is a fingerprint attribute on the 'c' line of the SDP." > An attribute is a separate line, not part of a c-line. Fixed. > 13. "This is computed from Bob's self-signed certificate." > That is true for the answer, but for the offer it is from Alice's > certificate. Doh! > 14. "a=tcap:1 UDP/TLS/RTP/AVP RTP/AVP" > Shouldn't this be: > "a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP" Done. > 15. "Message 3 shows Bob > sending a DTLS ClientHello directly to Alice for each 'm' line in > the SDP. In this case two DTLS ClientHello messages are sent to > Alice. Bob sends a DTLS ClientHello to 192.168.1.103:6056 for RTP > and another to port 6057 for RTCP." > The figure does not show two ClientHello messages, but it should do. > This would then make the first sentence above wrong - it would be two > per 'm'line, not one per 'm' line. It is only one per 'm' line if > RTP/RTCP mux is used. I fixed this by rewriting the text, not the figure. > 16. "Note that in this case, Bob signals the actual transport protocol > configuration of SRTP over DTLS in the acfg parameter." > This appears under message 9 (RTP/RTCP), but really it should occur > under message 8 (200 OK). Fixed. > 17. "When phone number URIs (e.g., > 'sip:+17005551008@chicago.example.com') 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 might suggest that the problem exists only when user=phone is > absent, whereas it exists also (more particularly so) when user=phone is > present. It might be better to say: > "When phone number URIs (e.g., > 'sip:+17005551008@chicago.example.com' or > 'sip:+17005551008@chicago.example.com;user=phone') are used...." Done. > NITS: > - Change "media plan" to "media plane". > - "in Enhancements for Authenticated Identity > Management in SIP [RFC4474] is used" - delete "in". > - "SIP proxies downstream of the identity service" change to "SIP > proxies downstream of the authentication service" > - "Since the identity header is a > digital signature across several SIP headers, in addition to the > bodies of the SIP message, " > This contains several instances of wrong terminology. "identity header" > should be "Identity header field. "SIP headers" should be "SIP header > fields", and "bodies" should be "body". A SIP message has a single > header (comprising header fields) and a single body (perhaps containing > multiple body parts). Similar corrections are needed throughout the > document. I think I got all these. > - "upon receiving the other side's then" > I think this should say: > "upon receiving the other side's SDP then" Done. > - "and key negotiation succeeds otherwise RTP is used" > Change to: > "and key negotiation succeeds, otherwise RTP is used" Done. > - "RTP is the > default and will be understood by endpoints that do not understand > SRTP or this key exchange mechanism but SRTP is preferred." > Change to: > "This allows an offerer to express a preference for SRTP, but RTP is the > default and will be understood by endpoints that do not understand > SRTP or this key exchange mechanism. Done. " > - "Answerers SHOULD use this UPDATE mechanisms." > Change "mechanisms" to "mechanism". > - "the assurances of DTLS-SRTP provides " > Change to: > "the assurances that DTLS-SRTP provides" ^^^^ Done. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip To: "SIP IETF" Subject: [Sip] WGLC comments on draft-ietf-sip-dtls-srtp-framework-02 From: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Original-To: ekr@networkresonance.com Delivered-To: ekr@networkresonance.com X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001] X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 19:12:03 +0300 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0F8D412@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-sip-dtls-srtp-framework-02 Thread-Index: Acj5eOdUgdqYw3W1QqOmsc5MdWk4JgCU7TYg X-OriginalArrivalTime: 11 Aug 2008 16:13:19.0140 (UTC) FILETIME=[2B2E9640:01C8FBCD] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A few random comments: > The fingerprint alone protects against active attacks on the media > but not active attacks on the signalling. In order to prevent active > attacks on the signalling, in Enhancements for Authenticated Identity > Management in SIP [RFC4474] is used. > > I believe we should indicate that SIP Identity >>may<< be used. Done. > When Bob receives the offer, > Bob establishes a mutually authenticated DTLS connection with Alice. > > It is not really mutually authenticated at this point in time. > Something like > " > When Bob receives the offer, > Bob initiates a DTLS exchange 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. I rewrote this a little differently. > > We would have to assume symmetric RTP (which is only recommended by > draft-ietf-avt-dtls-srtp) here to allow Alice to send media immediately > after the DTLS handshake. Otherwise we may need another DTLS handshake > before Alice can send media to Bob. I think the new text covers this. > I was actually wondering why not to mandate symmetric RTP given that the > number of exchanges are much lower. the consensus in AVT was not to do so. > Alice and Bob will verify the > fingerprints from the certificates received over the DTLS handshakes > match with the fingerprints received in the SDP of the SIP signaling. > This provides the security property that Alice knows that the media > traffic is going to Bob and vice-versa without necessarily requiring > global PKI certificates for Alice and Bob. > > > o When RFC 4474 Identity is used, this solution works even when the > SIP proxies downstream of the identity service are not trusted. > > We could provide a pointer to the security considerations section, > namely Section 8.6. I provided a pointer. > A pointer to RFC 4916 ("Connected Identity"), even though I do not > consider it as too important based on the scenarios it addresses, would > not hurt here. > Maybe something like would help: > "Retargeting of a dialog-forming request (changing the value of the > Request-URI), the UA that receives > it (the User Agent Server, UAS) can have a different identity from > that in the To header field. When RFC 4916 is used then it is > possible to supply its identity to the peer UA by means of a request in > the > reverse direction, and for that identity to be signed by an > Authentication Service. > " Added. > There is no need to reveal keys in the SIP signaling or in the SDP > message exchange. In order for SDES and MIKEY to provide this > security property, they require distribution of certificates to > the endpoints that are signed by well known certificate > authorities. > > > I believe we should delete the last sentence since we provide a detailed > discussion of SDES and MIKEY in the media security requirements > document. > Removed. > Section 5 > > The far endpoint (answerer) may now establish a mutually > authenticated DTLS association to the offerer. > > > The same comment from above applies since at this stage there two end > points aren't mutually authenticated yet. > > > o If the fingerprint does not match the hashed certificate then the > endpoint MUST tear down the media session immediately. > > Tentatively establishing a session and tearing it down if the > fingerprint doesn't match is one possible strategy. Alternatively, the > offerer could wait for an answer with the fingerprint and subsequently > execute the DTLS handshake and cancel the handshake and the session > establishment immediately if the cert used in the handshake does not > match the fingerprint. I added some material. > This would obviously delay the establishment of the secure channel. > Particularly for early media this would mean that media is unprotected. > Early media will, however, be tough anyway. > > I don't have a strong opinion on the two approaches but I believe we > should mention the DoS potential in the security consideration section. I don't see that there is any signifciant DoS potential. Can you provide some text? > 6.5. Session Modification > > Once an answer is provided to the offerer, either endpoint MAY > request a session modification which MAY include an updated offer. > This session modification can be carried in either an INVITE or > UPDATE request. Once the answer is received, the active endpoint > will either reuse the existing association or establish a new one, > tearing down the existing association as soon as the offer/answer > exchange is completed. > > > I think we need to differentiate the case where the SDP changes only > slightly, for example, a change in codec vs. the case where, for > example, an IP address changes. > Hence, in some cases creating a new association might not even be > possible. I added some text. > Section 7: > > The SIP signaling from Alice to her proxy is transported over TLS to > ensure an integrity protected channel between Alice and her identity > service. Note that all other signaling is transported over TCP in > this example although it could be done over any supported transport. > > I guess we should also say that the communication between the SIP > proxies is protected someone, specifically when SIP Identity (or other > security mechanisms) is not available. I added some text. > This shows the initial INVITE from Alice to Bob carried over the > TLS transport protocol to ensure an integrity protected channel > between Alice and her proxy which acts as Alice's identity > service. Note that Alice has requested to be either the active or > passive endpoint by specifying a=setup:actpass. Bob chooses to > act as the DTLS server and will initiate the session. Also note > that there is a fingerprint attribute on the 'c' line of the SDP. > This is computed from Bob's self-signed certificate. > > Shouldn't this be Alice's self-signed cert, as shown in the subsequent > exchange. Fixed. > At this point, Bob can begin sending early media (RTP and RTCP) to > Alice. Note that Alice can't yet trust the media since the > fingerprint has not yet been received. This lack of trusted, > secure media is indicated to Alice. > > At the last sentence we should indicate that this indication is part of > the user interface rather than something that is meant to be part of the > protocol exchange. Fixed. > Section 8: Security Considerations > > > Other mechanisms, such as the S/MIME mechanism described > in RFC 3261, or the mechanisms described in > [I-D.wing-sip-identity-media] or [I-D.fischer-sip-e2e-sec-media], > could also serve this purpose. > > > I believe we should just mention S/MIME and SIP CERT rather than > individual drafts that may not go anywhere. I've removed this, but I have no strong position so I'll put it back in if people object. > Section 8.2: > > > This sentence is a bit tough to read: > > If SIP Identity is not used, but the signaling is protected by SIPS, > the security guarantees are weaker, but some security is still > provided as long as all proxies are trusted, this provides integrity > for the fingerprint. > > > Suggest to break it into 3 sentences: > > If SIP Identity is not used, but the signaling is protected by SIPS, > the security guarantees are weaker. Some security is still > provided as long as all proxies are trusted. This provides integrity > for the fingerprint in a chain-of-trust security model. Done. > It does not provide a strong assertion of who > Alice is communicating with. However, as much as the target domain > can be trusted to correctly populate the From header field value, > Alice can use that. The security issue with this approach is that if > one of the Proxies wished to mount a man-in-the-middle attack, it > could convince Alice that she was talking to Bob when really the > media was flowing through a man in the middle media relay. However, > this attack could not convince Bob that he was taking to Alice. > > > I believe that this last paragraph does not provide a lot of value given > that SIPS fits into the chain of trust security model and hence, by > definition, you have to trust the proxies. If the proxies are, for some > reason, not trustworthy anymore than there is a problem. I trimmed this down quite a bit. > 8.3. S/MIME > > > I would delete the last sentence from that section, namely > " > However, so far there have been no deployments of S/MIME > for SIP. > " > > Reason: The problem is not really S/MIME as such. The problem is how to > distribute the certificates. This problem has, however, been tackeled > with SIP CERT and hence the situation may look different in a few years. > Additionally, one could argue of lack of deployment of other security > mechanisms as well. Removed. > 8.5. Short Authentication String > > DTLS does not natively support > this mode, however it would be straightforward to add one as a TLS > extension [RFC3546]. > > I would delete the term "straightforward" and say something like > " > DTLS does not natively support > this mode. Based on the level of deployment interest a TLS > extension [RFC3546] could provide support for it. > " > > Reason: There has not been a lot of interest in this mechanism lately. > Hence, I am not sure whether there is actually a lot interest from the > community. Done. > Additionally, it might be useful to indicate that this mechanism only > helps when you actually know the person's voice. This fits to some > communication patters. When you know your communication partners already > out-of-band then things are a lot easier anyway. > For those cases where this is not true things get more complicated. For > example, how do I know that I talk to a person at my bank, insurance > company, car dealer, travel agency, help desk, etc.? One may not know > the voice of these folks. Added some material. > Appendix A: > > A.4. Clipping (R-AVOID-CLIPPING) > > Because the key establishment occurs in the media plane, media need > not be clipped before the receipt of the SDP answer. > > > I believe we should indicate that in this case the early media is not > secured. That's not 100% accurate. I've added clarifying text. > A.7. (R-SIG-MEDIA, R-ACT-ACT) > > > It might be good to indicate that the interaction between the UA and the > authentication service needs to be secured as well and that the > authentication service is responsible for executing proper > authentication of the user. Done. > A.8. Binding to Identifiers (R-ID-BINDING) > > We should weaken the language a bit to indicate that other mechanisms, > such as SIP CERT and S/MIME may also be used and not only SIP Identity. Done. > A.11. RTP Validity Check (R-RTP-VALID) > > We should also mention STUN packets by referencing Section 5.1.2 of > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-03 Done. > A.15. Denial of Service Vulnerability (R-DOS) > > DTLS offers some degree of DoS protection particuarly as a built-in > feature. > > > > A.16 is already covered by A.7. I would delete it. Done. > A.18: Maybe we should add one more sentence: "RFC 4474 is able to > prevent an active attacker on the signalling path to downgrade the call > from SRTP to RTP." Done. > A.22. Interworking with Intermediaries (R-TRANSCODER) > > " > A description of the interworking with Session Border Controllers is > described in this document. > " > > The interworking with SBCs is covered in > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-path-middleb > oxes-01.txt > > However, as the text of interworking is written in > http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requir > ements-07.txt > the transcoder needs to have access to the keying material and therefore > the description from A.21 on media recording (and key disclosure) is > applicable here as well. I added a short amount of text. > A.23. PSTN Gateway Termination (R-PSTN) > > The DTLS-SRTP framework allows the media security to terminate at a > PSTN gateway. This does not provide end-to-end security, but is > consistent with the security goals of this framework because the > gateway is authorized to speak for the PSTN namespace. > > > There are several scenarios that would have to be discussed in this > context; they are described in Section 3 of > draft-schwartz-sip-e164-ownership-01.txt, namely > * IP-IP Case (not relevant to Section A.23 although E.164 numbers are > used). > * IP-PSTN-IP Case > * PSTN-to-IP Case > * IP-to-PSTN Case > > The problems are slightly different for each of these cases. However, as > most folks would probably agree the security of all these cases is > rather weak (or at least unpredictable). > > I wonder how to best treat this subject but it may not hurt to describe > the issues in more detail in the appendix. Text is already available -- > hence it would be more of a copy-and-paste operation. I think this is actually contentious enough that I'd rather not get into it, since this is just about media-security-requirements compliance. > There are two requirements that have not been discussed: R-ALLOW-RTP and > R-HERFP. > > "R-ALLOW-RTP: DTLS-SRTP allows RTP media to be received by the calling > party until SRTP has been negotiated with the answerer, after which SRTP > is preferred over RTP. > " > > Here is first try: > " > R-HERFP: The Heterogeneous Error Response Forking Problem (HERFP) is not > applicable to DTLS-SRTP since the key exchange protocol will be executed > along the media path and hence error messages are communicated along > this path and proxies do not need to progress them. " I added this text. _______________________________________________ > To: "'Eric Rescorla'" , "'SIP IETF'" > Subject: Re: [Sip] WGLC on DTLS Framework draft-ietf-sip-dtls-srtp-framework-02 > From: "Dan Wing" > X-Original-To: ekr@networkresonance.com > Delivered-To: ekr@networkresonance.com > X-IronPort-AV: E=Sophos;i="4.31,243,1215388800"; d="scan'208";a="130825676" > Date: Wed, 23 Jul 2008 21:05:34 -0700 > Message-ID: <16c801c8ed42$85f8aaf0$c2f0200a@cisco.com> > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > X-Mailer: Microsoft Office Outlook 11 > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 > Thread-Index: Acjsnc/GxIykw+/QS2iwD8QHFFy5BAAnFgqw > DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6680; t=1216872335; x=1217736335; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Re=3A=20[Sip]=20WGLC=20on=20DTLS=20Framework=20 draft-ietf-sip-dtls-srtp-framework-02 |Sender:=20; bh=TYYG8+VBQrzhiDHbCm8x/bQQxDrL4cc4+r4L2lBqI2E=; b=bgTVwkMMkP6HZXx31/ckCuB7+D+ctpZBb7F8MpOmtl72A0CC2P0JehjHo/ 2DL/VgJNJriq0r6J5LNqzdtiZzdWMfpX5d6RjONy287bQeyUWHAI9xlXjAHF b0wcuG2uNc; > Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > Sent: Wednesday, July 23, 2008 1:26 AM > > To: SIP IETF > > Cc: Cullen Jennings > > Subject: [Sip] WGLC on DTLS Framework draft-ietf-sip-dtls-srtp-framework-02 > > > > > > I'm happy to announce a Working Group Last Call on the > > standards-track DTLS Framework document: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-02.txt > > > > I'd like to conclude this WGLC by Friday, August 8, 2008. > > > > Please review the document and send any comments to the list and > > author Eric Rescorla. > > I'm happy to see this finally WGLC'd, too! > > > > Overall: > > The framework document needs to require endpoints send and > receive ietf-mmusic-sdp-capability-negotiation. Without support > for that draft, many of the media security requirements cannot be > met (as mentioned in A.1 of draft-ietf-sip-dtls-srtp-framework-02). > ietf-mmusic-sdp-capability-negotiation should be promoted > to a normative requirement, and should be required (MUST) for > endpoints to support in order to adhere to the DTLS-SRTP framework. > Otherwise, we are hosed for forking and hosed for retargeting. Agreed. Added. > Section 1, Introduction: > > However, even hop-by-hop security such as provided by SIPS provides > some protection against modification by attackers who are not on the > signalling path. > > With or without SIPS, if the attacker is off the signalling path, the > attacker has little hope of doing much damage -- they need to > guess a lot of SDP values and guess a bunch of SIP values (call-id) > in order to be successful. > > So, I would replace the last phrase with: > > "... who are not in control of on-path signaling elements." > > resulting in: > > However, even hop-by-hop security such as provided by SIPS provides > some protection against modification by attackers who are not in > control of on-path signaling elements." Done. > Section 5, Exchanging Certificates: > > (the text exceeds the section title when it goes beyond just what > happens with certificate exchange; perhaps consider re-titling). > > My slightly more substantive comment is: > > The answerer SHOULD use the setup attribute value of > setup:active and will send the client_hello in the media path." > ^^^^ > MUST Refined to match your comments and Peter's. > Section 6.6, "ICE Interaction": > > ... > If ICE is not being used, then there is potential for a bad > interaction with SBCs via "latching", as described in > [I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this > issue, if ICE is not being used and the DTLS handshake has not > completed, upon receiving the other side's then the passive side MUST > ^ > SDP > > do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis] > connectivity check in order to open up the appropriate pinhole. > > > Requirements to do something when ICE is *not* being used should not be in a > section titled "ICE Interaction". I would move this paragraph describing how > to handle SBC 'latching' to its own section perhaps titled "SBC Interaction". Done. > Section 8.6, > > o When phone number URIs (e.g., > 'sip:+17005551008@chicago.example.com') are used, > > I believe the current consensus is that a phone number would include > ;user=phone, so the example should be > sip:+17005551008@chicago.example.com;user=phone Done > Section 8.6, "Limits of Identity Assertions" > > (This section is well written.) > > > Implementors should therefore take care not to indicate > misleading peer identity information in the user interface. e.g. If > ^^^^^^ > formatting error around here > the peer's identity is sip:+17005551008@chicago.example.com, it is > not sufficient to display that the identity of the peer as > +17005551008, unless there is some policy that states that the domain > "chicago.example.com" is trusted to assert E.164 numbers. > > chicago.example.com only needs to be trusted to assert numbers you trust > it to assert -- not a blanked "to assert E.164 numbers". For example, > I might trust, and expect, Verizon to claim E.164s that it owns, but > I do not trust, nor expect, Verizon to claim an E.164 with a +353 > country code. > > I would revise the above to end with something like: > > ... unless there is some policy that states that the domain > "chicago.example.com" is trusted to assert the E.164 number > is it asserting. > ^^^^^^^^^^^^^^^ Done. > later, > > Otherwise, the recipient cannot rely on the RFC 4474 Identity > assertion and the UA MUST not indicate to the user that a secure call > ^^^^^^^^ > MUST NOT > has been established to the claimed identity. Implementations which > are configured to only establish secure calls SHOULD terminate the > call in this case. Done. > Section A.3: > > > add a reference to draft-ietf-avt-dtls-srtp-03.txt > which describes how session resumption is supposed to be > implemented. Done. > > Section A.12., "3rd Party Certificates (R-CERTS, R-EXISTING)" > > Third party certificates are not required. However, if the parties > share an authentication infrastructure that is compatible with TLS > (3rd party certificates or shared keys) it can be used. > > > RFC4474 is part of the framework for securing DTLS-SRTP, and > as you know there is a lot of consternation around this point. > Citing section 13.4 of RFC4474 would be helpful, because section > A.12 of sip-dtls-srtp-framework relies on the following small > sentence in Section 13.4 of RFC4474: > > It > is strongly RECOMMENDED that self-signed domain certificates should > not be trusted by verifiers, unless some previous key exchange has > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > justified such trust. > ^^^^^^^^^^^^^^^^^^^^ I added a reference. > Section A.15, Denial of Service Vulnerability (R-DOS) > > Please add a reference to Section 4.2.1 of RFC4347. Done. > > Section A.18., "Downgrading Protection (R-DOWNGRADE)" > > DTLS provides protection against downgrading attacks since the > selection of the offered ciphersuites is confirmed in a later stage > of the handshake. This protection is efficient unless an adversary > is able to break a ciphersuite in real-time. > > This should also mention integrity protection of signaling is > necessary in order to prevent downgrade to RTP (because I believe > we need to require sdp-capability-negotiation for all of this to > work correctly.) Agreed. added some text per this and Hannes's comments. > Peter Schneider: > > > 1) The draft currently states in section 5: > > " The endpoint MUST use the setup attribute defined in [RFC4145]. > The endpoint which is the offerer MUST use the setup attribute > value of setup:actpass and be prepared to receive a client_hello > before it receives the answer. The answerer SHOULD use the setup > attribute value of setup:active and will send the client_hello in > the media path." > > My proposal is to replace the last sentence by "The answerer MUST use > the setup > attribute value of setup:active or the setup attribute value of > setup:passive." I set this to MUST use both but with active as recommended. The answerer MUST use either a setup attribute value of setup:active or setup:passive. Note that if the answerer uses setup:passive, then the DTLS handshake will not begin until the answerer is received, which adds additional latency. setup:active allows the answer and the DTLS handshake to occur in parallel. Thus, setup:active is RECOMMENDED. The active party MUST send the ClientHello in the media path. I think this is the best compromise. There's really no advantage to being passive. > With this, if the receiver takes up the active role, as recommended in > the original text, he can start the handshake and if the handshake has > been carried out successfully before the SDP answer, he can send > encrypted early media (before the SDP answer). Obviously, with the usage > of self signed certificates, the offerer can authenticate the origin of > the early media only retrospectively, after he has received the SDP > answer, which somewhat reduces the value of encrypting the early media. > Early media as well as a handshake at that point in time will however > not work in an environment, where middleboxes are present that will not > let traffic pass in the media plane before the answer has been sent. > > So if the receiver assumes such an environment, he may decide to take up > the passive role. By this, the offerer will start the handshake as soon > as he receives an answer, which would typically be close to the first > point in time at which the handshake messages will be able to pass the > middleboxes. > > I feel it's quite reasonable to do the handshake after offer and answer > have been exchanged, because the offerer can check the fingerprint of > the certificate received in the handshake immediately; and he will not > accept encrypted media that may be sent by an attacker. So he is less > vulnerable to DoS. This does not allow encrypted early media to be > received, but is this so essential? In fact, accepting only encrypted > early media could be harmful, as it would prevent a caller to receive > e.g. an announcement that is sent by some server in the network that > only sends unsensitive announcements and therefore does not support > encryption at all. I think this is covered in the security considerations section. I don't really understand what DoS issue you're concerned about. > 2) With respect to unmanaged (e.g. residential) stateful firewalls the > draft currently states in section 6.6 that if ICE is not used and the > handshake could not be completed (until offer and answer have been > exchanged) > > "the passive side MUST > do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis] > connectivity check in order to open up the appropriate pinhole. All > implementations MUST be prepared to answer this request during the > handshake period even if they do not otherwise do ICE." > > And later, in the message flow on page 13 and the respective > explanations it becomes obvious that the idea is that the sender of this > STUN connectivity check in fact waits for an answer before he proceeds That's not intended at all. They're done in parallel. > (although implementations must only *be prepared* to answer a > connectivity request - I wonder whether "be prepared" should rather be > removed from this sentence). However, if there are middleboxes on the > path that block the STUN connectivity check, an answer will never come, > although the purpose of the connectivity check - to establish a session > in the residential firewall and open it up for incoming traffic - may > already have been achieved. > > So instead of making the sending of the STUN connectivity check > mandatory in this situation, I propose rather to recommend that the > passive UA in the connection setup should try to make sure that a > firewall protecting the UA does not block the client hello starting the > handshake. This could be done by STUN or other means. This is exactly > what is recommended also in draft-ietf-mmusic-media-path-middleboxes-01, > section 7, REC #1. I think IETF general policy is to prefer ICE, which is what you would do here. This is a stopgap. > 3) More generally, I propose that the draft should mention possible > problems with middleboxes, and should advise implementors to follow the > recommendations in draft-ietf-mmusic-media-path-middleboxes. I don't want to create a normative reference, but I added a section that points at that and states it has recommendations. > 4) Concerning the possible sequence of messages used to establish > sessions that use DTLS-SRTP, the draft IMO should give clearer > recommendations. This is currently mostly treated in the section > "example message flow", which indeed explains two flows currently. It is > unclear, to which degree this is normative, and what variants of such > flows would also be considered compliant to the draft. I went through and tried to add some clarifying text where I thought appropriate. That said, since TLS allows inband negotiation and there is some inherent reordering due to the use of multiple parallel flows, a lot of different variants are legal. Is there some particular point you want clarified? > 5) Another topic where information is only given in the example flows is > the treatment of RTCP. If RTP/RTCP multiplexing on a single port is not > used, at which time should the handshake for RTCP be done - immediately > after the handshake for RTP, so that sender reports could be sent for > early media? Or only after the SDP answer, when both sides know which > ports are used on both sides? This becomes even more complex, if > non-symmetric RTP/RTCP would be applied, which is not excluded in > draft-ietf-avt-dtls-srtp-02. > I propose to describe these issues in a dedicated section. I added some text and referenced the AVT draft which talks about the performance issues. -Ekr