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

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


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
REFER?

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

Regards,

Daniel