[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Request header integrity in HTTP Digest
> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Friday, June 22, 2001 3:45 AM
> To: Jonathan Rosenberg
> Cc: aki.niemi@nokia.com; corey@hearme.com; sip@ietf.org
> Subject: Re: [Sip] Request header integrity in HTTP Digest
>
>
> > 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 ;)
You are still missing the point.
My point is *not* that it fixes all problems. My point is that it fixes some
problems that regular digest has, and doesn't introduce any new security
weaknesses. In that case, how can one possibly object to it?
>
> >
> > > 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.
Really? SIP references HTTP Basic and digest directly, since they are
directly useful in SIP. If the security models were not compatible, how
could we do this?
>
> > 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.
James, this attack is possible in regular digest if you don't do the same
thing Corey suggests. Thus, your point is utter nonsense since you are
trying to argue against the mechanism based on general digest issues that
are not specific to the proposal at all. As I said, send a complaint to the
authors of rfc2617.
>
> >
> > 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.
Sigh. I don't know how much clearer I can be. Perhaps if I try e-shouting.
THE ATTACK YOU DESCRIBE IS POSSIBLE IN REGULAR DIGEST!!!!! This attack is
not fixed by the pnonce and still exists there. I am not claiming that this
mechanism fixes all the problems in digest. I am claiming that it is better
than digest. I am claiming that because it fixes some attacks present in
regular digest, and introduces no new ones. So, your objections are
completely nonsense unless, as I requested above, you can demonstrate an
attack that is not possible with regular temporal-based + private key nonces
(i.e., nonce = H(round-time:key), but is present in a nonce that is
temporal-based + private key and includes a hash of some request headers
(i.e., a pnonce = H(round-time:key:request-headers)).
>
>
> >
> > 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.
Well, there is one problem here, James. This attack is also possible in
regular digest if you use a nonce that is based on time rounded to the
nearest hour. Put a private key in the nonce, and it fixes this problem in
any challenge response mechanism, including the pnonce. My apologies for
leaving off the private key from the hash in the document. As I already
responded to Corey's original mail, he is correct and that security is
improved if its there. THats true for plain-old digest as well.
>
> 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.
There is a difference between claiming the draft doesn't mention problems
that remain, and claiming that the mechanism is worthless. You have accused
me of foolishness by proposing a worthless mechanism that makes security
worse. I claim that you are completely wrong, and that this mechanism fixes
many important attacks, yet introduces no new ones. So, do you, or do you
not, claim that this mechanism worsens security compared to more traditional
nonce computations?
-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 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