Subject: Re: [siprec] Proposed text for security section in siprec-protocol

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 1 Oct 2012 14:24:36 +0000

Hi Henry,

See below.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henry Lum
> Sent: 27 September 2012 22:42
> To: [email-masked]
> Subject: [siprec] Proposed text for security section in siprec-protocol
> 
> It's my first attempt to begin writing the security section for the
> protocol draft. I try to capture all the important points raised in the
> previous meeting to ensure we have enough coverage for the security
> concerns.
> 
> Regards,
> Henry
> 
> 
> 12.  Security Considerations
> 
>    The recording session is fundamentally a standard SIP dialog
>    [RFC3261], therefore, the recording session can reuse any of the
>    existing SIP security mechanism available for securing the recorded
>    media as well as metadata.

Also for securing the SIP Signalling.

>  The user cases and requirements document
>    [RFC6341] outlines the general security considerations, and the
>    following describe specific security recommendations.
> 
>    The SRC and SRS MUST support SIPS and TLS as per RFC3261.

Probably should refer to RFC 5630 here rather than 3261.

>  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
>    signalling and RTP/SAVP for media, then the RS does not downgrade
> the
>    level of security in the RS to SIP or plain RTP since doing so will
>    mean an automatic 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 SRC
>    may choose lower the level of security when establishing the
>    recording session.  While physically securing the SRC and SRS may
>    prevent an outside attacker from accessing important call
> recordings,
>    this still does not prevent from an inside attacker from accessing
>    the internal network to gain access to the call recordings.
> 
> 12.1.  Authentication and Authorization
> 
>    The recording session reuses the SIP mechanism to challenge requests
>    that is based on HTTP authentication.  The mechanism relies on 401
>    and 407 SIP responses as well as other SIP header fields for
> carrying
>    challenges and credentials.
> 

Should we also say something here about the use of TLS Authentication including Mutual TLS Authentication?

>    The SRS may have its own set of recording policies to authorize
>    recording requests from the SRC.  The use of recording policies is
>    outside the scope of the Session Recording Protocol.
> 
>    The SRC and SRS MUST support mutual authentication for establishing
>    the recording session.  In deployments where the SRC and the SRS are
>    in the same administrative domain, the deployment may choose not to
>    authenticate each other or only to have SRC authenticate the SRS as
>    there is an inherent trust relation between the SRC and the SRS when
>    they are hosted in the same administrative domain.  In deployments
>    where the SRS can be hosted on a different administrative domain,
>    then it is important to perform mutual authentication to ensure the
>    authenticity of both the SRC and the SRS before transmitting any
>    recorded media.  The risk of not authenticating the SRS is that the
>    recording may be sent to a compromised SRS and that sensitive call
>    recording will be obtained by an attacker.  On the other hand, the
>    risk of not authenticating the SRC is that an SRS will be willingly
>    accept any call recording from an unknown SRC and allow potential
>    forgery of call recordings.
> 
> 12.2.  RTP handling
> 
>    In many scenarios it will be critical that the media transported
>    between the SRC and SRS to be protected.  Media encryption is an
>    important element in the overall SIPREC solution; therefore SRC and
>    SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124].  RTP/
>    SAVP and RTP/SAVPF provide media encryption, integrity protection,
>    replay protection, and a limited form of source authentication.
> They
>    do not contain or require a specific keying mechanism.
> 
>    When RTP/SAVP or RTP/SAVPF is used, RS can choose to use the same or
>    different security keys than the ones used in the CS.  Some SRCs are
>    designed to simply replicate RTP packets from the CS media stream to
>    the SRS, and the SRC will be reusing the same keys as the CS.  In
>    this case, the SRC MUST secure the SDES in the RS with at least the
>    same level of security as the CS.  The risk of lowering the level of
>    security in the RS for this case is that it will effectively become
> a
>    downgrade attack on the CS since the same key is used for both CS
> and
>    RS.

When referring to "SDES" can you change to "Source Description (SDES)" and give the reference to RFC3550. Just to avoid any confusion.

> 
>    For SRCs that perform transcoding or mixing of media before sending
>    to the SRS, the SRC MUST negotiate a different security key than the
>    one being used in the CS, to ensure that the security in the CS is
>    not compromised by the SRC when reusing the same security key.
> 
> 12.3.  Metadata
> 
>    Metadata contains sensitive information such as the address of
> record
>    of the participants and other extension data placed by the SRC.  It
>    is essential to protect the content of the metadata in the RS.
> Since
>    metadata is a content type transmitted in SIP signalling, metadata
>    can be protected by SIPS/TLS.  If the RS is not secured for any
>    reason, the metadata content can also be secured by using S/MIME.

Can we make a firm recommendation to secure using TLS and not refer to S/MIME at all?

