Subject: [Sipbrandy] Benjamin Kaduk's Discuss on draft-ietf-sipbrandy-rtpsec-07: (with DISCUSS and COMMENT)

From: Datatracker on behalf of Benjamin Kaduk <[email-masked]>
Date: Thu, 07 Mar 2019 05:59:37 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipbrandy-rtpsec-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we need to have a bit more clarity on exactly how/what parts of
4916 are updated (per Section 4.3).  Thta is, we have some text that's
indented as if it's supposed to be logically inserted into a "revised
4916", but no indication of where or whether anything else is removed.
Furthermore, that text includes section references to portions of 4916
that are incorrect; normally an Update: would point to such text and say
"this is removed" or "this is replaced by <x>", and the current
formulation looks like it's constructing a virtual document that is
internally inconsistent.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to the authors for putting together this comprehensive treatment
of what we need for full-stack media protection via SIP/SDP/etc.; it's a
pleasure to read.

That said, I'm a little confused at whether I signal in-band that I'm using the
Section 3.1 Comprehensive Protection vs. Section 3.2 Opportunistic Security.
Does the "msec" type get used in both cases?

Section 3.1

               Broadly, it is the responsibility of SIP to provide
   integrity protection for the media keying attributes conveyed by SDP,
   and those attributes will in turn identify the keys used by endpoints
   in the RTP media session(s) that SDP negotiates.  Note that this
   framework does not apply to keys that also require confidentiality
   protection in the signaling layer, such as the SDP "k=" line, which
   MUST NOT be used in conjunction with this profile.  In that way, once

Maybe s/keys/key exchange mechanisms/?  I misread this the first time around.

   SIP and SDP have exchanged the necessary information to initiate a
   session, media endpoints will have a strong assurance that the keys
   they exchange have not been tampered with by third parties, and that
   end-to-end confidentiality is available.

I think I'm missing a step in the reasoning here.  Just because the keys
themselves don't go in cleartext we're confident there's no tampering?

   To establishing the identity of the endpoints of a SIP session, this
   specification uses STIR [RFC8224].  The STIR Identity header has been

nit: 8224 doesn't really call itself "STIR" anywhere.

   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
   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.  [...]

I think that "over the media keys" is potentially confusing.  What seems
to be signed here is the [fingerprint of the] asymmetric keys used as
intput to a key-exchange mechanism that is used to generate the
(symmetric) media keys.

Section 3.2

   Opportunistic encryption approaches typically have no integrity
   protection for the keying material in SDP.  Sending SIP over TLS hop-
   by-hop between user agents and any intermediaries will reduce the
   prospect that active attackers can alter keys for session requests on
   the wire.  However, opportunistic confidentiality for media will
   prevent passive attacks of the form most common in the threat of
   pervasive monitoring.

I'm a little confused by this statement.  How is the capability of
active attackers reduced?

Section 4

"SIP UAS" (or even "UAS") are not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt, so UAS should
be expanded on first use (or the terminology section expanded to note
documents with which the reader is assumed to be familiar).

   The SIPBRANDY deployment profile of STIR for media confidentiality
   thus shifts these responsibilities to the endpoints rather than the
   intermediaries.  [...]

Which responsibilities?

   When generating either an offer or an answer [RFC3264], compliant
   implementations MUST include an "a=fingerprint" attribute containing
   the fingerprint of an appropriate key (see Section 4.1).

nit: since this stuff crosses many different layers, is it friendly to
the reader to be explicit about "SDP offer or answer"?

Section 4.2

   Even for anonymous sessions, providing media confidentiality and
   partial SDP integrity is still desirable.  This specification
   RECOMMENDS using one-time self-signed certificates for anonymous
   communications, with a subjectAltName of
   "sip:[email-masked]".  [...]

Should we recommend that the commonName be absent?

                This signature only provides protection against non-
   Identity aware entities that might modify SDP without altering the
   PASSporT conveyed in the Identity header.

It also protects against passive observers, right?

Section 4.4

   For this profile, however, a compliant verification service that
   receives a dialog-forming SIP request containing an Identity header
   with a PASSporT type of "msec", after validating the request per the
   steps described in Section 6.2 of [RFC8224], MUST reject the request
   if there is any failure in that validation process with the
   appropriate status code per Section 6.2.2.  [...]

nit: that's 6.2.2 of RFC8224 still, but the tooling (and arguably some
readers as well) will pick it up as section 6.2.2 of the current
document (which does not exist).

                    As any verification service that receives an
   Identity header in a SIP request with an unrecognized PASSporT type
   will simply ignore that Identity header, an authentication service
   will know whether or not the terminating side supports "msec" based
   on whether or not its user agent receives a signed request in the
   backwards direction per Section 4.3.  [...]

