RE: [Sip] Request header integrity in HTTP Digest

[Corey Gates <corey@hearme.com>]

Jonathan Rosenberg wrote:

>
<<SNIP>>
> 
> It solves all three replay attacks presented section 2. It won't solve the
> MITM attacks if the attacker is smart and is careful about modifying the
> request in the same way between the original one and resubmitted one. 

> If you believe if doesn't solve the problems it claims to, please indicate
> clearly, for the three replay attacks, how these are not prevented by the
> mechanism, even though I claim they are.
>

I agree that the three specific replay attacks as described in the document
are mitigated with the use of pnonce.  Note that they are also mitigated
using standard 2617 nonces if the server rejects previously used nonces
during the timespan of the nonce, but this is not as nice.  

The problem I have is that a small modification of the replay attacks are
possible if the "private-key" is not included.  This small modification is
to get the client to authorize a "pnonce" the attacker generates, which can
then be used later.  Since there is no "private-key" included in the hash,
the server does not know that the pnonce was generated by the attacker.
This fake pnonce could include the headers and source IP that the attacker
wants to use.  Note that this is NOT a MITM attack, because the attacker
needs only to elicit an authorized INVITE or REGISTER from the UAC, not
intercept/forward a transaction.  This could be done by sending a
constructed 401 as soon as the attacker sees any message leaving the UAC.  

By adding the "private-key" to the pnonce generation, the attacker must
guess the "private-key" in order to generate the pnonce, making this
modified replay attack more difficult.

>
<<SNIP>>
> 
> Utter nonsense. Corey pointed out that the nonce should include a private
> key so that its not guessable. Guessing it doesn't help you terribly much,
> but fine, we'll do that. The same issue arises with regular digest. 
> 
> I claim that this approach improves security, since it removes replay
> attacks that require modification of the message. An example is modifying
> the Contact in a REGISTER to route calls to my phone. Regular http digest
> doesn't protect against this. The pnonce does. So, if you still believe
that
> pnonce is useless, please argue that:
> 
> 1. I am incorrect, and this attack is not possible with digest, or
> 2. I am incorrect, and this attack is possible with digest, but still
> possible in my proposed approach.
> 
> Continuously throwing out attacks that are still possible with pnonces
> proves nothing, and only shows that you continue to miss the point. It
only
> proves that digest, with or without pnonce, are susceptible to these. I
have
> offered, in the doc, three CONCRETE replay attacks that are prevented with
> pnonces. If you believe that this mechanism makes things worse, please
point
> out a concrete attack which is not possible in regular digest, but is now
> possible with pnonces. If you cannot offer such an attack, then your
claims
> that it fixes nothing are bogus.
>

I was trying to point out that fake pnonces are possible without the use of
the "private-key" as specified in 2617.  

Note that the draft could potentially be as simple as saying that the "ETag"
field used in generating nonces in 2617 is replaced with "<canonized header
values>" and be done with it.  This would be clear and understandable.
pnonces are simply a method of assigning a resource tag to a transaction set
and otherwise follow 2617.  Obviously this means that most of the attacks
presented in 2617 are the same and still there.  Now, however, it easier for
the server to reject bad nonces without having to store them for a time.

I think this is a good idea and a helpful draft.  I simply want to keep the
nonce generation par with 2617, so we need to include "private-key" in the
pnonce generation.

Corey Gates

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip