> > So in that case, the implementation guideline for an UA set for both > methods would be to first try with the strongest algorithm, then upon > reception > of a 401/407 to that one, test with the next one in list until it is > out of > algorithms in which case the 401/407 means that the password is indeed > wrong. > > The UA could also, as you point out, send all headers at once to make it > a quicker round-trip, but doing it that way would also expose the > weaker MD5 > hash which we want to avoid. > > Thanks for your replies, Dale. This seems easier than expected. Anyone > else > that sees any caveats or issues?
I fear I can only agree partially. To me it seems that you are only seeing the upgrade path from the server side: the server simply supports multiple, not to say all, hash or authentication algorithms and advertises all of them. And you are missing an possible attack in your current proposal (see below). If we remove the current restriction of only one madatory hash algorithm for everybody we will, or at least might, have implementations with multiple hash algorithms. And in worst case both implementations will not have a common subset. We already have a similar problem with AKA vs. MD5 in IMS (which is caused by differences between implementations and specifications - but that is a different story). Don't get me wrong: I totaly agree that we should look for alternatives to MD5. But I think if we take that road we should consider some mechanism which allows UAC and UAS to advertise and agree (?) on the most preferred algorithm for the authentication. And I guess it should be mandatory that this mechanism prevents that an attacker can modify the message exchange in a way that the weakest algorithm is chosen (which is the case with current proposed solution). Greetings Nils Ohlmeier _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
