On 12-08-2005 15:45, Federico Giannici wrote:

Hummm...It seems my email didn't interested anybody...

Let's try another sub-question.

Yesterday I read the specification of the Remote-Party-ID header field and it says that it is used "When an untrusted UAC sends an INVITE, OPTIONS, REGISTER or extension method request". That is EVERY method (even unknown ones) except ACK, BYE and CANCEL.

It make sense to me to follow the same rule for the authentication, because those three methods are in practice "responses" to previous actions, and so shouldn't be blocked.

Do you agree?

You should authenticate REGISTER messages and check the value of To header field (in REGISTER To contains the subscriber being registered). You can check To with check_to. This would prevent subscribers from incercepting calls of someone else.

If you want to verify the identity of the caller then you should also authenticate INVITE messages and verify the contents of From header field. INVITE messages should only be authenticated if they contain the domain of your proxy server in From.

INVITEs that do not contain your domain in From but contain your domain in the Request-URI should be allowed (because they are for one of your subscribers). Any other INVITE can be rejected.

The only two SIP messages that must not be authenticated are CANCEL and ACK (the authentication modules in SER will always return "authenticate" for them).

The same as for INVITEs applies to any requests that are not sent within a dialog, such as MESSAGE, SUBSCRIBE, OPTIONS.

Messages within a dialog, such as BYE, re-INVITE (has To tag), NOTIFY are a bit more tricky, because they can be sent by either party and thus the contents of From and To could be swapped. You can only authenticate in-dialog requests if they contain your domain in From. If they don't then you should allow them.

Note that it can happen that an in-dialog request (such as BYE) does not contain the domain of your proxy server at all. This will happen if a 3rd party user is calling one of your subscribers and puts a different URI in To (this is legal). The Request-URI will be rewritten with the Contact of the callee in in-dialog requests and the information about your domain will be lost. This is the reason why you should never reject in-dialog requests.

Jan.

Federico Giannici wrote:

...

I'm relatively new to SIP and I'm learning how to configure SER for a little ISP.

I'm currently asking myself when we should authenticate users. Obviously, I don't wont to have an open-relay SIP server. So I'm thinking that I have to authenticate users for every message that comes and that have a "From:" header that matches one of our domains. Is this correct?

Then I have to call check_to() for REGISTER messages and check_from() for all the others. Is this correct?

So here it is a scheme of the logic I'm going to implement. Do you think is correct?

IF uri == myself IF method == REGISTER www_authenticate() check_to() save() ELSE IF From == myself proxy_authenticate() check_from() Normal processing ELSE IF From == myself proxy_authenticate() check_from() t_relay() ELSE Error!

Thanks.

-- ___________________________________________________ __ |- giannici@neomedia.it |ederico Giannici http://www.neomedia.it ___________________________________________________

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers