[SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...

[Olle E. Johansson]

> On 17 Jun 2020, at 10:58, Aymeric Moizard <amoizard at gmail.com <mailto:amoizard at gmail.com>> wrote:
> 
> 
> 
> Le mer. 17 juin 2020 à 08:29, Olle E. Johansson <oej at edvina.net <mailto:oej at edvina.net>> a écrit :
> Aymeric,
> Good to hear from you!
> 
> ;)
> 
> There’s been some discussion in the IETF which we haven’t resolved on how to handle this. I think you need to setup
> different domains or realms each with one auth algorithm. If you offer two at the same time - what’s the point?
> 
> I don't understand why using different realm compared to one realm for both would be better?
Each realm would have a *SINGLE* auth algorithm.

> 
> You are still wide open for downgrade attacks and haven’t accomplished much. 
> 
> Today, MD5 is used. If both MD5 and SHA-256 are proposed, it can't be worst in terms of security... It is true that it doesn't bring much!
Right, if you think you are raising security, you’re wrong… That’s a problem.

> 
> My intention is to start migration.
> I guess, today, the safest start is to choose at runtime based on the user-agent or some internal rules. In a later step, the old way would be removed.
Maybe, but in many cases that will never happen because you have legacy phones that hang around until the end of time.
We need to find a decent way to make segments of your network require stronger algorithms and don’t offer downgrades. Basing that on user-agent headers is not a working solution - and you know it :-)

> 
> If people providing services don't start to use newer algo, there won't be any effort on the endpoint side.
> 
> My initial complete objective: (theory)
> 1/ offer bother md5 and sha-256 to user-agent which still use md5 and which are NOT broken in this mode. (Runtime decision)
> 2/ offer only sha-256 to user-agent with sha-256 support.
> 3/ offer only MD5 to user-agent with don't support sha-256 AND are broken if both are offered.
> 
> I could also start with point 2 and 3 only, but would prefer to have 1/2/3…
Check RFC 8760 for advice and hints on this.

Cheers
/O
> 
> 
> Regards,
> Aymeric
> 
> I guess we will have to wait until the IETF resolves this issue, which propably applies to more protocols.
> The big question is how to upgrade a user base to stronger authentication algorithms in HTTP Digest auth
> without allowing downgrade attacks.
> 
> Cheers,
> /O
> 
>> On 16 Jun 2020, at 20:42, Henning Westerholt <hw at skalatan.de <mailto:hw at skalatan.de>> wrote:
>> 
>> Hello,
>>  
>> take a look to this parameter, you can switch between MD5 and SHA256, but only use once at a time:
>>  
>> https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm <https://www.kamailio.org/docs/modules/5.3.x/modules/auth.html#auth.p.algorithm>
>>  
>> About planned features – I am not aware of major extensions in this module. Of course, any contribution is welcome.
>>  
>> Cheers,
>>  
>> Henning
>>  
>> -- 
>> Henning Westerholt – https://skalatan.de/blog/ <https://skalatan.de/blog/>
>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>  
>> From: sr-users <sr-users-bounces at lists.kamailio.org <mailto:sr-users-bounces at lists.kamailio.org>> On Behalf Of Aymeric Moizard
>> Sent: Monday, June 15, 2020 10:31 PM
>> To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>>
>> Subject: [SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...
>>  
>> Hi All,
>>  
>> I'd like to improve my setup by switching to SHA-256. 
>> However, as a first step, I would like to offer both MD5 and SHA-256
>> in 2 different WWW-Authenticate header.
>>  
>> If I'm correct, this is not doable with the latest auth module?
>> Is this a planned feature?
>>  
>> As an alternative, I would like to decide the algorithm in the script
>> instead of a module parameter. It looks to me this is also not doable?
>> Again, is this a planned feature?
>>  
>> Thanks to all,
>>  
>> Regards
>> Aymeric
>>  
>> -- 
>> Antisip - http://www.antisip.com <http://www.antisip.com/>_______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200617/f2a8956e/attachment.html>