> 
> 12.4.  Storage and playback
> 
>    While storage and playback of the call recording is beyond the scope
>    of this document, it is worthwhile to mention here that it is also
>    important for the recording storage and playback to provide a level
>    of security that is comparable to the communication session.  It
>    would defeat the purpose of securing both the communication session
>    and the recording session mentioned in the previous sections if the
>    recording can be easily played back with a simple unsecured HTTP
>    interface without any form of authentication or authorization.
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 1 Oct 2012 09:03:32 -0700

Thanks for the quick review. Please see inline.

Henry

> From: Jain, Rajnish [mailto:[email-masked]]
> Sent: September-27-12 9:31 PM
> To: Henry Lum; [email-masked]
> Subject: RE: Proposed text for security section in siprec-protocol
> 
> Hi Henry,
> 
> Pls. see a few comments in-line [rj]:
> 
Behalf Of
> Henry Lum
> Sent: Thursday, September 27, 2012 5:42 PM
> To: [email-masked]
protocol
> draft. I try to capture all the important points raised in the
previous
> meeting to ensure we have enough coverage for the security concerns.
> 
> Regards,
> Henry
> 
> 
> [rj] The existing SIP security mechanisms will also allow secure RS
SIP
> signaling (such as over TLS or IPSec).
> Substitute: ... available for securing _session signaling_, recorded
media as
> well as metadata.

[Henry] Okay I will fix this.
> [rj] _use cases_
> [rj] RFC 3261 does not require TLS support in all SIP entities. Quote
from RFC
> 3261:

[Henry] Let's change the wording to:

The SRC and SRS MUST implement SIPS and TLS.

> 
> ------------
> 26.3.1 Requirements for Implementers of SIP
> 
>    Proxy servers, redirect servers, and registrars MUST implement TLS,
>    and MUST support both mutual and one-way authentication.  It is
>    strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY
also
>    be capable of acting as a TLS server.
> ------------
> 
>    The Recording Session SHOULD be at least as secure as the
Communication
the
recordings,
carrying
> [rj] Since the paragraph above suggests that only server-side
authentication
> might be sufficient if SRC and SRS are in the same administrative
domain,
> shouldn't the first statement in the paragraph (a normative statement)
loosen
> the MUST strength.

[Henry] I meant to say that the SRC and SRS must implement TLS mutual
authentication, although not all deployments are required use them, so
it's mandatory to implement and optional to use.

They
a
and
record
Since

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 1 Oct 2012 09:21:49 -0700

Please see inline.

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: October-01-12 10:25 AM
[Henry] Ok
> Probably should refer to RFC 5630 here rather than 3261.
[Henry] Would it be better to simply to say SRC/SRC must support
SIPS/TLS without referring to this RFC?

> including Mutual TLS Authentication?
[Henry] This is mentioned in the second paragraph below, but it's a
little unclear what it means. I will clarify that as must implement both
TLS authentication and mutual TLS authentication.
> When referring to "SDES" can you change to "Source Description (SDES)"
and
> give the reference to RFC3550. Just to avoid any confusion.
[Henry] Okay.
> Can we make a firm recommendation to secure using TLS and not refer to
S/MIME
> at all?
[Henry] I am okay with that and prefer only using TLS too :) I reference
S/MIME since it was mentioned in RFC3261 as a way to protect the
content, but then it's weird that you only protect metadata and not the
rest of the content, unless you don't want any proxies in between to see
the metadata. Anyone object to removing this?

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 3 Oct 2012 17:32:33 +0000

> On 01/10/12 9:51 PM, "Henry Lum" <[email-masked]> wrote:

>the metadata. Anyone object to removing this?

If mandating TLS between SRC and SRS is the intent here, I don¹t think we
can mandate that. Of course we can add a recommendation saying for
deployments where SRC and SRS are in different administrative domains it
is highly recommended to use TLS.

Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Oct 2012 10:20:48 -0400

I see no point in mentioning S/MIME.
AFAIK *nobody* implements it.

	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 5 Oct 2012 16:01:09 +0000

Hi Ram,

We do make TLS support by the SRC and SRS a MUST requirement in the protocol draft and I think this is the correct thing to do. So it is mandatory to implement but not mandatory to use. It has to be like that otherwise we could not support the requirement to make the RS at least as secure as the CS.

Regards
Andy

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> Sent: 03 October 2012 18:33
> To: Henry Lum; Hutton, Andrew; [email-masked]
> Subject: Re: [siprec] Proposed text for security section in siprec-
> protocol
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 5 Oct 2012 16:26:55 +0000

> On 05/10/12 9:31 PM, "Hutton, Andrew"
><[email-masked]> wrote:

>Hi Ram,
>
>We do make TLS support by the SRC and SRS a MUST requirement in the
>protocol draft and I think this is the correct thing to do. So it is
>mandatory to implement but not mandatory to use. It has to be like that
>otherwise we could not support the requirement to make the RS at least as
>secure as the CS.

