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

Daniel Pocock daniel at pocock.pro
Fri Nov 16 05:00:17 CST 2018


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 at example.org, 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
REFER?

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

Regards,

Daniel






More information about the resiprocate-devel mailing list