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: Thursday, June 21, 2001 3:40 AM
> > To: Jonathan Rosenberg
> > Cc: aki.niemi@nokia.com; corey@hearme.com; sip@ietf.org
> > Subject: Re: [Sip] Request header integrity in HTTP Digest
> >
> >
> > > 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.
>
> 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.

You selected only cases this works for, failed to mention the myriad of
cases it
is no use at all for. By dumbing down the attacks you protect yourself from
security is easy, why not have a Forged header that attackers have to set to
true and claim you can find all forged messages that are SIP complient ;)

>
> > 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.
>
> I am missing your point here. SIP digest is identical to http digest.
>

SIP and HTTP share a lot of the same headers, request response model
granted,
but these similarities shouldn't fool you into thinking that the protocols
are
similar. Transactions in SIP and HTTP are totally different in nature, a
security model for one does not map to a security model for the other.

>
> >
> > >
> > > 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?
>
> Common scenario? It only works when the UA sends a Contact: * Expires: 0
and
> the re-registers with new contacts right away.

Clearing the old registrations and moving to a new location isn't a common
scenario?

> Doesn't seem that frequent a
> case at all. When would this happen in practice? The mechanism will not
> protect you from attacks where the attacker replays (but doesn't modify)
the
> request. That is a subset of the attacks possible with digest, where you
can
> replay modified requests.
>
> > I think if worsens it as Corey pointed out (and I totally
> > missed even when
> > he
> > did).
>
> Utter nonsense. Corey pointed out that the nonce should include a private
> key so that its not guessable. Guessing it doesn't help you terribly much,
> but fine, we'll do that. The same issue arises with regular digest.
>

What Corey pointed out was a rouge poxy can request a UA to register using a
nonce that it knows a second proxy will give it at some time in the future
(of
the rouge proxies choosing). If you think that is nonsense we might as well
stop
discussing any security now.

>
> I claim that this approach improves security, since it removes replay
> attacks that require modification of the message. An example is modifying
> the Contact in a REGISTER to route calls to my phone. Regular http digest
> doesn't protect against this. The pnonce does. So, if you still believe
that
> pnonce is useless, please argue that:
>
> 1. I am incorrect, and this attack is not possible with digest, or
> 2. I am incorrect, and this attack is possible with digest, but still
> possible in my proposed approach.

As pointed out before UA sends a REGISTER with contact X. Bad Guy changes X
to Y
and proxies on the request, the registrar 401 with contact Y encrypted into
the
nonce. Bad guy proxies on this response, UA sends a REGISTER with Contact X
and
credentials for Contact Y in the nonce. The bad guy changes X to Y and
forwards
to the registrar with the credentials provided by the UA. The registrar
accepts
the registration with contact Y.


>
> Continuously throwing out attacks that are still possible with pnonces
> proves nothing, and only shows that you continue to miss the point. It
only
> proves that digest, with or without pnonce, are susceptible to these. I
have
> offered, in the doc, three CONCRETE replay attacks that are prevented with
> pnonces. If you believe that this mechanism makes things worse, please
point
> out a concrete attack which is not possible in regular digest, but is now
> possible with pnonces. If you cannot offer such an attack, then your
claims
> that it fixes nothing are bogus.

UA registers with Bad guy, bad guy constructs a pnonce it knows a registrar
will
construct in an hours time using its IP address, headers the server will
protect
and the round time an hour in the future. The UA authenticates this and in
an
hour the bad guy replays the message and authenticates with the credentials
the
UA provided an hour ago.

But submitting a draft that doesn't mention you are only protected from
these
specific attacks but not more sophisticated ones youI haven't mentioned
provides
the reader with a false sense of security. This is far worse than just
pointing
out the limitations. Selling snake oil will do SIP security no favours.

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