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]
>
> 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?

It fixes no problems in regular Digest Authentication, that is the point,
replay
attacks don't exist if you allow the client to only use a nonce once before
it
goes stale.


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

Well I am in the process of writing a draft, I believe fixes HTTP digest so
it
works as well for SIP (i.e. it has only the same flaws as HTTP, but allows
the
server to check it is seeing what the client sent with the integrity of
relevant
headers intact.) A register request for instance requires the To, From,
Contact
and Expires headers remain intact for the integrity of the request. The big
problem is it will be a new scheme, requiring changes to servers and
clients,
something your draft doesn't require and the reason it adds nothing new (see
the
end of the message for the challenge if you think it does) .

I only hope people read it and tell me what it is I've missed, and as
security
is hard I know I'll have missed something.

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

If you choose to ignore their advice and break the nonce generation, it
states
Security Considerations the importance of a proper nonce. In fact my only
issue
with rfc2617 is the don't mention about removal or downgrading of the qop
parameter as a possible attack to interfere with the body of the request.

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

And all the protection you describe is possible with no modification of
rfc2617
just use it as is, your scheme increases the chance of legitimate clients
failing and solves nothing but the most half-hearted attacks, my point is
why
bother producing yet another ID for people to implement that adds minimal
value.

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

No, I am not claiming you introduce new weaknesses now you're fixed the
private-key issue, the problem is this draft does nothing plain old HTTP
digest
doesn't do, by saying I will protect against attack X and attack X is
defended
by the base spec being implemented properly, you are just reiterating the
original spec. As you point out all the attacks I describe are possible
against
regular HTTP digest.

The challenge for you is to provide a single case where you are protecting
against an attack possible in rfc2617 (I will be choosing to generate nonces
as
per section 4.3 of rfc2617 and making them go stale after one use ).

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