SECURITY GUIDANCE FOR ITU-T RECOMMENDATIONS
WTSA-2004 Resolution 50 identifies that the converged legacy networks and IP networks are potentially more vulnerable to intrusion if adequate care is not taken in the security design and management. Resolution 50 resolves that the ITU-T evaluate existing and evolving new Recommendations, especially signalling and communications protocol recommendations, with respect to their security considerations.
The intent of this document is to provide guidance to authors and reviewers of ITU-T Recommendations to consistently address security considerations within their Recommendations.
Telecommunication network security requirements are specified in Recommendation E.408. This Recommendation provides an overview and framework that identifies security threats to telecommunication networks in general (both fixed and mobile; both voice and data) and gives guidance for planning countermeasures that can be taken to mitigate the risks arising from the threats. This Recommendation is generic in nature and does not identify or address requirements for specific networks.
While it is not practical that all Recommendations be immune to all forms of threats and attacks, it is still necessary for authors of ITU-T Recommendations to address three essential questions with regards to security:
What are the threats and what kind of protection is needed to counter these threats?
What are the distinct types of network equipment and facility groupings that need to be protected?
What are the distinct types of network activities that need to be protected?
One way to answer these questions, and to ensure that ITU-T Recommendations adequately addresses security considerations, is to ensure alignment with a recognized security architecture.
A useful security architecture to help answer these questions is illustrated by Figure 3 of Rec. X.805 Security architecture for systems providing end to end communications (2003).
Figure 3/X.805 – Security architecture for end-to-end network security
The architecture identifies threats/attacks, vulnerabilities, security dimensions, security layers, and security planes. Additional detailed information may be found in Rec. X.805.
Recommendation X.805 identifies security issues that need to be addressed in order to prevent both intentional threats as well as accidental threats. The following threats are described in section 9 of Rec. X.800 (1991), Security architecture for Open Systems Interconnection for CCITT applications:
destruction of information and/or other resources;
corruption or modification of information;
theft, removal or loss of information and/or other resources;
disclosure of information;
interruption of services.
In addition, the IETF Best Current Practice RFC 3552 Guidelines for Writing RFC Text on Security Considerations also describes an Internet Threat Model including several attack descriptions.
5Applying the Security Architecture to ITU Recommendations
The security architecture can be applied to any type of network at any level of the protocol stack. For example, in an IP network, which resides at layer three of the protocol stack, the infrastructure layer refers to the individual routers, the point-to-point communications links between the routers (e.g., SONET, ATM PVCs, etc.), and server platforms used to provide the support services required by an IP network. The services layer refers to the basic IP service itself (e.g., Internet connectivity), the IP support services (e.g., AAA, DNS, DHCP, etc.), and advanced value-added services offered by the service provider (e.g., VoIP, QoS, VPN, etc.). Finally, the applications layer refers to the security of user applications that are to be accessed via the IP network (such as email, etc.).
Authors of ITU-T Recommendations should look to Rec. E.408 for security requirements and to Rec. X.805 section 10 for a methodical approach to adequately consider security within their Recommendation. A series of 9 modules have been generated that raises security considerations for a security layer with a security plane for the eight security dimensions.
As an example, a module is described for securing the control plane of the services layer. This module consists of securing the control or signalling information used by the network service. For example, issues of securing the SIP protocol that is used to initiate and maintain the VoIP sessions are addressed here.
Recommendation X.805 defines security dimension as a set of security measures designed to address a particular aspect of the network security. Properly designed and implemented security dimensions support security policy that is defined for a particular network and facilitate the rules set by the security management.
It is essential to identify the security requirements of a protocol in the initial stages of its development. Consideration of the security dimensions may assist this process. The X.805 list of security dimensions presents an extensive inventory of the available types of security protection. A decision on whether a particular dimension should be addressed in the protocol’s design depends on security requirements that defined by an applicable security policy, network environment where protocol will function, and considerations for cost-efficiency of the projected security solutions. Thus, determination of a subset of security dimensions to be addressed can be recommended as the first step in designing a secure protocol. Below is the list of the X.805 security dimensions with implementation-related information.
Access control security dimension
The access control security dimension protects against unauthorized use of network resources. Access control ensures that only authorized personnel or devices are allowed access to network elements, stored information, information flows, services and applications. In addition, Role-Based Access Control (RBAC) provides different access levels to guarantee that individuals and devices can only gain access to, and perform operations on, network elements, stored information, and information flows that they are authorized for. Access control cannot be properly accomplished without authentication. RADIUS is the protocol that is widely deployed and commonly used for access control and authentication. Another example of an AAA (Authentication, Authorization, Accounting) protocol is Diameter – a new IETF protocol. Diameter has been designed as a more secure, more reliable than RADIUS protocol, it also has several additional capabilities that meet requirements of the modern applications. It is highly advisable to re-use solutions of the RADIUS, Diameter and other existing protocols while designing a new protocol with authorization requirements.
Authentication security dimension
The authentication security dimension serves to confirm the identities of communicating entities. Authentication ensures the validity of the claimed identities of the entities participating in communication (e.g., person, device, service or application) and provides assurance that an entity is not attempting a masquerade or unauthorized replay of a previous communication. Along with mentioned RADIUS and Diameter protocols the Extensible Authentication Protocol (EAP) can serve as a source of solutions for authentication. EAP (another IETF protocol) allows for the use of various authentication methods without costly changes on the Network Access Servers (NAS). Both RADIUS and Diameter are capable of carrying EAP messages. IEEE 802.1x protocol is designed to carry EAP messages over wireless connection between Wi-Fi client and Access Point (AP). The cryptographic key generation and distribution that is most commonly done in conjunction with the authentication phase, also should be a major concern for the designers of the protocols that need to meet additional security requirements (e.g. communication security, data confidentiality, data integrity). The authentication solutions that have been specified by EAP and 802.1x could be useful for designing of new secure protocols that have to provide authentication.
Non-repudiation security dimension
The non-repudiation security dimension provides means for preventing an individual or entity from denying having performed a particular action related to data by making available proof of various network-related actions (such as proof of obligation, intent, or commitment; proof of data origin, proof of ownership, proof of resource use). It ensures the availability of evidence that can be presented to a third party and used to prove that some kind of event or action has taken place. The various elaborate cryptographic methods are the main foundation for technical solutions for non-repudiation.
Data confidentiality security dimension
The data confidentiality security dimension protects data from unauthorized disclosure. Data confidentiality ensures that the data content cannot be understood by unauthorized entities. Encryption, access control lists and file permissions are methods often used to provide data confidentiality. Although a protocol cannot ensure confidentiality of the data at the end of the communication channel (this is out of a protocol’s scope) it must provide encryption of the data being transmitted and it should convey the requirements to confidentiality of stored data when needed.
Communication security dimension
The communication security dimension ensures that information flows only between the authorized end points (the information is not diverted or intercepted as it flows between these end points). When information flows through open networks (e.g. Internet), encryption is the only way to secure it. The widely used protocols for providing communication security are Transport Layer Security protocol (TLS) and IP Security protocol (IPsec) specify solutions that could be used for development of a protocol with requirements of communication security.
Data integrity security dimension
The data integrity security dimension ensures the correctness or accuracy of data. The data is protected against unauthorized modification, deletion, creation, and replication and provides an indication of these unauthorized activities. More information on data integrity and the mechanisms for ensuring data integrity is available in ITU-T Recommendation X.800 (it should be noted that the Recommendation X.805 inherits some major concepts of the X.800 and compliments it with security solutions tailored for the systems providing end-to-end communications).
Availability security dimension
The availability security dimension ensures that there is no denial of authorized access to network elements, stored information, information flows, services and applications due to events impacting the network. Disaster recovery solutions are included in this category. Although a protocol alone cannot ensure availability of the services it supports, it can provide solutions that would assist for providing availability. For example, it can keep count of connections established by a communicating entity and limit the number of connections attempted by a malicious user, thus preventing the denial of service attack against other users’ legitimate requests.
Privacy security dimension
The privacy security dimension provides for the protection of information that might be derived from the observation of network activities. Examples of this information include web-sites that a user has visited, a user's geographic location, and the IP addresses and DNS names of devices in a service provider network. A protocol may be required to provide privacy protection. The IETF GEOPRIV Working Group (WG) is chartered to assess the authorization, integrity and privacy requirements that must be met in order to transfer geographic location information, or authorize the release or representation of such information through an agent. Although geographic location information is only one kind of information that need privacy protection, the GEOPRIV WG approach can serve as valuable input for the developers of the new protocols with requirements to privacy.
5.2Using the concept of security layers in designing secure protocols
Recommendation X.805 identifies a hierarchy of network equipment and facility groupings, which are referred to as security layers. The Recommendation defines three security layers:
– the Infrastructure Security Layer;
– the Services Security Layer and;
– the Applications Security Layer
The security architecture addresses the fact that each layer has different security vulnerabilities and offers the flexibility of countering the potential threats in a way most suited for a particular security layer.
It should be noted that security layers (as defined above) represent a separate category and all three security layers can be applied to each layer of the OSI reference model.
Security dimensions must be applied to these security layers in order to enable end-to-end security solutions. When designing a secure protocol it is essential to identify security layer(s) that will be involved in the protocol’s work. Establishing such logical link between the protocol and the relevant security layer(s) allows to employ X.805 as a guide for identifying the objectives that can be achieved by application of security dimensions to security layers. Understanding of which security layers support a protocol’s functioning would also aid in deciding on what security solutions (that could be built into the security layers) the future protocol may rely.
5.3Using the concept of security planes in designing secure protocols
The security planes are another powerful concept introduced by the Recommendation X.805. The Recommendation defines security plane as a certain type of network activity protected by security dimensions. It identifies three security planes to represent the three types of protected activities that take place on a network. The security planes are:
– the Management Security Plane;
– the Control Security Plane; and
– the End-User Security Plane.
These security planes address specific security needs associated with network management activities, network control or signaling activities, and end-user activities correspondingly. Rec. X.805 provides detailed description of the security planes that could be used for identifying the activities a protocol will be involved in and for “mapping” of the protocol’s activities to the security planes of Rec. X.805.
6. Reporting Results of Security Evaluation
SG17 recommends that evaluation of security considerations be conducted by layer and plane, with the results summarized in tabular form with a summary column to describe the extent to which the security objectives are met.