回覆: [asterisk-dev] sip authentication again

[King Ho]

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.

Best Regards,

King

-----原始郵件-----
寄件者: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] 代理 Luigi Rizzo
寄件日期: Thursday, 19 October, 2006 6:31
收件者: Asterisk Developers Mailing List
主旨: [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