Skip to main content

Best Practices for Securing RTP Media Signaled with SIP
RFC 8862

Yes

(Ben Campbell)

No Objection

Alvaro Retana
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Spencer Dawkins)
(Terry Manderson)

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

Alvaro Retana No Objection

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!

(Adam Roach; former steering group member) Yes

Yes (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)...

(Alexey Melnikov; former steering group member) (was No Objection) Yes

Yes (2019-04-24 for -07)
Taking over as the responsible AD from Ben.

(Alissa Cooper; former steering group member) Yes

Yes (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."

(Ben Campbell; former steering group member) Yes

Yes (for -07)

                            

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

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

(Deborah Brungard; former steering group member) No Objection

No Objection (for -07)

                            

(Eric Rescorla; former steering group member) No Objection

No Objection (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,..

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -07)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -07)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (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.

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -07)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (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]."

(Terry Manderson; former steering group member) No Objection

No Objection (for -07)