Ok sounds fine.

Thanks,
Ram

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 8 Oct 2012 22:32:36 +0000

I agree with making TLS support a MUST. I am not as sure about SIPS. 
To me, it is more important that TLS with SIP be supported than TLS with SIPS.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ram Mohan R (rmohanr)
> Sent: Friday, October 05, 2012 9:27 AM
> To: Hutton, Andrew; Henry Lum; [email-masked]
> Subject: Re: [siprec] Proposed text for security section in siprec-protocol
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 9 Oct 2012 08:25:22 +0000

+1.

Andy

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: 08 October 2012 23:33
> To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; [email-masked]
> Subject: RE: [siprec] Proposed text for security section in siprec-
> protocol
> 
> Behalf
> > >> >>Can we make a firm recommendation to secure using TLS and not
> refer
> > >> to
> > >> >S/MIME
> > >> >>at all?
> > >> >content, but then it's weird that you only protect metadata and
> not
> > >> the
> > >> >rest of the content, unless you don't want any proxies in between
> to
> > >> see
> > >> If mandating TLS between SRC and SRS is the intent here, I don¹t
> think
> > >> we
> > >> deployments where SRC and SRS are in different administrative
> domains
> > >> it

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 9 Oct 2012 08:56:58 +0000

I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I agree that RS should be as secure as CS (and we should leave it that way). 

I think most of the SRC/SRS deployments are going to be (as they currently are) in Trust Domain governed by their own Spec(T). If we're going to mandate TLS than are we also mandating which cipher suites SRC and SRS must implement? I view siprec as an extension of the SIP protocol and not a mechanism for dictating security.

Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Tuesday, October 09, 2012 4:25 AM
To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; [email-masked]
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

+1.

Andy

> > >protocol draft and I think this is the correct thing to do. So it 
> > >is mandatory to implement but not mandatory to use. It has to be 
> > >like
> that
> > >> can mandate that. Of course we can add a recommendation saying 
> > >> for deployments where SRC and SRS are in different administrative
> domains
> > >> it

---

From: Mary Barnes <[email-masked]>
Date: Tue, 9 Oct 2012 08:35:11 -0500

Raj,

This document won't get through the IESG/Secdir review without having a
mandatory to implement security protocol.  Spec(T) won't do anything to
help you. That concept was introduced in the context of a specific P-header
and is not a standard SIP concept.  SIPREC is intended to be used in
non-trusted domains and the protocol spec must have a mandatory to
implement security protocol.

Mary.

On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish <[email-masked]> wrote:

> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I
> agree that RS should be as secure as CS (and we should leave it that way).
>
> I think most of the SRC/SRS deployments are going to be (as they currently
> are) in Trust Domain governed by their own Spec(T). If we're going to
> mandate TLS than are we also mandating which cipher suites SRC and SRS must
> implement? I view siprec as an extension of the SIP protocol and not a
> mechanism for dictating security.
>
> Raj
>
> Of Hutton, Andrew

---

From: Michael Smith <[email-masked]>
Date: Tue, 9 Oct 2012 14:03:33 +0000

Correct me if I'm wrong, but I think the proposal is that SIP-over-TLS must be supported by the SRC and SRS, but use of it on an RS is only mandatory when the CS is using it. Is that correct? If so, that seems reasonable and advisable.

Michael Smith (APCO/NENA NG9-1-1 PSAP WG co-leader)
Chief Technologist
Ph: 606.877.2788 | Mobile: 606.231.0243 

DSS Corporation / Equature
18311   W. Ten Mile Road, Suite 200
Southfield, MI - 48075
Tel: 1-888.305.3428
Fax: 1-248.569.6567
www.dss-corp.com
www.dispatchimprovement.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jain, Rajnish
Sent: Tuesday, October 09, 2012 4:57 AM
To: Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; [email-masked]
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Tuesday, October 09, 2012 4:25 AM
To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; [email-masked]
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

+1.

Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 13:38:33 -0400

> I think most of the SRC/SRS deployments are going to be (as they currently are) in Trust Domain governed by their own Spec(T). If we're going to mandate TLS than are we also mandating which cipher…

So, are you saying that there can be a valid implementation that doesn't 
support TLS if it only records calls that didn't use TLS?

I guess that might be ok.
Perhaps we should then add some wording that makes it explicit that if 
the SRC cannot establish an RS as secure as the CS it will not record 
the CS at all.

	Thanks,
	Paul

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 9 Oct 2012 19:17:17 +0000

Mary,

Understand. I think we can address this with correct wording. The idea would be to not compromise security (RS must be as secure as CS - no more no less).

Thanks,
Raj

From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, October 09, 2012 9:35 AM
To: Jain, Rajnish
Cc: Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; [email-masked]
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

Raj,

