Subject: Re: [Sip] News article on CA impersonation attack

From: "Dale Worley" <[email-masked]>
Date: Fri, 02 Jan 2009 10:34:04 -0500

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...

Dale

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Johansson Olle E <[email-masked]>
Date: Fri, 2 Jan 2009 17:17:02 +0100

> to be useful with reasonably-priced hardware.  But that will come with

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.

/O

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 02 Jan 2009 11:27:13 -0500

> 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'.

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).

Dale

---

From: Johansson Olle E <[email-masked]>
Date: Fri, 2 Jan 2009 17:45:36 +0100

> Of course, we have yet to define the details of the header with
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 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

---

From: "Dale Worley" <[email-masked]>
Date: Sun, 04 Jan 2009 11:24:30 -0500

On Fri, 2009-01-02 at 17:45 +0100, Johansson Olle E wrote:
> 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.

I don't see why you'd want to have a multiple-try algorithm -- if you're
willing to send the MD5 hash at all, you should send it the first time.
Otherwise you're just adding round-trips before you send the MD5 hash.

> weaker MD5 hash which we want to avoid.

We actually haven't resolved the question whether using MD5 *exposes*
your key.  As far as I can tell, what's been shown is that *trusting* an
MD5 is not a good idea.  But I'm not a crypto expert.

Dale

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Tue, 6 Jan 2009 15:33:34 +0100 (CET)

> 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

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Tue, 6 Jan 2009 16:27:33 +0100 (CET)

> MD5 is not a good idea.  But I'm not a crypto expert.

I'm not a crypto expert either but I think it is a good idea to be
prepared to replace MD5 whenever we will have to do it. And as such a
replacement takes time until it reaches the end user it would be better to
start early.

Just my 2 cents
  Nils