Subject: [Sip] Comments on draft of broad requirements for VoIP security

From: Stu Jacobs <[email-masked]>
Date: Mon, 18 Nov 2002 13:17:14 -0500

As a follow-up to the announcement of the draft
draft-jacobs-signaling-security-requirements-00.txt, with Jon Peterson's ok,
we are posting a private exchange between ourselves and Jon
regarding the draft.

 > -----Original Message-----
 > From: Eric Nielsen [mailto:[email-masked]]
 > Sent: Friday, November 15, 2002 11:47 AM
 > To: Peterson, Jon
 > Cc: [email-masked]'
 > Subject: RE: draft-jacobs-signaling-security-requirements-00
 >
 >
 > Jon,
 >
 > Stu and I spent the time to answer your questions
 > more point by point. We would like to share this
 > on the mailing list - is that OK with you?
 >
 > Also, is it possible to discuss, or at least mention it
 > during the IETF meeting next week?  I will be attending,
 > and think that or an off-line discussion will be useful.
 >
 > Thanks,
 >
 > Eric Nielsen
 >
 >
 > > Hi,
 > >
 > > I happened to see the announcement of your draft (both on the ietf 
list and
 > > the Internet2 VidMiz list), and I have a few questions and  comments. 
For  the
 > > most part, my comments are confined to the portions of your document that
 > > discuss SIP.
 > >
 > > First, I wanted to note that RFC3261, which defines SIP, contains a lot of
 > > security text - a whole lot - a good starting point would be Section 26,
 > > which goes into a detailed threat model, considers possible attacks,
 > > provides protocol requirements, and even contains illustrations of the use
 > > of recommended mechanisms to satisfy these requirements. Several other
 > > chapters deal exclusively with security, in particular with defining 
the use
 > > of security mechanisms for SIP. I don't read anything in your draft that
 > > suggests that you are familiar with Section 26 of RFC3261. I think it 
might
 > > prove an interesting read for you.
 > >
 > > In fact, from my initial glance at your document, it appears that the
 > > sections pertaining to SIP contain a subset of the threats, requirements,
 > > and mechanism analysis that was performed as part of the process of
 > > assembling the security sections of  RFC3261. This process involved dozens
 > > of contributors (from various parts of the industry) and occupied much of
 > > the SIP WG's attention for the first part of this year.  Security isn't
 > > exactly something that we've swept under the rug. While most of your
 > > requirements are certainly valid, they have already been captured in the
 > > baseline specification, as have solutions to these requirements.
 > >
 > > Also, as one of the chairs of the IETF SIP WG I'm a little uncertain about
 > > the status of your document. What do you intend to do with it?
 > >
 > > Some of the language in the SIP sections of the draft (e.g. Security
 > > Association) is undefined (the reference to RFC 240x does not help me to
 > > understand what you mean). The concepts of authentication, session key
 > > exchange and the establishment of a 'Security Association' seem to be
 > > frequently conflated in your document (in many security mechanisms, these
 > > are separable operations). It might be better to restrict the ontology to
 > > canonical SIP entities (presumably a Call Agent acts towards a SIP 
entity as
 > > some sort of user agent or proxy server, correct?).
 > >
 > > On an organizational matter, I would also note that the security
 > > requirements of SIP are radically different from the requirements of 
Megaco
 > > (an Internet standard) or MGCP (a discarded proposal for an Internet
 > > standard). Unlike SIP, MGCP and Megaco are intended to be intradomain
 > > protocols - protocols that do not traverse the public Internet. Trying to
 > > use these protocols between administrative domains (vide 3.3.14) is 
probably
 > > ill-advised. Anyway, I would put Megaco-specific requirments into a 
separate
 > > document- the 'common' requirements in section 3.4 could be fielded 
out to a
 > > third document and referenced by the Megaco/SIP docs if necessary.
 > >
 > > I also have some brief but specific comments on your requirements:
 > >
 > > 3.1.1 - This is a requirement that is satisfied by the baseline SIP 
protocol
 > > already. While it is nice to know that this is also a  requirement 
