Subject: Re: [siprec] security considerations for protocol draft

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 5 Dec 2012 19:13:22 +0000

Hi Paul,

I don't disagree that something better than transitive trust is desirable; however, I don't think Digest authentication really helps. Connected Identity does seem useful, but adding requirements around it seems troublesome at this point to me. P-Asserted-Identity relies on transitive trust, so I don't think it makes things any better.
I'd like to hear from those with deployment experience what they do and what would work for them. 

Cheers,
Charles

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, November 30, 2012 12:23 PM
> To: Charles Eckel (eckelcu)
> Cc: [email-masked]
> Subject: Re: [siprec] security considerations for protocol draft
> 
> On 11/30/12 2:32 PM, Charles Eckel (eckelcu) wrote:
> > 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.
> 
> 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
> 
> > Cheers,
> > Charles
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[email-masked]]
> >> Sent: Friday, November 30, 2012 10:19 AM
> >> To: Charles Eckel (eckelcu)
> >> Cc: [email-masked]
> >> Subject: Re: [siprec] security considerations for protocol draft
> >>
> >> On 11/30/12 1:02 PM, Charles Eckel (eckelcu) wrote:
> >>> 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?
> >>
> >> 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
> >>
> >>> Thanks,
> >>> Charles
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf
> >>>> Of Charles Eckel (eckelcu)
> >>>> Sent: Friday, November 30, 2012 9:08 AM
> >>>> To: Paul Kyzivat; [email-masked]
> >>>> Subject: Re: [siprec] security considerations for protocol draft
> >>>>
> >>>> Good point. Thanks for clarifying.
> >>>>
> >>>> Cheers,
> >>>> Charles
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf
> >>>>> Of Paul Kyzivat
> >>>>> Sent: Wednesday, November 28, 2012 9:35 AM
> >>>>> To: [email-masked]
> >>>>> Subject: Re: [siprec] security considerations for protocol draft
> >>>>>
> >>>>> On 11/27/12 5:49 PM, Charles Eckel (eckelcu) 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?
> >>>>>
> >>>>> 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
> >>>>> _______________________________________________
> >>>>> 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: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Dec 2012 14:50:49 -0500

On 12/5/12 2:13 PM, Charles Eckel (eckelcu) wrote:
> Hi Paul,
>
> I don't disagree that something better than transitive trust is desirable; however, I don't think Digest authentication really helps.

It could help if it was deployed and used. It would require that SRCs 
(assuming they are the initiators) be configured with a password.

> Connected Identity does seem useful, but adding requirements around it seems troublesome at this point to me.

It we required it, then it might indeed be a problem for some.
But we could make it mandatory to implement, optional to use. And offer 
it as one of several alternatives for meeting the security requirement.

> P-Asserted-Identity relies on transitive trust, so I don't think it makes things any better.

It does require transitive trust. But it still can make things better. 
It at least ensures that, based on trust, you are talking to who you 
called, rather than the possibility that this was forwarded to a 
different UA than expected.

Perhaps we could say that the SRC MUST/SHOULD verify that it is talking 
to the intended SRS via one of a list of techniques.

I have two concerns here:
- as a user of phones, and caller of call centers, I would like some
   assurance that when my calls are recorded, that those recordings are
   secure.

- I expect that this will get a very thorough security review.
   I would prefer to get this nailed down now rather than invite
   objections by the security reviewers.

> I'd like to hear from those with deployment experience what they do and what would work for them.

Yes, that would be good.
But I fear that in most cases people just don't worry about it at all.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 5 Dec 2012 21:35:10 +0000

> Sent: Wednesday, December 05, 2012 11:51 AM
> > I don't disagree that something better than transitive trust is desirable;
> however, I don't think Digest authentication really helps.
> 

Yes, but that simply allows the SRS to authenticate the SRC. However, we state in the draft that authentication of the SRS by the SRS is what is really important. 
 
> to the intended SRS via one of a list of techniques.

This approach could help with a security review, but I don't see if helping interworking much. That said, I do not have any better ideas right now.

Cheers,
Charles