Subject: Re: Thomas versus 3GPP SIP security requirements (was: [Sip] SIP secu rity requirements (this might mean you!))

From: "Vesa Torvinen (LMF)" <[email-masked]>
Date: Fri, 7 Dec 2001 16:05:45 +0100

Sorry, Scott! 

I hope this version is easier to read. 

Vesa 

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> 
> can you resend this with line wrap on - this is very hard to read

-----Original Message-----

Hi Michael, 

You asked authors of different SIP drafts to compare their current security 
expectations with your SIP security requirement document. I have been analysing 
your work (draft-thomas-sip-sec-framework-00.txt and draft-thomas-sip-sec-req-
00.txt) and 3GPP security requirements (e.g. draft-garcia-sipping-3gpp-reqs-
02.txt) for some time, so I decided to write a comparison between them. Maybe 
this piece of work will make your task of capturing all possible requirements a 
little easier. 

Vesa 

--------------

SIP Security Requirement Comparison: Thomas versus 3GPP
Vesa Torvinen
Ericsson 

Abstract 

This paper discusses SIP security requirements. It takes the requirement 
analysis presented by Thomas (2001b) as a starting point and uses 3GPP IMS 
architecture to validate them. The paper concludes that the current 3GPP 
architecture seems to support directly or indirectly most of the requirements 
presented by Thomas. In general, 3GPP IMS architecture is able to verify 
security requirements at some SIP interfaces (i.e. UA-to-first-hop-proxy, End-
to-end and Non-adjacent-proxy-to-proxy interface), but more data on different 
system environments are needed in order to complete the requirement analysis. 
For example, more data on different SIP use scenarios on End-to-end, UA-to-
Intermediate-proxy, Adjacent-proxy-to-proxy and Non-adjacent-proxy-to-proxy 
interfaces are needed. There are also some requirements which are important for 
3GPP but which are not included in Thomas's requirement document. Requirements 
that are related to optimization, negotiation and delegation are among them. 

1. Introduction 

SIP Security work is currently re-emerging in IETF. Some SIP security related 
frameworks and general solutions has been published recently (e.g. Thomas 2001a, 
Schulzrinne 2001). Also some discussion on SIP security requirements has taken 
place in different SIP mailing lists, as well as in different documents (e.g. 
Thomas 2001b, Garcia et al. 2001). 

This paper discusses the general SIP security requirements. It takes Thomas 
(2001b) work as a starting point and compares its requirements with 3GPP SIP 
security requirements (Garcia et al. 2001). The content of the documents is 
taken as given, and the comparison is done at rather general level leaving some 
details uncovered. The aim is to test and validate Thomas's requirements and 
also to identify areas, which has not been covered by Thomas from 3GPP 
perspective and visa versa. Similar comparisons, which use some other 
environments as references, should be done in order to get more feedback for SIP 
security requirement work. 

In order to avoid potential misunderstanding, some characteristics of 3GPP SIP 
security requirements must be clarified. Firstly, 3GPP requirements have been 
written for 3GPP UMTS Release 5 which includes so-called 'IP Multimedia 
Subsystem' (IMS). The requirements represent the first version of a system 
architecture, which applies SIP. If some security features are not included in 
these requirements, it does not conclude that such a security feature would not 
be needed for SIP. It only means, that such a feature is not needed for 3GPP 
UMTS Release 5. If something is included, it means that 3GPP honestly believes 
that such a feature is needed in order to implement UMTS Release 5. Other SIP 
environments or future UMTS releases may include additional requirements for SIP 
security. Secondly, 3GPP requirements reflect evolutionary approach from mobile 
operators' perspective. For example, 3GPP wants to use the authentication tokens 
already implemented in wireless telecommunication networks for SIP. Thirdly, SIP 
will have a more important role in the future of wireless services in general 
when the old signaling protocols are replaced by SIP. At that stage, it will be 
even more important that SIP is able to serve the needs of existing and future 
mobile operators. 

It is also important to understand that IETF has quite different perspective on 
SIP security than 3GPP. Firstly, SIP is a protocol, which has already existed 
some time. It means that there already are SIP implementations and that the 
backward compatibility is an important issue for these implementations. 
Secondly, IETF must take into account several environments in which SIP is 
applied - not just 3GPP. Security solutions should be general enough to fulfill 
all (or most of) the needs there exist. Furthermore, other HTTP like protocols, 
which follow similar design principles and use similar message structure, should 
be taken into account. Finally, decisions taken today will have a long-term 
effect because features standardized today will be features for which the 
backward compatibility must be provided tomorrow. Furthermore, interoperability 
between different SIP environments should be ensured. 

This paper proceeds as follows. The next chapter starts the comparison between 
Thomas's and 3GPP requirements focusing on the proxy routed message interfaces. 
Chapter 3 continues the comparison by taking a look at the general SIP security 
requirements. Chapter 4 draws some conclusions. 

2. Proxy Routed Message Interfaces 

Thomas (2001b) discusses SIP security requirements at quite general level. He 
analyses various threats that may occur while deploying SIP. The requirement 
analysis is done using a proxy routed INVITE as a test case. The context of the 
analysis is a generalized SIP environment, i.e. the so-called 'SIP Jack in the 
Box' (SIP JITB). SIP JITB is an extended SIP trapezoid. In a normal SIP 
trapezoid, there are only four entities: UAC, UAS and two intermediate proxies. 
SIP JITB includes one additional proxy in order to cover more message 
interfaces, e.g. the one in which a proxy is not directly known to either of the 
UAs. 

In SIP JITB, Thomas discusses five message interfaces: 

(1) UA-to-first-hop-proxy interface 
(2) UA-to-Intermediate-proxy interface
(3) End-to-end interface 
(4) Adjacent-proxy-to-proxy interface
(5) Non-adjacent-proxy-to-proxy interface 

With all these interfaces Thomas discusses the security requirements related to 
authentication, confidentiality, message integrity and freshness proofs, and 
authorization. Requirements related to redirect and registration services are 
regarded equal to the ones of the UA/Proxy interfaces, however, this statement 
is incomplete in our opinion. Thomas should have regarded them also as equal to 
the End-to-end interface because redirect and registration services are able to 
act as servers, not just proxies. The Non-adjacent-proxy-to-proxy interface is 
included just to complete the analysis and Thomas does not consider it as a 
valid requirement interface. 

In some sense, 3GPP IMS share security requirements within all the interfaces 
presented by Thomas. Some of the interfaces are weakly recognized, however, all 
of them are present to some degree. 

The most visible 3GPP requirements are related to the UA-to-first-hop-proxy 
interface (1) probably because this hop includes the air interface. In general, 
UAs and the first hop proxies are always assumed to belong to different trust 
domains. 3GPP requires solutions for confidentiality protection, message 
integrity protection and message freshness proof over this interface. 
Authentication and authorization are not directly required even though the proxy 
receives indirect information on the authentication/authorization status from 
the home network, and the proxy is assumed to make some decisions about the 
authorization status of the incoming and outgoing messages. 

It must be noted that UA-to-first-hop-proxy interface covers also the 
terminating SIP messages, i.e. last-hop-proxy-to-UA traffic. 3GPP requirements 
cover the both ends. 

Another well recognized interface in 3GPP is the End-to-end interface (3). 
However, this does not include INVITEs and other messages between end-user 
devices. 3GPP is currently interested in the communication between the UA and 
the Registrar. The security requirement for this interface is mutual 
authentication. However, this does not mean that other security services would 
be despised. There is an inherent assumption in 3GPP requirements that the 
system architecture will take care of the rest, i.e. confidentiality, message 
integrity, replay protection and authorization. For example, both the first hop 
proxy and the registrar are assumed to be located in relatively safe 
communication networks, and the messaging between these networks is based on 
roaming agreements. Furthermore, there are fixed security gateways between the 
networks. On the other hand, two end-users are assumed to be able to trust on 
their service providers and consequently the need for end-to-end mutual 
authentication between the end users is not considered as a high priority 
security service. 

3GPP IMS architecture includes also a trust boundary in Non-adjacent-proxy-to-
proxy interface (5). There are two non-adjacent proxies (i.e. the first hop 
proxy and the Registrar acting in the role of proxy), which share a very 
distinctive trust relationship. Registrar and the first hop proxy need to agree 
at the time of registration that the first hop proxy will protect the messaging 
between the UA and itself. UA and its Registrar(s) always belong to the same 
trust domain and all UA originated (and terminated) messages must be routed via 
the Registrar. The first hop proxy is assumed to belong to a different trust 
domain than UA and Registrar. The trust between the domains is based on roaming 
agreement and the use of security gateways, however, the Registrar still needs 
to delegate a short-term security association to the first hop proxy based on 
its own long-term security association with the UA. When the UA sends an INVITE, 
for example, it is protected in the first hop using the delegated association. 
When the Registrar (now acting as a proxy) receives the INVITE, it trusts that 
the first hop proxy has not forwarded any unauthorized messages to it. It also 
trusts that the security gateways between the networks filter all other 
unauthorized messages. Even though 3GPP does not directly require any SIP 
specific protection for the Non-adjacent-proxy-to-proxy interface (5), it 
assumes that there exists a delegation mechanism in this interface. 

Currently, 3GPP does not recognize the UA-to-Intermediate-proxy interface (2). 
However, there has been some recent discussion whether the trust relationship 
between the first hop proxy and the Registrar is secure enough from Registrar's 
perspective. There is a possibility that the first hop proxy or UA may cheat the 
Registrar. It is possible that Registrar should be able to confirm that all 
INVITEs really originate form the claimed UA, and this could constitute some 
security requirements for the UA-to-Intermediate-proxy interface. 

Adjacent-proxy-to-proxy interface (6) is assumed to be fulfilled by 3GPP IMS 
architectural structure instead of SIP security. 3GPP assumes security between 
proxies but does not require it for SIP because it uses some other means like 
security gateways. However, the interface would be valid for 3GPP if these means 
didn't exist. 

3. Requirements 

In addition to proxy routed message interfaces, Thomas presents a list of 
concrete requirements. From 3GPP perspective, the Thomas's requirements can be 
classified in four groups. The first group includes those requirements, which 
are directly supported by 3GPP UMTS Release 5. The second group includes those 
requirements which are also needed but which may require further clarification 
and, in some cases, supplementary details in order to satisfy all 3GPP needs. 
The third group composes those requirements which are important for SIP in 
general, but which are not currently required by 3GPP UMTS Release 5. This is 
the group of requirements which are probably important for 3GPP in the future, 
but which have not been properly discussed in 3GPP. Finally, there are 
requirements which are important for 3GPP but which are either missing or not 
been stressed enough in current document. In this chapter, I shortly describe 
all of these groups. 

3.1 Requirements supported by 3GPP UMTS Release 5 

3GPP UMTS Release 5 directly support the requirements presented in the list 
below. These requirements are not further discussed in this document even though 
people may have different interpretation of their full meaning. 3GPP seems to 
support the further clarification of these requirements. 

- "Authentication -- the recipient of a SIP message MUST be able to demand 
authentication from the initiator. There MUST be mechanisms, which provide for 
end to end authentication as well as authentication to intermediate proxies." 
(Thomas 2001b)

- "Mutual Authentication -- a SIP host, which is challenged to authenticate 
itself to another SIP host, MUST be able to demand mutual authentication. 
[XXX/mat: is it worth while considering the case where a client wants the server 
to authenticate itself, but the server doesn't care, ala TLS/Web?]" (Thomas 
2001b)

