[asterisk-dev] [Code Review] SIP authentication support

Olle E. Johansson oej at edvina.net
Wed Feb 13 10:44:54 CST 2013


13 feb 2013 kl. 16:14 skrev Mark Michelson <mmichelson at digium.com>:

> On 02/13/2013 02:07 AM, Olle E. Johansson wrote:
>> 
>> 
>> However, that quote answers my question about migrating to SHA256, even though I think there's a policy issue here - why would you want to offer a bad auth mech when you have a better. How should a client respond? I think there is work to be done here. Let's discuss that at SIPit.
>> 
>> /O
>> 
> 
> I think the idea behind offering multiple schemes is that a server may support both MD5 and SHA256, but the client that is trying to authenticate may only support MD5. Even though SHA256 is the better scheme, the server also accepts MD5 for compatibility purposes.
I do understand that, but as I said - you don't want that in reality. You challenge with the strongest and want the strongest auth. If that fails, you may downgrade in the next challenge. There's no reason to say "I want your ID and passport, but if that fails, any membership card in a bookclub will do".

Now, if we challenge with SHA256 and the client fail to support that, will it retry? How do we handle this migration and negotiation without downgrading everything even if the client supports the strong one? I don't really trust developers to "pick the strongest one". People will use the book-club membership cards. Or other club cards that I don't want to mention in this forum.

> 
> If a client is presented with multiple schemes that it knows how to use, then my thought is that the client should determine which scheme is "strongest" and respond to that challenge only. We can discuss it more at SIPit for sure. We just need to be sure to document what we come up with on the wiki.
See you next week!

/O
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130213/e985edd3/attachment.htm>


More information about the asterisk-dev mailing list