This document won't get through the IESG/Secdir review without having a mandatory to implement security protocol.  Spec(T) won't do anything to help you. That concept was introduced in the context of a specific P-header and is not a standard SIP concept.  SIPREC is intended to be used in non-trusted domains and the protocol spec must have a mandatory to implement security protocol.

Mary.
On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish <[email-masked]<mailto:[email-masked]>> wrote:
I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I agree that RS should be as secure as CS (and we should leave it that way).

Raj

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hutton, Andrew
Sent: Tuesday, October 09, 2012 4:25 AM
To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; [email-masked]<mailto:[email-masked]>
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

+1.

Andy

> From: Charles Eckel (eckelcu) [mailto:[email-masked]<mailto:[email-masked]>]
> To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf
> > Of Ram Mohan R (rmohanr)
> > To: Hutton, Andrew; Henry Lum; [email-masked]<mailto:[email-masked]>
> > ><[email-masked]<mailto:[email-masked]>> wrote:
> >
> > >Hi Ram,
> > >
> > >> From: Ram Mohan R (rmohanr) [mailto:[email-masked]<mailto:[email-masked]>]
> > >> To: Henry Lum; Hutton, Andrew; [email-masked]<mailto:[email-masked]>
> > >> > On 01/10/12 9:51 PM, "Henry Lum" <[email-masked]<mailto:[email-masked]>>
> > wrote:
> > >>
> > [email-masked]<mailto:[email-masked]>
_______________________________________________
siprec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/siprec

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 15:36:13 -0400

Note that 3261 says proxies MUST implement TLS, while UAs are not 
required to.

I think that implies that a UA that is acting as its own SRC should not 
be required to implement TLS, as long as it's consistent.

A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably 
can't depend on the 3261 requirement applying to it, but IMO we are 
justified in imposing that requirement on it as an SRC.

IMO it makes sense to require an SRS to support TLS.

	Thanks,
	Paul

On 10/9/12 3:17 PM, Jain, Rajnish wrote:
> Mary,
>
> Understand. I think we can address this with correct wording. The idea
> would be to not compromise security (RS must be as secure as CS – no
> more no less).
>
> Thanks,
>
> Raj
>
> *From:*Mary Barnes [mailto:[email-masked]]
> *Sent:* Tuesday, October 09, 2012 9:35 AM
> *To:* Jain, Rajnish
> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);
> Henry Lum; [email-masked]
> *Subject:* Re: [siprec] Proposed text for security section in
> siprec-protocol
>
> Raj,
>
> help you. That concept was introduced in the context of a specific
> P-header and is not a standard SIP concept.  SIPREC is intended to be
> used in non-trusted domains and the protocol spec must have a mandatory
> to implement security protocol.
>
> Mary.
>
> I think most of the SRC/SRS deployments are going to be (as they
> currently are) in Trust Domain governed by their own Spec(T). If we're
> going to mandate TLS than are we also mandating which cipher suites SRC
> and SRS must implement? I view siprec as an extension of the SIP
> protocol and not a mechanism for dictating security.
>
> Raj
>
>
> From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] On
> Behalf Of Hutton, Andrew
> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum;
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>
>  > > From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] On
>  > Behalf
>  > > Of Ram Mohan R (rmohanr)
>  > > To: Hutton, Andrew; Henry Lum; [email-masked] <mailto:[email-masked]>
>  > > ><[email-masked]
> <mailto:[email-masked]>> wrote:
>  > >
>  > > >Hi Ram,
>  > > >
> <mailto:[email-masked]>
>  > > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> DISCLAIMER: This e-mail may contain information that is confidential,
> privileged or otherwise protected from disclosure. If you are not an
> intended recipient of this e-mail, do not duplicate or redistribute it
> by any means. Please delete it and any attachments and notify the sender
> that you have received it in error. Unintended recipients are prohibited
> from taking action on the basis of information in this e-mail.E-mail
> messages may contain computer viruses or other defects, may not be
> accurately replicated on other systems, or may be intercepted, deleted
> or interfered with without the knowledge of the sender or the intended
> recipient. If you are not comfortable with the risks associated with
> e-mail messages, you may decide not to use e-mail to communicate with
> IPC. IPC reserves the right, to the extent and under circumstances
> permitted by applicable law, to retain, monitor and intercept e-mail
> messages to and from its systems.
>
>
>
>

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 9 Oct 2012 19:58:26 +0000

Paul,

I agree. I think it makes sense to require SRS (not SRC) to implement TLS (drawing parallel to 3261). This way, TLS becomes optional to implement/use in SRC (with the condition that RS must be as secure as CS).

Thanks,
Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, October 09, 2012 3:36 PM
To: [email-masked]
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

Note that 3261 says proxies MUST implement TLS, while UAs are not required to.

I think that implies that a UA that is acting as its own SRC should not be required to implement TLS, as long as it's consistent.

