Thanks, Rifaat, much appreciated! I've updated my prototype and it looks good. We also tested it against at least 2 other implementations (Drachtio and SIP Vicious), it seems to be working fine.
https://github.com/sippy/voiptests/compare/9b7a2834f85a...d873e0e5d925 https://travis-ci.com/github/sippy/voiptests/builds/184406051 00:00:06.425/GLOBAL/alice_ua: RECEIVED message from [::1]:5060: SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP [::1]:5061;rport=5061;branch=z9hG4bK272b7d9aef9f739c5c8c58e8565ef5d6 From: "Alice Smith" <sip:alice_reinv_brkn2_ipv6@ [::1]>;tag=4PbL1QmzFx9`8QLo4IXj4hjBx043C_~m To: <sip:bob_reinv_brkn2@[::1]>;tag=2910bcde5c7c5672e713abe253de4ff5 Call-ID: rbw~`72E1w]R3/[ic/aKWo+/"T(_nd][@)[RihhbcZ_Od7ME` CSeq: 200 INVITE Server: Sippy B2BUA (RADIUS) WWW-Authenticate: Digest realm="[::1]",nonce="DWUGu6I99b7t1Z50P0iGA5VFM4qG7zQQZf4LlcoNAtw",qop=auth,algorithm=SHA-512-256 WWW-Authenticate: Digest realm="[::1]",nonce="gZQV8cmPFGxJq1GD3KaR5eu0mL8aS6MC1K3ZEYEaiQo",qop=auth,algorithm=SHA-256 WWW-Authenticate: Digest realm="[::1]",nonce="5hj5ZnW5Ml8sdFaQkYGkFpFRV4N/liv+EvorJQW8M34",qop=auth,algorithm=MD5 Content-Length: 0 -Max On Mon, Sep 14, 2020 at 6:29 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > Hi Maxim, > > See my reply inline below. > > Regards, > Rifaat > > > > On Mon, Sep 14, 2020 at 6:59 PM Maxim Sobolev <sobo...@sippysoft.com> > wrote: > >> FYI. rifaat.i...@gmail.com bounces... Thanks! >> >> -Max >> >> ---------- Forwarded message --------- >> From: Maxim Sobolev <sobo...@sippysoft.com> >> Date: Mon, Sep 14, 2020 at 3:51 PM >> Subject: RFC8760: Using different nonces for alternative algorithms [Was: >> [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-14.txt] >> To: Rifaat Shekh-Yusef <rifaat.i...@gmail.com> >> Cc: <sip-implementors@lists.cs.columbia.edu>, Olle E. Johansson < >> o...@edvina.net> >> >> >> 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. >> >> > I do not see any problem with the examples; notice that the above quote is > saying you need to generate a new nonce for each 401 response, not for each > scheme. > But there is nothing wrong with creating new and different nonces for each > scheme per challenge. > > Regards, > Rifaat > > > >> 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
