[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Request header integrity in HTTP Digest
Hi,
May have missed some points in this thread. But let's not totally trash this
idea, creative usage of nonce values does indeed increase security. I think
this is stated in 2617, and this draft is exactly that, a creative usage of
nonce values.
But I have to agree with James on the fact, that ultimatelly, the same
threats present with digest are still present with pnonce. Hence, it doesn't
deliver the goods it promises, which is integrity of headers.
Br,
Aki
> -----Original Message-----
> From: ext James Undery [mailto:jundery@ubiquity.net]
> Sent: 26 June, 2001 10:58
> To: Jonathan Rosenberg
> Cc: sip@ietf.org
> Subject: Re: [Sip] Request header integrity in HTTP Digest
>
>
>
>
> 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
>
_______________________________________________
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