from your
 > > perspective, this is a very elementary requirement that we  have already
 > > captured in the SIP specification, and provided a mechanism  to address.
 >
 > Agree, provided that the manner of authenticating with a SIP  proxy does not
 > prevent an initiating SIP UA from authenticating with the recipient UA
 >
 > >
 > > 3.1.2 - The concept that a user agent needs to communicate  'securely' 
with a
 > > proxy server (be it a failover proxy or no) is very vague.  The 
baseline SIP
 > > protocol provides mechanisms like TLS that satisfy most  definitions of
 > > 'securely' (in that TLS provides canonical security properties - 
integrity,
 > > confidentiality, authentication, replay protection).  Anyway, I 
suspect SIP
 > > already meets these requirements.
 >
 > TLS requires an extensive PKI and X.509v3 certs to allow mutual
 > authentication.  To expect a SIP phone appliance to have the computing power
 > and storage to a full PKI and still be commodity priced is unreasonable.
 > Furthermore should a SIP Proxy fail and it's backup take over, TLS will
 > either require an apriori relationship between the backup SIP Proxy and the
 > UA or force a delay while the SIP UA and the backup Proxy establish the
 > relationship.
 >
 > >
 > > 3.1.3 - I have a hard time imagining a security mechanism that 
wouldn't meet
 > > this requirement (all of the ones that come to mind do - Digest, TLS, 
IPSec,
 > > S/MIME, PGP). I would also note that your Explanatory Text seems somewhat
 > > out of parity with the requirement itself.
 >
 > This is there for completeness so when one proposes a security solution this
 > is not overlooked.
 >
 > >
 > > 3.1.4 - There was really no danger of anyone who uses the existing 
security
 > > mechanisms in the baseline SIP specification ever making that mistake. The
 > > attacks considered in RFC3261 Section 26 contain numerous instances of
 > > source-address spoofing, and the mechanisms provided mitigate these 
attacks.
 > >
 > Security mechanisms like IPsec cannot cleanly operate across NAT because
 > they are dependant on the Correspondent's IP address not changing.  A SIP UA
 > is really identified by the user of the UA and not the platform upon which
 > the UA is executing.
 >
 > > 3.1.5 - Section 3.1.5 seems to contain a number of confusing assumptions.
 > > Authentication systems have no dependency on addressing (as your bullet
 > > 3.1.4 correctly notes). To say that all but the simplest networks use NATs
 > > is a bit of an exaggeration. NAT traversal, either way, is a orthogonal to
 > > authentication.
 >
 > The reality is that NAT will be with us for many years and many, if not
 > most, service provider customers use NAT between their local networks and
 > the service provider network.  We cannot expect residential, SOHO and small
 > business customers to know about or even understand what NAT is let alone
 > whether NAT is present between their local net and the service provider net.
 >
 > >
 > > 3.1.6 - Again, this requirement is well-substantiated in RFC3261. Mutual
 > > authentication systems are already provided in SIP.
 > >
 >
 > This is there for completeness so when one proposes a security solution this
 > is not overlooked.
 >
 > > 3.1.7 - We have done a lot of work on identity in SIP. A SIP URI (we would
 > > say an address-of-record URI) is the predominant form of identity 
used, for
 > > example, in draft-ietf-sip-asserted-identity-02, a draft (soon to be known
 > > as RFC 3325) that I imagine you would find interesting. A host name is not
 > > an identity.
 > >
 >
 > We are simply stating that SIP security must work with a logical identity
 > and not something as mutable as an IP address.  If one were to use
 > address-of-record URIs and TLS then the certs TLS relies on would also have
 > to use address-of-record URI as the identity.
 >
 > > 3.1.8 - All of the authentication mechanisms supported by SIP provide
 > > versioning. This requirement, I note, is the first that seems to 
suggest you
 > > are designing some sort of authentication 'protocol' for SIP. Why on earth
 > > would we do that? Aren't there enough authentication protocols in the 
world?
 >
 > This is there for completeness so when one proposes a security solution this
 > is not overlooked. As to whether we are designing "some sort of
 > authentication 'protocol' for SIP" is dependant on whether there 
