Authentication: Is it possible to ignore realm? How to avoice unnecessary challenge because of changed realm?
Hi
As mentioned in the last email, we have a CPE which adds credentials to any request so I would like to validate them.
We use $rd as realm. Let's use example.com as example.
During the initial INVITE, this works as expected.
I try to only show the headers I think are relevant to the issue I face.
INVITE sip:1234@example.com SIP/2.0 Proxy-Authorization: [...] realm="example.com" Contact: sip:9876@192.168.1.1:5060
Authentication user in realm "example.com" == $rd is validated and accepted.
The connection is establised:
200 OK From: sip:9876@example.com;tag=1 To: sip:1234@example.com;tag=2 Contact: sip:1234@192.168.7.7:5060
The caller terminates the connection:
BYE: sip:1234@192.168.7.7:5060 SIP/2.0 From: sip:9876@example.com;tag=1 To: sip:1234@example.com;tag=2 Proxy-Authorization: [...] realm="example.com"
Performing: $var(authres) = pv_auth_check("$rd", "$avp(authsecret)", "0", "1");
fails wirh result -5 as there is no authsecret for realm "192.168.7.7"
So an unnecessarey challenge is issued:
SIP/2.0 407 Proxy Authentication Required To: sip:1234@example.com From: sip:9876@example.com CSeq: 3 BYE Proxy-Authenticate: Digest realm="192.168.7.7"
To which the client replies with the changed realm:
Proxy-Authorization: Digest username="****",realm="157.161.7.7",[...]
and succeeds authentication.
Is there a way to accept 'any' realm? Or to avoid this unnecessary change of realm just because the remote site submitted a domain realm in the contact header?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello,
what about just using the approach in the documentation and example cfg, take the from domain as realm for the challenge?
Cheers,
Henning
Hi Henning
what about just using the approach in the documentation and example cfg, take the from domain as realm for the challenge?
This is what I am doing now, tentatively...
The Issue with this, is that we have an SBC in front of Kamailio, that uses the R-URI domain of the initial INVITE or REGISTER for routing to the desired registrar / proxy.
So using $rd in kamailio seemed more straight forward to me at that time as I know, existing customers setups will have this domain set correctly when migrating from our actual platform to kamailio. I'm not sure if every customer will send a correct $fd but that has to be determined when testing migration.
Mit freundlichen Grüssen
-Benoît Panizzon-
-
Benoit Panizzon -
Henning Westerholt