Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05

From: Leon Portman <[email-masked]>
Date: Tue, 3 Jul 2012 09:28:31 +0300

Richard Hi

Thank you very much for the review. It is very helpful. Please see below my answers.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Thursday, June 28, 2012 6:58 PM
To: [email-masked]
Subject: [siprec] Security review of draft-ietf-siprec-protocol-05

Dear SIPREC,

At the SIPREC meeting at the last IETF, I volunteered to do a security review of the SIPREC protocol document.  Thanks to the chairs increasingly persistent reminders, I've finally gotten around to doing it :)

At one level, my basic question is: How is this better than just doing a PCAP?  I can see the efficiency gains in terms of RTP handling, but I'm concerned that (1) the security requirements need to be more tightly specified, and (2) there seems to be quite a bit of information loss.
[LeonP] PCAP method (passive sniffing) requires usage of SPAN ports in order to forward RTP traffic towards recording system. It used to be popular method of recording but now Enterprises prefer active methods for following reasons: less configuration overhead, support for remote recording systems, better security, support for selective recording etc. I agree on some level of information loss but we do plan to support different extension of metadata so all additional information still can be captured.

Starting with the most obvious part: The Security Considerations needs to be tightened up.  This document benefits from the fact that the SRC and the SRS are logically within the same administrative domain, so it should be feasible to establish credentials that they use to authenticate one another.  So the document should REQUIRE that the SRC and the SRS mutually authenticate to one another, either using SIP authentication or using TLS authentication beneath SIPS.
[LeonP] Agree

At the media level, is there a reason that you don't specify a keying mechanism?  Why would you not just specify DTLS-SRTP?  It may also be worth noting that because this protocol will tend to be used within an administrative domain, the need for confidentiality is lower than in the general Internet; however, there is still a strong need for authentication.  So this document should REQUIRE that implementations support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND support for others.
[LeonP] Actually we wanted to support all standard keying mechanisms. However because SIPREC media session is established in parallel to the actual communication session, we want to prefer to use keying mechanism with fastest session negotiation time in order to minimize lost of recoding (media clipping). DTLS-SRTP is problematic from this point of view.

Speaking of SRTP, it's not clear whether there's a requirement for the SRC/SRS to have access to the keys used to protect secure media, in the case where the SRC is a middlebox, not terminating media.  To support this case, you would need (1) a way to get the key from the endpoint to the SRC, and (2) a way to get the key from the SRC ot the SRS.  I would suggest looking at EKT / KTR for both of these [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section-4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-03].
[LeonP] Our assumption  was that it is out of scope of this work how SRC will get keys. We used to have text about it and it was removed. We should discuss it little more.

Finally, it seems like a gap that the SIP signaling information for the recorded session doesn't get passed off to the SRC.  Section 8 of the current document describes how to pass "metadata", but doesn't really define what the metadata is. 
[LeonP] We have separate draft for the description of the metadata

Hope this helps,
--Richard

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 16:24:34 -0400

Couple of responses inline.

> [LeonP] Actually we wanted to support all standard keying mechanisms. However because SIPREC media session is established in parallel to the actual communication session, we want to prefer to use k…

Well, you could buffer to prevent clipping, of course, since this isn't actually real-time.  

In any case, with TLS session resumption, you can amortize the cost of TLS negotiation across a long period of time.

> [LeonP] We have separate draft for the description of the metadata

Sorry, missed the reference.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 28 Jul 2012 22:39:45 +0000

Hi,

So if I try to summarize the open issues would the following be correct?

1. We need to tighten up the section on authentication to require mutual authentication which could be done via SIP authentication of Mutual TLS Authentication with the later probably preferred. However personally I don't think we want to require SIPS in the TLS case.

2. Richard suggested that we should specify a key exchange mechanism and suggested we might specify DTLS-SRTP with a particular protection profile. As Leon pointed out so far we have worked on the assumption that we don't need to specify a particular mechanism but maybe we need to tighten up the wording here. Are there any other opinions on this?

3. At present we don't say anything about how the SRC might obtain keys if it is not terminating media and Richard indicated that we might want to consider EKT as a solution. However again this is an area we have deliberately not specified so is there a reason to do so?

Regards
Andy

