Subject: [Sip-security] Re: [Sip] SIP Negotiate

From: "Jari Arkko" <[email-masked]>
Date: Mon, 3 Sep 2001 21:51:23 +0300

RE: [Sipping] SIP Negotiate
I agree that there is a need for this kind of functionality. However,
when you say in the beginning "Examples of parameters that
... include ... message integrity mechanisms, encryption
algorithms, etc.", I'd like to note that this what we need in
terms of security parameters is a _secure_ negotiation of them.
As you say yourself in section 10.1 of
http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt :

> One of the intended uses for the negotiation mechanism is to set
> up authentication and message integrity algorithms. Thus the 
> NEGOTIATE method itself is not subject to these protections - this
> makes the recipient vulnerable to the Man-in-the-middle attacks. 
> Views are solicited to mitigate this security consideration.

This is a crucial point to handle correctly. Otherwise the peers
may be fooled onto using insecure algorithms or perhaps even
no algorithms at all. It is also interesting to note that the answer
can't really be "integrity protect the NEGOTIATE" because
that would mean an integrity protection algorithm would have
to be applied before one is selected!

We've done some work on this issue earlier in the context of
SIP usage in 3G networks, and came up with some requirements.
These included the following:

* MUST be able to choose different integrity algorithms,
  MAY be able to choose other security parameters,
  encryption algorithms, and security protocols.
* It MUST be possible to protect the parameter negotiation
  against attackers who do not have the secret authentication
  keys (and can't forge hashes in real-time).
* MUST not add new roundtrips (i.e. done in parallel with
  other setup such as registration or authentication). In particular,
  it would not be nice if we had separate negotiation phases for security,
  compression, sip itself, and only then we'd be able to do
  something.

Traditionally, security protocols have solved secure negotiation
of parameters by hashing/signing the offers with authentication
keys or keys derived from authentication. For instance, IKE
negotiates parameters in cleartext but in a later phase a keyed
hash is taken from the original parameter offers and responses,
and sent to the other side as a proof that nothing was changed in
the packet's path.

Something similar needs to happen here as well. We've had
the idea that once integrity protection can be turned on, you'll
repeat the offers under it, and only after this you can start to
trust and use what was negotiated. (Integrity protection can be
turned on basically after something has given you keys
and you have agreed on the selected algorithm.)

Jari Arkko
Ericsson

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

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 8 Sep 2001 08:06:24 +0300

Sriram writes:

>** As far as message integrity goes, yes I am talking about SIP 
>level message integrity. Choosing a baseline algorithm is definitely 
>easier. But then you are defeating the flexibility of SIP (which was 
>one of the original goals of the protocol correct?)

Jonathan's proposal of choosing a baseline algorithm would be the
easiest way. But I'm afraid that as we talk about security, the ability
to change algorithms will be a requirement. One reason for this is
that algorithms could be broken and other ones would have to be
used thereafter. Secondly, algorithms development will introduce
new algorithms with different characteristics, and people want to
take advantage of this. (All security protocols seem to offer this
functionality in one way or another, even, say, HTTP Digest.)

Jari

---

From: "Sriram Parameswar" <[email-masked]>
Date: Tue, 18 Sep 2001 10:49:07 -0500

Jari:

Sorry for the delay - please see inline. 

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Monday, September 03, 2001 1:51 PM
To: Parameswar, Sriram [NGB:B658:EXCH]; sip
Cc: jari.arkko; Valerius, Lee [RICH2:2H12:EXCH]; tiina.s.koskinen;
sip-security
Subject: Re: [Sip] SIP Negotiate

[Sriram] One way around this is to ensure that the UA is authenticated
post NEGOTIATE - the authentication algorithm being one of the items
being negotiated. This would diminish the chances of a MITM attack.
Also the message post negotiate may be integrity protected which
is further strengthens security. This of course would require
keys to be sent back in the response to the NEGOTIATE. The
combination of authentication and message integrity would be
good solution to MITM attacks.

* MUST be able to choose different integrity algorithms,
  MAY be able to choose other security parameters,
  encryption algorithms, and security protocols.
[Sriram] Met by NEGOTIATE
* It MUST be possible to protect the parameter negotiation
  against attackers who do not have the secret authentication
  keys (and can't forge hashes in real-time).
* MUST not add new roundtrips (i.e. done in parallel with
  other setup such as registration or authentication). In particular,
  it would not be nice if we had separate negotiation phases for security,
  compression, sip itself, and only then we'd be able to do
  something.
[Sriram] NEGOTIATE does add one more roundtrip however so does sending
in a REGISTER and having a 401 challenge. The advantage of NEGOTIATE
is that several different meta-session parameters can be negotiated
at the same time.

Jari Arkko
Ericsson