Best Practices for Securing RTP Media Signaled with SIP
RFC 8862

Note: This ballot was opened for revision 07 and is now closed.

(Ben Campbell) Yes

(Alissa Cooper) Yes

Comment (2019-03-06 for -07)
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."

(Alexey Melnikov) (was No Objection) Yes

Comment (2019-04-24 for -07)
No email
send info
Taking over as the responsible AD from Ben.

(Adam Roach) Yes

Comment (2019-03-05 for -07)
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)...

(Ignas Bagdonas) No Objection

(Deborah Brungard) No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-05-02)
Thank you for resolving my Discuss point!

(Suresh Krishnan) No Objection

Comment (2019-03-05 for -07)
* Section 4.3.

I had a hard time understanding this updated text. Either this is incorrect (e.g. Should this refer to 8224 instead of 4474?) or it needs some clarification.

"The examples in [RFC4916] are based on the original [RFC4916], and will not match signatures using [RFC4474]."

Warren Kumari No Objection

Comment (2019-03-05 for -07)
Please also see Dan Romascanu's OpsDir review - it makes some really good points. Thanks Dan!

(Mirja Kühlewind) No Objection

Comment (2019-02-28 for -07)
Given that use of ietf-mmusic-trickle-ice-sip is recommended, it feels like this doc should be a normative reference.

(Terry Manderson) No Objection

(Eric Rescorla) No Objection

Comment (2019-03-06 for -07)
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,..

Alvaro Retana No Objection

Martin Vigoureux No Objection