< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Mutual TLS / From and Referred-By header authentication issues

Hi Daniel,

>What would you expect a phone to put in the From header of an in-dialog REFER?
I don't believe the phone has a choice.  Since REFER is an in-dialog request, the From header cannot be different from the To/From header that was used to establish the call.

I like the idea of tracking that the dialog was already authenticated (ie: from the INVITE) and as long as future requests arrive on the same TLS connection, then mid-dialog requests don't need to be checked.


On Fri, Nov 16, 2018 at 6:01 AM Daniel Pocock <daniel@xxxxxxxxxx> wrote:

Hi all,

I've been testing transfers (SIP REFER method) with endpoints using
mutual TLS.  I use repro as edge proxy and reConServer, derived from
testUA, as an example.

The SIP RFC specifies that "From" and "Referred-by" headers should
contain logical addresses, e.g. user@xxxxxxxxxxx, not IP addresses.

When DIGEST authentication is used, those headers aren't inspected for
authorization purposes.

The CertificateAuthenticator code, however, does try to match the From
header and/or Referred-by header to the domain in the certificate or the
whitelist (file/table).

I've noticed that:

- all the phones I've tested are putting their Contact URI (which has an
IP address) into the From header of in-dialog requests like REFER

- some phones also put the Contact URI / IP address into the Referred-by
header.  Polycoms don't do this if a full SIP URI is configured as the
SIP address for the line but if only the username is specified, the
domain is filled in with the IP address.

For now, I think the CertificateAuthenticator can do the following:

- if Referred-by exists in a REFER request, ignore the From header as
long as the Referred-by header can be validated

- if Referred-by doesn't exist, validate the From header

How do other people feel about this?

What would you expect a phone to put in the From header of an in-dialog

Can CertificateAuthenticator use some other logic to determine if
in-dialog requests are authorized and just ignore those headers?



resiprocate-devel mailing list