Subject: [siprec] security considerations for protocol draft

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 27 Nov 2012 22:49:42 +0000

Hi,

I am in the process of updating some sections of the protocol draft per the conclusions reached at IETF 85. In working on the security considerations, I ran into a couple issues.

First, section 12.1 Authentication and Authorization, reads as follows:

   The recording session reuses the SIP mechanism to challenge requests
   that are 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.

   At the transport level, the recording session uses TLS authentication
   to validate the authenticity of the SRC and SRS.  The SRC and SRS
   MUST implement TLS mutual authentication for establishing the
   recording session, and whether the SRC/SRS chooses to use
   authentication is a deployment decision.

If using mutual TLS authentication, what is the purpose of the digest authentication? It seems to me the paragraph on digest authentication should be removed. Does anyone disagree?

Second, section 12.2, RTP handling, currently ends as follows:

   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.

During the SIPREC session at IETF 85, there was discussion as to why it is necessary to negotiate a different security key. I am not sure what else to put here as justification for this requirement. Any suggestions? If not, I will leave it as is.

Cheers,
Charles

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Nov 2012 17:58:57 -0500

Transcoding, not so sure.  Mixing, you could observe that if SRC used A's key to encode A+B then, in theory, A could observe A+B and decode it.  in practice, if SRC is mixing A and B, then A can hear/see/type B anyway.

Maybe get rid of the MUST and just say that re-use of keys should consider if it's possible for the other end, who has the original key, to get data they shouldn't be able to get.

Brian

On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) <[email-masked]> wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2012 12:35:09 -0500

> If using mutual TLS authentication, what is the purpose of the digest authentication? It seems to me the paragraph on digest authentication should be removed. Does anyone disagree?

TLS authentication is hop by hop. Digest authentication is e2e.

*If* there are no intermediaries between the SRC and SRS then perhaps 
digest authentication is unnecessary. But I don't think it is even 
possible to determine if this situation holds.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 29 Nov 2012 01:08:49 +0000

How about if we say:

        SRCs that modify an encrypted media stream (e.g. transcode or mix) when relaying 
        it from a CS to an RS SHOULD negotiate a different security key than the
        one used in the CS, to ensure that it is not possible for someone who has the key from
        the CS to access data they should not be able to access.

Does that cover it clearly?

Thanks,
Charles

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2012 2:59 PM
> To: Charles Eckel (eckelcu)
> Cc: [email-masked]
> Subject: Re: [siprec] security considerations for protocol draft
> 
> Transcoding, not so sure.  Mixing, you could observe that if SRC used A's key
> to encode A+B then, in theory, A could observe A+B and decode it.  in
> practice, if SRC is mixing A and B, then A can hear/see/type B anyway.
> 
> Maybe get rid of the MUST and just say that re-use of keys should consider if
> it's possible for the other end, who has the original key, to get data they
> shouldn't be able to get.
> 
> Brian
> 
> > I am in the process of updating some sections of the protocol draft per the
> conclusions reached at IETF 85. In working on the security considerations, I
> ran into a couple issues.
> >
> > If using mutual TLS authentication, what is the purpose of the digest
> authentication? It seems to me the paragraph on digest authentication
> should be removed. Does anyone disagree?
> >
> > During the SIPREC session at IETF 85, there was discussion as to why it is
> necessary to negotiate a different security key. I am not sure what else to
> put here as justification for this requirement. Any suggestions? If not, I will
> leave it as is.
> >
> > Cheers,
> > Charles

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 29 Nov 2012 08:18:02 +0000

|SRCs that modify an encrypted media stream (e.g. transcode or mix)

"modify an encrypted media stream" looks a bit vague. My suggestion:

    SRCs that decrypt an encrypted CS media stream and re-encrypt it when 
    sending it to the SRS SHOULD use a different key for the RS media stream 
    than what is used for the CS media stream, to ensure that it isn't possible
    for someone who has the key for the CS media stream to access the recorded
    data they aren't authorized to access.

