¦^ÂÐ: [asterisk-dev] sip authentication again

[Luigi Rizzo]

On Thu, Oct 19, 2006 at 12:19:11PM +0800, King Ho wrote:
> Hi,
> 
> With the ordering in part 3, I can see a problem that we are having with the
> existing code 1.2.12.1. That is, if the remote system has a user having the
> same name as a local user, who requires authentication, then even if the
> remote system IP/port has insecure=yes specified, Asterisk will still ask
> for authentication and is authenticating using the local user credential.
> 
> Since if a call comes from a system that doesn't require authentication or
> already authenticated, then we shouldn't need to authenticate per user
> again. Should the ordering in part 3 be: 3b, 3c, 3a, 3d.

the problem you are exposing is the same that i had and prompted
me to start this discussion.
The thing is, step 3a (which i only included for those who
want full backward compatibility) in my opinion is totally bogus
and people should not use it.

surely, in principle sip.conf could have an ordered list of
UA matching algorithms, that are applied in sequence until one
gives a final answer.

That would make experimenting with solutions a lot easier.

	cheers
	luigi

s Best Regards,
> 
> King
> 
> -----­ì©l¶l¥ó-----
> ±H¥óªÌ: asterisk-dev-bounces at lists.digium.com
> [mailto:asterisk-dev-bounces at lists.digium.com] ¥N²z Luigi Rizzo
> ±H¥ó¤é´Á: Thursday, 19 October, 2006 6:31
> ¦¬¥óªÌ: Asterisk Developers Mailing List
> ¥D¦®: [asterisk-dev] sip authentication again
> 
> subject changed to raise attention :)
> 
> taking kevin's ideal model below:
> 
> On Mon, Oct 16, 2006 at 12:27:21PM -0500, Kevin P. Fleming wrote:
> ...
> > If the service they are asking to INVITE is open to the world,
> > then the INVITE goes through unchallenged and you don't know who
> > is connecting to you. If the service they are asking to INVITE is
> > protected (by domain-based authentication) then you challenge them
> > and find out who they are.
> > 
> > At least, this is the 'ideal' model... it is not what Asterisk fully
> implements today.
> 
> it seems that we need to implement the following steps, all of which
> seem straightforward to code and can be enabled/disabled through
> sip.conf options (so backward compatibilty can be preserved for
> those who need it):
> 
> 1. a more fine-grained mechanism (basically an access list, or a sequence
>    of patterns such as those that we find in the dialplan) to select which
>    services are 'open' and which ones are not.
>    Right now there is only an 'allowguest' variable.
>    In any case this part is rather straightforward, reusing the extension
>    matching code.
> 
> 2. if #1 says the service is not open, and there is authentication info,
>    we have credentials to locate the other useragent, and at most we could
>    try a different challenge if the one submitted is not on our records.
>    This is the 5 lines of code i submitted a few days ago.
> 
> 3. if in #2 we have no credentials, then we could try the following, in
> sequence,
>    to locate the correct entry
> 
>    3a. (only for backward compatibility) match the From: field against the
> users list
>        and then behave as we do now. This is the existing code.
> 
>    3b. match the source IP/port against the info for registered peers, and
> then decide
>        if we trust the IP/port match as credential or (more safely) send a
> challenge;
>        This is also existing code
> 
>    3c. fetch a domain or IP address from one of the relevant header fields
>        (the first Via: ? i don't think other fields can help, because they
> seem
>        to refer to the originator of the call and not the entity talking to
> us)
>        to select the peer entry, then behave as 3b.
>        Very easy too.
> 
>    3d. just send a challenge and wait for a response, so next round we have
> case #2
> 
> Unless i am missing something big, this seems to be pretty compatible with
> the
> existing architecture - with a few general sip.conf options we can decide
> which
> of the steps above should be enabled or not, and all seems to be confined to
> chan_sip.c::check_user_full().
> 
> Makes more sense now ?
> 
> 	cheers
> 	luigi
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev