Subject: [Sip] Request header integrity in HTTP Digest

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 08:51:02 -0400

Folks,

I've just submitted a new I-D to the archives. It proposes a mechanism that
allows HTTP Digest to provide request header integrity. This means that the
server can verify that the request was sent by a specific party, and that
certain header fields, such as the To, From, Contact, and Call-ID, were not
altered.

Amazingly, the proposal requires no protocol changes in the way HTTP Digest
works, nor does it require any change in the behavior of clients. It is
purely a server implementation choice. I call the proposed approach
"predictive nonces", as its based on a computation of the nonce based on a
prediction of the values of specific invariant headers in the resubmitted
request (namely, that they are unchanged from the original request that is
being challenged). It also works for HTTP, but is less useful there. The
approach is totally stateless as well, unlike one time nonces, which are
not.

Until the draft appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-http-pnonce-00.txt

I think this will address some important security concerns raised on the
list, many of which are summarized in the draft.

Comments, questions, and criticisms welcome as always.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: James Undery <[email-masked]>
Date: Mon, 18 Jun 2001 06:53:37 -0400

> Comments, questions, and criticisms welcome as always.

There is a large and obvious flaw, this mechanism provides NO protection
against sophisticated man in the middle attacks. If the man in the middle
alters the first request and passes back the pnonce to the user who
authenticates it, when the man in the middle alters the second request it is
perfectly acceptable to the registrar. The backwards compatibility is
exactly
the thing that breaks this attempted solution.

On the subject of man in the middle attacks being to hard to launch, I'd
direct
you to the recent problems of SourceForge.net and Apache.org where an ISP
was
compromised leading to break ins on both these sites through man in the
middle
attacks.

James Undery

---

From: Corey Gates <[email-masked]>
Date: Mon, 18 Jun 2001 09:11:30 -0700

Jonathan,

I believe you left out the "private-key" in the nonce computation in
draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:

nonce = H(source-IP:<canonicalization of headers to be
protected>:round-time:private-key)

Without this the nonce could be generated.

Corey Gates

---

From: James Undery <[email-masked]>
Date: Tue, 19 Jun 2001 03:32:06 -0400

> Without this the nonce could be generated.

I fail to see what you've gained by hashing the password into the nonce,
the nonce is only really
there so the server can be sure the client's messages aren't just being
replayed, the client will hash in the password to provide
authentication. (Obviously this explanation is very simplistic.)

James Undery

---

From: [email-masked]
Date: Tue, 19 Jun 2001 14:26:46 +0300

Hi,

> authentication. (Obviously this explanation is very simplistic.)

As in RFC 2617, I think what was meant here was, that the private-key is
just some data only known to the server and not the shared secret
(password). 

I think this would also make sense for pnonce, since otherwise all
information contained in the hash can readily be found from the message
itself.

Br,
Aki

---

From: James Undery <[email-masked]>
Date: Tue, 19 Jun 2001 07:56:20 -0400

> information contained in the hash can readily be found from the message

True although is only a suggestion for nonce generation, and digest
authentication is quite weak.  The real problem with this draft is it is
just plain broken. To my mind it is also unfixable until backwards
compatibility is lost i.e. the client explicitly includes the required
headers in the credentials along with the server provided time stamp. Unless
this is done a MITM attack will always be possible. (Then again I could be
wrong about the fixability as security is a hard problem, not suited to the
amateur I am.)

James Undery

---

From: [email-masked]
Date: Tue, 19 Jun 2001 15:34:36 +0300

Jonathan,

This really sounds like a good idea.

However, the man-in-the-middle attacks discussed in the draft are still
viable in a scenario, where the server calculates the pnonce from an already
compromised set of headers.

For example, the REGISTER case with altered Contact: 

            UA               MITM             Server
            |--Contact------->|--ContactX------>|
            |                 |                 |  Calculates pnonce
H(header:ContactX)
            |<-401, pnonce----|<--401, pnonce---|
Calculates  |                 |                 |
credentials |                 |                 |
            |-Contact, cred.->|ContactX, cred-->|  Authentication passes,
                                                   Stores wrong Contact

I admit, these kinds of attacks are probably a little trickier to make, but
the main idea still has to fail, because the headers aren't included in the
integrity hash at the client's side. 

Of course, the client can produce a pnonce of its own (call it p-cnonce),
but this won't help either, since the server doesn't know how to integrity
check the headers with p-cnonce. Real integrity protection has to be based
on a shared secret between the server and the client.

But for some increase in integrity protection, this idea has merit. Also,
since pnonce is completely an implementation issue at the server side, it is
deployable.

Br,
Aki	

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 16 June, 2001 15:51
> To: [email-masked]'
> Subject: [Sip] Request header integrity in HTTP Digest
> 
> 
> Folks,
>

---

From: Corey Gates <[email-masked]>
Date: Tue, 19 Jun 2001 09:12:05 -0700

> wrong about the fixability as security is a hard problem, not suited to
the

I agree that the draft is broken with respect to MITM attacks.  But without
the private-key known only to the server, the nonce generation is also
broken such that an attacker can get a client to generate credentials for
nonces that can be used later, even when the client is offline and the
attacker is no longer in the "middle"!

Again, I agree that Man-in-the-Middle attacks are not addressed in the
draft.  I just don't want someone to go off and implement a nonce generation
scheme that is less secure then RFC 2617...

Corey Gates

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Jun 2001 16:03:54 -0400

> From: James Undery [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 7:56 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sip] Request header integrity in HTTP Digest
> 
> 
> 
> 
> just plain broken. 

The only thing thats broken is your perception of the problem being solved.

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. 

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

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. 

-Jonathan R.

---

---

From: James Undery <[email-masked]>
Date: Thu, 21 Jun 2001 03:39:50 -0400

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

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

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

> It doesn't fix all of them, including

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.

> 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). IMHO it is a simple fix to very little, although an important area for
the
WG to investigate, and as I've said before I think a new type of
authentication
based on HTTP digest authentication but tailored for SIP is important.

James Undery

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 12:41:47 -0400

> Sent: Thursday, June 21, 2001 3:40 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]; [email-masked]

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
> > offended, but they will probably have to agree with you 
> that the problem
> you
> > no doubt. The right way to ultimately fix it is to have a 
> nice, fully
> scoped

I am missing your point here. SIP digest is identical to http digest.

> > better than digest. It fixes some of the most horrible and 
> easiest to
> launch

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.

> > implementation choice for the server, and the decision to 
> use it can be
> made
> > headers that are being protected, as far as I know, but its 
> nice to just
> say
> > it.
> 

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.

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

---

From: Corey Gates <[email-masked]>
Date: Thu, 21 Jun 2001 13:54:38 -0700

Jonathan Rosenberg wrote:

<<SNIP>>

> mechanism, even though I claim they are.

I agree that the three specific replay attacks as described in the document
are mitigated with the use of pnonce.  Note that they are also mitigated
using standard 2617 nonces if the server rejects previously used nonces
during the timespan of the nonce, but this is not as nice.  

The problem I have is that a small modification of the replay attacks are
possible if the "private-key" is not included.  This small modification is
to get the client to authorize a "pnonce" the attacker generates, which can
then be used later.  Since there is no "private-key" included in the hash,
the server does not know that the pnonce was generated by the attacker.
This fake pnonce could include the headers and source IP that the attacker
wants to use.  Note that this is NOT a MITM attack, because the attacker
needs only to elicit an authorized INVITE or REGISTER from the UAC, not
intercept/forward a transaction.  This could be done by sending a
constructed 401 as soon as the attacker sees any message leaving the UAC.  

By adding the "private-key" to the pnonce generation, the attacker must
guess the "private-key" in order to generate the pnonce, making this
modified replay attack more difficult.

<<SNIP>>
> that it fixes nothing are bogus.

I was trying to point out that fake pnonces are possible without the use of
the "private-key" as specified in 2617.  

Note that the draft could potentially be as simple as saying that the "ETag"
field used in generating nonces in 2617 is replaced with "<canonized header
values>" and be done with it.  This would be clear and understandable.
pnonces are simply a method of assigning a resource tag to a transaction set
and otherwise follow 2617.  Obviously this means that most of the attacks
presented in 2617 are the same and still there.  Now, however, it easier for
the server to reject bad nonces without having to store them for a time.

I think this is a good idea and a helpful draft.  I simply want to keep the
nonce generation par with 2617, so we need to include "private-key" in the
pnonce generation.

Corey Gates

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: James Undery <[email-masked]>
Date: Fri, 22 Jun 2001 03:44:46 -0400

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

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

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.

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