> Sent: 12 July 2012 21:25
> To: Leon Portman
> Cc: [email-masked]
> Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05
> 
> > At the SIPREC meeting at the last IETF, I volunteered to do a
> security review of the SIPREC protocol document.  Thanks to the chairs
> increasingly persistent reminders, I've finally gotten around to doing
> it :)
> >
> > At one level, my basic question is: How is this better than just
> doing a PCAP?  I can see the efficiency gains in terms of RTP handling,
> but I'm concerned that (1) the security requirements need to be more
> tightly specified, and (2) there seems to be quite a bit of information
> loss.
> > [LeonP] PCAP method (passive sniffing) requires usage of SPAN ports
> in order to forward RTP traffic towards recording system. It used to be
> popular method of recording but now Enterprises prefer active methods
> for following reasons: less configuration overhead, support for remote
> recording systems, better security, support for selective recording
> etc. I agree on some level of information loss but we do plan to
> support different extension of metadata so all additional information
> still can be captured.
> >
> > Starting with the most obvious part: The Security Considerations
> needs to be tightened up.  This document benefits from the fact that
> the SRC and the SRS are logically within the same administrative
> domain, so it should be feasible to establish credentials that they use
> to authenticate one another.  So the document should REQUIRE that the
> SRC and the SRS mutually authenticate to one another, either using SIP
> authentication or using TLS authentication beneath SIPS.
> > [LeonP] Agree
> >
> > At the media level, is there a reason that you don't specify a keying
> mechanism?  Why would you not just specify DTLS-SRTP?  It may also be
> worth noting that because this protocol will tend to be used within an
> administrative domain, the need for confidentiality is lower than in
> the general Internet; however, there is still a strong need for
> authentication.  So this document should REQUIRE that implementations
> support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND
> support for others.
> > [LeonP] Actually we wanted to support all standard keying mechanisms.
> However because SIPREC media session is established in parallel to the
> actual communication session, we want to prefer to use keying mechanism
> with fastest session negotiation time in order to minimize lost of
> recoding (media clipping). DTLS-SRTP is problematic from this point of
> view.
> 
> In any case, with TLS session resumption, you can amortize the cost of
> TLS negotiation across a long period of time.
> 
> 
> > Speaking of SRTP, it's not clear whether there's a requirement for
> the SRC/SRS to have access to the keys used to protect secure media, in
> the case where the SRC is a middlebox, not terminating media.  To
> support this case, you would need (1) a way to get the key from the
> endpoint to the SRC, and (2) a way to get the key from the SRC ot the
> SRS.  I would suggest looking at EKT / KTR for both of these
> [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section-
> 4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-
> 03].
> > [LeonP] Our assumption  was that it is out of scope of this work how
> SRC will get keys. We used to have text about it and it was removed. We
> should discuss it little more.
> >
> > Finally, it seems like a gap that the SIP signaling information for
> the recorded session doesn't get passed off to the SRC.  Section 8 of
> the current document describes how to pass "metadata", but doesn't
> really define what the metadata is.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Jul 2012 02:08:49 -0400

> 1. We need to tighten up the section on authentication to require mutual authentication which could be done via SIP authentication of Mutual TLS Authentication with the later probably preferred. Ho…

I understand why the SRC needs to authenticate the SRS before sending 
data to it.

I *don't* understand why, from a security perspective, its necessary to 
prevent an SRS from recording unauthenticated SRCs if it wants to. Of 
course an SRS expends significant resources making recordings, so its 
likely that it will *want* to authenticate. But that's still a policy 
decision.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Sun, 29 Jul 2012 12:16:24 +0300

SRC authentication is also important specially for compliance recording use case. We can always of course rely on voice print authentication but still such "fake" SRC can send for example metadata about false calls claiming for example some financial trader had communication session with another trader that he is not allowed to talk to (trading chinese wall compliance rule for example)

Leon

On Jul 29, 2012, at 9:08 AM, Paul Kyzivat <[email-masked]> wrote:

> I understand why the SRC needs to authenticate the SRS before sending data to it.
> 
> I *don't* understand why, from a security perspective, its necessary to prevent an SRS from recording unauthenticated SRCs if it wants to. Of course an SRS expends significant resources making recordings, so its likely that it will *want* to authenticate. But that's still a policy decision.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Jul 2012 12:01:23 -0400

> SRC authentication is also important specially for compliance recording use case. We can always of course rely on voice print authentication but still such "fake" SRC can send for example metadata…

Sure, I understand that.
But not all recording is done for compliance purposes.

I'm only questioning putting a MUST strength requirement on this.
I do think SHOULD strength is appropriate. And I do think MUST strength 
is appropriate for authentication of the SRS.

	Thanks,
	Paul

> Leon
>
>
> On Jul 29, 2012, at 9:08 AM, Paul Kyzivat<[email-masked]>  wrote:
>