Subject: [sipcore] SIP Digest - SHA2 Support

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 12 Jan 2017 08:33:05 -0500

Hi,

RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA2* to
replace the MD5 algorithm.

I am trying to revolve this old draft that does the same for SIP:
https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/

I would appreciate any review and comments on the draft.

Regards,
 Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 12 Jan 2017 11:08:39 -0500

Sorry, it is RFC7616 that updated the HTTP Digest mechanism.
https://tools.ietf.org/html/rfc7616

Regards,
 Rifaat

On Thu, Jan 12, 2017 at 8:33 AM, Rifaat Shekh-Yusef <[email-masked]>
wrote:

> Hi,
>
> RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA2*
> to replace the MD5 algorithm.
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 12 Jan 2017 11:44:47 -0500

> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/

It makes sense to do this, of course, as MD-5 is thoroughly obsolete.

As a matter of exposition, you say "This section does NOT maintain
backward compatibility with RFC 2069."  But of course as a consequence
of that, it isn't compatible with RFC 3261 either.

I'd like to see a description of how the draft's section 2.6 compares
with the existing SIP authentication scheme -- is this just adding the
new algorithms and making qop mandatory?

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 12 Jan 2017 13:07:24 -0500

Thanks Dale!

Please, see my reply inline...

Regards,
 Rifaat

> of that, it isn't compatible with RFC 3261 either.

The statement you quoted was in the previous version of the document, but
not in v05.
If I remember correctly, we discussed that and during one of the IETF
meetings and it was deemed unnecessary to maintain that.
We did the same with the new HTTP Digest mechanism defined in RFC7616.

Is that a problem for SIP?

> Yes, the idea is that this draft will add the SHA2 algorithms as the
recommended algorithms, and only keep the MD5 for backward compatibility.

Regards,
 Rifaat

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Jan 2017 09:29:00 +0100

Rifaat,
THank you for your work on this and coming back.

I feel we need to have some writing about how to migrate. There is a significant risk of downgrade attacks
if we have both mechanisms running, like you get two challenges or one challenge with two algorithms
(if that’s possible). The web has a simpler upgrade path, given the small amount of browsers that operate
a majority of the requests. We have many years of legacy software that propably will not upgrade unless customers
require it. And it will take some time to get new firmware out there with support for this unless there’s significant
customer demand.

We definitiely need to get this done and move SIPconnect 2.x to require this on public networks and
forbid MD5 in those situations as a first step. Hopefully that can help some customers to demand the right thing.

How do an operator of a service upgrade to SHA2? Do we have to have a cut-off date and stop
accepting MD5, do we migrate somehow or do we mark “new” phones for ONLY SHA2 and old clients
for MD5 and SHA2 in some authentication service database?

Implementors need to know how to handle this and I haven’t figured out any good solution in my own
head since we started this discussion five years ago or so….

If we can solve this process now, we’re in better shape when SHA2 becomes the algorithm that no one
wants to use any more.

/O

> On 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> Thanks Dale!
> 
> On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worley <[email-masked] <mailto:[email-masked]>> wrote:
> Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> writes:
> > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ <https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/>
> 
> The statement you quoted was in the previous version of the document, but not in v05.
> If I remember correctly, we discussed that and during one of the IETF meetings and it was deemed unnecessary to maintain that.
> Yes, the idea is that this draft will add the SHA2 algorithms as the recommended algorithms, and only keep the MD5 for backward compatibility.
> 
> Regards,
>  Rifaat
> 
> 
>  
> Dale
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 13 Jan 2017 12:49:16 -0500

Thanks Olle,

This document gives the operator the tools to migrate, but *migration
policy *is probably be out of scope this document.

What do others think?

Regards,
 Rifaat

On Fri, Jan 13, 2017 at 3:29 AM, Olle E. Johansson <[email-masked]> wrote:

> a majority of the requests. We have many years of legacy software that
> propably will not upgrade unless customers
> require it. And it will take some time to get new firmware out there with
> support for this unless there’s significant
> customer demand.
>
> forbid MD5 in those situations as a first step. Hopefully that can help
> some customers to demand the right thing.
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 13 Jan 2017 19:41:28 -0500

> The statement you quoted was in the previous version of the document, but

Hmmm, for some reason I wasn't looking at the 05 version.

> recommended algorithms, and only keep the MD5 for backward compatibility.

What I meant was a positive statement in the draft of what the
differences are, so the reader doesn't have to correlate section 2.6
with the previous RFCs.

"Olle E. Johansson" <[email-masked]> writes:
> I feel we need to have some writing about how to migrate. There is a
> significant risk of downgrade attacks if we have both mechanisms
> running, like you get two challenges or one challenge with two
> algorithms (if that's possible).

Certainly we need to worry about avoiding downgrade attacks, and this
should be included in the security considerations.  (I can imagine
techniques to prevent it, such as when digest-protecting a message,
including in the protected information a list of ciphers that the sender
is willing to support, so that the receiver can verify that no better
cipher that it offered to use is also supported by the sender.)

Forking in the general case ... gets ugly.  I'm not sure how much it
matters in practice.  But if one fork returns a 401 for domain
example.com that demands use of MD-5, and another fork returns a 401 for
domain example.com with two Proxy-Authenticate headers that allow either
MD-5 or SHA-256, the combined 401 returned to the UAC contains 3
Proxy-Authenticate headers for one domain, two of which use MD-5 and one
SHA-256.  Is there any way to prescribe behavior for the UAC that will
cause successful operation?

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 14 Jan 2017 09:09:52 +0100

> On 13 Jan 2017, at 18:49, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> Thanks Olle,
> 
> This document gives the operator the tools to migrate, but migration policy is probably be out of scope this document.
Agree that policy is out of scope, but advice to implementors should be in scope so we do not cause
security flaws in software.

/O
> 
> 
> What do others think?
> 
> Regards,
>  Rifaat
> 
> 
> 
> On Fri, Jan 13, 2017 at 3:29 AM, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> Rifaat,
>> On 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Thanks Dale!
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
> 
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 17 Jan 2017 22:46:01 -0500

> differences are, so the reader doesn't have to correlate section 2.6

I see. ok.

> should be included in the security considerations.

Agree.

> (I can imagine
> I am not clear on this comment. Can you please elaborate on what you mean
by this?

> matters in practice.

Yeah, I agree.
We need to simplify this and avoid the complexity that comes with forking.

Regards,
 Rifaat

> But if one fork returns a 401 for domain

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 17 Jan 2017 22:52:43 -0500

That is what the Security Consideration section for; or are you looking for
something beyond that?

Regards,
 Rifaat

On Sat, Jan 14, 2017 at 3:09 AM, Olle E. Johansson <[email-masked]> wrote:

>> significant risk of downgrade attacks