A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably can't depend on the 3261 requirement applying to it, but IMO we are justified in imposing that requirement on it as an SRC.

	Thanks,
	Paul

On 10/9/12 3:17 PM, Jain, Rajnish wrote:
> would be to not compromise security (RS must be as secure as CS - no 
> more no less).
>
> Thanks,
>
> Raj
>
> This document won't get through the IESG/Secdir review without having 
> a mandatory to implement security protocol.  Spec(T) won't do anything 
> to help you. That concept was introduced in the context of a specific 
> used in non-trusted domains and the protocol spec must have a 
> mandatory to implement security protocol.
>
> Mary.
>
> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. 
> I agree that RS should be as secure as CS (and we should leave it that way).
>
> going to mandate TLS than are we also mandating which cipher suites 
> SRC and SRS must implement? I view siprec as an extension of the SIP 
>  > From: Charles Eckel (eckelcu) [mailto:[email-masked] 
> <mailto:[email-masked]>]  > Sent: 08 October 2012 23:33  > To: Ram 
> Mohan R (rmohanr); Hutton, Andrew; Henry Lum; [email-masked] 
> <mailto:[email-masked]>  > Subject: RE: [siprec] Proposed text for 
> security section in siprec-  > protocol  >  > I agree with making TLS 
> support a MUST. I am not as sure about SIPS.
> > Behalf  > > Of Ram Mohan R (rmohanr)  > > Sent: Friday, October 05, 
> 2012 9:27 AM  > > To: Hutton, Andrew; Henry Lum; [email-masked] 
> <mailto:[email-masked]>  > > Subject: Re: [siprec] Proposed text for 
> security section in siprec-  > protocol  > >  > > > On 05/10/12 9:31 
> PM, "Hutton, Andrew"
>  > > >We do make TLS support by the SRC and SRS a MUST requirement in 
> the  > > >protocol draft and I think this is the correct thing to do. 
> So it  > > >is mandatory to implement but not mandatory to use. It has 
> to be  > > >like  > that  > > >otherwise we could not support the 
> requirement to make the RS at  > least as  > > >secure as the CS.
>  > >
>  > > Ok sounds fine.
>  > >
>  > > Thanks,
>  > > Ram
>  > >
>  > > >
>  > > >Regards
>  > > >Andy
>  > > >
>  > > >
>  > > >
>  > > >> From: Ram Mohan R (rmohanr) [mailto:[email-masked] 
> <mailto:[email-masked]>]  > > >> Sent: 03 October 2012 18:33  > > 
> <mailto:[email-masked]>  > > >> Subject: Re: [siprec] Proposed text 
> for security section in  > siprec-  > > >> protocol  > > >>  > > >> > 
>  > > >> >>Can we make a firm recommendation to secure using TLS and 
> not  > refer  > > >> to  > > >> >S/MIME  > > >> >>at all?
>  > > >> >[Henry] I am okay with that and prefer only using TLS too :) 
> I  > > >> reference  > > >> >S/MIME since it was mentioned in RFC3261 
> as a way to protect the  > > >> >content, but then it's weird that you 
> only protect metadata and  > not  > > >> the  > > >> >rest of the 
> content, unless you don't want any proxies in  > > >> >between  > to  
> > > >> see  > > >> >the metadata. Anyone object to removing this?
>  > > >>
>  > > >> If mandating TLS between SRC and SRS is the intent here, I 
> don¹t  > think  > > >> we  > > >> can mandate that. Of course we can 
> add a recommendation saying  > > >> for deployments where SRC and SRS 
> are in different administrative  > domains  > > >> it  > > >> is 
> highly recommended to use TLS.
>  > > >>
>  > > >> Ram
>  > > >
>  > > >
>  > >
>  > >
>  > > [email-masked] <mailto:[email-masked]>  > > 
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------
>
> by any means. Please delete it and any attachments and notify the 
> sender that you have received it in error. Unintended recipients are 
> prohibited from taking action on the basis of information in this 
> e-mail.E-mail messages may contain computer viruses or other defects, 
> may not be accurately replicated on other systems, or may be 
> intercepted, deleted or interfered with without the knowledge of the 
> sender or the intended recipient. If you are not comfortable with the 
> risks associated with e-mail messages, you may decide not to use 
> e-mail to communicate with IPC. IPC reserves the right, to the extent 
> and under circumstances permitted by applicable law, to retain, 
> monitor and intercept e-mail messages to and from its systems.
>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 16:17:43 -0400