currently exists an
 > authentication mechanism for SIP that meets our other requirements.
 >
 > >
 > > 3.1.9 - SIP supports extensible authentication mechanisms already.
 >
 > This is there for completeness so when one proposes a security solution this
 > is not overlooked.
 >
 > >
 > > 3.1.10 - This one, I think, is totally meaningless, unless you define 
a 'SIP
 > > Security Association'. I know what an IPSec SA is, do you mean that? 
How do
 > > you define the attributes of a trust relationship? What is a trust
 > > relationship?
 > >
 >
 > The problem with IPsec SAs is that they are tightly bound to IP addresses;
 > in point of fact, an IPsec SA is specifically identified by the following
 > tuple (source IP address, destination IP address, SPI).  Any SA used with
 > SIP cannot rely on IP addresses for identification.
 >
 > > 3.1.11 - This isn't precluded in any security mechanism I'm aware of. It
 > > would essentially have to be IP-based authentication, which (as you note
 > > many times here) has a lot of problems and which therefore  no one uses.
 > >
 > Agreed
 >
 >
 > > 3.1.12 - Again, no real risk of this using any of the mechanisms we've
 > > defined for SIP.
 > >
 >
 > IPsec SAs do rely on IP addresses and TLS would necessitate the existence of
 > the address-of-record URI as the identity in X.509v3 certs for UAs and SIP
 > Proxies.
 >
 > > 3.1.13 - These qualities are provided by RFC3261.
 > >
 >
 > This is there for completeness so when one proposes a security solution this
 > is not overlooked.
 >
 > > 3.1.14 - 'MUST operate' isn't terribly specific. But anyway, this just 
means
 > > 'must run over the Internet'. We assume in RFC3261 that SIP runs over the
 > > Internet, not some sort of private 'trusted domain'.
 > >
 >
 > This is there for completeness so when one proposes a security solution this
 > is not overlooked.
 >
 > > 3.1.15 - Provided in RFC3261.
 > >
 >
 > This is there for completeness so when one proposes a security solution this
 > is not overlooked.
 >
 > > 3.1.16 - Digest meets this requirement, and is an authentication 
mechanism.
 > >
 > Yes but Digest has problems, i.e. key management
 >
 > > 3.1.17 - Full encryption and signature algorithm  requirements are given
 > > already in RFC3261.
 > >
 > Yes but for any alternative security mechanism this applies
 >
 > > 3.1.18 - Provided by all application-layer security mechanisms (including
 > > Digest, TLS, S/MIME etc).
 >
 > Yes but these mechanisms have other problems (such as working when NAT
 > present,  dealing with Proxy failover, simplicity of provisioning, reliance
 > on IP addresses, etc.)
 >
 > >
 > > 3.1.19 - Provided by Digest, for example.
 > >
 > Agreed
 >
 > > 3.1.20 - This fleshes out, to some degree, what you think an SA should be.
 > > This sort of aging capability could be realized in Digest,  for 
example, with
 > > a nonce cache - when the 'SA' expires, the nonce is no longer valid and a
 > > new challenge must be issued.
 > >
 > Yes, it means we must make it explicit, that is all. Either they are coupled
 > or they are decoupled.
 >
 > > 3.4.1 - I'm not sure what protocol this is a requirement for... in any
 > > event, few people believe that SIP is a good way to distribute
 > > configurations or keys.
 > >
 > This is a VoIP deployment requirement. Whatever mechanism is used to
 > authenticate a trusted call agent should also be able to be re-used, or at
 > least facilitate signing configuration files downloaded from that same
 > authority.  If the configuration files and the image files on a VoIP network
 > appliance are not signed this can enable compromise of the user's keying
 > material, theft of services, etc... This is part of a whole security system.
 >
 > > 3.4.2 - We have a general requirement for federated identity models 
