Subject: [straw] AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07

From: "Ben Campbell" <[email-masked]>
Date: Mon, 05 Oct 2015 21:27:26 -0500

Hi,

This is my AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07. I think 
at least some of this needs to be resolved prior to IETF last call.

Thanks!

Ben.
-------------------

Comments and Questions
======================

- There's a marked lack of mention of B2BUAs that inspect or modify 
media content. I realize that this draft does not seek to enable that 
particular elephant-in-the-room. Is it worth mentioning them as out of 
scope? Does this draft intend to make them illegal for SRTP protected 
sessions with it's proscription about terminating dtls?

- 1.2: "The following sections describe the behavior B2BUAs MUST follow 
in
    order to avoid any impact to end-to-end DTLS-SRTP sessions."
Does that need the MUST, since the described behavior also uses 
normative language? Also, is this really a matter of things the b2bUA 
MUST do, or a set of other things it MUST NOT do?

Also, this paragraph could use some elaboration. There are a number of 
use cases that violate this(e.g. 3GPP's e2ea security model). This 
doesn't seem to forbid those, since they don't purport to support e2e 
crypto--is that the intent? Can "impact" be more precise?

-3.1.1, 3rd paragraph from end: "the B2BUA SHOULD be prepared
    to receive DTLS, STUN and media on the ports it advertised to Bob in
    the INVITE request. "

What are the consequences if it's not prepared to do so? Also, this is a 
timing issue, right? So shouldn't is say something like "SHOULD be 
prepared immediately prepared" or "should be prepared to 
receive...before the it receives the SIP response"?

-3.1.1, 2nd to last paragraph:
Is the a general proscription, or is it limited to cases where 4474bis 
is in use?

Also, I think the 4474bis reference needs to be normative, given that 
one needs to understand that draft to implement the normative bits about 
modifying anything protected by the signature. OTOH, does this need to 
reference 4474bis, or would 4474 suffice?

-3.1.2: "The mechanism described in Security Considerations section MUST 
be
    used by endpoint to detect malicious B2BUA’s that MAY attempt to
    terminate the DTLS-SRTP session."

I'm not sure it makes sense for this draft to put normative requirements 
on endpoints. Do you mean to say they "can" use
the mechanism? Also, that MAY is a statement of fact, not a normative 
requirement.

I'm confused by language about "inspect[ing] the RTP headers and RTCP 
packets" here and in the subsections. What do you mean about inspecting 
rtcp packets? Is this an attempt to dance around content inspection? 
Wont a good portion of the "rtcp packets" be encrypted?

- 3.1.2.2:
Is the point of this to say b2buas that modify things are out of scope? 
Not allowed?
The paragraph takes the form of "To do A, you must do B, and B is not 
allowed". It might be easier to say that "You can't do A, because of the 
issue with B."

Can you be more precise about what "break end-to-end security" means? 
e.g. the receiver would consider the packets invalid? Also, this 
paragraph might could use another mention of 4474/4474bis.

- 4: "Since DTLS operates on
    the 5-tuple"

What does that mean? It sounds something like "encrypts" or 
"authenticates" the 5, tuple--but I don't think that's what you mean.

"unique transport addresses"
Do you mean the b2bua must replace each answerers's address with a 
distinct address? Also do you mean distinct address, or distinct 
combination of address and port?

-5: "This document does not
    introduce any specific security considerations beyond those detailed
    in [RFC5763]."

It seems like the previous sentence qualified as a security 
consideration beyond those in 5763.

Editorial and nits
==================

- Section 1.1: "DTLS-SRTP is defined for point-
    to-point media sessions"
I suggest "currently defined". That's starting to change with PERC.

- 3.3, 3rd paragraph from end:
s/"B2BUA cannot decrypt..."/"The B2BUA cannot decrypt..."

- 3.3, 2nd to last paragraph: "the B2BUA MUST
    ensure that it does not modify..."
I suggest "the B2BUA MUST NOT modify..."

- 5:"A malicious B2BUA MAY try to
    break into the DTLS connection"
That shouldn't be a 2119 MAY; it's a statement of fact.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 8 Oct 2015 08:41:16 +0000

Hi Ben,

Thanks for your comments. Please see inline

-----Original Message-----
From: straw <[email-masked]> on behalf of Ben Campbell
<[email-masked]>
Date: Tuesday, 6 October 2015 7:57 am
To: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: [straw] AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07

>scope? 

 In section 1.2 (Goals) we can add this text. Is this ok ?
EXISTING:
The following sections describe the behavior B2BUAs MUST follow in order
to avoid any impact to end-to-end DTLS-SRTP sessions.

NEW:
The following sections describe the behavior B2BUAs can follow to avoid
breaking end-to-end DTLS-SRTP sessions. B2BUAs terminating DTLS-SRTP
session are outside the scope of this document.

>Does this draft intend to make them illegal for SRTP protected

The behaviour for cases where B2BUA terminates DTLS-SRTP is not in the
scope of this draft.

>normative language?

I have re-worded this sentence as above.

>Also, is this really a matter of things the b2bUA

The draft tries to describe the behaviour that a B2BUA should follow and
this
includes what it should do and what it should not do.

>crypto--is that the intent? Can "impact" be more precise?

The sentence is re-worded now. Please see NEW text above.
The intent of this document is that B2BUA does not decrypt media. The
motivation for this comes out of the earlier discussions we had with
Stephen Farrell and in the WG where it was decided to
reduce the scope of the draft to not include B2BUAs that terminate
DTLS-SRTP sessions.

>What are the consequences if it's not prepared to do so?

The consequences can be - the messages may get dropped which in turn may
delay STUN/DTLS checks and would requires the endpoints to re-transmit the
messages. 

> Also, this is a 
>timing issue, right?

Yes. Its a timing issue.
> So shouldn't is say something like "SHOULD be

I will re-word to:

EXISTING:
The B2BUA SHOULD be prepared to receive DTLS, STUN and media on the ports
it advertised to Bob in the INVITE request.

NEW:
The B2BUA SHOULD be prepared to receive DTLS, STUN and media on the ports
it advertised to Bob in the SIP offer before it receives a SIP answer from
Bob.

>Is the a general proscription, or is it limited to cases where 4474bis

It is for cases where 4474bis is in use.

>reference 4474bis, or would 4474 suffice?

 rfc4474bis is appropriate since it defines mechanisms to use SDP
parameters (like a=fingerprint) in the Identity header digest.
 We will use rfc4474bis and make the reference normative.

>    used by endpoint to detect malicious B2BUA¹s that MAY attempt to
>the mechanism? 

This has to be fixed. The idea is to have either endpoint or the SIP proxy
server in the endpoints network to generate Identity header on behalf of
the endpoint and perform identity validation procedure.

>Also, that MAY is a statement of fact, not a normative
>requirement.

Agree. Will re-word this para to
NEW:
The identity validation mechanism described in Security Considerations
section MUST be used by the endpoint or the proxy server in the endpoints
network to detect malicious B2BUAs that attempt to
terminate the DTLS-SRTP session

>Wont a good portion of the "rtcp packets" be encrypted?

Yes. A B2BUA can inspect the unencrypted portions of the RTCP packet.

Yes. Not in scope.

>allowed". It might be easier to say that "You can't do A, because of the

Ok. Will re-word this sentence to some thing like this:

NEW:
A B2BUA cannot modify RTP headers or RTCP packets, as to do so it needs to
act as a DTLS endpoint, terminate the DTLS-SRTP session and
decrypt/re-encrypt RTP packet.

>paragraph might could use another mention of 4474/4474bis.

How about this:
EXISTING:
This would break end-to-end security and hence a B2BUA MUST NOT
terminate DTLS-SRTP session.

NEW:
This would cause the identity verification procedure discussed in 4474bis
to fail and hence a B2BUA MUST NOT terminate the DTLS-SRTP session.

>"authenticates" the 5, tuple--but I don't think that's what you mean.

How about this ?
"Since each DTLS connection is setup on a unique 5-tuple.."

>combination of address and port?

Transport address means IP address and port

>consideration beyond those in 5763.

Will re-word to:
"Security considerations discussed in [RFC5763] are also applicable to
this document."

>Editorial and nits

Will fix all the NITS above.

Regards,
Ram

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

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 08 Oct 2015 09:19:18 -0400

Thanks for the response. Further comments inline. I removed sections 
that don't appear to need further discussion.

Thanks!

Ben.

On 8 Oct 2015, at 4:41, Ram Mohan R (rmohanr) wrote:

[...]

> session are outside the scope of this document.

I think that's moving in the right direction, but there's normative text 
elsewhere that says b2buas MUST NOT terminate dtls-srtp. Would it make 
sense to say something like "B2BUAs that inspect or modify media content 
are outside the scope of this document"?

Or is it the intent to forbid such devices?

> The behaviour for cases where B2BUA terminates DTLS-SRTP is not in the

See above comment about normative statements concerning the termination 
of dtls-srtp.

[...]

> delay STUN/DTLS checks and would requires the endpoints to re-transmit 

Given that this is a SHOULD rather than a MUST, it would be useful to 
describe those consequences in the text.

[...]

> We will use rfc4474bis and make the reference normative.

Your response is reasonable, but keep in mind that will block 
publication of this draft until 4474bis is published.

> the endpoint and perform identity validation procedure.

I'm not sure I understand what you mean by "this has to be fixed". Do 
you mean fixed in the draft, or that endpoints need to fix behavior?

[...]

> Yes. A B2BUA can inspect the unencrypted portions of the RTCP packet.

The wording "and RTCP packets" may lead people to believe it can inspect 
the entire packet. It might be worth saying "unencrypted parts of the 
RTCP packet". It's probably not necessary to say that every time, since 
it complicates the sentence structure, but it would be helpful to do so 
at least the first time.

[...]

> decrypt/re-encrypt RTP packet.

I suggest "...it would need to...". Otherwise that looks good.

> to fail and hence a B2BUA MUST NOT terminate the DTLS-SRTP session.

I suggest "identity and integrity protection procedures". Otherwise it 
looks good.

> "Since each DTLS connection is setup on a unique 5-tuple.."

Works for me.

> Transport address means IP address and port

I'm not sure everyone will read it that way, unless you define that in 
the draft or reference a definition.

[...]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 8 Oct 2015 10:27:20 -0400

> it complicates the sentence structure, but it would be helpful to do so

There is no point in specifying that the B2BUA cannot (or MUST not) 
inspect encrypted parts. It *can* inspect the encrypted data. And that 
is not a problem as long as it doesn't have the keys to decrypt it.

All you can meaningfully do is observe that the B2BUA does not have the 
ability to inspect the unencrypted form of encrypted data that flows 
through it.

I think this applies to several points that discuss inspection.

	Thanks,
	Paul

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 8 Oct 2015 14:45:34 +0000

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, October 08, 2015 6:49 PM
> To: Ram Mohan R (rmohanr)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [straw] AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07
> 
> Thanks for the response. Further comments inline. I removed sections that
> don't appear to need further discussion.
> 
> Thanks!
> 
> Ben.
> 
> >> particular elephant-in-the-room. Is it worth mentioning them as out
> >> of scope?
> >
> > The following sections describe the behavior B2BUAs MUST follow in
> > order to avoid any impact to end-to-end DTLS-SRTP sessions.
> >
> >
> > NEW:

I think the above line is not required. This doc discusses the problem with B2BUAs terminating DTLS-SRTP session, mechanism to detect such B2BUA and says that B2BUA must not to be enabled in this mode.

> Or is it the intent to forbid such devices ?

The intent is to prohibit such devices because of the privacy concern.

> describe those consequences in the text.

The other alternative would be to change from SHOULD to MUST and avoid the above problems.

> publication of this draft until 4474bis is published.

Yes, https://tools.ietf.org/html/rfc4474#section-13.1 discusses signature over the SIP bodies but does not go into detail like rfc4474bis explains using fingerprint for generating assertion. Would it be okay to have normative reference of rfc4474 and informative reference of rfc4474bis ?

> you mean fixed in the draft, or that endpoints need to fix behavior?

I think Ram meant fix the draft. 

> I suggest "...it would need to...". Otherwise that looks good.

Sure, will change.

> I suggest "identity and integrity protection procedures". Otherwise it

Okay, will change.

> the draft or reference a definition.

Yes, will add reference.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 8 Oct 2015 14:46:17 +0000

> From: straw [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, October 08, 2015 7:57 PM
> To: [email-masked]
> >>> I'm confused by language about "inspect[ing] the RTP headers and
> >>> RTCP packets" here and in the subsections. What do you mean about
> >>> inspecting rtcp packets? Is this an attempt to dance around content
> inspection?
> > The wording "and RTCP packets" may lead people to believe it can
> > inspect the entire packet. It might be worth saying "unencrypted parts
> > of the RTCP packet". It's probably not necessary to say that every
> > time, since it complicates the sentence structure, but it would be
> > helpful to do so at least the first time.
> 
> There is no point in specifying that the B2BUA cannot (or MUST not) inspect
> encrypted parts. It *can* inspect the encrypted data. And that is not a
> problem as long as it doesn't have the keys to decrypt it.
> 
> ability to inspect the unencrypted form of encrypted data that flows through
> it.
> 

Agreed.

-Tiru

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 08 Oct 2015 12:48:08 -0400

On 8 Oct 2015, at 10:45, Tirumaleswar Reddy (tireddy) wrote:

> I think the above line is not required. This doc discusses the problem 
> with B2BUAs terminating DTLS-SRTP session, mechanism to detect such 
> B2BUA and says that B2BUA must not to be enabled in this mode.
>

See next comment...

> The intent is to prohibit such devices because of the privacy concern.

That's a different answer than Ram gave. Content aware/modifying B2BUAs 
cannot both be forbidden and out-of-scope at the same time.

I think the confusion here is around whether this draft should say 
b2buas MUST not terminate dtls-srtp, or to say that they cannot under 
most circumstances without breaking 4474/4474bis identity signatures. 
The former needs 2119 language, the latter is just a statement of fact.

There are some exceptions to the "cannot" in the above paragraph. For 
example, a b2bua that is collocated with the offerer's identity service 
could modify fingerprints prior to applying the identity signature. Or 
since 5763 only says endpoints SHOULD use 4474, a b2bua might see 
unprotected fingerprints and attempt to modify them.  Does this draft 
mean to forbid those behaviors?

>>> delay STUN/DTLS checks and would requires the endpoints to 
>>> re-transmit
>>> the
>>> messages.
>>>
>>

I would not object to that--although on reflection, isn't this 
requirement true of all b2buas? That is, is it in any way specific to 
dtls-srtp?  Is that documented elsewhere?

> Yes, https://tools.ietf.org/html/rfc4474#section-13.1 discusses 
> signature over the SIP bodies but does not go into detail like 
> rfc4474bis explains using fingerprint for generating assertion. Would 
> it be okay to have normative reference of rfc4474 and informative 
> reference of rfc4474bis ?

Both protect the fingerprint. 4474 just does it by protecting the entire 
body. 4474bis has the may be more deployable. But it seems to me that 
either work for the purposes of this draft. And since 4474bis proposes 
to obsolete 4474, a reference to 4474 will effectively become a 
reference to 4474bis.

>>> server in the endpoints network to generate Identity header on 
>>> behalf
>>> of

In any case, if this draft places new normative requirements on 
dtsl-srtp endpoints or identity services, it would need to update 5763.

[...]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 8 Oct 2015 17:01:01 -0400

On 10/8/15 12:48 PM, Ben Campbell wrote:

> could modify fingerprints prior to applying the identity signature.

A similar situation (or maybe just another way of talking about the same 
one) is that a B2BUA that can sign for the user might just be considered 
to *be* the caller in the call. The leg from that B2BUA to the "actual" 
UA can be considered to just be the implementation of a deconstructed UA.

I don't know whether to consider that a bug or a feature. I don't see 
any way to forbid this.

	Thanks,
	Paul