- "Privacy -- SIP Messages MUST be able to be transported confidentially hop by 
hop. SIP MUST also provide a means of transporting portions of SIP messages that 
are not required for hop-by-hop processing privately between arbitrary SIP nodes 
in the proxy routed path." (Thomas 2001b)

- "Replay protection -- Both hop by hop solutions and point to intermediate 
proxy routed point MUST be able to detect replays and reject them. It MUST NOT 
be possible for a snooper to replay a sequence of bits which is not detectable." 
(Thomas 2001b)

- "Transport -- A SIP host MUST be able to transport entire SIP messages 
securely (eg, private, replay proof, integrity checked...) for TCP and UDP. SCTP 
SHOULD be supported as well." (Thomas 2001b)

- "Support secret key authentication -- the solution MUST provide a means of 
using direct peer to peer secret key authentication as well as privacy and 
message integrity checking. The solution MUST allow either initially or in the 
future centralized secret key based authentication schemes like Kerberos and 
AAA." (Thomas 2001b)

- "The solution SHOULD consider the sizes of messages, and SHOULD provide a 
mechanism to first compress any encrypted portions of messages." (Thomas 2001b)

3.2 Requirements which need further clarification from 3GPP perspective 

Thomas presents two requirements which are interesting from 3GPP perspective but 
which need further clarification or maybe even supplementary details in order to 
fulfill 3GPP needs. These requirements are: 

- "The solution SHOULD allow for multiple different authentication schemes to be 
added in time (eg, PKI-based, Kerberos based, AAA, etc). The solution MUST 
provide a solution for direct pre-shared keys." (Thomas 2001b)

- "The solution SHOULD consider the cost of any public key operations which are 
used, and the sizes of authentication credentials. If deemed necessary, the 
solution SHOULD provide a means of caching the state of "expensive" credentials 
which are amortized over subsequent messaging using less expensive mechanisms." 
(Thomas 2001b)

3GPP authentication model is rather exceptional if compared with current SIP 
philosophy. Firstly, it assumes the use of legacy authentication method. The 
authentication method is based on symmetric cryptography, and it utilizes 
removable, tamper-resistant subscriber identity modules (SIMs) for terminal 
equipment. Symmetric keys are stored on these security devices. Secondly, it 
intends to minimize the communication between SIP and AAA infrastructure, and 
consequently authenticates the SIP users only periodically. The legacy 
authentication method is able to generate session keys, and these keys can be 
used to protect all messages until a new user authentication is required. 

Thomas's requirements above suggest the use of different authentication schemes 
but it is not exactly clear whether it is possible for 3GPP to use one of its 
own. Thomas also suggests that the solution should have a feature in which the 
expensive and less expensive security mechanisms can be used. 3GPP would 
probably want to extend this to symmetric methods as well in order to protect 
the subsequent messaging in between the periodical authentication. 

3.3 Requirements that are not currently needed for 3GPP UMTS Release 5 

The following requirements are not currently needed for 3GPP UMTS Release 5. 
However, some of these requirements may be needed in some other SIP environments 
or in future 3GPP UMTS releases. Furthermore, Release 5 requirements have not 
been completed which proposes that 3GPP opinion on these requirements may also 
change. Anyway, these requirements are not in conflict with 3GPP. 

- "Considering the difficulty of deploying strong cryptographic based solutions, 
the solution MUST provide a means to prevent source spoofing attacks which does 
not rely on strong authentication, and SHOULD provide authentication security on 
the order guessing a large number in the absense of active snooping. This 
solution MUST be mandatory to execute when strong authentication is not 
available." (Thomas 2001b)

- "Proxied authentication -- an intermediate SIP node MUST be able to assert 
identity for user agents which are be used in addition or in lieu of user agent 
credentials. These identities MUST have the ability to be support strong 
cryptographic authentication." (Thomas 2001b)

