Summary: | ASTERISK-04338: possible bug in checking SIP authentication | ||
Reporter: | Luigi Rizzo (rizzo) | Labels: | |
Date Opened: | 2005-06-03 12:09:49 | Date Closed: | 2005-07-11 18:31:30 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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. |