[Home]

Summary:ASTERISK-04338: possible bug in checking SIP authentication
Reporter:Luigi Rizzo (rizzo)Labels:
Date Opened:2005-06-03 12:09:49Date Closed:2005-07-11 18:31:30
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Long description follows.
The short description is that when a asterisk node, say 'home', tries to
register to a peer (or friend) asterisk with this line in sip.conf,

   register => bob:xxxyyyzzz@office/123456

then node 'office' uses the extension (123456) in the username field of
the Digest, and node 'home' uses the peer's name (office) in the same field.
I would have expected the username field (bob) to be used by both.

There is a workaround, which is to use the same string for the peer name
and the extension in the register line. But of course this is heavily
confusing because then you don't know which is which.


--- LONG DESCRIPTION ---

I have two asterisk nodes, 'home' (dynamic IP) and 'office' (static IP)
with the config below:

   home: sip.conf
           register => bob:xxxyyyzzz@office/123456
      [office]
      type=peer ; using friend does not change behaviour
      host=12.34.56.78 ; actually, office's real IP!
      secret=xxxyyyzzz

   office: sip.conf
      [bob]
      type=friend
      secret=xxxyyyzzz
      host=dynamic

   office: extensions.conf
      [my_friends]
      exten => bob,1,Dial(SIP/${EXTEN})


'home' registers with 'office' correctly. The REGISTER message has

       Proxy-Authorization: Digest username="bob", ...

and this is the username used to compute hashes. Pretty much what I expected.

'home' can Dial(SIP/someexten@office) correctly. The INVITE message has

       Proxy-Authorization: Digest username="bob", ...

and this is the username used to compute hashes. Pretty much what I expected.

If 'office' tries to call bob@my_friends, registration fails.
"sip debug" shows that the INVITE message from 'office' has

       Proxy-Authorization: Digest username="123456", ...

which seems a bit odd, given that the '123456' comes from the
peer record, where there is also a username="bob" record.
I suspect that the username should be used instead.

The second odd thing is that 'home' tries to compute the hashes with

       username="office"

(in this particular case, the code matches a peer, and line 6157
in chan_sip.c calls check_user_full() with peer->name as username.
Once again, peer has a username field which i would expect to be used.



****** ADDITIONAL INFORMATION ******

also occurs with -stable

Comments:By: Olle Johansson (oej) 2005-06-03 12:44:02

This is all very confusing, one of the reasons I want to remove users and clean this mess up. So far I had no positive feedback.
By: Olle Johansson (oej) 2005-06-03 12:44:40

Try using realm based authentication, see the sample sip.conf
By: Olle Johansson (oej) 2005-06-03 12:48:22

I need to see your sip.conf and extensions.conf to figure out where the 123456 is coming from. Also, you have to provide full SIP debugs to help us try to figure this out.

"If 'office' tries to call bob@my_friends, registration fails.
"sip debug" shows that the INVITE message from 'office' has"

Registration fails? INVITE is not a registration! Do you mean authentication?
By: Kevin P. Fleming (kpfleming) 2005-06-03 15:24:38

This is all due to Asterisk's use of the From: header for authentication, which is also used for called number transfer. As long as Asterisk is using the From: header for authentication, it cannot be used to specify the called number. When the From: header contains the called number, the call cannot use authentication, unless domain-based authentication is used.

I do not want to apply _any_ patches to change this behavior that don't move us towards using domain-based authentication; any more changes that complicate the existing behavior will only move us farther from the proper authentication method.
By: Luigi Rizzo (rizzo) 2005-06-03 15:48:25

kpfleming: I don't want to change anything, just understand what to expect from
the register and peer-specific sections, so that next time i or others
won't spend hours trying to use different values for what appear to
be independent parameters (remote-hostname and local-extension)
By: Kevin P. Fleming (kpfleming) 2005-06-03 16:00:57

That's fine; if you can think of any way to improve the existing config samples or documentation based on the discussion in this bug, please feel free to comment. You are right that this particular is somewhat confusing :-)
By: Olle Johansson (oej) 2005-06-04 06:58:21

I still need to see the full config data to find out what's going on. Thank you.
By: Michael Jerris (mikej) 2005-06-28 00:50:38

rizzo-  can you please provide the debug for this?
By: Kevin P. Fleming (kpfleming) 2005-07-11 18:31:16

We're going to have to close this one for now; most likely it's behaving 'as expected', but without additional details we can't make any decisions about whether that behavior should be changed or not.