[sr-dev] Using auth module with SHA-256 instead of MD5

[Huber Andreas]

Hello,

We would like to adapt the "auth" module to allow digest authentication that uses a different hashing algorithm (SHA-256 instead of MD5). We use the auth module together with the "auth_db" module.
I identified the following changes that would be required for this feature:

1. The field algorithm=SHA-256 must be present in the "WWW-Authenticate" and "Proxy-Authenticate" headers to indicate the custom algorithm
e.g. WWW-Authenticate: Digest realm="realm.test", nonce="VzMh7lczIMKzhKh2gFjSnAnufvKupxx0B3JSSoA=", qop="auth", algorithm=SHA-256

2. The rfc2617.h/c files must be duplicated and adapted to use SHA-256

3. A SHA-256 hash value is twice as long as a MD5 hash value. So we must make sure that large enough char arrays are allocated to hold hash values.
It looks like this is no problem for the auth_* modules because they use char[256] for the ha1 hash values. The HASHHEX which is char[33] seems only to be used inside the auth module itself.


I thought of some possible solutions and we would like to get a feedback if any of these could make it into the official kamailio version and which one you would prefer:


Solution A: Add SHA-256 capabilities to module "auth" :
Add a module parameter "algorithm" that allows configuring "SHA-256" instead of "MD5" (which would be the default value).
Add SHA-256 versions for the functions calc_HA1 and calc_response (similar to rfc2617.c/h) and add two function pointers that can either point to the MD5 or SHA256 implementations, depending on the config.
Use the function pointers in the functions auth_s, auth_check_response and pv_authenticate where calc_HA1 or calc_response are used.
In the function auth_check_response replace HASHHEX allocated on the stack by char[65] or char[256] and compare the length of the credentials provided by the client dynamically depending on the config (32 for MD5, 64 for SHA-256).
Provide the configured algorithm to the two calls to get_challenge_hf to build the challenge header field with the desired algorithm.


Solution B: Add a new module "auth_sha256" that 'extends' the module "auth"
The idea of this solution is to put any sha256 specific code in a separate module while reusing most of the other code from the auth module.
As in solution A, the auth module would use some function pointers for the calc_HA1 and calc_response functions.
But instead of a configuration value, these function pointers could be initialized in mod_init depending whether the auth_sha256 module is available or not. (e.g. the module auth could call  a function in the module auth_sha256 similar to bind_auth_s to replace parts of its own api by SHA-256 specific functions.)


Solution C: Add a new module "auth_sha256" that is a duplicate of the module "auth", adapted for SHA-256
With this solution, no existing modules have to be modified, but more code has to be duplicated and maintained separately.



Kind regards,
Andreas Huber