Subject: [Rum] Digest algorithms

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Mar 2021 15:36:02 -0500

MD5 is insecure, full stop, for any current application.  Base RFC3261 uses MD5 and does not allow any other digest algorithm.

RFC8760 update RFC3261 to support SHA-256.  Actually what it does is allow negotiation of the digest algorithm, and specifically allows MD5, SHA-256, and SHA-512 to be negotiated.

There really isn’t any defensible reason to support MD5.  It’s insecure.  But nearly the entire universe of SIP only supports MD5 today.

It was suggested to mandate support of RFC8760.  The issue is whether to mandate support for ONLY SHA-256 or higher (meaning not allow MD5 to be used).  

RFC8760 says this:
   This specification adds new secure algorithms to be used with the
   Digest mechanism to authenticate users.  The obsolete MD5 algorithm
   remains only for backward compatibility with [RFC2617 <https://tools.ietf.org/html/rfc2617>], but its use
   is NOT RECOMMENDED.

   This opens the system to the potential for a downgrade attack by an
   on-path attacker.  The most effective way of dealing with this type
   of attack is to either validate the client and challenge it
   accordingly or remove the support for backward compatibility by not
   supporting MD5.

   See Section 5 of [RFC7616] <https://tools.ietf.org/html/rfc7616#section-5> for a detailed security discussion of the
   Digest Access Authentication scheme.

We don’t really have a way to validate the client; the algorithm is used for digest authentication!

So what do we want to do?

Brian

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Mar 2021 07:51:42 +0100

> On 10 Mar 2021, at 21:36, Brian Rosen <[email-masked]> wrote:
> 
I suggest that we get rid of MD5 and select *ONE* algorithm, sha-512, to select something
that will likely hold for a while (assuming it’s stronger than sha-256).  Having multiple algorithms may lead to interoperability issues and downgrade attacks.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Mar 2021 11:13:09 -0500

On 3/11/21 1:51 AM, Olle E. Johansson wrote:
> 
> 
>> On 10 Mar 2021, at 21:36, Brian Rosen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> MD5 is insecure, full stop, for any current application.  Base RFC3261 
>> uses MD5 and does not allow any other digest algorithm.
>>
>> RFC8760 update RFC3261 to support SHA-256.  Actually what it does is 
>> allow negotiation of the digest algorithm, and specifically allows 
>> MD5, SHA-256, and SHA-512 to be negotiated.
>>
>> There really isn’t any defensible reason to support MD5.  It’s 
>> insecure.  But nearly the entire universe of SIP only supports MD5 today.
>>
>> It was suggested to mandate support of RFC8760.  The issue is whether 
>> to mandate support for ONLY SHA-256 or higher (meaning not allow MD5 
>> to be used).
>>
>> RFC8760 says this:
>>     SeeSection 5 of [RFC7616]  <https://tools.ietf.org/html/rfc7616#section-5>  for a detailed security discussion of the
> that will likely hold for a while (assuming it’s stronger than sha-256). 
>   Having multiple algorithms may lead to interoperability issues and 
> downgrade attacks.

Do you have a suggestion for how to do this in an environment where 
there are lots of users with accounts that are secured with passwords 
using MD5?

Of course those are being used with devices not compliant with this 
spec. But when RUE compatible devices become available they will 
presumably be phased in. At the very least, users will need to change 
passwords on their account to get one that is secured by a new algorithm.

One possibility does occur to me: if we make it clear that this spec 
will support sha-256 and not md5, then providers can do the migration on 
their existing equipment and hopefully have completed it before the RUE 
implementations are deployed.

Can providers speak up here please?

	Thanks,
	Paul

---

From: Isaac Roach <[email-masked]>
Date: Thu, 11 Mar 2021 21:31:18 +0000

Something better than MD5 would be ideal but I think we need to allow a transition period. What about adding the hashing algorithm to the configuration service json ("MD5", "SHA-256",  "SHA-256-sess", etc)? 

If the algorithm is not indicated it should default to MD5. 

Isaac Roach
VP Engineering
P: 801-558-0814
E: [email-masked]

Sorenson Communications, LLC
4192 S. Riverboat Rd.
Salt Lake City, UT 84123
www.sorenson.com
 
CONFIDENTIALITY NOTICE. The information contained in this e-mail transmission and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information and is intended only for the use of the intended recipient. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply email at [email-masked] or by telephone at 801-287-9801, and destroy the original transmission and its attachments without reading them or saving them to disk.

On 3/11/21, 2:19 PM, "Isaac Roach" <[email-masked]> wrote:

    On 3/11/21, 9:13 AM, "Rum on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

        [EXTERNAL] 

        	Thanks,
        	Paul

        -- 
        Rum mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/rum

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 12 Mar 2021 07:50:01 +0100

> On 11 Mar 2021, at 17:13, Paul Kyzivat <[email-masked]> wrote:
> 
>>> On 10 Mar 2021, at 21:36, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> Do you have a suggestion for how to do this in an environment where there are lots of users with accounts that are secured with passwords using MD5?

With the tools I use it would be very simple to setup a different SIP domain for new devices and operate both
domains in the same platform, with different requirements on authentication. They could  of course share the same
outbound proxy, so that all devices connect to the same servers.

/O
> 
> Of course those are being used with devices not compliant with this spec. But when RUE compatible devices become available they will presumably be phased in. At the very least, users will need to change passwords on their account to get one that is secured by a new algorithm.
> 
> One possibility does occur to me: if we make it clear that this spec will support sha-256 and not md5, then providers can do the migration on their existing equipment and hopefully have completed it before the RUE implementations are deployed.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2021 09:57:51 -0500

> outbound proxy, so that all devices connect to the same servers.

This seems to fall within the class of solutions that require the user 
to have distinct id and/or password for the RUE and their older devices. 
That seems like a distinctly un-user-friendly thing to do.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2021 10:01:15 -0500

Isaac,

> If the algorithm is not indicated it should default to MD5.

I'm asking if you can do the migration from MD5 within your existing 
infrastructure. Then we could start the RUE out fresh without MD5 support.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 12 Mar 2021 19:06:33 +0100

> On 12 Mar 2021, at 15:57, Paul Kyzivat <[email-masked]> wrote:
> 
> This seems to fall within the class of solutions that require the user to have distinct id and/or password for the RUE and their older devices. That seems like a distinctly un-user-friendly thing to do.

I think there was a distinction between SIP account and user account here? Isn’t the SIP account provisioned by a configuration server?

/O

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Mar 2021 13:17:08 -0500

Right now, they are one and the same.  There has been discussion of separating them, but that’s not what the text does now.

Brian

> On Mar 12, 2021, at 1:06 PM, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2021 13:33:32 -0500

On 3/12/21 1:17 PM, Brian Rosen wrote:
> Right now, they are one and the same.  There has been discussion of 
> separating them, but that’s not what the text does now.
> 
> Brian
> 
>> On Mar 12, 2021, at 1:06 PM, Olle E. Johansson <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>> On 12 Mar 2021, at 15:57, Paul Kyzivat <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>>> there are lots of users with accounts that are secured with 
>>>>> passwords using MD5?
>>>> With the tools I use it would be very simple to setup a different 
>>>> SIP domain for new devices and operate both
>>>> domains in the same platform, with different requirements on 
>>>> authentication. They could  of course share the same
>>> This seems to fall within the class of solutions that require the 
>>> user to have distinct id and/or password for the RUE and their older 
>>> devices. That seems like a distinctly un-user-friendly thing to do.
>>
>> I think there was a distinction between SIP account and user account 
>> here? Isn’t the SIP account provisioned by a configuration server?

*If* the sip account is configured then using a separate id/pw for that 
would be possible without inconveniencing the end users.

But how is this same problem being solved for web servers? We are also 
using a web server for our configuration, and the providers have web 
interfaces for their customer service interface. MD5 should be equally a 
problem there.

If we can get the providers to deal with this migration before the RUE 
spec is finalized then we don't have to solve it.

	Thanks,
	Paul

---

From: Isaac Roach <[email-masked]>
Date: Fri, 12 Mar 2021 19:20:15 +0000

We all want to do everything we can to improve security but RFC 8760 is relatively new (March 2020) and many SIP system providers have not yet implemented it. Some expensive hardware systems stop receiving new features so I think some VRS providers would need at least a five year transition plan (maybe longer). 

Thanks,

Isaac

On 3/12/21, 11:34 AM, "Rum on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    [EXTERNAL] 

    	Thanks,
    	Paul

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Mar 2021 14:35:05 -0500

Understood, but security these days doesn’t allow that kind of cycle.  All it takes is one break-in and then you have weeks to upgrade and your name is mud no matter what you do.  Getting out ahead of something as obvious as MD5 digest on a password is pretty important.  You really, really don’t want to be explaining to anyone what your 5 year plan was when someone got compromised.

As with the IPv6 discussion, for a provider, all that matters is your SBC is upgraded to handle SHA-256.  That whole interface is point-to-point between the RUE device and the SBC, assuming that providers do have an SBC between users and their proxies.  It could just use MD5 inside, and between it and older devices.

Brian

> On Mar 12, 2021, at 2:20 PM, Isaac Roach <[email-masked]> wrote:
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 15 Mar 2021 08:24:31 +0100

> On 12 Mar 2021, at 20:20, Isaac Roach <[email-masked]> wrote:
> 

This is the IETF after all. We’ve known for a long time that MD5 is insecure and can’t publish standards in
2021 accepting insecure authentication mechanisms. Transition plans are not part of standard documents,
those are plans on how to reach up to the level required by a standard.

https://tools.ietf.org/html/rfc6151 <https://tools.ietf.org/html/rfc6151> declared MD5 unacceptable in 2011. 

/O