Re: Implementing SHA digest auth (new topic)

2 jan 2009 kl. 17.27 skrev Dale Worley:

> On Fri, 2009-01-02 at 17:17 +0100, Johansson Olle E wrote:
>> 2 jan 2009 kl. 16.34 skrev Dale Worley:
>>
>>> On Tue, 2008-12-30 at 21:30 +0100, Johansson Olle E wrote:
>>>> Also: How can we move away from MD5 digest auth?
>>>
>>> The authentication headers all allow the algorithm to be  
>>> specified, so
>>> we can convert to SHA1 fairly straightforwardly.  But the current
>>> attack
>>> benefits from the fact that one can spend hours synthesizing a
>>> certificate.  I doubt one could attack a SIP session setup fast  
>>> enough
>>> to be useful with reasonably-priced hardware.  But that will come  
>>> with
>>> time...
>>
>> We need some implementation guidelines for doing this. How do we
>> respond to an MD5 auth request we don't accept?
>>
>> If for some strange reason, I want to support both old MD5 UA's and
>> new SHAx UA's - how do I indicate both?
>>
>> We propably need some test code and test scenarios here.
>
> There isn't any negotiation mechanism for auth algorithms.  But if you
> generate both, you could include two auth headers for your realm, one
> with 'algorithm=MD5' and one with 'algorithm=SHA1'.
>
> Of course, we have yet to define the details of the header with
> 'algorithm=SHA1'.
Might as well define all SHA's at the same time and prepare for new
algorithms as well. The HTTP digest auth RFC doesn't really mention
much about this. My experience from SIPit tests tells me we need very
detailed guidelines for developers as well as test suites, reference
implementations, to test with in order for any change to happen.
>
>
> The current method of rejecting the use of any particular  
> authentication
> system is for the UAS to ignore the auth header generated by that
> system, which usually results in the UAC receiving a 401/407  
> response to
> a request which carries all the credentials the UAC is prepared to
> attach to the request.  So the UAC gives up on the request (and  
> returns
> the 401/407 to the application layer).

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?

/O
_______________________________________________
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