Subject: [siprec] Ben Campbell's Discuss on draft-ietf-siprec-protocol-17: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Thu, 02 Jul 2015 15:17:28 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-siprec-protocol-17: 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-siprec-protocol/

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

I am concerned that this draft allows the recording session to downgrade
security from the communication session. It says "SHOULD NOT", but then
explicitly allows for the downgrade when the SRC and SRS are in the same
administrative domain. This seems to create a whole new "last hop
exception" for media, similar to the one for SIPS that we took so many
years to deprecate. (Except it's worse because the potentially insecure
hop goes to an endpoint not necessarily expected to be a party to the
media.)

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

[Thanks for addressing my second and third discuss points. I've removed
them from the discuss.]

The reference to 7245 is informational. Do you expect that a
reader/implementor could understand/implement this draft without
understanding the architecture and terminology from that RFC? The same
applies for 3550--I'm skeptical that one could implement this draft
without understanding RTP.

-- Figure 1: The text says the flow is basically the same whether the SRC
is in an endpoint or separate. This may be logically true, but the flow
really would change--none of of the flow between UA(A) and SRC would
exist.

-- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS"
reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to add
some motivation as to why this draft seems to prefer UPDATE.

-- 5.3: It seems odd to me that the SRC can ignore an explicit preference
not to record. Wouldn't it be better just to refuse to complete/accept
the call, if some policy overrides the end-user's preference?

-- Figure 3: If the UA prefers not to be recorded, shouldn't it express
that at setup time, rather than wait for the SRC to indicate recording is
happening? As shown, this almost guarantees a bit of media will be
recorded. (Seems like there should be some guidance about this in the
text.) The last paragraph of 6.1.2 seems to reinforce the problem by
suggesting the participant might base the decision to express a
preference on a tag that is optional for the SRC to send in the first
place.

-- 6.3, last paragraph: It seems odd that the requirement to render a
recording indicator be lower for a media server than for other UAs. This
seems to circumvent user notification in one of the most common uses of
recording these days.

-- 9.1 : The last bullet seems to be a motivation to not send metadata at
all, which is expressly forbidden in the first paragraph.

-- 9.2: The use of  the content-type value as the sole indicator that the
an UPDATE request should be interpreted as an request for a metadata
snapshot update is rather odd.  If you end up with new kinds of metadata
requests in the future, does each one get it's own media-type?

-- 12: If this doc is to depend on the security considerations in 6341,
that needs to be a normative reference--which is a bit of a pain because
I think it's an informational RFC.

-- 12.1: 
"recording session uses TLS" -- I assume that's for SIP? Also It's worth
discussing how mutual authentication applies if the SRC is in an end-user
device. Is it expected to have a client cert? No option to use  SIP
identity?

Also, I'm a bit uncomfortable assuming devices in the same administrative
domain automatically trust each other. It might be better to say "If they
trust each other..."

-- 12.2:

I get quite a bit of heartburn out of making Security Descriptions MTI
and dtls-srtp optional. I guess I may have to hold my nose on this one.

Editorial:

-- 4: 2nd paragraph: " ... does not represent the protocol"
 and first bullet: "Delivering recorded media in real-time as the CS
media"

I don't understand what either of those mean.

-- 5.1, 2nd paragraph: "B2BUA to bridge
the media between UA(A) and UA(B)"

Is there a reason not to use the terminology from RFC 7092? (e.g. “relay”
or “terminate” media)?

-- 7.3.1: The normative language in the first paragraph is redundant to
similar language in 6.3.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 05 Jul 2015 18:40:33 -0400

> draft-ietf-siprec-protocol-17: Discuss

It looks like some of these comments were to -16, since -17 seems to 
address a number of them.

> some motivation as to why this draft seems to prefer UPDATE.

Section 9.2 now has one rationale.

Another is that UPDATE can be completed without doing an O/A, while 
INVITE requires an O/A. Since in most cases it will be unnecessary and 
undesirable to do an O/A in a request initiated by the SRS, UPDATE is a 
better choice.

> the call, if some policy overrides the end-user's preference?

As it is, with a sufficiently configurable UA I could by default 
indicate a preference not to record in all calls, and then if the UA 
alerts me that the call is being recorded I can make a decision whether 
to hang up. Or I could configure the UA to automatically disconnect as 
soon as it sees a recording indication.

If the SRC were required to honor the preference else refuse the call, 
then those choices would be harder to manage. I would have to choose a 
priori whether to indicate my preference or not. Then sometimes there 
might be calls that are recorded that would not have been had I 
indicated the preference.