- "Support for public key authentication -- the solution MUST provide a means 
either initially or in the future to use public key based authentication, either 
using direct public keys, or using public key infrastructures. It MUST also 
provide a means leveraging authentication to provide strong crypto based 
integrity and privacy.  (PKI's)." (Thomas 2001b)

- "Guard against hostile MITM -- In situations where traffic is routed through 
possibly untrusted intermediaries (proxies), the solution MUST provide a means 
of transporting sensitive headers integrity protected as well as private to 
their ultimate destination. The solution MUST NOT try to protect against attacks 
which are inherent to routing itself." (Thomas 2001b)

- "The solution SHOULD allow for the transport of 3rd party 
authentication/authorization tokens for use in conjunction with other protocols. 
(eg, DCS state blobs, OSP tokens, etc)" (Thomas 2001b)

- "The solution MUST consider denial of service attacks, and in particular MUST 
consider the ramifications of CPU and storage attacks from unauthenticated 
sources against SIP nodes. The solution MAY consider denial of service attacks 
by authenticated, but otherwise rogue nodes." (Thomas 2001b)

3.4 3GPP requirements that are not present 

3GPP has some general requirements, which are not present in Thomas's document 
or which have not been stressed enough. These requirements are: 

- "All security mechanisms that involve 3GPP terminals should minimize the 
number of necessary extra roundtrips. In particular, during normal call 
signaling there should not be any additional security related messages." (Garcia 
et al. 2001) 

People with different background may have different interpretation what the 
roundtrip minimization requirement really means. For 3GPP, it means that 
communication between the SIP entities should be cut down in the air interface 
as well as in the fixed network. The number of users is assumed to be so high 
that all possible must be done to save the network resources. This requirement 
includes all network layers: SIP, transport, and IP. 

- "A method for secure negotiation of security must be provided, to negotiate 
the security services to be used in the access domain." (Garcia et al. 2001)  

3GPP wants to guarantee future upgrades to new security solutions in a secure 
manner, e.g. due to algorithm compromise or the availability of some general 
protocols in all devices. For this reason, 3GPP requires secure negotiation of 
security solutions between SIP entities. Currently, this negotiation is supposed 
to be done between UA and the fist hop proxy, however, there is a change that 
more SIP entities could be involved in the negotiation (see a proposed solution 
in Arkko et al. 2001). 

- "The SIP serving proxy that performed the initial authentication must be able 
to securely delegate subsequent SIP signaling protection (e.g. session keys for 
integrity or encryption) to an authorized SIP proxy further downstream." (Garcia 
et al. 2001) 

As described before, the current 3GPP security architecture needs a mechanism to 
delegate security tasks in Non-adjacent-proxy-to-proxy interface. Note that this 
feature would not have any negative influence on interoperability between 
various SIP networks even if it were specified as 3GPP specific feature. 
Delegation and key transfer is done only within 3GPP networks. SIP terminals do 
not necessarily have to be aware of the delegation. 

4. Conclusions 

In this paper, I have gone through Thomas (2001b) SIP security requirements and 
compared them with 3GPP SIP security requirements (Garcia et al. 2001). 

On proxy routed message interfaces, 3GPP IMS architecture seems to cover quite 
many security requirements at UA-to-first-hop-proxy interface. 3GPP architecture 
also includes requirements at End-to-end interface when one communicating SIP 
entity takes the role of Registrar. 3GPP architecture has also some interesting 
characteristics for Non-adjacent-proxy-to-proxy interface which would benefit 
the SIP security requirement work. Security requirements for UA-to-Intermediate-
proxy and Adjacent-proxy-to-proxy interfaces are not currently developed enough 
to really benefit the requirement analysis. Naturally, this may change in the 
future because 3GPP SIP security requirements are not fully static yet. 

In general, quite many of Thomas's requirements are supported by 3GPP 
architecture. There are some requirements, which may need further clarification 
and supplementary details in order to fulfill all 3GPP needs. There are no 
conflicting requirements even though there probably exist different 
interpretations on what the requirements mean in practice and which solutions 
fulfill them. There are also some 3GPP requirements, which are not included in 
Thomas's requirements. These requirements should be further discussed in IETF. 