that has
 > > already been taken pretty far in SIP. You might want to look at
 > > draft-ietf-sip-identity-00.
 > >
 > I agree that the draft-ietf-sip-identity-00 is based on dealing with this
 > requirement, but not really in SIP.
 >
 > > 3.4.4 - This requirement is met by SIP in a number of ways.
 > >
 > In hop-by-hop security the entire message can be authenticated and integrity
 > checked. In common usage of SIP Digest many aspects of the message are not
 > integrity checked. While in theory it is possible to meet this requirement
 > in SIP, in common usage it does not.
 >
 > We need to be able to assure integrity on a hop-by-hop basis. At the same
 > time there needs to be a trust relationship that allows going through NATs
 > and proxies without requiring the intervening devices that alter the SIP
 > message to know the user's symmetric passphrase or private key information.
 > S/MIME can do end-to-end authentication (assume a full PKI and difficult
 > implementation for small devices) in addition to hop-by-hop authentication.
 >
 > However this is inadequate in the scenario where caller "A" is known by
 > carrier "AA" and caller "B" is known by caller "BB", and carrier "A" trusts
 > carrier "B"'s claims.  In this situation there are two virtually centralized
 > authorities. Caller's "A" and "B" may exchange S/MIME messages for there own
 > end-to-end security, if they choose. However the carrier needs to
 > authenticate only from the endpoint to the carrier's border.  With
 > hop-by-hop security the carrier is unable to validate the end-user's
 > symmetric passphrase or public key while, at the same time assure full
 > packet integrity on a hop-by-hop basis. I do not believe SIP can do this. I
 > believe your draft-ietf-sip-identity-00 requires a PKI to do this.
 >
 > > 3.4.5 - Same as 3.4.4.
 > >
 >
 > This simply means that the protocol must be able to perform as required in
 > 3.4.4 while at the same time statefully share session keys in a practical
 > way. For example, I am not sure how many folks would consider replicating an
 > IPsec SADB is practical.
 >
 >
 > > 3.4.6 - This seems to be potentially in conflict with 3.4.3. In any event,
 > > this is something of an implementation requirement, not a protocol
 > > requirement (no protocol requirements arise from this).
 > >
 > While this is not a protocol requirement, it is a requirement on the
 > handling of passphrases and public/private key pairs. Part of a security
 > solution is to minimize the exposure of keys. Anytime a key is persistently
 > stored, exposure becomes more likely. We must have a security system that
 > minimizes the use of stored keys, particularly those keys that are mobile,
 > such as human passphrases or biometrics. If my phone uses a biometric
 > mechanism to authenticate it, what happens when I reboot the phone? In the
 > real world people expect the phone to still work as it did before thereboot.
 >
 > The point here is that we need a protocol that supports good behavior
 > relative to human passphrases upon phone reboot.. I do not believe that it
 > really exists.
 >
 >
 >
 > > 3.4.7 through 3.4.12 - I'm not sure how any security mechanism that 
has been
 > > passed in the IETF could fail to meet these requirements. In any event,
 > > these are met by the mechanisms described in the SIP specification. Any
 > > security mechanism (for example, TLS) has these sorts of properties.
 > >
 > 3.4.7  requires that the security mechanims used allows the key/identity
 > used for authentication be associated at the VoIP layer identity. In the
 > case of IPsec as mention in 3261 (and MGCP and MEGACO and ...) this is not
 > true. IPsec security is transparent to the application layer. A message can
 > be authenticated that it came from source "A", however its payload can look
 > like it came from source "B".  SIP Digest links the application identity to
 > security layer. TLS can vary by implementation.
 >
 > 3.4.8  key dilution or weakening of security algorithm strength is possible
 > in frameworks where there is negotiation of algorithms and key lengths. This
 > seems to be a common subject, and part of the rationale behind security
 > suites.
 >
 > 3.4.9  Common usage of SIP Digest does not use session keys. Instead it uses
 > the persistent symmetric passphrase associated with the SIP URI. Theoretical
 > usage might be to use session keys, however in practice what happens in what
 > is simple and cheap. It is very important to develop a security solution so
 > that when it gets used in practice the human keys are easy to manage, not
 > over-used or over-stored in a way that leads to greater probability of
 > exposure.
 >
 > If we assume IKE or some other exchange that presumes a full PKI, we have a
 > practical problem that seems unresolvable (as well as uneconomical) in the
 > next few years.
 >
 > 3.4.10 - 3.4.12  Yes, these are standard requirements. I am unaware how SIP
 > Digest does this, however I do know that TLS and IPsec can meet these
 > requirements. For IPsec IKE is required to renegotiate a new session key.
 >
 >
 > > 3.4.13/3.4.14 - SIP has considerations for these conditions, even for
 > > Digest.
 >
 > 3.4.13  This is a matter of minimizing the work required to authenticate a
 > message. The more parsing and interpretation, etc, required before
 > authentication, the greater the potential load caused by unauthorized
 > messages. Simplicity also keeps it more secure.  Simpler is better, and it
 > is a judgment call on whether something is simple enough. In this respect,
 > IPsec, one of the security mechanisms mentioned in 3261 is very simple.
 >
 >
 > 3.4.14  This is the potential for tens of thousands of endpoints needing to
 > set up new Security associations at once.  The current form of IKE was not
 > designed for this kind of load. I doubt TLS using certificates is either.
 > Manually keyed mechanisms (digest, etc.) essentially already have their
 > security association statically defined, so there is no set up time
 > involved.
 >
 > >
 > > 3.5.1 - I'm not sure what ENUM has to do with this requirement.
 >
 > 3.5.1 has a Non-requirement: Globally Certified Identities
 >
 > The only reason ENUM was mentioned as a related comment, ENUM
 > shares some of the same issues as North American LNP: Who controls
 > what an E.164 number connects to, and who is allowed to change
 > that mapping. We do not assert that some globally certified
 > identity gets to define what E.164 number it maps to. Instead
 > we assert that an E.164 points to some information about an
 > identity. Look up based on the identity is error prone, where-as
 > look up based on the E.164 number is not.
 >
 > For SIP URIs the URI should not be mistaken for the identity
 > of one of the endpoints of a call. Instead it is some information
 > about the identity. And it is also a guarantee of sorts that
 > the entity that you call today using that URI is the same
 > as you called yesterday with that URI. Third parties (carriers
 > in the US) have direct control on how this mapping changes,
 > and who has rights to request changes.
 >
 > The short answer is that a URI cannot be considered equivalent
 > to an enduser identity. It can't have semantics greater than
 > a service provider who advertises (in a directory sense) the
 > URI knowing where to terminate calls directed to that URI, and
 > having adequate knowledge to bill someone for that service.
 >
 > >
 > > 3.5.4 - So, signaling needs to traverse non-trusted domains, but it can be
 > > unencrypted? Not even because of end-user privacy concerns?  I find that a
 > > little hard to swallow. Take a look at some of the threats in RFC3261 -
 > > there are vulnerabilities that arise from this.
 > >
 > > - Jon
 >
 >
 > All of these requirements suggest a systemic security solution that
 > incorporates authentication, keying, rekeying, and key storage, and human
 > key handling. The security issue, while composed of components defined at
 > multiple layers, must also link these layers as a package to make it usable.
 > The components must be designed to meet the system requirements.
 >

A significant issue for this draft is that the requirements
do not neatly fit into any one WG charter. I believe this
is more of a security issue than an application level
issue. To date the SIP WG has worked to fill in a variety
of gaps whereas MGCP and Megaco say not much more than
"just use IPsec".  Security is an essential part of VoIP,
and many of the needed features exist. Still, the issue of
a cohesive, workable security solution for carrier-scale
deployment remains beyond the scope of any one workgroup.
Thus we are posting this note here.

The goal of this draft is to get agreement on the broader
requirements, followed by an determining what gaps there
are between what exists and what is needed. Obviously if
we could see a full solution, we would not be pursuing this.
For example, common usage of current technology leads to
poor practices in handling keying material. The technology
must be defined so that it is possible to define simple and
secure common practices.

We would like to work to get agreement on the requirements,
as well as how to best meet them.

Thank you,

Eric Nielsen
Sylantro Systems

Stuart Jacobs CISSP
Verizon Laboratories

_______________________________________________
Sip mailing list  https://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