> seems to circumvent user notification in one of the most common uses of

The problem is that with media servers it isn't evident who the "user" 
is, or even if there is one.

Consider an IVR. There is no human user at the IVR end. Presumably the 
IVR *code* can be aware that recording is being done (by the caller or 
an intermediary) and could adjust its behavior accordingly. But that 
isn't the same thing.

I guess we could try to enumerate different types of media servers, and 
specify what we mean for each, but that seems like a fetch-the-rock 
exercise.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 8 Jul 2015 16:03:37 +0000

There was a lot of discussion about this in the working group I remember and I think Richard Barnes raised this at the time. The reality of many deployments is that the SRC and SRS are located in the same data centre and are physically connected to the same switch without any encryption of the media over this connection. This may not be much comfort but it is the reality that the working group wanted to capture in the document and therefore the text was written to accommodate this and detail the associated risks of doing this which it does by saying that even if this physical security exists an internal attack is still possible.  The risks therefore of ignoring the "SHOULD NOT" are stated.

If this is not acceptable then I guess this could be made a "MUST NOT" but this would be ignoring a real deployment scenario.

Regards
Andy

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jul 2015 11:10:54 -0500

On 8 Jul 2015, at 11:03, Hutton, Andrew wrote:

> There was a lot of discussion about this in the working group I 
> remember and I think Richard Barnes raised this at the time. The 
> reality of many deployments is that the SRC and SRS are located in the 
> same data centre and are physically connected to the same switch 
> without any encryption of the media over this connection. This may not 
> be much comfort but it is the reality that the working group wanted to 
> capture in the document and therefore the text was written to 
> accommodate this and detail the associated risks of doing this which 
> it does by saying that even if this physical security exists an 
> internal attack is still possible.  The risks therefore of ignoring 
> the "SHOULD NOT" are stated.
>
> If this is not acceptable then I guess this could be made a "MUST NOT" 
> but this would be ignoring a real deployment scenario.

My concern is not that the administrators of the SRC and SRS will make 
bad security decisions. They might, but there's not much we can do about 
that. My concern is that a caller, who is likely not a party to those 
security decisions, negotiates certain security properties on a session 
and reasonably believes those properties to apply end-to-end. I think 
that caller has a reasonable expectation that any associated RS has at 
least similar security properties.

(As I mentioned, I am discussing this with the security ADs to see if 
they agree.)

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 8 Jul 2015 19:47:23 +0000

> least similar security properties.

I understand but to be honest no such end-to-end security exists when talking to a SRC which is not co-located with the SIP endpoint anyway so if the SRC is a B2BUA which in this scenario it will have to be then the caller cannot make any such assumption even without SIPREC.

Andy

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jul 2015 16:53:54 -0500

On 8 Jul 2015, at 14:47, Hutton, Andrew wrote:

> I understand but to be honest no such end-to-end security exists when 
> talking to a SRC which is not co-located with the SIP endpoint anyway 
> so if the SRC is a B2BUA which in this scenario it will have to be 
> then the caller cannot make any such assumption even without SIPREC.

