RE: [Sip] Request header integrity in HTTP Digest

[aki.niemi@nokia.com]

Jonathan,

This really sounds like a good idea.

However, the man-in-the-middle attacks discussed in the draft are still
viable in a scenario, where the server calculates the pnonce from an already
compromised set of headers.

For example, the REGISTER case with altered Contact: 

            UA               MITM             Server
            |--Contact------->|--ContactX------>|
            |                 |                 |  Calculates pnonce
H(header:ContactX)
            |<-401, pnonce----|<--401, pnonce---|
Calculates  |                 |                 |
credentials |                 |                 |
            |-Contact, cred.->|ContactX, cred-->|  Authentication passes,
                                                   Stores wrong Contact

I admit, these kinds of attacks are probably a little trickier to make, but
the main idea still has to fail, because the headers aren't included in the
integrity hash at the client's side. 

Of course, the client can produce a pnonce of its own (call it p-cnonce),
but this won't help either, since the server doesn't know how to integrity
check the headers with p-cnonce. Real integrity protection has to be based
on a shared secret between the server and the client.

But for some increase in integrity protection, this idea has merit. Also,
since pnonce is completely an implementation issue at the server side, it is
deployable.

Br,
Aki	

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 16 June, 2001 15:51
> To: 'sip@ietf.org'
> Subject: [Sip] Request header integrity in HTTP Digest
> 
> 
> Folks,
> 
> I've just submitted a new I-D to the archives. It proposes a 
> mechanism that
> allows HTTP Digest to provide request header integrity. This 
> means that the
> server can verify that the request was sent by a specific 
> party, and that
> certain header fields, such as the To, From, Contact, and 
> Call-ID, were not
> altered.
> 
> Amazingly, the proposal requires no protocol changes in the 
> way HTTP Digest
> works, nor does it require any change in the behavior of 
> clients. It is
> purely a server implementation choice. I call the proposed approach
> "predictive nonces", as its based on a computation of the 
> nonce based on a
> prediction of the values of specific invariant headers in the 
> resubmitted
> request (namely, that they are unchanged from the original 
> request that is
> being challenged). It also works for HTTP, but is less useful 
> there. The
> approach is totally stateless as well, unlike one time 
> nonces, which are
> not.
> 
> Until the draft appears in the archives, you can pick up a copy at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-sip-http-pnonce-00.txt
> 
> I think this will address some important security concerns 
> raised on the
> list, many of which are summarized in the draft.
> 
> Comments, questions, and criticisms welcome as always.
> 
> Thanks,
> 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
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
> 

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip