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

From: Stu Jacobs <[email-masked]>
Date: Tue, 19 Nov 2002 07:08:37 -0500

I am reposting this as it seems to have gotten lost the first time

>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

==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
[email-masked] [email-masked]  [email-masked]
==========================

_______________________________________________
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