Different situations yield different expectation. The point is, the use 
of SIPREC should not cause users to have less security than they think 
they do. (I'm intentionally ignoring the privacy implications of the 
recording itself, since I think that's a different issue.)

For example, assume Bob calls Carol, and successfully negotiates secure 
media using DTLS-SRTP. Carol's UA is co-located with the SRC. If the SRC 
establishes an RS with less protection, then Bob has been mislead. In 
the B2BUA case, I would expect the RS to have at least as good of 
protection as the legs between the B2BUA and the endpoints (for example, 
SRTP using SDes)

It may be worth discussing whether the RS needs to have the same 
protections, or merely equivalent ones. That runs the risk of making 
people figure out equivilance-of-protection, but it's hard to argue that 
"clear-text in the same administrative domain" is the same level of 
protection as DTLS-SRTP.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 9 Jul 2015 17:01:36 +0000

On: 08 July 2015 22:54 Ben Campbell [mailto:[email-masked]]
> establishes an RS with less protection, then Bob has been mislead.

In this case Carol's UA is acting as a SIP B2BUA between the CS and RS it is really no different to the centralized B2BUA case.

> In

I agree and the draft does state that but also as we are debating it also states that if you really think you know what you are doing then there might be circumstances in which this could be relaxed.  I personally would be ok with removing that part as it would not really change anything but others in the WG might want to say something on that.

> "clear-text in the same administrative domain" is the same level of

No argument.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Jul 2015 17:57:05 -0500

On 9 Jul 2015, at 12:01, Hutton, Andrew wrote:

> In this case Carol's UA is acting as a SIP B2BUA between the CS and RS 
> it is really no different to the centralized B2BUA case.
>
>
>> In
> I agree and the draft does state that but also as we are debating it 
> also states that if you really think you know what you are doing then 
> there might be circumstances in which this could be relaxed.  I 
> personally would be ok with removing that part as it would not really 
> change anything but others in the WG might want to say something on 
> that

>> "clear-text in the same administrative domain" is the same level of

After a discussion with Stephen, I think it's okay to allow the RS to be 
secured in different ways from the CS, as long as the protection is not 
downgraded. I think the "same admin domain with a protected switch" 
exception is simultaneously too wide and too specific. But language to 
the effect of " the RS media component transits a secure network path" 
could be okay here.

Here's a concrete proposal for the second paragraph in section 12:

Old:
    The SRC and SRS MUST support SIP with TLS version 1.2, SHOULD follow
    the best practices when using TLS as per [RFC7525], and MAY use SIPS
    with TLS as per [RFC5630].  The Recording Session SHOULD be at least
    as secure as the Communication Session, meaning using at least the
    same strength of cipher suite as the CS if the CS is secured.  For
    example, if the CS uses SIPS for signaling and RTP/SAVP for media,
    then the RS SHOULD NOT downgrade the level of security in the RS to
    SIP or plain RTP since doing so will mean an effective security
    downgrade for the CS.  In deployments where the SRC and the SRS are
    in the same administrative domain and the same physical switch that
    prevents outside user access, some SRCs may choose to lower the 
level
    of security when establishing a recording session.  While physically
    securing the SRC and SRS may prevent an outside attacker from
    accessing important call recordings, this still does not prevent an
    inside attacker from accessing the internal network to gain access 
to
    the call recordings.
New:
    The SRC and SRS MUST support SIP with TLS version 1.2, SHOULD follow
    the best practices when using TLS as per [RFC7525], and MAY use SIPS
    with TLS as per [RFC5630].  The Recording Session MUST be at least
    as secure as the Communication Session, meaning using at least the
    same strength of cipher suite as the CS if the CS is secured.  For
    example, if the CS uses SIPS for signaling and RTP/SAVP for media,
    then the RS may not use SIP or plain RTP unless other equivalent
    security measures are in effect, since doing so would mean an
    effective security downgrade. Examples of other potentially 
equivalent
    security mechanisms include mutually-authenticated TLS for the RS
    signaling channel or an appropriately protected network path for
    the RS media component.

Thanks!

Ben.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 10 Jul 2015 08:21:59 +0000

Looks good to me.

Andy

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: 09 July 2015 23:57
> To: Hutton, Andrew
> Cc: [email-masked]; [email-masked]; siprec-
> [email-masked]; [email-masked]; The IESG;
> [email-masked]; [email-masked];
> Stephen Farrell
> Subject: Re: Ben Campbell's Discuss on draft-ietf-siprec-protocol-17:
> (with DISCUSS and COMMENT)
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 10 Jul 2015 17:27:10 -0500

> Looks good to me.

Excellent. I entered the DISCUSS so we would discuss this. We've done 
so, so I will clear. That text or similar would make me happier, but I 
will leave it to the authors, the responsible AD, and the wg to decide 
what actually goes in the draft.

Thanks!

Ben.

>>>> media using DTLS-SRTP. Carol's UA is co-located with the SRC. If 
>>>> the
>>>> SRC

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 13 Jul 2015 21:07:22 +0000

Ben,

One question

The OLD version had:

   the RS SHOULD NOT downgrade the level of security

The NEW version has:
   
   the RS may not use SIP or plain RTP unless Š

Is the use of non normative language intentional?

Thanks,
Charles

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 13 Jul 2015 16:13:00 -0500

> Is the use of non normative language intentional?

Yes, because that phrase shows up in an example, supporting the 
normative statement that the RS MUST be at least as secure as the CS.

In context as proposed:

> [...]The Recording Session MUST be at least as secure as the 
> Communication Session, meaning using at least the same strength of 
> cipher suite as the CS if the CS is secured.  For example, if the CS 
> uses SIPS for signaling and RTP/SAVP for media, then the RS may not 
> use SIP or plain RTP unless other equivalent security measures are in 
> effect, since doing so would mean an effective security downgrade. 
> [...]

Does that make sense?

Thanks!

Ben.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 13 Jul 2015 21:24:14 +0000

Yep. Thanks.