Re: [Sip] Request header integrity in HTTP Digest

[James Undery <jundery@ubiquity.net>]

Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> >
> > But I have to agree with James on the fact, that ultimatelly, the same
> > threats present with digest are still present with pnonce.
> > Hence, it doesn't
> > deliver the goods it promises, which is integrity of headers.
>
> I will back down on the statement that it provides header integrity,
because
> of the MITM attack that I agree is still possible.
>

Well now it'll be time to admit I also quite like this idea (and playing
Devils
Advocate), although I would remove the source-IP field (farms of stateless
proxies combined with IP spoofing make this of doubtful worth), add a
private
key, put a copy of N inside the hash to prevent tampering and use a
time-stamp
in a similar way to better control granularity. e.g.

nonce = H(private-key ":" <headers to protect> ":" N ":" time-stamp) "." N
"."
time-stamp

which would prevent replays at an arbitrarily fine level (rather than a
minute)
make the nonce unguessable with the private key, allow simple checking of
the
time-stamp before checking the hash and provide integrity for the time-stamp
and
N.

>
> However, it prevents against replay attacks which modify protected header
> fields. These attacks can also be prevented with one time nonces. I will
> agree that the approach cannot prevent any attacks that are prevented by
> one-time nonces in rfc2617. But as the draft points out, one time nonces
> require state in the server between the original request, and the new
> request with credentials. As a result of this, the server becomes amenable
> to DoS attacks since it stores state for unauthenticated requests. The
> proposed mechanism, which is well within the spirit of rfc2617, which
allows
> for creative nonces as Aki has pointed out, provides the same benefits as
> one time nonces without the cost of state.

I'd also be a bit careful making this DoS claim, the authentication state is
going to be minimal and large tags and Call-IDs could soon make up the
difference.

James Undery


_______________________________________________
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