Is this actually the case?  My understanding was that an active MITM
could drop the authentication bits and obscure whether the actual
peer supports "msec".

Section 6

                  In many such implementations, only hop-by-hop media
   confidentiality is possible.  Work is ongoing to specify a means to
   encrypt both the hop-by-hop media between a user agent and a
   centralized server as well as the end-to-end media between user
   agents, but is not sufficiently mature at this time to make a
   recommendation for a best practice here.  [...]

Tantalizing, but you're not going to give an informative reference?

Section 7

   Note that in the comprehensive protection case, the use of Connected
   Identity [RFC4916] with ICE entails that the answer containing the
   key fingerprints, and thus the STIR signature, will come in an UPDATE
   sent in the backwards direction a provisional response and
   acknowledgment (PRACK), rather than in any earlier SDP body.  [...]

nit: there seems to be a missing word here.

Section 12.2

It looks like trickle ICE should be normative (as we RECOMMEND its
implementation).

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Mar 2019 08:56:48 -0600

Hi Benjamin,

One comment inline:

Thanks!

Ben.

> On Mar 7, 2019, at 7:59 AM, Datatracker on behalf of Benjamin Kaduk <[email-masked]> wrote:
> 

I m willing to believe the draft needs more detail on what changes in 4916. But if you are asking that it be in the form of patches, that is, “old text” to be removed and “new text” that replaces it, then I don’t think that’s ever been a hard requirement. I think it’s perfectly okay to discuss the update conceptually.

I personally prefer the latter in a lot of cases, but I think both approaches are okay. The patch approach would make sense if we actually rendered patched RFCs, but we don’t.

> _______________________________________________
> Sipbrandy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipbrandy

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Mar 2019 08:59:20 -0600

> I personally prefer the latter in a lot of cases, but I think both approaches are okay. The patch approach would make sense if we actually rendered patched RFCs, but we don’t.

I'm not insisting on patches, no.
The particular trigger for me here was the apparent construction of a
compound document that is internally inconsistent.  Even de-indenting some
of the text here might be enough to avoid that conflict (though I didn't
actually check), as then we would have "commentary surrounding the update"
that is not intended to be actually in force as part of the updated
document.

-Benjamin

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2019 15:31:53 +0000

Hi,

    >>> I m willing to believe the draft needs more detail on what changes in 4916. But if you are asking that it

    >>> be in the form of patches, that is, “old text” to be removed and “new text” that replaces it, then I don’t

    >>> think that’s ever been a hard requirement. I think it’s perfectly okay to discuss the update conceptually.

    >> I personally prefer the latter in a lot of cases, but I think both approaches are okay. The patch approach would

    >> make sense if we actually rendered patched RFCs, but we don’t.

    > document.

    I have traditionally been a strong believer in patches, but I have learned to accept that it may not always be needed, or even feasible. It really depends on what we update.

    If we update detailed procedures, with MUSTs, MUST NOTs etc, that will affect functionality and/or interoperability if understood wrong, we need to make sure that a non-patch

    update still keep the details clear.

    And, just to verify (I may have asked this already earlier in the process), it is ok for a BCP to make normative updates to a Standards Track, right?

    Regards,

    Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Mar 2019 09:39:05 -0600

> On Mar 7, 2019, at 9:31 AM, Christer Holmberg <[email-masked]> wrote:
> 

That is my understanding. We usually treat BCPs as of equivalent maturity to the standards track. (sometimes even higher.)

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2019 15:43:49 +0000

Hi,

> That is my understanding. We usually treat BCPs as of equivalent maturity to the standards track. (sometimes even higher.)

That is how I remembered things too. Just wanted to verify.

Regards,

Christer

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 20 Mar 2019 17:19:15 +0000

-Benjamin

I think you are correctly sensing here that we're a bit on the fence about whether this really "updates" RFC4916. We should get off that fence one way or another. At the end of section 4.3, we do kind of leave it to later work to do a real formal update of RFC4916 (that is alluding to the stir-connected-identity draft, very obliquely).  I would be happy to de-indent, and indeed I'd probably be fine removing the formal normative update of RFC4916 from the boilerplate. Really, the point of the text here is to say that if you were using RFC4916 with STIR for this purpose, you would have to do a couple of things differently. That doesn't mean RFC4916 is broken or requires modification outside of this use case.

Jon Peterson
Neustar, Inc.