[asterisk-dev] bug or feature (use From: instead of Digest username to match INVITE) ?

[Luigi Rizzo]

On Wed, Oct 11, 2006 at 09:52:38PM +0200, Johansson Olle E wrote:
> 
> 10 okt 2006 kl. 01.40 skrev Kevin P. Fleming:
> 
> > ----- Luigi Rizzo <rizzo at icir.org> wrote:
> >> I am not sure how to handle this. Maybe i miss that, but what's wrong
> >> in using the "username" entry in the Proxy-Authorization: line
> >> to lookup the matching entry in the users list ?
> >
> > This is a design problem with the way that Asterisk handles SIP  
> > authentication. It should be domain-based, but it is not.
> >
> > The simple answer to your question is: we need to know what user it  
> > is before we have asked for authentication, so we don't have the  
> > Proxy-Authorization information yet.
> >
> > There are two options: either request authentication for all  
> > incoming INVITEs, or request authentication based on the target URI  
> > being requested and the domain of the requestor (this is 'domain  
> > based' authentication).
> 
> This is something I started coding earlier in chan_sip2 and realized,  
> as Kevin says, it's deep down in the core
> design of chan_sip and can't easily be fixed. It's a catch22. We need  
> to know before we challenge who we are
> challenging and without an auth header, we have no auth user name -  
> so we can't base any auth on the auth
> user name alone. Yet.
> 
> Chan_sip3 will have a different algorithm for authentication and  
> matching. Btw, it will not have users, nor peers.
> And each domain will have it's own name space.
> 
> But we still have to remember that the extension namespace and the  
> device naming namespace are two different
> things in Asterisk. We should not try to merge them, it will just be  
> confusing. Not using the From: username
> will remove this particular confusion.
> 
> However, remember that many providers has a policy that the From:  
> user name (caller ID) and the auth user ID
> needs to match. It still has to be possible to enforce such a policy  
> with Asterisk.

How about the following ? From my reading of the code it should
work fine, and is a small trivial change to the existing code:

	Device	Event

 	A:	send to B:   INVITE without authentication

        B:      [#1] do not even try to match, but unconditionally
                require authentication and generate a new nonce, nonce_1.

		send to A: 401/407 with nonce_1

                We can safely forget nonce_1 after sending the msg,   
                or (as an optimization), [#4] store it on B for a while
                in a table of "pending nonces".


	A:	receive nonce_1, compute auth info and resend
        	send to B: INVITE with auth based on nonce_1

        B:      [#2] use username="xyz" to lookup a matching entry, 
                and possibly check authentication if required by xyz.
		(Possibly, if usernames from different providers may collide,
		we can add the domain as well).
		
                [#3] If we have not stored nonce_1 on B, the check will result
                in a nonce mismatch, so we reply with 401/407 and a new nonce,
                nonce_2 (possibly one already in the entry for xyz),
                which this time can associate to "xyz" so the
                next transaction will succeed.

                [#4] If we stored nonce_1 on B, we can look it up (to make
                sure A is not providing a fake nonce) and accept it as
                a valid one -- and record in xyz's entry if it has no
                nonce yet.

        	send to A:  either 401/407 with nonce_2, or success

#1 is a trivial change in check_user_full() to just call
        transmit_response_with_auth() and return AUTH_CHALLENGE_SENT
        if there is no auth header;
#2 is implemented by the small patch i posted in this thread; 
#3 is already implemented by the existing code; 
#4 is only an optimization (so it is not strictly necessary)
   that can be implemented with a simple
   hash table or similar data structure; 

i am only unsure how a device would react to 401/407 if it
does not support authentication (is there any ?) - will it
just give up or what ?

	cheers
	luigi