[asterisk-dev] Plaintext auth support in IAX2

[Tilghman Lesher]

On Tue, Nov 5, 2013 at 12:11 PM, Matthew Jordan <mjordan at digium.com> wrote:
>
> On Tue, Nov 5, 2013 at 3:04 AM, Eugene Varnavsky <varnavruz at gmail.com>
> wrote:
>>>
>>> Section 8.6.3 of RFC 5456 is "CALLING ANI":
>>> http://tools.ietf.org/html/rfc5456. I'm guessing that isn't what you were
>>> referring to.
>>
>>
>> Sorry for typo, I meant section 8.6.13
>>
>>>
>>> Here's what I'd recommend:
>>>
>>> In Asterisk 12, patch chan_iax2 to emit a WARNING if auth=plaintext is
>>> used. That WARNING should tell a user that the option is deprecated.
>>>
>>> Additionally, add a note in UPGRADE that the plaintext option has been
>>> deprecated.
>>>
>>>  In trunk (Asterisk 13), remove support for "plaintext". This means:
>>>
>>> If a user specified "plaintext", emit an ERROR and reject loading
>>> chan_iax2. Users should not be allowed to load the channel driver with an
>>> invalid configuration, and you don't want to "help them" with their
>>> authentication options.
>>> Remove support for plaintext authentication in the code.
>>> Add a note in UPGRADE that support for plaintext has been removed.
>>
>>
>> Sounds fine for me.
>>
>> I made a patch for 12 that emits a warning if auth methoid is set to
>> plaintext, or plaintext is one of auth methods.
>> I'm going to test it and then upload it to the ticket ASTERISK-22820
>>
>> Additionally, warning is emitted every time plaintext auth is sent or
>> accepted. Why? The tricky thing with deprecation is what auth methods we set
>> as default. As far as I can see inside sources, if auth= parameter is
>> omitted, auth methods are set to "md5 first, then plaintext".
>> So, if we leave auth= at defaults, and other side has auth=plaintext, we
>> will see warning anyway.
>
>
> What about defaulting only to md5 and not falling back to plaintext? While
> that is a slightly more meaningful change, it prevents having to spam
> WARNING messages.
>
> I would prefer not to have any messages displayed during run time operation,
> after the module is loaded. This would especially apply to messages that are
> received. The fact that some other system has chosen to send authentication
> in plaintext is presumably outside of the control of the receiving system.
> Creating a message that spams someone when they cannot control is bound to
> only cause frustration.

This has given me an idea for a feature to add, which would be a
deprecation log subsystem.  Essentially, deprecation warnings are not
only emitted as WARNING logs, but they are saved in memory (and
de-duplicated), sufficient to be seen with a command line request of
"core show deprecation warnings" and cleared with "core clear
deprecation warnings".  They are suggested as constant strings only,
sufficient to ensure that de-duplication can be accomplished with
pointer comparisons, instead of string comparisons.  Upon upgrading
any version in the future, administrators are encouraged to run that
command line and modify their configurations until running that
command no longer produces deprecation warnings after startup and a
sufficiently representative variety of calls.

The difference between the current method of reading UPGRADE.txt and
running this set of commands would be the difference between making
administrators aware of all deprecations versus only those
deprecations which apply to their instances.  It also provides
sufficient warning to administrators who may read UPGRADE.txt and have
forgotten about a little-used feature in their systems which is still
subject to deprecation and needs to be corrected.

-Tilghman