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.
Scott
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
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel