Re: [sipcore] SIP Digest - SHA2 Support

["Olle E. Johansson" <[e-mail]>]

> On 13 Jan 2017, at 18:49, Rifaat Shekh-Yusef <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Thanks Dale!
>> 
>> Please, see my reply inline...
>> 
>> Regards,
>>  Rifaat
>> 
>> 
>> On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worley <[e-mail] <mailto:[e-mail]>> wrote:
>> Rifaat Shekh-Yusef <[e-mail] <mailto:[e-mail]>> writes:
>> > 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/ <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.
>> 
>> 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?
>> 
>> 
>>  
>> 
>> 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?
>> 
>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore