[asterisk-dev] sip authentication again

[Luigi Rizzo]

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