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