[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: 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.
>
> > 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.
I am missing your point here. SIP digest is identical to http digest.
>
> >
> > 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. 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.
>
> > 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.
I agree that the ultimate mechanism will make sure the client knows what it
is authenticating. Digest, both HTTP and SIP (as they are the same) doesn't
work this way.
>
> > 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).
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.
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.
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.
-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