Summary:ASTERISK-07201: [patch] Invalid handling of multiple secrets for peer/friend entries
Reporter:Paul Cadach (pcadach)Labels:
Date Opened:2006-06-19 00:37:43Date Closed:2006-08-08 13:53:14
Versions:Frequency of
Environment:Attachments:( 0) iax2-auth.diff
( 1) iax2-auth2.diff
Description:When you specify multiple secret lines in IAX user/peer/friend configuration section, chan_iax2 merges them into single string with semicolon as delimiter. For incoming (user) call, authentication code successfully walks through all secrets to find one from the list. But for outgoing (peer) call full secret string (including all passwords and its delimiters) is used, which is wrong.


Two solutions is provided (common part is commited by Russell yesterday - use last secret only for peers and don't try to collect all specified secrets into single line):
1) You can specify multiple secrets but LAST one used for peer authentication, while all previous - for user authentication;
2) Special "peersecret" is used to specify peer's secret when multiple (or different) user secrets is specified.
Comments:By: Tilghman Lesher (tilghman) 2006-06-22 10:13:40

I wonder if #1 is more sane, but if we should use the first secret, not the last secret.  This would logically make more sense; the first secret should be the primary, and all others should be secondary.

By: Russell Bryant (russell) 2006-07-02 22:49:23

I'm not sure that any further changes are really needed here.  The change that was already made makes it so multiple secrets are only stored in the iax2_user struct and only the last secret specified in an entry will be saved in the iax2_peer struct.

If there is a need for separating the secrets to be different between users and peers, then a friend entry shouldn't be used.  They just need to be split up into separate user and peer entries.

By: Matt O'Gorman (mogorman) 2006-07-07 11:02:25

is this a dead issue?  or is more needed

By: Serge Vecher (serge-v) 2006-08-08 11:11:04

PCAdach: *ping*

By: Paul Cadach (pcadach) 2006-08-08 11:47:06

vechers: pong ;-)
I've found the bug, made some proposals how to solve it, and needs to know someone's else "point of view" to proposed solutions.

Corydon's point of view is good but requires much more work than for my proposals. Russel's opinion have some incorrectness because it shares a key between user and peer (but incoming, user and outgoing, peer connection could have really different username/passwords and having more keys than required provides security hole).

By: Russell Bryant (russell) 2006-08-08 13:53:14

Well, my feeling is still that if you want a different password for a user and a peer of the same name, then they should be specified in different type=user and type=peer entires.

I'm going to have to make an executive decision here and declare this as resolved.  If you feel there are still further changes that should be made, then please start a discussion on the asterisk-dev mailing list.  Thanks