> I agree. I think it makes sense to require SRS (not SRC) to implement TLS (drawing parallel to 3261). This way, TLS becomes optional to implement/use in SRC (with the condition that RS must be as s…

Note that I'm also proposing that we require a B2BUA acting as an SRC 
(e.g. an SBC or PBX) be required to support TLS.

Another thing to consider is RS sessions initiated by an SRS.
What if the SRS wants to use TLS?

	Thanks,
	Paul

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 9 Oct 2012 21:19:12 +0000

Paul,

Pls. see inline:

> Note that I'm also proposing that we require a B2BUA acting as an SRC (e.g. an SBC or PBX) be required to support TLS.

[rj] That's fine. I don't know what a B2BUA is anymore (because most practical server-side SIP implementations are some sort of UAs combined in some fashion). I don't know if you're referring to passive recording (sniffing media and recording that media). 

[rj] That's fine as well. In this case, the administrator has decided to use TLS between SRS and SRC. Pls. note that it is left to the administrator/implementer to decide.

Thanks,
Raj

> Behalf Of Paul Kyzivat
>> Understand. I think we can address this with correct wording. The 
>> idea would be to not compromise security (RS must be as secure as CS 
>> - no more no less).
>>
>> Thanks,
>>
>> Raj
>>
>> a mandatory to implement security protocol.  Spec(T) won't do 
>> anything to help you. That concept was introduced in the context of a 
>> specific P-header and is not a standard SIP concept.  SIPREC is 
>> intended to be used in non-trusted domains and the protocol spec must 
>> have a mandatory to implement security protocol.
>>
>> Mary.
>>
>> currently are) in Trust Domain governed by their own Spec(T). If 
>> we're going to mandate TLS than are we also mandating which cipher 
>> suites SRC and SRS must implement? I view siprec as an extension of 
>> the SIP protocol and not a mechanism for dictating security.
>>
>> Raj
>>
>>
>>   > To me, it is more important that TLS with SIP be supported than 
>> TLS
>>> with SIPS.
>>   >
>>   > Cheers,
>>   > Charles
>>   >
>>   > > >We do make TLS support by the SRC and SRS a MUST requirement 
>> in the  > > >protocol draft and I think this is the correct thing to do.
>> So it  > > >is mandatory to implement but not mandatory to use. It 
>> has to be  > > >like  > that  > > >otherwise we could not support the 
>>   > > >> >[Henry] I am okay with that and prefer only using TLS too 
>> :) I  > > >> reference  > > >> >S/MIME since it was mentioned in 
>> RFC3261 as a way to protect the  > > >> >content, but then it's weird 
>> that you only protect metadata and  > not  > > >> the  > > >> >rest 
>> of the content, unless you don't want any proxies in  > > >> >between  
>> > to
>> intended recipient of this e-mail, do not duplicate or redistribute 
>> it by any means. Please delete it and any attachments and notify the

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 17:50:12 -0400

> [rj] That's fine. I don't know what a B2BUA is anymore (because most practical server-side SIP implementations are some sort of UAs combined in some fashion). I don't know if you're referring to pa…

If it terminates one dialog and initiates another, and keeps them 
connected in order to establish a single "call" then it's a B2BUA. That 
is true whether it terminates media or not. You can see the documents of 
the STRAW WG for more on current thinking about B2BUAs.

An entirely passive recorder is out of scope for siprec. The SRC must be 
able to cause an indication of recording to be conveyed to the 
participants, either in the CS sip signaling or in the media to the 
participants.

	Thanks,
	Paul

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 9 Oct 2012 23:07:20 +0000

Hi Paul,

While this discussion isn't about defining B2BUAs, I'd like to express *as an SRC implementer* that the 3261 definition of a B2BUA has got muddied with time and as we've gained more implementation experience. E.g. I've state machines in my product that don't fit the definition of a B2BUA (as per 3261) but they do work. SUBSCRIBE/NOTIFY and OOB NOTIFY are at the forefront of such examples.

Coming back to the TLS topic, I wish we could relax TLS for SRC (I'd be honest; our SRC TLS implementation doesn't scale well with TLS enabled and our customers do not require it).

Thanks,
Raj

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2012 5:50 PM
To: Jain, Rajnish
Cc: [email-masked]
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

> [rj] That's fine. I don't know what a B2BUA is anymore (because most practical server-side SIP implementations are some sort of UAs combined in some fashion). I don't know if you're referring to pa…

If it terminates one dialog and initiates another, and keeps them connected in order to establish a single "call" then it's a B2BUA. That is true whether it terminates media or not. You can see the documents of the STRAW WG for more on current thinking about B2BUAs.

An entirely passive recorder is out of scope for siprec. The SRC must be able to cause an indication of recording to be conveyed to the participants, either in the CS sip signaling or in the media to the participants.

	Thanks,
	Paul

