Hi Rifaat, thanks again for incorporating my small suggestion into the
final document and sorry somehow I overlooked the second part of your
response a while back. Now that we are actually implementing this RFC I
tried to find any place in RFC7616 that specifically requires nonce to be
re-used for all alternatives and I could not find any, apart from examples
given in the https://tools.ietf.org/html/rfc7616#section-3.9.1
<https://www.google.com/url?q=https://tools.ietf.org/html/rfc7616%23section-3.9.1&sa=D&ust=1600112246589000&usg=AFQjCNEo-IffDNxmG85B8k9K4_GzcssSbQ>
.
The only place where it kinda suggesting singularity of nonce per response
is this:
nonce
A server-specified string which should be uniquely generated each
time a 401 response is made.
However, one could technically argue that in case of multiple challenges,
the longer string is generated once and broken down into pieces, one piece
per algorithm.
So it might be just the unimaginative choice of examples, perhaps? Would
you say that for the purposes of the RFC8760 we are free to use different
nonce per each challenge? That would make implementation a bit easier and
secure I think.
Thanks!
-Max
On Thu, Oct 31, 2019 at 3:43 PM Rifaat Shekh-Yusef <rifaat.i...@gmail.com>
wrote:
> Hi Maxim,
>
> I will address the first comment in the next version of the document.
>
> With regards to the second comment, where do you see that RFC7616 requires
> that you use the same nonce for all alternatives?
>
> Regards,
> Rifaat
>
>
> On Thu, Oct 31, 2019 at 1:37 PM Maxim Sobolev <sobo...@sippysoft.com>
> wrote:
>
>> Hi, I am new here, so not sure what the proper process is, but there are
>> few comments I have with regards to the proposed RFC:
>>
>> 1. In the Abstract section there is a phrase "the broken MD5 algorithm". I
>> think "broken" might be a bit strong and emotionally charged. There is
>> nothing broken about MD5 as far as hashing algorithm is concerned. It is
>> proven to be not very secure in this day and age, but given the right
>> amount of time any today's algorithm would probably be in that category.
>>
>> 2. Would be nice to have some examples, especially WRT multiple
>> alternative algorithms. What I don't like about RFC7616 (which this RFC
>> builds upon), though, is that they appear to suggest using the same nonce
>> for all alternatives. Is it really required for the functionality or not?
>> For the same amount of network BW used, you may provide more random bits
>> and make attacker's life maybe a bit harder. Also, I am not a security
>> expert, but it appears intuitively correct that a hash function with a
>> longer output might require more salt bits, so you might actually save some
>> BW by supplying each algorithm with just the right amount of randomness
>> this way.
>>
>> Thanks!
>>
>> -Max
>>
>> On Thu, Oct 31, 2019 at 6:20 AM <internet-dra...@ietf.org> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Session Initiation Protocol Core WG of
>>> the IETF.
>>>
>>> Title : The Session Initiation Protocol (SIP) Digest
>>> Authentication Scheme
>>> Author : Rifaat Shekh-Yusef
>>> Filename : draft-ietf-sipcore-digest-scheme-14.txt
>>> Pages : 9
>>> Date : 2019-10-31
>>>
>>> Abstract:
>>> This document updates RFC 3261 by updating the Digest Access
>>> Authentication scheme used by the Session Initiation Protocol (SIP)
>>> to add support for more secure digest algorithms, e.g., SHA-256 and
>>> SHA-512-256, to replace the broken MD5 algorithm.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-14
>>> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-14
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-14
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipc...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>
>>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
