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 -----原始郵件----- 寄件者: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 代理 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 _______________________________________________ --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
