[SR-Users] MD5 and SHA-256 instead of MD5 or SHA-256...

[Maxim Sobolev]

On Thu, Jun 18, 2020 at 1:42 AM Olle E. Johansson <oej at edvina.net> wrote:

>
>
> On 17 Jun 2020, at 17:22, Maxim Sobolev <sobomax at sippysoft.com> wrote:
>
> Whoever works on this needs to consider two things I think:
>
> - ability to select algorithms when challenging UAC (MD5-only,
> SHA256-only, SHA-512/256-only, all permutations). The RFC allows UAS to
> include multiple HFs(*).  MD5-only should probably be the default. I
> suspect there might be a significantly non-trivial population of UACs that
> would get confused receiving multiple digests. Plus enabling challenges for
> all protocols would expand the size of 401s messages.
>
> Agree, multiple challenges will break stuff. I’m not sure that
> implementations actually bother with parsing the algorithm parameter.
>

Sad but true... Checked some of my implementations and not all of them do.

> - ability to accept response in either of supported hashing methods or any
> combination of thereof. The reasonable default here is probably MD5-only
> for now, again to prevent the possibility of foul play when we only request
> MD5, while for some reason getting say SHA-256 back.
>
> If you challenge with SHA512 only, you should not accept anything else.
>

Right, this is what I am trying to say. Some complications here, namely how
do you tell in practice what you have challenged the last transaction with
when presented with a particular new request? Impossible in the stateless
mode, won't work in the transaction mode (this is a new transaction), and
dialog won't help either (no dialog at this point). When the RFC was
discussed I suggested the need to expand upon HTTP RFC7616 to allow
different nonces for different algorithms which might allow it to be
possible and also improve overall security by giving more random bits to
more advanced digests. However I got a response that authors trust all
decisions made by RFC7616 and don't see any need to improve over that. :(

The only recourse I see with this is to either do some pre-selection based
on *whatever* (user-agent, IP, etc) and then challenge/process requests
with different but matching flags or store some inter-transaction  state
somewhere and work from there.

-Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200618/1f203932/attachment.html>