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
