Summary:	ASTERISK-23322: Unable to use SIP INVITE authentication with type=peer and device name mismatch with username
Reporter:	Igor Nikolaev (microlana)	Labels:
Date Opened:	2014-02-18 03:46:29.000-0600	Date Closed:	2014-03-07 09:51:39.000-0600
Priority:	Trivial	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	11.7.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-chan_sip-inbound-invite-auth.patch
Description:	Scenario: sip.conf {noformat} [devicename] type=peer fromuser=authuser secret=... {noformat} In this case if devicename not equal authuser you need add statement "insecure=invite" for receiving incoming calls. But this INVITEs is not authenticated by receiving system. It's security hole.
Comments:	By: Igor Nikolaev (microlana) 2014-02-18 03:51:52.989-0600 This patch fix described issue. If you specify parameter "fromuser=..." in sip.conf device entry for a peer, incoming INVITE checked with fromuser name instead of device name. Therefore, device name may be either with authname and INVITE auth still checked (you don't need specify "insecure=invite") By: Michael L. Young (elguero) 2014-02-19 11:32:21.156-0600 From sip.conf: {noformat} ;------------------------------------------------------------------------------ ; DEVICE CONFIGURATION ; ; The SIP channel has two types of devices, the friend and the peer. ; * The type=friend is a device type that accepts both incoming and outbound calls, ;   where Asterisk match on the From: username on incoming calls. ;   (A synonym for friend is "user"). This is a type you use for your local ;   SIP phones. ; * The type=peer also handles both incoming and outbound calls. On inbound calls, ;   Asterisk only matches on IP/port, not on names. This is mostly used for SIP ;   trunks. ; ; For device names, we recommend using only a-z, numerics (0-9) and underscore ; ; For local phones, type=friend works most of the time {noformat} So, if you are setting a device as type=peer then name is not used at all according to the documentation unless the documentation is not correct. _*Edit:* Except this issue has to do with authenticating, not matching peers.  The patch is proposing to use the "fromuser" setting as part of the authentication process if it has been set.  Instead of using the device name, use the fromuser for matching the username set in the Authorization line.  I think I am understanding better the proposed patch.  Can you please confirm that this what the intent is of the patch?_ By: Igor Nikolaev (microlana) 2014-02-19 23:36:01.207-0600 Well, please explain me how i can make following configuration: 1. My asterisk need to register into remote system via SIP register 2. With this registered (peer? friend?) i must make both inbound and outbound calls 3. Remote system require SIP INVITE auth for outbound calls and support SIP INVITE auth for inbound calls (inbound and outbound as terms of my Asterisk) 4. I'm use realtime sip peers (but this not important, may be configuration stored into *.conf files), but SIP device names in the my Asterisk must be different with auth names from remote system (important). If i describe this connection as type=peer, then i can REGISTER into remote system, make outbound calls with SIP INVITE auth, but can't accept inbound calls w/o setting insecure=invite (else i got error "username mismatch, have <%s>, digest has <%s>"). The same issue i can see when i describe this peer with type=friend (because auth name got from peer->name field from sip_peer structure). This is wrong because my internal device name (peer->name) must not be known to the remote system, it's used only - into my asterisk system as device name (ex. Dial application etc); - when other systems which register with my asterisk. By: Matt Jordan (mjordan) 2014-02-19 23:39:15.773-0600 # In general, I don't agree with changing this behaviour as a fix for a bug. While defaulting to using "fromuser" and then falling back to the peer name may seem harmless, this could easily cause authentication issues if the fromuser is different than the peer but the peer had been configured to authenticate as the peer name. Making this change in a release branch seems like a bad idea. # That leads to considering it as an improvement. As it would be an improvement, the patch would need to be written against trunk, not Asterisk 11. # As a general improvement, this patch creates a behaviour mismatch in how we perform authentication. We now would authenticate INVITE requests in a fashion different than REGISTER requests, which would be bad. A behaviour change should change how all peers are authenticated, not just how they are authenticated for some requests. Even so, I'd discourage changing this behaviour. It changes a long standing mechanism in Asterisk for very little gain. The fact that you named your peer something other than what it wanted to authenticate as was a choice you made when you configured Asterisk. That's not a security hole, it's a poor choice in your configuration. By: Igor Nikolaev (microlana) 2014-02-20 00:03:48.654-0600 You can still use type=peer with insecure=invite as described with doc. Also, w/o patch, w/o insecure=invite you always got "username mismatch" message if device name not equal remote auth name. Ok, is following situation is possible in real life? 1. I have two different remote systems (uplinks), where I must register. That systems have different IPs, auth passwords, but unfortunally auth names are the same. Different VoIP providers can have same auth names, because they know nothing about each other. sip.conf [device1] type=peer ; may be type=friend, result is the same host=host1 fromuser=authname1 secret=secret1 ... [device2] type=peer ; may be type=friend, result is the same host=host2 fromuser=authname2 secret=secret2 where authname1 == authname2 2. I need to determine, from which provider i got incoming call. Yes, i can do it by describe two devices with different names and type=peer and insecure=invite. But this is not secure solution, because anybody can set fake source IP (for UDP is not difficult) as my uplink and i receive call, originated by fake system, not by my operators. Therefore we can't use several uplinks with same auth name w/o security hole. By: Rusty Newton (rnewton) 2014-03-07 09:50:55.774-0600 I'm closing this out, as it is becoming a support issue rather than a bug report. Igor, feel free to ask that same question on the asterisk-users list to discuss with others the possible and/or best or worst approaches. If you want to attach a patch for trunk, then we might re-open, but you would really want to discuss that with others on the asterisk-dev list first as it may be controversial.