> 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 01:59:31 -0400

> Sent: Friday, June 22, 2001 3:45 AM
> To: Jonathan Rosenberg

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?

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

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

> > doesn't protect against this. The pnonce does. So, if you 
> still believe
> that

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

> > 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
> > pnonces. If you believe that this mechanism makes things 
> worse, please
> point

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.

> out the limitations. Selling snake oil will do SIP security 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 02:07:28 -0400

> From: Corey Gates [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 4:55 PM
> To: 'Jonathan Rosenberg'; [email-masked]'
> Subject: RE: [Sip] Request header integrity in HTTP Digest
> 
> 
> 
> 

Right, and I point this out in the draft.

> constructed 401 as soon as the attacker sees any message 

I agree completely. The lack of a private-key was not a statement that I
didn't think it should be there, but rather an omission. The idea is to add
a few more things to the nonce, not to remove some.

> values>" and be done with it.

Another way of saying the same thing, sure.

>  This would be clear and understandable.
> and otherwise follow 2617. 

Correct. Thats why I have said its an implementation choice and not a
protocol change.

> nonce generation par with 2617, so we need to include 

Agreed. Thanks for your helpful comments.

-Jonathan R.

---

---

From: James Undery <[email-masked]>
Date: Tue, 26 Jun 2001 03:57:44 -0400

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

> directly useful in SIP. If the security models were not compatible, how

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.

> are not specific to the proposal at all. As I said, send a complaint to
the

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.

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

> not, claim that this mechanism worsens security compared to more
traditional

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

---

From: [email-masked]
Date: Tue, 26 Jun 2001 17:47:37 +0300

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

> From: ext James Undery [mailto:[email-masked]]
> Sent: 26 June, 2001 10:58
> To: Jonathan Rosenberg
> Cc: [email-masked]
> > My point is *not* that it fixes all problems. My point is 
> that it fixes
> some
> > are not specific to the proposal at all. As I said, send a 
> complaint to
> the
> > authors of rfc2617.
> >
> 
> > not fixed by the pnonce and still exists there. I am not 
> claiming that
> this
> > attack that is not possible with regular temporal-based + 
> private key
> nonces
> > worse. I claim that you are completely wrong, and that this 
> mechanism
> fixes

---

From: James Undery <[email-masked]>
Date: Tue, 26 Jun 2001 11:01:00 -0400

> this is stated in 2617, and this draft is exactly that, a creative usage
of

Unfortunately, the source-IP part is also suspect if the hop before the
server
is a farm of stateless proxies, but don't get me started on stateless
proxies
;-)

James Undery

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 18:18:40 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 10:48 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

I will back down on the statement that it provides header integrity, because
of the MITM attack that I agree is still possible.

However, it prevents against replay attacks which modify protected header
fields. These attacks can also be prevented with one time nonces. I will
agree that the approach cannot prevent any attacks that are prevented by
one-time nonces in rfc2617. But as the draft points out, one time nonces
require state in the server between the original request, and the new
request with credentials. As a result of this, the server becomes amenable
to DoS attacks since it stores state for unauthenticated requests. The
proposed mechanism, which is well within the spirit of rfc2617, which allows
for creative nonces as Aki has pointed out, provides the same benefits as
one time nonces without the cost of state.

In any case, its a local choice at the server, and need not be standardized.
If you think it won't help you, don't do it.

-Jonathan R.

---

---

From: James Undery <[email-masked]>
Date: Wed, 27 Jun 2001 05:10:56 -0400

> of the MITM attack that I agree is still possible.

Well now it'll be time to admit I also quite like this idea (and playing
Devils
Advocate), although I would remove the source-IP field (farms of stateless
proxies combined with IP spoofing make this of doubtful worth), add a
private
key, put a copy of N inside the hash to prevent tampering and use a
time-stamp
in a similar way to better control granularity. e.g.

nonce = H(private-key ":" <headers to protect> ":" N ":" time-stamp) "." N
"."
time-stamp

which would prevent replays at an arbitrarily fine level (rather than a
minute)
make the nonce unguessable with the private key, allow simple checking of
the
time-stamp before checking the hash and provide integrity for the time-stamp
and
N.

> one time nonces without the cost of state.

I'd also be a bit careful making this DoS claim, the authentication state is
going to be minimal and large tags and Call-IDs could soon make up the
difference.

James Undery