Re: [Sip] Request header integrity in HTTP Digest

[James Undery <jundery@ubiquity.net>]

Jonathan Rosenberg wrote:

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

That's exactly what I was getting at this approach will never solve the
problems
it claims to.

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

HTTP is totally different from SIP I have no problem at all with that draft
Section 4 is very clear about the limitations of the draft.

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

UA sends a "Contact: *",  "Expires: 0" REGISTER request and authenticates
it.
Bad guy sniffs the authenticated register
UA then sends the new contacts for the user.
Bad guy then replays the first message with an incremented CSeq quickly.

Common scenario, simple attack how does you draft help?

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

The whole point is to better secure digest authentication the UA needs to
include important headers and the server supplied nonce hashed in the
credentials, so the UA knows exactly what it is authenticating. This still
leaves all the problems of digest authentication but puts SIP on a similar
level
to HTTP.

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

I think if worsens it as Corey pointed out (and I totally missed even when
he
did). IMHO it is a simple fix to very little, although an important area for
the
WG to investigate, and as I've said before I think a new type of
authentication
based on HTTP digest authentication but tailored for SIP is important.

James Undery


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