Best Practices for Securing RTP Media Signaled with SIP
RFC 8862
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
Please also see Dan Romascanu's OpsDir review - it makes some really good points. Thanks Dan!
(Adam Roach; former steering group member) Yes
Thanks to the work that the authors and other contributors have put into describing these practices. I have a handful of relatively minor comments. --------------------------------------------------------------------------- During the development of this document, was there any discussion of the issues raised by draft-ietf-mmusic-sdp-uks? Minimally, it seems that the problem described there should be summarized and an informative link to that document provided, probably somewhere in §3.1. --------------------------------------------------------------------------- §4: > needs to be repeated at the endpoint obtain the end-to-end assurance. Nit: "...at the endpoint to obtain end-to-end assurance." ^^ ^ > Intermediaries supporting this specification MUST NOT block or > otherwise redirects calls Nit: "...redirect..." --------------------------------------------------------------------------- §4: > STIR > authentication services MUST signal their compliance with this > specification by adding the "msec" header element defined in this > specification to the PASSporT header. The use of the term "header element" threw me off for a few moments. It almost sounds like the document is proposing a new PASSporT parameter, rather than defining a new value for the "ppt" parameter. I think this means to say something like "...by adding a PASSporT with a type of "msec"..." This phrasing also appears in section 8. --------------------------------------------------------------------------- §4.1: > service on behalf of an entire domain, just as in SIP an proxy server Nit: "...a proxy server..." --------------------------------------------------------------------------- §4.3: > Identity header for the recipient of an INVITE. The procedures in Nit: "...Identity header field..." --------------------------------------------------------------------------- §4.3: > STIR [RFC8224] provides integrity protection for the SDP bodies of > SIP requests... I thought that generalized body protection was one of the things we removed between 4474 and 8224. On a quick check, it looks like the only body-level integrity protection 8224 affords is "a=fingerprint" attributes. I propose: "...provides integrity protection for the fingerprint attributes in SIP request bodies..." (and similar changes for the other two mentions of "body" in this paragraph) --------------------------------------------------------------------------- §4.4: > Identity header in a SIP request with an unrecognized PASSporT type Nit: "...Identity header field..." --------------------------------------------------------------------------- §6: > Another class of entities that might relay SIP media are back-to-back > user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], > it may be possible for those devices to act as media relays while > still permitting end-to-end confidentiality between user agents. I'm a little surprised to see no mention of the interaction between B2BUAs and the "trust on first use" technique described in Section 4.1. In particular, an endpoint that is persistently behind a B2BUA, where that B2BUA implements the Identity handling described in this document (acting as an endpoint) could persistently receive the same identity for a remote user -- where that remote identity is actually one created by the B2BUA. I don't think mitigation is something this document needs to figure out; but I think the situation should be called out explicitly. --------------------------------------------------------------------------- §7: > In order to best enable end-to-end connectivity between user agents, > and to avoid media relays as much as possible, implementations of > this specification must support ICE [RFC8445]. It seems this is intended to be a normative "MUST." --------------------------------------------------------------------------- §7: > ...will come in an UPDATE > sent in the backwards direction a provisional response and > acknowledgment (PRACK)... I can't parse this clause. I think it means to say: ...will come in an UPDATE sent in the backwards direction, a provisional response, and a provisional acknowledgment (PRACK)...
(Alexey Melnikov; former steering group member) (was No Objection) Yes
Taking over as the responsible AD from Ben.
(Alissa Cooper; former steering group member) Yes
Very glad to see this work coming to a close. = Section 3.2 = OLD Work is already underway on defining approaches to opportunistic media security for SIP in [I-D.johnston-dispatch-osrtp] NEW At the time of this writing, work was underway to define approaches to opportunistic media security for SIP in [draft-ietf-sipbrandy-osrtp] = Section 4 = s/at the endpoint obtain/at the endpoint to obtain/ = Section 5 = Please update the OSRTP citation to point to draft-ietf-sipbrandy-osrtp. = Section 10 = Presumably "PASSporT Type registry" should say "PASSporT Resource Priority Header (rph) Types registry."
(Ben Campbell; former steering group member) Yes
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you for resolving my Discuss point!
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4970 IMPORTANT S 4.1. > > 4.1. Credentials > > In order to implement the authentication service function in the user > agent, SIP endpoints will need to acquire the credentials needed to > sign for their own identity. That identity is typically carried in How do relying parties determine whether the certificate is attached to an intermediary or the client. S 4.1. > possession certificates similar to those used in the email world > could be offered for SIP, either for greenfield identifiers or for > telephone numbers, this specification does not require their use. > > For users who do not possess such certificates, DTLS-SRTP [RFC5763] > permits the use of self-signed keys. This profile of STIR employs This doesn't seem quite right. DTLS-SRTP uses self-signed certs that go in a fingerprint which is then transitively signed by the cert via STIR COMMENTS S 1. > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 > > 1. Introduction > > The Session Initiation Protocol (SIP) [RFC3261] includes a suite of > security services, ranging from Digest authentication for Nit: maybe "including". Ranging is an odd phrase with three things S 1. > available, such as Secure RTP [RFC3711]. However, the practices > needed to bind security at the media layer to security at the SIP > layer, to provide an assurance that protection is in place all the > way up the stack, rely on a great many external security mechanisms > and practices, and require a central point of documentation to > explain their optimal use as a best practice. This sentence is kind of run-on. S 1. > and practices, and require a central point of documentation to > explain their optimal use as a best practice. > > Revelations about widespread pervasive monitoring of the Internet > have led to a reevaluation of the threat model for Internet > communications [RFC7258]. In order to maximize the use of security I don't actually agree that this is a reevaluation. 3552 already told you what you needed to know here. S 3.1. > STIR generates a signature over certain features of SIP requests, > including header field values that contain an identity for the > originator of the request, such as the From header field or P- > Asserted-Identity field, and also over the media keys in SDP if they > are present. As currently defined, STIR only provides a signature > over the "a=fingerprint" attribute, which is a key fingerprint Not "only" because you just said that it covered other things. Maybe "in additon" S 3.1. > Asserted-Identity field, and also over the media keys in SDP if they > are present. As currently defined, STIR only provides a signature > over the "a=fingerprint" attribute, which is a key fingerprint > utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers > comprehensive protection for SIP sessions, in concert with SDP and > SRTP, when DTLS-SRTP is the media security service. The underlying I would remove the commas around , in concert,..
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
Given that use of ietf-mmusic-trickle-ice-sip is recommended, it feels like this doc should be a normative reference.
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection