Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA

Hi Greg and thanks for your response. Some
further discussion below.

>> What I understood James proposing is that *if* AKA is used for the
>> authentication of an INVITE to the home after being used for 
>> authenticating
>> a REGISTER, then AKA should be re-run.
> 
> Yes, in theory that would be fine, but I did not get this from my 
> reading of draft-undery. It appears to me that it uses the same A1 that 
> was calculated during the processing of the register message, in the 
> subsequent step.

This may be true, but draft-undery doesn't deal with AKA. Draft-niemi
does. If you meant draft-niemi, then we should fix it (it shouldn't
do that).

> It helps but it doesn't completely solve the problem. Whatever the 
> process by which RES (old *or new*) is used to calculate the 
> authentication values, can be used by a man-in-the-middle:
> 1. Mal gets the SIP message, and blocks its onward delivery.
> 2. He quickly sets his lab of computers to the task of finding 32-bit RES.
> 3. Before the reply timer expires, he can create any message he wants, 
> and authenticate it using that value of RES, even though it is only used 
> once.
> 
> Note that even a 64-bit RES probably defeats this.

Fair enough, I suspected that this might be the case.
But a further question. Assuming a MD5(RES) is crackable
and the MitM can send his own request, why isn't pure RES
crackable in the same way? That is, if we send just the
RES, the MitM can just pick the value and without any lab
computers he can place the RES in a different request, and
the server side can't detect anything. So, while I understand
the attack, what does removing MD5 encapsulation give us?

>> Also, I have proposed simply requiring 128 bit RES values to be used,
>> that solves the problem but is there any reason why we couldn't require
>> it?
> 
> I had understood that there were compatibility issues with this, but 
> that is a question for operators to answer... I don't know. Anyway, I'd 
> be perfectly happy if that was done; all my objections would go away.

Ok, let's try to figure this question out then.

Jari

_______________________________________________
Sip-security mailing list
Sip-security@ietf.org
https://www1.ietf.org/mailman/listinfo/sip-security