[asterisk-dev] Plaintext auth support in IAX2

[Matthew Jordan]

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.



>
> Patch adds note to UPGRADE.txt too.
>


As Tilghman noted, we probably should wait longer than a single version to
remove support for a deprecated feature. If I recall correctly, standard
operating procedure is two versions from the time when a feature is
deprecated, which put Asterisk 14 as the earliest time this feature can be
removed.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131105/8a9f4d6c/attachment.html>