Internet Draft S. Jacobs Category: Informational Verizon Expires: May 2003 E. Nielsen Sylantro October 2002 draft-jacobs-signaling-security-requirements-00.txt MGCP, MEGACO, and SIP VoIP Signaling Protocol Security Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 28, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies the requirements that the MGCP, MEGACO, and SIP VoIP Signaling Protocols must satisfy in order to meet the needs for VoIP deployment in carrier class and large geographically distributed organization networks. These requirements were developed with a specific focus on network address translation (NAT), network through application layer packet filtering, signaling across multiple trust domains, and redundancy of call/controllers, media gateways, proxies and registrars. Jacobs, Nielsen Informational [Page 1] VoIP Signaling Security Requirements October 2002 1. Introduction This document presents security requirements for the SIP, MGCP and Megaco Voice over IP signaling protocols as deployed in a carrier class network context. These requirements were developed by examining the likely deployment within a large communications service provider context where high availability of services is necessary and mechanisms to prevent attacks, such as identity spoofing and theft of services are critical. In such a deployment, the service provider will most likely deploy SIP Servers, Media Gateways, Media Gateway Controllers/Call Controllers in an "1 to n" redundant manner. The service provider also, for economic and competitive reasons, must keep SIP User Agent or MGCP/MEGACO endpoint installation and provisioning sufficiently simple. Customers must be able to self install to avoid the need for carrier service technician involvement. The installation must create a Security Association (SA) between the endpoints and the call agent so that it can be subsequently maintained. These needs are the basis for extracting requirements, both explicit and implicit, that appear within this document. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3. Requirements Each requirement is presented as a statement, followed by explanatory material as appropriate. 3.1. Session Initiation Protocol (SIP) Security Requirements 3.1.1. Requirement: The SIP protocol authentication mechanisms MUST enable a SIP User Agent (UA), executing as either a network appliance or "soft-phone" requiring the services of a SIP Proxy or Registrar server, to establish an authenticated Security Association(SA) between itself and the SIP server. Jacobs, Nielsen Informational [Page 2] VoIP Signaling Security Requirements October 2002 Explanatory Text: This states that the protocol must allow the SIP server to obtain the identity of a SIP UA and authenticate this identity when the SIP UA either registers or requests services and allow the SIP server to make a determination as to whether or not the SIP UA request will/can be allowed. 3.1.2. Requirement: The SIP protocol authentication mechanisms MUST allow a SIP UA to securely communicate with a SIP Server that has taken over for a failed SIP Server with which a SIP UA has an existing SIP UA. Explanatory Text: In any but the most simple network, a SIP UA will need to interact with more than one SIP server when SIP Servers are deployed in redundant configurations using different Server IP addresses. The SIP protocol security mechanism design must not preclude the ability to do this. 3.1.3. Requirement: The SIP protocol authentication mechanisms MUST allow a SIP server to securely communicate with more than one SIP UA simultaneously. Explanatory Text: There may be multiple instances of a single SIP application or multiple SIP applications desiring service from a single SIP server, and different SIP UAs will represent them. The SIP protocol security mechanisms must not preclude the ability to do so. 3.1.4. Requirement: The SIP protocol authentication mechanisms MUST NOT use the IP address of the host system where a SIP UA is executing for the identity of the SIP UA. Jacobs, Nielsen Informational [Page 3] VoIP Signaling Security Requirements October 2002 Explanatory Text: This states that the SIP protocol authentication mechanism will use information, other that source IP address, to identify a SIP UA since source IP addresses are routinely modified by Network Address Translation (NAT) or can be spoofed. 3.1.5. Requirement: The SIP protocol authentication mechanisms running within a SIP UA MUST NOT need to be configured with knowledge as to the existence of NAT in the interface between the network where the SIP UA is located and the network where the SIP Server is located. Explanatory Text: In any but the most simple network, the network where the SIP UA ("home" network) is located will connect to a service provider and use NAT to map between the "private" or "non-routable" address space of the SIP UA's home network and the "public" routable address space of the Service Provider's network. 3.1.6. Requirement: The SIP protocol authentication mechanisms MUST provide for the mutual authentication of SIP UA and SIP server to one another. Explanatory Text: In addition for the more obvious need for the SIP UA to authenticate itself to the SIP server, there are some attacks against the protocol which can be mitigated by having the SIP server authenticate to the SIP UA. 3.1.7. Requirement: The SIP protocol authentication mechanisms MUST identify SIP UAs via the use of information elements such as a SIPuri, Network Access Identifier (NAI) (RFC2486) or host name. Jacobs, Nielsen Informational [Page 4] VoIP Signaling Security Requirements October 2002 Explanatory Text: This states that the SIP protocol authentication mechanism will use application oriented information for identifying a SIP UA that will not be affected by the presence of NAT or subject to modification by intermediate nodes during transfer between a SIP UA and a SIP Server. 3.1.8. Requirement: The SIP protocol authentication mechanisms MUST contain version numbers to enable subsequent extensions to support future requirements of applications not considered at this stage. Explanatory Text: We assume that there will be later revisions of this protocol. The initial version will focus on protocol communication security through firewalls and NATs, and it is possible that the protocol will need to be modified, as support for other SIP functionality is added or deployment scenarios evolve. 3.1.9. Requirement: The syntax and semantics of the SIP protocol authentication mechanisms MUST be extensible to allow the requirements of future security capabilities to be adopted. Explanatory Text: This is related to, but different from, the requirement for versioning support. As support for additional SIP security functionality is added there may be a need to add new message field types. 3.1.10. Requirement: The SIP protocol authentication mechanisms MUST support the ability of an SIP UA to use a SIP Security Association (SA) that defines the attributes of the trust relationship between a SIP UA and a SIP Server or a SIP UA and another SIP UA. Jacobs, Nielsen Informational [Page 5] VoIP Signaling Security Requirements October 2002 Explanatory Text: This states that the protocol security mechanisms must support authenticated signaling between SIP UAs and between SIP UAs and SIP Servers. 3.1.11. Requirement: The SIP protocol authentication mechanisms MUST NOT preclude multiple SIP Servers from securely communicating using the same SIP SA. Explanatory Text: The authorizing Call Agent may be deployed on multiple servers at multiple IP addresses. The SA that represents the trust association from a SIP UA to a SIP server or Call Agent should be reused among these servers. The SIP UA must have rules that define which servers share the same SA, and these rules should be given to the UA in a secure way. 3.1.12. Requirement: The SIP protocol authentication mechanisms MUST use SIP SAs which are identified by information not affected by the use of NAT or other mechanisms that alter IP addresses. Explanatory Text: The selection and validation of SA used to authenticate communication between SIP servers and UAs must be based on the SIP identity of the two endpoints, and not on their IP addresses or ports which can be altered by intervening NATs. 3.1.13. Requirement: The SIP protocol security mechanisms must provide for message Authentication and integrity. Jacobs, Nielsen Informational [Page 6] VoIP Signaling Security Requirements October 2002 Explanatory Text: The authentication mechanisms used must assure integrity of the entire message on the network. Any changes to the signaling must be authenticated by a trusted network component. 3.1.14. Requirement: The SIP protocol authentication mechanisms MUST operate across un-trusted domains, between the SIP UA and SIP server in a secure fashion. Explanatory Text: Untrusted intervening networks must not be able to change the content of messages sent between UAs and CAs. 3.1.15. Requirement: The SIP protocol authentication mechanisms must define mechanisms to mitigate replay attacks on the control messages. Explanatory Text: A copy of any message already received by a server or UA must be ignored. This applies to both during the SA setup process as well as during standard call signaling. 3.1.16. Requirement: The SIP protocol authentication mechanisms must operate on SIP UA platforms that may have light-weight processing capabilities, limited non-volatile storage capacity and scant memory resources. Explanatory Text: The authentication mechanism must be inclusive, such that light weight VoIP appliances as well as full featured soft UAs can perform all necessary security functions. The processing power and ability to gather randomness for key generation must not exceed the ability of a light-weight endpoint. Jacobs, Nielsen Informational [Page 7] VoIP Signaling Security Requirements October 2002 3.1.17. Requirement: The SIP protocol authentication mechanisms must provide cryptographic strength equal to or greater than that provided by the HMAC-SHA1-96 method. Explanatory Text: HMAC=SHA1-96 is considered by most as an adequate level of endpoint security for the foreseeable future. 3.1.18 Requirement: An SA must be able to be applied to multiple endpoints on a single device, however it must also be controllable so that by default one identity's SA is to not applied to all endpoints. Explanatory Text: SIP: A single device or platform may execute a UA on behalf of multiple users simultaneously. The authentication of signaling for each UA must be separable by user. 3.1.19. Requirement: A SIP UA's Security Association (SA) with a Call Agent (CA) does not preclude S/MIME end-to-end authentication within the body of the SIP message through that CA. Explanatory Text: An SA between provides authentication to the service provider. This authentication must not interfere with the ability of end-to-end authentication of user identities using S/MIME. Jacobs, Nielsen Informational [Page 8] VoIP Signaling Security Requirements October 2002 3.1.20 Requirement SA expiration and renewal must be reconciled with SIP REGISTRATION expiration semantics. Explanatory Text: A consistent set of rules must exist that relates the registration time of a SIP URI at a given location and the SA used to signal with the endpoint. They may be defined to share expiration times, or they may have separate expiration semantics. Jacobs, Nielsen Informational [Page 9] VoIP Signaling Security Requirements October 2002 3.2. MGCP Protocol Security Requirements 3.2.1. Requirement: The MGCP protocol MUST enable a MGCP Client Agent (MGCP CA), executing within a Voice over IP (VoIP) client, requiring the services of a VoIP Call/Media Gateway Controller (C/MGC) Server, to establish an authenticated MGCP Security Association(SA) between itself and the C/MGC Server. Explanatory Text: This states that the protocol must allow the C/MGC Server to obtain the identity of an MGCP CA and authenticate this identity when the MGCP CA either registers or requests services and allow the C/MGC Server to make a determination as to whether or not the MGCP CA request will/can be allowed. 3.2.2. Requirement: The MGCP protocol MUST allow a MGCP CA to securely communicate with a C/MGC Server that has taken over for a failed C/MGC Server with which an MGCP CA has an existing MGCP SA. Explanatory Text: In any but the most simple network, MGCP CAs will need to interact with more than one C/MGC Server when C/MCG Servers are deployed in redundant configurations using different Server IP addresses. The MGCP protocol security mechanism design must not preclude the ability to do this. 3.2.3. Requirement: The MGCP protocol authentication mechanisms MUST allow a C/MGC Server to securely communicate with more than one MGCP CA simultaneously. Explanatory Text: There may be multiple instances of a single MGCP application or multiple MGCP applications desiring service from a single C/MCG Server, and different MGCP CAs will represent them. The MGCP protocol security mechanisms must not preclude the ability to do so. Jacobs, Nielsen Informational [Page 10] VoIP Signaling Security Requirements October 2002 3.2.4. Requirement: The MGCP protocol authentication mechanisms MUST NOT use the IP address of the host system where an MGCP CA is executing for the identity of the MGCP CA. Explanatory Text: This states that the MGCP protocol authentication mechanism will use information, other that source IP address, to identify an MGCP CA since source IP addresses are routinely modified by Network Address Translation (NAT) or can be spoofed. 3.2.5. Requirement: The MGCP protocol authentication mechanisms running within an MGCP CA MUST NOT need to be configured with knowledge as to the existence of NAT in the interface between the network where the MGCP CA is located and the network where the C/MGC Server is located. Explanatory Text: In any but the most simple network, the network where the MGCP CA ("home" network) is located will connect to a service provider and use NAT to map between the "private" or "non-routable" address space of the MGCP CA's home network and the "public" routable address space of the Service Provider's network. 3.2.6. Requirement: The MGCP protocol authentication mechanisms MUST provide for the mutual authentication of an MGCP CA and C/MGC Server to one another. Jacobs, Nielsen Informational [Page 11] VoIP Signaling Security Requirements October 2002 Explanatory Text: In addition for the more obvious need for the MGCP CA to authenticate itself to the C/MGC Server, there are some attacks against the protocol which can be mitigated by having the C/MGCP Server authenticate to the MGCP CA. 3.2.7. Requirement: The MGCP protocol authentication mechanisms MUST identify MGCP CAs via the use of information elements such as an Network Access Identifier (NAI) (RFC2486) or host name. Explanatory Text: This states that the MGCP protocol authentication mechanism will use application oriented information for identifying an MGCP CA that will not be affected by the presence of NAT or subject to modification by intermediate nodes during transfer between an MGCP CA and a C/MGC Server. 3.2.8. Requirement: The MGCP protocol authentication mechanisms MUST contain version numbers to enable subsequent extensions to support future requirements of applications not considered at this stage. Explanatory Text: We assume that there will be later revisions of this protocol. The initial version will focus on protocol communication security through firewalls and NATs, and it is possible that the protocol will need to be modified, as support for other MGCP functionality is added or deployment scenarios evolve. 3.2.9. Requirement: The syntax and semantics of the MGCP protocol authentication mechanisms MUST be extensible to allow the requirements of future security capabilities to be adopted. Jacobs, Nielsen Informational [Page 12] VoIP Signaling Security Requirements October 2002 Explanatory Text: This is related to, but different from, the requirement for versioning support. As support for additional MGCP security functionality is added there may be a need to add new message field types. 3.2.10. Requirement: The MGCP protocol authentication mechanisms MUST support the ability of an MGCP CA to use a MGCP Security Association (SA) that defines the attributes of the trust relationship between an MGCP CA and a C/MGC Server or an MGCP CA and another MGCP CA. Explanatory Text: This states that the protocol security mechanisms must support authenticated signaling between MGCP CAs and between MGCP CAs and C/MGC Servers. 3.2.11. Requirement: The MGCP protocol authentication mechanisms MUST NOT preclude multiple C/MCG Servers from securely communicating with the same MGCP CA. Explanatory Text: The authorizing C/MCG Service may be deployed on multiple servers at multiple IP addresses. The SA that represents the trust association from a MGCP CA to a C/MCG server or Call Agent should be reused among these servers. The MGCP CA must have rules that define which servers share the same SA, and these rules should be given to the MGCP CA in a secure way. 3.2.12. Requirement: The MGCP protocol authentication mechanisms MUST use MGCP SAs which are identified by information not affected by the use of NAT or other mechanisms that alter IP addresses. Jacobs, Nielsen Informational [Page 13] VoIP Signaling Security Requirements October 2002 Explanatory Text: The selection and validation of SA used to authenticate communication between MGCP endpoints must not be based on their IP addresses or ports which can be altered by intervening NATs. Instead they can be addressed using their endpoint names or other consistent identification method. 3.2.13. Requirement: The MGCP protocol security mechanisms must provide for message Authentication and integrity. Explanatory Text: The authentication mechanisms used must assure integrity of the entire message on the network. Any changes to the signaling must be authenticated by a trusted network component. 3.2.14. Requirement: The MGCP protocol authentication mechanisms MUST operate across un-trusted domains, between MGCP CAs and C/MGC Servers in a secure fashion. Explanatory Text: Untrusted intervening networks must not be able to change the content of messages sent between MGCP endpoints. 3.2.15. Requirement: The MGCP protocol authentication mechanisms must define mechanisms to mitigate replay attacks on the control messages. Explanatory Text: A copy of any message already received by a C/MGC Server or MGCP CA must be ignored. This applies to both during the SA setup process as well as during standard call signaling. Jacobs, Nielsen Informational [Page 14] VoIP Signaling Security Requirements October 2002 3.2.16. Requirement: The MGCP protocol authentication mechanisms must operate on MGCP CA platforms that may have light-weight processing capabilities, limited non-volatile storage capacity and scan memory resources. Explanatory Text: The authentication mechanism must be inclusive, such that light weight VoIP appliances as well as full featured soft UAs can perform all necessary security functions. The processing power and ability to gather randomness for key generation must not exceed the ability of a light-weight endpoint. 3.2.17. Requirement: The MGCP protocol authentication mechanisms must provide cryptographic strength equal to or greater than that provided by the HMAC-SHA1-96 method. Explanatory Text: HMAC=SHA1-96 is considered by most as an adequate level of endpoint security for the foreseeable future. 3.2.18. Requirement: An SA must be able to be applied to multiple endpoints on a single device, however it must also be controllable so that by default one identity's SA is to not applied to all endpoints. Explanatory Text: A single device or platform may execute an MGCP CA on behalf of multiple endpoints simultaneously. The authentication of signaling for each UA must be separable by user, however multiple endpoints associated with the same user can share the same SA. Jacobs, Nielsen Informational [Page 15] VoIP Signaling Security Requirements October 2002 3.3. Megaco/H.248 Protocol Security Requirements 3.3.1. Requirement: The Megaco/H.248 protocol MUST enable a Megaco/H.248 Client Agent (Megaco CA), executing within a Voice over IP (VoIP) client, requiring the services of a VoIP Call/Media Gateway Controller (C/MGC) Server, to establish an authenticated Megaco Security Association(SA) between itself and the C/MGC Server. Explanatory Text: This states that the protocol must allow the C/MGC Server to obtain the identity of a Megaco CA and authenticate this identity when the Megaco CA either registers or requests services and allow the C/MGC Server to make a determination as to whether or not the Megaco CA request will/can be allowed. 3.3.2. Requirement: The Megaco/H.248 protocol MUST allow a Megaco CA to securely communicate with a C/MGC Server that has taken over for a failed C/MGC Server with which a Megaco CA has an existing Megaco SA. Explanatory Text: In any but the most simple network, Megaco CAs will need to interact with more than one C/MGC Server when C/MCG Servers are deployed in redundant configurations using different Server IP addresses. The Megaco/H.248 protocol security mechanism design must not preclude the ability to do this. 3.3.3. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST allow a C/MGC Server to securely communicate with more than one Megaco CA simultaneously. Jacobs, Nielsen Informational [Page 16] VoIP Signaling Security Requirements October 2002 Explanatory Text: There may be multiple instances of a single Megaco/H.248 application or multiple Megaco/H.248 applications desiring service from a single C/MCG Server, and different Megaco CAs will represent them. The Megaco protocol security mechanisms must not preclude the ability to do so. 3.3.4. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST NOT use the IP address of the host system where a Megaco CA is executing for the identity of the Megaco CA. Explanatory Text: This states that the Megaco/H.248 protocol authentication mechanism will use information, other that source IP address, to identify a Megaco CA since source IP addresses are routinely modified by Network Address Translation (NAT) or can be spoofed. 3.3.5. Requirement: The Megaco/H.248 protocol authentication mechanisms running within a Megaco CA MUST NOT need to be configured with knowledge as to the existence of NAT in the interface between the network where the Megaco CA is located and the network where the C/MGC Server is located. Explanatory Text: In any but the most simple network, the network where the Megaco CA ("home" network) is located will connect to a service provider and use NAT to map between the "private" or "non-routable" address space of the Megaco CA's home network and the "public" routable address space of the Service Provider's network. 3.3.6. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST provide for the mutual authentication of a Megaco CA and C/MGC Server to one another. Jacobs, Nielsen Informational [Page 17] VoIP Signaling Security Requirements October 2002 Explanatory Text: In addition for the more obvious need for the Megaco CA to authenticate itself to the C/MGC Server, there are some attacks against the protocol which can be mitigated by having the C/MGCP Server authenticate to the Megaco CA. 3.3.7. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST identify Megaco CAs via the use of information elements such as an Network Access Identifier (NAI) (RFC2486) or host name. Explanatory Text: This states that the Megaco/H.248 protocol authentication mechanism will use application oriented information for identifying Megaco CAs that will not be affected by the presence of NAT or subject to modification by intermediate nodes during transfer between a Megaco CA and a C/MGC Server. 3.3.8. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST contain version numbers to enable subsequent extensions to support future requirements of applications not considered at this stage. Explanatory Text: We assume that there will be later revisions of this protocol. The initial version will focus on protocol communication security through firewalls and NATs, and it is possible that the protocol will need to be modified, as support for other Megaco/H.248 functionality is added or deployment scenarios evolve. 3.3.9. Requirement: The syntax and semantics of the Megaco/H.248 protocol authentication mechanisms MUST be extensible to allow the requirements of future security capabilities to be adopted. Jacobs, Nielsen Informational [Page 18] VoIP Signaling Security Requirements October 2002 Explanatory Text: This is related to, but different from, the requirement for versioning support. As support for additional Megaco/H.248 security functionality is added there may be a need to add new message field types. 3.3.10. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST support the ability of a Megaco CA to use a Megaco/H.248 Security Association (SA) that defines the attributes of the trust relationship between a Megaco CA and a C/MGC Server or a Megaco CA and another Megaco CA. Explanatory Text: This states that the protocol security mechanisms must support authenticated signaling between Megaco CAs and between Megaco CAs and C/MGC Servers. 3.3.11. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST NOT precludeauthenticating multiple C/MCG Serversusing the same SA to the Megaco CA. Explanatory Text: The authorizing C/MCG Service may be deployed on multiple servers at multiple IP addresses. The SA that represents the trust association from a Megaco CA to a C/MCG server or Call Agent should be reused among these servers. The Megaco CA must have rules that define which servers share the same SA, and these rules should be given to the Megaco CA in a secure way. 3.3.12. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST use Megaco SAs which are identified by information not affected by the use of NAT or other mechanisms that alter IP addresses. Jacobs, Nielsen Informational [Page 19] VoIP Signaling Security Requirements October 2002 Explanatory Text: The selection and validation of SA used to authenticate communication between Megaco endpoints must not be based on their IP addresses or ports which can be altered by intervening NATs. Instead they can be addressed using their endpoint names or other consistent identification method. 3.3.13. Requirement: The Megaco/H.248 protocol security mechanisms must provide for message Authentication and integrity. Explanatory Text: The authentication mechanisms used must assure integrity of the entire message on the network. Any changes to the signaling must be authenticated by a trusted network component. 3.3.14. Requirement: The Megaco/H.248 protocol authentication mechanisms MUST operate across un-trusted domains, between Megaco CAs and C/MGC Servers in a secure fashion. Explanatory Text: Untrusted intervening networks must not be able to change the content of messages sent between Megaco endpoints. 3.3.15. Requirement: The Megaco/H.248 protocol authentication mechanisms must define mechanisms to mitigate replay attacks on the control messages. Explanatory Text: A copy of any message already received by a C/MGC Server or Megaco CAs must be ignored. This applies to both during the SA setup process as well as during standard call signaling. Jacobs, Nielsen Informational [Page 20] VoIP Signaling Security Requirements October 2002 3.3.16. Requirement: The Megaco/H.248 protocol authentication mechanisms must operate on Megaco CA platforms that may have light-weight processing capabilities, limited non-volatile storage capacity and scant memory resources. Explanatory Text: The authentication mechanism must be inclusive, such that light weight VoIP appliances as well as full featured soft UAs can perform all necessary security functions. The processing power and ability to gather randomness for key generation must not exceed the ability of a light-weight endpoint. 3.3.17. Requirement: The Megaco/H.248 protocol authentication mechanisms must provide cryptographic strength equal to or greater than that provided by the HMAC-SHA1-96 method. Explanatory Text: HMAC=SHA1-96 is considered by most as an adequate level of endpoint security for the foreseeable future. 3.3.18 Requirement: An SA must be able to be applied to multiple endpoints on a single device, however it must also be controllable so that by default one identity's SA is to not applied to all endpoints. Explanatory Text: A single device or platform may execute an MGCP CA on behalf of multiple endpoints simultaneously. The authentication of signaling for each UA must be separable by user, however multiple endpoints associated with the same user can share the same SA. Jacobs, Nielsen Informational [Page 21] VoIP Signaling Security Requirements October 2002 3.4. General Requirements 3.4.1. Requirement: The security exchange must provide keys to the endpoint to sign downloaded endpoint configuration files. Explanatory Text: Many endpoint types download executable images and configuration files dynamically. These need to be authenticated. Executable images may be signed by the manufacturer, however configuration files cannot. A UA or endpoint must be able to authenticate that files came from the same source that it has an SA with. If configuration files are downloaded prior to establishment of a trust relationship, the signature on these files should be validated after the trust relationship is set up. 3.4.2. Requirement: The SA must be amenable to a Federated Security Model Explanatory Text: The security requirements described here provide for a single authority, an Authoritative Call Agent (ACA), to have many trust relationships with endpoints. Endpoints, in turn must trust that the ACA direct their call to the specified endpoint. The endpoint's identity is specified consistent with the rules of the ACA. In a federated security model a proxy may itself be an ACA that assures the identity of all endpoints behind it, and allows a single security relationship between the ACAs themselves that allows signaling to be forwarded through another ACA to be delivered to the identified endpoint. For two ACAs to do this, the semantics and range of endpoint NAIs they represent must be defined prior to setting up the inter-ACA SA. 3.4.3. Requirement: Human pass-phrases or other base symmetric keys (biometrics, etc.) must not be required to be persistently stored or remain in memory beyond completion of the initial bootstrap authentication process. Jacobs, Nielsen Informational [Page 22] VoIP Signaling Security Requirements October 2002 Explanatory Text: A complete security model depends on minimizing the exposure of persistent keying material. Persisting user-specific long-lived keys on devices is a major vulnerability. This does not however limit the storage of transient keys or device-specific keys. 3.4.4. Requirement: Intervening NAT and proxy devices must not require knowledge of persistent symmetric or private keys. Explanatory Text: A signaling between an endpoint/UA and a Call Agent must go securely through intervening NATs or proxies. The intervening NAT should not have knowledge of persistent keying material of either the UA or CA. 3.4.5. Requirement: Intervening NAT and proxy devices must be able to provide transparent redundancy. Explanatory Text: A signaling between an endpoint/UA and a Call Agent must go securely through intervening NATs or proxies. NAT/proxies must be able to share session keying material for redundancy. 3.4.6. Requirement: The endpoint must be able to reboot and re-establish an SA. Jacobs, Nielsen Informational [Page 23] VoIP Signaling Security Requirements October 2002 Explanatory Text: If an endpoint reboots and looses all persistent data, it still must be able to re-establish or re-use an SA with the Call Agent (CA). The overall security model must include rules on what key and identity material is persisted on an endpoint to limit potential compromise. 3.4.7. Requirement: Application must be aware that an incoming message is authenticated, and to which VoIP identity it has been authenticated. Explanatory Text: 3.4.8. Requirement: SA setup process must not enable attacks which dilute the strength of the persistent key. Explanatory Text: Responses to repeated SA setup requests from sources that do not know an identity's persistent key must not incrementally reduce the strength of any persistent key. 3.4.9. Requirement: All SAs must use session keys. Explanatory Text: SAs between endpoints or UAs or CAs are transient. Setting up the SA depends on using persistent keys. The SA itself must use a separate key for communications, typically a symmetric key for efficiency purposes. Jacobs, Nielsen Informational [Page 24] VoIP Signaling Security Requirements October 2002 3.4.10. Requirement: Session keys must not be based on the previous session key. Explanatory Text: Disclosure of a transient session key must not enable future or past session keys to be discovered. 3.4.11. Requirement: Either end of the SA can cause an SA to expire and be renewed. Explanatory Text: An SA has a limit to its lifetime. The most restrictive policy requested by either end must be honored. Also, if either end of an SA determines that the SA has been compromised or that service should be terminated, the SA can be expired administratively at any time. Once expired, any reuse of an SA should be answered with an "authentication error" message. 3.4.12 Requirement: A non-authenticated source cannot cause any SA to expire. Explanatory Text: An SA cannot expire due to any messages that are not authenticated by their source. This would allow very simple denial of service attacks on individual endpoints. 3.4.13. Requirement: The SA setup process must be resistant to DoS from sources that do not have valid authentication keys. Jacobs, Nielsen Informational [Page 25] VoIP Signaling Security Requirements October 2002 Explanatory Text: The SA setup process must determine whether a request to setup an SA is valid or not with minimal processing and state maintenance to mitigate malicious denial of service attacks as well as misconfigured endpoints. 3.4.14 Requirement: SA setup process must be tolerant of large numbers of authentic new SA setups. Explanatory Text: The large-scale power outage scenario must be handled. The SA setup process must handle very large numbers of endpoints recreating new SAs or persisting pre-existing SAs. This has implications on the efficiency of the model. Jacobs, Nielsen Informational [Page 26] VoIP Signaling Security Requirements October 2002 3.5. Non Requirements 3.5.1. Non-requirement: Globally Certified Identities Explanatory Text: The authentication required here is not absolute. Instead it is relative to the authority running the ACA. Trust between ACA domains is a separate problem. ENUM is addressing these kinds of issues. 3.5.2. Non-requirement: There is no requirement for an external revocation mechanism Explanatory Text: This requires a trust relationship defined only within a single administrative domain. Revocation is an administrative action within that domain, and is not a protocol requirement. 3.5.3. Non-requirement: Negotiation of security parameters. Explanatory Text: There is no requirement to negotiate security parameters or methods. Given that trust is established between a managed domain and an endpoint, minimum key lengths and expiration policies can be dictated by the most conservative of either end of the trust relationship. Still, there is the need to look forward to when this security mechanism is deemed inadequate due to technical advances and discoveries. Given that strength of security is systemic, this suggests that the entire key lifecycle and cryptographic technology should be improved as a new revision providing a whole solution. Lesser incremental improvements are not required. Jacobs, Nielsen Informational [Page 27] VoIP Signaling Security Requirements October 2002 3.5.4. Non-requirement: Encryption and Perfect Forward Secrecy Explanatory Text: Encryption of signaling is not a requirement for large carrier service. PFS applies only to encrypted data. 3.5.5. Non-requirement: Renewal of persistent keying material, such as human passwords or personal certificates and their mapping to an NAI, SIP URI or E.164 number. Explanatory Text: Given that trust is established between a managed domain and users, the persistent keys that enable the trust relationship to be defined can be changed administratively on demand. These processes require some out-of-band interaction. 3.5.6. Non-requirement: Be sure that in almost all cases an endpoint can automatically renegotiate an SA. Explanatory Text: Endpoint device reboot should not cause the user to lose service. However, it is possible to come up with situations where the endpoint must renew its transient key. It is acceptable that there be corner cases that require re-entry of the user's persistent passphrase (or other persistent keying material) to re-establish an SA with a CA. Stated another way, do not allow any false positives, but there is an allowance for a very small percentage of false negatives. 4. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which Jacobs, Nielsen Informational [Page 28] VoIP Signaling Security Requirements October 2002 any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards- track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 5. Security Considerations The security requirements for the SIP, MCGP and Megaco/H.248 VoIP Signaling protocols are discussed throughout section 3 of this document. 6. Normative References RFC-2119 Key words for use in RFCs to Indicate Requirement Levels, BCP 14, S. Bradner, March 1997 RFC 2401 Security Architecture for the Internet Protocol, S. Kent, R. Atkinson, November 1998. RFC 2402 IP Authentication Header, S. Kent, R. Atkinson, November 1998. RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH, C. Madson, R. Glenn, November 1998. RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV, C. Madson, N. Doraswamy, November 1998. RFC 2406 IP Encapsulating Security Payload (ESP), S. Kent, R. Atkinson, November 1998. RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP, D. Piper, November 1998. Jacobs, Nielsen Informational [Page 29] VoIP Signaling Security Requirements October 2002 RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP), D. Maughan, M. Schertler, M. Schneider, J. Turner, November 1998. RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec, R. Glenn, S. Kent, November 1998 RFC 2434 "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, Narten, T. and H. Alvestrand, October 1998. RFC 2486 The Network Access Identifier, B. Aboba, M. Beadles, January 1999. RFC 2705 Media Gateway Control Protocol (MGCP) Version 1.0, M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, October 1999. RFC 3015 Megaco Protocol Version 1.0, F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers, November 2000. RFC 3149 MGCP Business Phone Packages, A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram, September 2001. RFC 3261 SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, June 2002. 7. Authors' Addresses Stuart Jacobs Verizon Laboratories 40 Sylvan Road Phone: +1-781-466-3076 Waltham, MA. USA 02451 Email: stu.jacobs@verizon.com Eric Nielsen Sylantro Systems 910 E. Hamilton Ave Phone: +1-408-626-2345 Campbell, CA. USA Email: eric.nielsen@sylantro.com 8. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such Jacobs, Nielsen Informational [Page 30] VoIP Signaling Security Requirements October 2002 copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Jacobs, Nielsen Informational [Page 31]