Muthu
   
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
|Sent: Thursday, November 29, 2012 6:39 AM
|To: Brian Rosen
|Cc: [email-masked]
|Subject: Re: [siprec] security considerations for protocol draft
|
|How about if we say:
|
|        SRCs that modify an encrypted media stream (e.g. transcode or mix) when relaying
|        it from a CS to an RS SHOULD negotiate a different security key than the
|        one used in the CS, to ensure that it is not possible for someone who has the key from
|        the CS to access data they should not be able to access.
|
|Does that cover it clearly?
|
|Thanks,
|Charles
|
|> -----Original Message-----
|> From: Brian Rosen [mailto:[email-masked]]
|> Sent: Tuesday, November 27, 2012 2:59 PM
|> To: Charles Eckel (eckelcu)
|> Cc: [email-masked]
|> Subject: Re: [siprec] security considerations for protocol draft
|>
|> Transcoding, not so sure.  Mixing, you could observe that if SRC used A's key
|> to encode A+B then, in theory, A could observe A+B and decode it.  in
|> practice, if SRC is mixing A and B, then A can hear/see/type B anyway.
|>
|> Maybe get rid of the MUST and just say that re-use of keys should consider if
|> it's possible for the other end, who has the original key, to get data they
|> shouldn't be able to get.
|>
|> Brian
|>
|> On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) <[email-masked]>
|> wrote:
|>
|> > Hi,
|> >
|> > I am in the process of updating some sections of the protocol draft per the
|> conclusions reached at IETF 85. In working on the security considerations, I
|> ran into a couple issues.
|> >
|> > First, section 12.1 Authentication and Authorization, reads as follows:
|> >
|> >   The recording session reuses the SIP mechanism to challenge requests
|> >   that are 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.
|> >
|> >   At the transport level, the recording session uses TLS authentication
|> >   to validate the authenticity of the SRC and SRS.  The SRC and SRS
|> >   MUST implement TLS mutual authentication for establishing the
|> >   recording session, and whether the SRC/SRS chooses to use
|> >   authentication is a deployment decision.
|> >
|> > If using mutual TLS authentication, what is the purpose of the digest
|> authentication? It seems to me the paragraph on digest authentication
|> should be removed. Does anyone disagree?
|> >
|> > Second, section 12.2, RTP handling, currently ends as follows:
|> >
|> >   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.
|> >
|> > During the SIPREC session at IETF 85, there was discussion as to why it is
|> necessary to negotiate a different security key. I am not sure what else to
|> put here as justification for this requirement. Any suggestions? If not, I will
|> leave it as is.
|> >
|> > Cheers,
|> > Charles
|> > _______________________________________________
|> > siprec mailing list
|> > [email-masked]
|> > https://www.ietf.org/mailman/listinfo/siprec
|
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: Brian Rosen <[email-masked]>
Date: Thu, 29 Nov 2012 09:01:08 -0500

WFM either way

Brian

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 29 Nov 2012 16:51:04 +0000

Looks good to me.

Ram

> On 29/11/12 1:48 PM, "Muthu Arul Mozhi Perumal (mperumal)"
><[email-masked]> wrote:

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 30 Nov 2012 17:06:06 +0000

I will use the improved wording suggested by Muthu. Thanks everyone.

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Thursday, November 29, 2012 8:51 AM
> To: Muthu Arul Mozhi Perumal (mperumal); Charles Eckel (eckelcu); Brian
> Rosen
> Cc: [email-masked]
> >|From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >Of Charles Eckel (eckelcu)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 30 Nov 2012 17:07:44 +0000

Good point. Thanks for clarifying.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Wednesday, November 28, 2012 9:35 AM
> To: [email-masked]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 30 Nov 2012 18:02:03 +0000

Thinking about this more, I'm still a bit dubious of the value of this.
For the general case  in which the SRC is initiating the RS, the SRS can challenge the INVITE from the SRC with a 401 in order to force the SRC to authenticate itself to the SRS. However, we state later on that is really more important for the SRS to authentication itself to the SRC. The Digest authentication mechanism can be used by the SRC for this in the case of SRS initiated RSs, but not for the general case. Am I missing something again?

Thanks,
Charles

> Sent: Friday, November 30, 2012 9:08 AM
> To: Paul Kyzivat; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Nov 2012 13:19:21 -0500

> For the general case  in which the SRC is initiating the RS, the SRS can challenge the INVITE from the SRC with a 401 in order to force the SRC to authenticate itself to the SRS. However, we state…

I think it is good as far as it goes. (An SRS is likely to not want to 
do recording for everybody who comes along.)

But what you say, together with what I said, does raise a question of 
whether we actually have an adequate mechanism for the SRC to 
authenticate the SRS. We may need to have a further discussion about that.

Is it plausible that we require a direct connection without 
intermediaries? (Probably not.)

I wish this had come up sooner, rather than now. :-(

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 30 Nov 2012 19:32:06 +0000

I am leaning back toward my original proposal, of dropping the discussion about digest authentication entirely and relying on TLS. For cases in which there is an intermediary, transitive trust comes into play. If an SRS or SRC wants to use digest authentication, it can, but we do not need to say anything specific about it in SIPREC.

Cheers,
Charles

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, November 30, 2012 10:19 AM
> > For the general case  in which the SRC is initiating the RS, the SRS can
> challenge the INVITE from the SRC with a 401 in order to force the SRC to
> authenticate itself to the SRS. However, we state later on that is really more
> important for the SRS to authentication itself to the SRC. The Digest
> authentication mechanism can be used by the SRC for this in the case of SRS
> initiated RSs, but not for the general case. Am I missing something again?
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Nov 2012 15:22:44 -0500

> I am leaning back toward my original proposal, of dropping the discussion about digest authentication entirely and relying on TLS. For cases in which there is an intermediary, transitive trust come…

I don't see how transitive trust would work in typical cases. There is 
no guarantee that your call to the SRS hasn't been redirected to someone 
else.

At a minimum, connected identity (RFC4916) might be of *some* help to 
ensure you got who you intended to get. Getting an identity assertion, 
via Identity (RFC4474) or P-Asserted-Identity (RFC3325) would be 
stronger. (But I have no evidence that 4474 is deployed.)

I expect if we don't have something reasonably robust to recommend then 
we will have trouble with security review.

	Thanks,
	Paul