Re: [sipcore] SIP Digest - SHA2 Support

[Rifaat Shekh-Yusef <[e-mail]>]

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 <[e-mail]> wrote:

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