References 

Arkko, J., Torvinen, V., Haukka, T., Sen, S. & Varelius, L. (2001) Security 
Mechanism Agreement for SIP Connections, Work in progress, IETF Internet-Drafts, 
draft-arkko-sip-sec-agree-00.txt.

Garcia, M., Mills, D., Bajko, G., Mayer, G., Derome, F., Shieh, H., Allen, A., 
Chotai, S., Drage, K., Bharatia, J., Hobbis, K. & Willis, D. (2001) 3GPP 
requirements on SIP, Internet Draft, Internet Engineering Task Force, November 
2001, Work in progress. 

Schulzrinne, H. (2001) A Minimalist Security Framework for SIP, Internet Draft, 
Internet Engineering Task Force, November 2001, Work in progress. 

Thomas, M. (2001a) SIP Security Framework, Internet Draft, Internet Engineering 
Task Force, July 2001, Work in progress. 

Thomas, M. (2001b) SIP Security Requirements, Internet Draft, Internet 
Engineering Task Force, November 2001, Work in progress. 

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: 27. marraskuuta 2001 23:56
> To: [email-masked]
> Subject: [Sip] SIP security requirements (this might mean you!)
> 
> 
> 
> As promised, I separated out the requirements from
> the framework I hacked up for the last meeting,
> and they're currently available in
> draft-thomas-sip-sec-req-00.txt. Not a whole lot
> has changed here: I've mainly tried to capture
> the comments from our ad hoc meeting, and flesh
> out the requirements I had before.
> 
> So here's my dark confession: I can't keep up with
> the vast expanse of this working group's
> in-progress and proposed extensions to determine
> whether the set of requirements I've already come
> up with are necessary and sufficient. I've mainly
> paid attention to 2543bis and a few other drafts
> which I'm familiar, like the privacy draft. It is
> quite possible that any assumptions and hopes for
> SIP security that are being made in other drafts
> -- and I sure hope that their security
> considerations sections enumerate all of them --
> are not well accounted for in these requirements.
> 
> Therefore, it would be really, really helpful if
> the authors of these drafts helped out here by
> comparing their expectations for security with
> what is being claimed as requirements in the
> draft. Henning's questions on REFER security are
> exactly the kind of input that is needed to test
> to see if we're missing things -- either
> specifics, or general trends. If you all don't
> help out, you're probably going to be faced with
> the prospect of my limited understanding of many
> of these drafts, aided by their perfect security
> considerations section, filling in the blanks.
> This should probably not give you comfort.
> 
> 	 Mike

_______________________________________________
Sip mailing list  http://www1.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: Michael Thomas <[email-masked]>
Date: Sat, 8 Dec 2001 10:20:57 -0800 (PST)

Vesa Torvinen (LMF) writes:

Vesa, thanks for the write up. After reading this
through once, only one thing really concerns me

 > not necessarily have to be aware of the delegation. 

Essentially what you are asking for, I gather, is
the ability to transport keying material(s) in a
single SIP message for principals other than who
would be in the "secure-from" and "secure-to" in
the parlance of my framework draft. A couple of
comments:

1) It troubles me in general to explicitly require
   SIP to become a transport vehicle for key 
   distribution. I realize that this may happen
   with some auth schemes, but I view this as a
   side effect of the auth scheme, rather than a
   requirement per se for SIP security

2) I'm not sure whether this sort of thing would
   be a native feature of DIAMETER based auth,
   say, but I'd feel a lot more comfortable if
   we had this debate in the context of a
   particular plug-in for a framework, rather
   than a general requirement. In particular,
   I don't think that we should require auth
   schemes where this sort of thing isn't natural
   to go beyond what their goals are

3) <requirements gathering hat off> I think I
   understand what it is you're interested in 
   obtaining here and may have some ideas about
   alternative ways of doing this without 
   overloading SIP so much. We should talk in
   SLC if you'll be there.

	  Mike