RE: [Sip] Request header integrity in HTTP Digest

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

> -----Original Message-----
> From: Corey Gates [mailto:corey@hearme.com]
> Sent: Thursday, June 21, 2001 4:55 PM
> To: 'Jonathan Rosenberg'; 'sip@ietf.org'
> Subject: RE: [Sip] Request header integrity in HTTP Digest
> 
> 
> 
> 
> 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.  

Right, and I point this out in the draft.

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

I agree completely. The lack of a private-key was not a statement that I
didn't think it should be there, but rather an omission. The idea is to add
a few more things to the nonce, not to remove some.

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

Another way of saying the same thing, sure.

>  This would be clear and understandable.
> pnonces are simply a method of assigning a resource tag to a 
> transaction set
> and otherwise follow 2617. 

Correct. Thats why I have said its an implementation choice and not a
protocol change.

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

Agreed. Thanks for your helpful comments.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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