RE: [Sip] Request header integrity in HTTP Digest

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, June 19, 2001 7:56 AM
> To: aki.niemi@nokia.com
> Cc: corey@hearme.com; jdrosen@dynamicsoft.com; sip@ietf.org
> Subject: Re: [Sip] Request header integrity in HTTP Digest
> 
> 
> 
> 
> aki.niemi@nokia.com wrote:
> 
> > Hi,
> >
> > > Corey Gates wrote:
> > >
> > > > Jonathan,
> > > >
> > > > I believe you left out the "private-key" in the nonce 
> computation in
> > > > draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:
> > > >
> > > > nonce = H(source-IP:<canonicalization of headers to be
> > > > protected>:round-time:private-key)
> > > >
> > > > Without this the nonce could be generated.
> > >
> > > I fail to see what you've gained by hashing the password into
> > > the nonce,
> > > the nonce is only really
> > > there so the server can be sure the client's messages aren't
> > > just being
> > > replayed, the client will hash in the password to provide
> > > authentication. (Obviously this explanation is very simplistic.)
> >
> > As in RFC 2617, I think what was meant here was, that the 
> private-key is
> > just some data only known to the server and not the shared secret
> > (password).
> >
> > I think this would also make sense for pnonce, since otherwise all
> > information contained in the hash can readily be found from 
> the message
> > itself.
> 
> True although is only a suggestion for nonce generation, and digest
> authentication is quite weak.  The real problem with this 
> draft is it is
> just plain broken. 

The only thing thats broken is your perception of the problem being solved.

Your gripe is with the authors of rfc2617, not me. Please feel free to send
them a note saying that rfc2617 is "just plain broken". They may be
offended, but they will probably have to agree with you that the problem you
describe exists. The problem is not a problem with this draft, its a problem
with digest, and is not fixed by this draft. Digest provides weak security,
no doubt. The right way to ultimately fix it is to have a nice, fully scoped
out, shared secret and/or public key encryption/authentication mechanism.
But, we don't have that right now. 

The mechanism described in the draft provides a level of security that is
better than digest. It fixes some of the most horrible and easiest to launch
attacks (especially the replay ones). It doesn't fix all of them, including
the MITM attack you describe. However, the cost for this fix is *zero*,
since it requires no changes in the specs or client behaviors. It is an
implementation choice for the server, and the decision to use it can be made
independently for each transaction in each server, without impacting any
other devices. The only reason why it even needs to be discussed at all is
that it is best served by a one-liner in the SIP spec that says you
shouldn't generally change the SIP message between the initial request and
the new request with credentials. Not that anyone actually does change the
headers that are being protected, as far as I know, but its nice to just say
it.

So, to be clear, I am not proposing that this is the be-all and end-all of
security. It is, IMHO, a very elegant and simple fix that improves the
performance of digest significantly beyond where it is now. 

-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