>>> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R 
>>> (rmohanr); Henry Lum; [email-masked]
>>> This document won't get through the IESG/Secdir review without 
>>> having a mandatory to implement security protocol.  Spec(T) won't do 
>>> anything to help you. That concept was introduced in the context of 
>>> a specific P-header and is not a standard SIP concept.  SIPREC is 
>>> intended to be used in non-trusted domains and the protocol spec 
>>> must have a mandatory to implement security protocol.
>>>
>>> Mary.
>>>
>>> <mailto:[email-masked]>]  > Sent: 08 October 2012 23:33  > To: 
>>> Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; [email-masked] 
>>> security section in siprec-  > protocol  >  > I agree with making 
>>> TLS support a MUST. I am not as sure about SIPS.
>>>    > > From: [email-masked] 
>>> <mailto:[email-masked]> [mailto:[email-masked] 
>>> <mailto:[email-masked]>] On
>>> <mailto:[email-masked]>  > > Subject: Re: [siprec] Proposed text 
>>> for security section in siprec-  > protocol  > >  > > > On 05/10/12 
>>> 9:31 PM, "Hutton, Andrew"
>>> has to be  > > >like  > that  > > >otherwise we could not support 
>>> the requirement to make the RS at  > least as  > > >secure as the CS.
>>>    > >
>>>    > > Ok sounds fine.
>>>    > >
>>>    > > Thanks,
>>>    > > Ram
>>>    > >
>>>    > > >
>>>    > > >Regards
>>>    > > >Andy
>>>    > > >
>>>    > > >
>>>    > > >
>>> for security section in  > siprec-  > > >> protocol  > > >>  > > >> 
>>>    > > >> >>Can we make a firm recommendation to secure using TLS 
>>> and not  > refer  > > >> to  > > >> >S/MIME  > > >> >>at all?
>>> RFC3261 as a way to protect the  > > >> >content, but then it's 
>>> weird that you only protect metadata and  > not  > > >> the  > > >> 
>>> >rest of the content, unless you don't want any proxies in  > > >> 
>>> >between
>>>> to
>>> add a recommendation saying  > > >> for deployments where SRC and 
>>> SRS are in different administrative  > domains  > > >> it  > > >> is 
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> DISCLAIMER: This e-mail may contain information that is 
>>> confidential, privileged or otherwise protected from disclosure. If 
>>> you are not an intended recipient of this e-mail, do not duplicate 
>>> or redistribute it by any means. Please delete it and any 
>>> attachments and notify the sender that you have received it in 
>>> error. Unintended recipients are prohibited from taking action on 
>>> the basis of information in this e-mail.E-mail messages may contain 
>>> computer viruses or other defects, may not be accurately replicated 
>>> on other systems, or may be intercepted, deleted or interfered with 
>>> without the knowledge of the sender or the intended recipient. If 
>>> you are not comfortable with the risks associated with e-mail 
>>> messages, you may decide not to use e-mail to communicate with IPC. 
>>> IPC reserves the right, to the extent and under circumstances 
>>> permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.
>>>
>>>
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 22:42:42 -0400

On 10/9/12 7:07 PM, Jain, Rajnish wrote:
> Hi Paul,
>
> While this discussion isn't about defining B2BUAs,
> I'd like to express *as an SRC implementer* that the 3261 definition
> of a B2BUA has got muddied with time and as we've gained more
> implementation experience.

IMO it is not the B2BUA definition that has gotten muddy.
It is perfectly clear.

Some related problems that I see are:
- people wish to build something that is more than a proxy
   but less than a B2BUA. There is no spec for building
   such a thing, or measuring compliance of one. So they
   build things and we find they have unpredictable effects.

- there are many different sorts of things that people
   can build that are all at their heart a B2BUA.
   But often people who do so don't realize that all such
   things don't work the way theirs does.

> E.g. I've state machines in my product
> that don't fit the definition of a B2BUA (as per 3261) but they do work.

So I suspect you are building one of those things I describe in the 
first bullet above.

You say "they do work". I don't doubt that they work for you in the 
cases where you have tested them. But I am concerned that we can find 
sip compliant boxes you didn't consider that your product won't work with.

Feel free to write up a small informational draft describing what you 
have built and publish it for comments.

> SUBSCRIBE/NOTIFY and OOB NOTIFY are at the forefront of such examples.

OOB NOTIFY? Do you mean a NOTIFY sent outside of a dialog?

Certainly I am aware that it is done. (Cisco has used it in products.) 
But there are good reasons why such behavior has not been, and will not 
be, standardized.

> Coming back to the TLS topic, I wish we could relax TLS for SRC (I'd be honest; our SRC TLS implementation doesn't scale well with TLS enabled and our customers do not require it).

We will see. The security review may not allow such.
Of course there is nothing to prevent you from building such a box even 
if the spec says you must not. In any case, we only say it is required 
to implement, not to use. You apparently *have* an implementation. You 
can certainly control it with a configuration option and put up a big 
warning when somebody turns it on. That will be compliant.

Assuming that the disable of TLS applies equally to the CS and RS legs 
in your B2BUA, then you will never have any secure CS sessions, and so 
no need to use TLS on the RS.

	Thanks,
	Paul

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 10 Oct 2012 12:27:17 +0000

Hi Paul,

I'm just hoping that we don't require TLS support in SRC (RFC 3261 is a precedence). Obviously, the WG will weigh in.

Thanks,
Raj

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2012 10:43 PM
To: Jain, Rajnish
Cc: [email-masked]
Subject: Re: [siprec] Proposed text for security section in siprec-protocol

On 10/9/12 7:07 PM, Jain, Rajnish wrote:
> Hi Paul,
>
> While this discussion isn't about defining B2BUAs, I'd like to express 
> *as an SRC implementer* that the 3261 definition of a B2BUA has got 
> muddied with time and as we've gained more implementation experience.

> E.g. I've state machines in my product that don't fit the definition 
> of a B2BUA (as per 3261) but they do work.

So I suspect you are building one of those things I describe in the first bullet above.

You say "they do work". I don't doubt that they work for you in the cases where you have tested them. But I am concerned that we can find sip compliant boxes you didn't consider that your product won't work with.

Feel free to write up a small informational draft describing what you have built and publish it for comments.

Certainly I am aware that it is done. (Cisco has used it in products.) But there are good reasons why such behavior has not been, and will not be, standardized.

We will see. The security review may not allow such.
Of course there is nothing to prevent you from building such a box even if the spec says you must not. In any case, we only say it is required to implement, not to use. You apparently *have* an implementation. You can certainly control it with a configuration option and put up a big warning when somebody turns it on. That will be compliant.

Assuming that the disable of TLS applies equally to the CS and RS legs in your B2BUA, then you will never have any secure CS sessions, and so no need to use TLS on the RS.

	Thanks,
	Paul

>>>> having a mandatory to implement security protocol.  Spec(T) won't 
>>>> do anything to help you. That concept was introduced in the context 
>>>> of a specific P-header and is not a standard SIP concept.  SIPREC 
>>>> is intended to be used in non-trusted domains and the protocol spec 
>>>> [mailto:[email-masked] <mailto:[email-masked]>] 
>>>> On Behalf Of Hutton, Andrew
>>>>     > To me, it is more important that TLS with SIP be supported 
>>>> than TLS
>>>>> with SIPS.
>>>>     >
>>>>     > Cheers,
>>>>     > Charles
>>>>     >
>>>>     > > >We do make TLS support by the SRC and SRS a MUST 
>>>> requirement in the  > > >protocol draft and I think this is the correct thing to do.
>>>> <mailto:[email-masked]>]  > > >> Sent: 03 October 2012 18:33  > 
>>>> >
>>>> <mailto:[email-masked]>  > > >> Subject: Re: [siprec] Proposed 
>>>> text for security section in  > siprec-  > > >> protocol  > > >>  > 
>>>> > >>
>>>>> between to
>>>>     > > >> If mandating TLS between SRC and SRS is the intent here, 
>>>> I don¹t  > think  > > >> we  > > >> can mandate that. Of course we 
>>>> can add a recommendation saying  > > >> for deployments where SRC 
>>>> and SRS are in different administrative  > domains  > > >> it  > >

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 16 Oct 2012 15:13:41 +0000

Hi,

On
10 October 2012 13:27 Jain, Rajnish wrote:
> 
> I'm just hoping that we don't require TLS support in SRC (RFC 3261 is a
> precedence). Obviously, the WG will weigh in.
> 

What I have heard so far is that security is very important and needs to be clearly described if we are to get the SIPREC protocol released as an RFC. RFC 3261 is only the base on which we build so the fact that it does not mandate SIP over TLS is not something we can use as an argument for not requiring it in SIPREC.

We all agree that the RS MUST be at least as secure as the CS therefore to cover the generic case it makes sense to me to mandate that the SRS supports TLS as it does not know what is being used on the CS. Then it also makes sense to mandate TLS in the SRC especially as Paul points out if the RS is SRS initiated.

It is of course true that many real world deployments will not use TLS but that is a choice to be made depending on the deployment model. However for the SIPREC protocol spec that aims to provide interoperability between vendors it seems to make sense to mandate that both the SRC and SRS supports SIP over TLS. 

Regards
Andy

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 16 Oct 2012 15:32:19 +0000

Andy,

That's fine. I think I was mistaking a "MUST-support" statement with a "MUST-use" philosophy. So I think it makes sense to require MUST support for TLS for SRC.

Thanks,
Raj 

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2012 11:14 AM
To: Jain, Rajnish; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [siprec] Proposed text for security section in siprec-protocol

Hi,

On
10 October 2012 13:27 Jain, Rajnish wrote:
> 
> I'm just hoping that we don't require TLS support in SRC (RFC 3261 is 
> a precedence). Obviously, the WG will weigh in.
> 

Regards
Andy