< 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

On 16/11/18 18:42, Scott Godin wrote:
> Hi Daniel,
>>What would you expect a phone to put in the From header of an in-dialog
> 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.

Currently, the CertificateAuthenticator is not authenticating[1] the
headers for any ACK or BYE request, so this issue doesn't arise for
those methods.  That is much the same[2] in DIGEST authentication.

A similarly loose approach could permit other methods through a proxy
under the right conditions, for example, if both the To and From tags
are present.  If the tags were forged then the UAS would hopefully
reject the request and if TLS is used end-to-end then no eavesdropper
could sniff and replay the correct tags.

The CSeq value doesn't appear to be helpful in this case because it
doesn't have to start at 1 for the first request in a dialog.  Apart
from checking the presence of a To tag, is there any other hard rule for
determining if a request is for an existing dialog?

A stronger validation mechanism might be harder to achieve though if
outbound is to be supported.  If all requests go through the same proxy,
then the proxy can build a map of dialogs to certificates.  In the case
of outbound, the UA can maintain connections to multiple proxies in
parallel and all those proxies would need to share the state
information.  That is achievable but would introduce extra complexity,
so I wonder if the former approach would be sufficient and secure for
most cases.