4ITU Plenipotentiary Conference Resolution Strengthening the role of ITU in information and communication network securityresolvesto review ITU's current activities in information and communication network security;to intensify work within existing ITU study groups in order to:a) reach a common understanding on the importance of information and communication network security by studying standards on technologies, products and services with a view to developing recommendations, as appropriate;b) seek ways to enhance exchange of technical information in the field of information and communication network security, and promote cooperation among appropriate entities;c) report on the result of these studies annually to the ITU Council.
5Website www.itu.int/wsis/ Phase 1 Output Documents: Two Phases:Geneva, 10–12 December 2003Tunis, 16–18 November 2005WebsitePhase 1 Output Documents:Declaration of PrinciplesPlan of ActionURL: >>
6Declaration of Principles Build confidence and security in the use of ICTs (Sec.5, pg.5, para.35, 36, 37)Strengthening the trust frameworkPrevention of cybercrime/misuse of ICTFight SPAM (unsolicited electronic messages)
7Plan of Action (Action Line C5) Cooperation of all stakeholders (gov’ts, civil society, private sector)Guidelines, legislation, share good practicesUser education (privacy, etc)National legal instruments for formal recognition of electronic documents (e.g. authentication)Strengthen real-time incident handling and responseDevelopment of secure and reliable applicationsContributions to the intergov’l agencies working groups (e.g. ITU)
9A Taxonomy… General Guidance/Architecture Network perspective Users’ perspectiveSystem/Application-SpecificSecure InfrastructureEnd-to-end security
10General Guidance Overall concepts and architecture Public Key Infrastructure (PKI) / Privilege Management Infrastructure (PMI)Incident Handling
11Specific Implementations Secure InfrastructureThe underlying network provides the needed securityIP Cablecom ( IETF’s IPSec)Segregated Management PlaneSignalling (SS7, BICC)RestorationEnd-point securityDoes not assume that underlying network is capable to provide needed security (e.g. H.323 system and T.36 secure fax transmission)
12Areas of work Not only IP !!! General Guidance ITU-T Study Group 17 (Lead SG for Communications Security)ITU-T Study Group 2System/Application-SpecificITU-T Study Group 16 (Multimedia, H.323 in particular)ITU-T Study Group 9 (IP-Cablecom)ITU-T Study Group 4 (Management)ITU-T Special Study Group IMT2000 & BeyondITU-T Study Group 11 (Signalling)
13Vulnerabilities, Threats and Risks Vulnerability: by threat model (e.g. SS7), design (e.g. Ambiguities in BGP), implementation (e.g. SNMP, ASN.1) or configuration (e.g b)Threat: people willing to exploit a vulnerability (hackers, criminals, terrorists, etc)Risk: the consequences of such an exploitation (data loss, fraud, loss of public confidence, etc)While threats change over time, security vulnerabilities exist throughout the life of a protocol Risks must be continuously reassessed !!!BGP4: Border Gateway Protocol 4 (IETF RFC 1771). Its design implies that an ASN.1 of 0 is illegal, while the specification itself allows 0 (and 65535).What happens when an ASN of 0 is advertised? Different implementations probably handle this differently. Such protocol inconsistencies are at the root of many attacks on specific implementations.
15ITU-T Study Groups www.itu.int/ITU-T/ SG Operational aspects of service provision, networks and performanceSG Tariff and accounting principles including related telecommunications economic and policy issuesSG Telecommunication management, including TMNSG Protection against electromagnetic environment effectsSG Outside plantSG Integrated broadband cable networks and television and sound transmission SG Signalling requirements and protocolsSG End-to-end transmission performance of networks and terminalsSG Multi-protocol and IP-based networks and their internetworkingSG Optical and other transport networksSG Multimedia services, systems and terminalsSG Data networks and telecommunication softwareSSG Special Study Group "IMT-2000 and beyond"TSAG Telecommunication Standardization Advisory GroupCoordination role and focusSG17 Data networks and software for TelecommunicationCoveredSG 2 Operational aspects of service provision, networks and performanceSG 9 Integrated broadband cable networks and television and sound transmission SG 13 Multi-protocol and IP-based networks and their internetworkingSG 16 Multimedia services, systems and terminalsSG 4 Telecommunication management, including TMNSG 5 Protection against electromagnetic environment effectsSG 6 Outside plantSSG Special Study Group "IMT-2000 and beyond"
17ITU-T Study Group 17Lead Study Group for Communication System SecurityCoordination/prioritization of security effortsDevelopment of core security RecommendationsManage the ITU-T Security ProjectMaintain Compendia on Security-related Recommendations and Security DefinitionsExisting Recommendations includeSecurity architecture, model, frameworks, and protocols for open systems (X.800- & X.270-series)Trusted Third Party Services (X.842/X.843)Public-key and attribute certificate frameworks (X.509)Security architecture for end-to-end communications (X.805)X.509 (Approved)Information technology – The Directory: Public-key and attribute certificate frameworksThis Recommendation defines a framework for public-key certificates and attribute certificates. These frameworks may be used to profile application to Public Key Infrastructure (PKI) and Privilege Management Infrastructures (PMI). Also, this Recommendation defines a framework for the provision of authentication services by Directory to its users. It describes two level of authentication: simple authentication, using a password as a verification of clamed identity; and strong authentication, involving credentials formed using cryptographic techniques.X.842 (Approved) [Q13/7]Information technology – Security techniques – Guidelines for the use and management of Trusted Third Party servicesThis Recommendation provides guidance for the use and management of Trusted Third Party (TTP) services, a clear definition of the basic duties and services provided, their description and their purpose, and the roles and liabilities of TTPs and entities using their services. This Recommendation identifies different major categories of TTP services including time stamping, non-repudiation, key management, certificate management, and electronic notary public.X.843 (Approved) [Q13/7]Information technology – Security techniques – Specification of TTP services to support the application of digital signaturesThis Recommendation defines the services required to support the application of digital signatures for non repudiation of creation of a document. Since this implies integrity of the document and authenticity of the creator, the services described can also be combined to implement integrity and authenticity services.X.805 next slide
18ITU-T SG 17 Security Focus Authentication (X.509) – Rev.Planned: 2005Ongoing enhancements as a result of more complex uses: alignment with LDAP; distributed page resources; otherSecurity Architecture (X.805) Approved 2003For end-to-end communicationsTelebiometric Multimodal Model (X.1081, ex-X.tb)A framework for the specification of security and safety aspects of telebiometricsSecurity Management System (X.1051, ex-X.ism)For risk assessment, identification of assets and implementation characteristicsMobile Security (X.1121 and X.1122, ex-X.msec)For mobile end-to-end data communications
19X.805 - Security Architecture for End-to-End Communications Three Layers***Three Planes†††††A Security Dimension is a set of security measures designed to address a particular aspect of the network security. This Recommendation identifies eight such sets that protect against all major security threats. These dimensions are not limited to the network, but extend to applications and end user information as well. In addition, the Security Dimensions apply to Service Providers or enterprises offering security services to their customers. The Security Dimensions are: (1) Access Control, (2) Authentication, (3) Non-repudiation, (4) Data Confidentiality, (5) Communication Security, (6) Data Integrity, (7) Availability, and (8) Privacy.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.Authentication Security DimensionThe 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.Non-repudiation Security DimensionThe 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.Data Integrity Security DimensionThe 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.* Conventional Security dimensions† New concepts in X.805 (next slide)Vulnerabilities can exist in each Layer, Plane and Dimension72 Security Perspectives (3 Layers 3 Planes 8 Dimensions)
20X.805 – Security Dimensions X.805 differentiates Privacy (association of users to their action) /Confidentiality (eavesdropping, tampering, etc)Communication security dimension ensures that information flows only between authorized end points (information is not diverted or intercepted between these end points)Access Control security: prevention of unauthorized access to resources. It is related but beyond authentication.Availability dimension: avoid network interruption (includes network restoration, disaster recovery, etc)Access Control Security DimensionThe 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.Privacy Security DimensionThe 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.Data Confidentiality Security DimensionThe 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.Communication Security DimensionThe 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).Availability Security DimensionThe 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.
21Mobile Security – Multi-part standard X.1121 – Framework of security technologies for mobile end-to-end data communications - describes security threats, security requirements, and security functions for mobile end-to-end data communication- from the perspectives of the mobile user and application service provider (ASP)X.1122 – Guideline for implementing secure mobile systems based on PKI- describes considerations of implementing secure mobile systems based on PKI, as a particular security technologySecurity Policy (under development)- different quality of security service needs to satisfy various requirements of security services of both user and ASP
22Telebiometrics – X.1081Model for security and public safety in telebiometricsAuthentication based on “what you are” instead of “what you know” (PIN #,etc) – augments “what you have” (ID cards, etc)Biometric authenticationProvide a framework for developing a taxonomy of biometric devicesFacilitate the development of authentication mechanisms based on both static (e.g., fingerprints) and dynamic (e.g. gait or signature pressure variation) personal attributes
23SG 17 security challengeSG 17 is the “Lead Study Group” for security issues in ITU-T >>Lead Study Group work is organized into several questions:G/17, Security ProjectH/17, Security Architecture and FrameworkI/17, Cyber SecurityJ/17, Security ManagementK/17, TelebiometricsL/17, Secure Communication Services(Note: Question numbers above will be revised after WTSA-04)
25Security studies in ITU-T SG 16 (application-specific) “Lead Study Group” on Multimedia and on E-business/E-Commerce >>Focal point for security issues in the SG: Question G/16 - “Multimedia Security”Secure H.323-based IP TelephonyH.235 and associated security profilesH.530: Security for H.323 mobilitySecure H.320 Audio/Video and T.120 Data ConferencingSecure H.248 Media Gateway DecompositionH.350-series: MM Directory (H.235 extension)T.36: Secure fax transmissionSecurity aspects in TDR & E-healthThe security work in SG 16 is coordinated by Q.G.Q.G is a horizontal question, which means that it coordinates the work across different questions that define the different terminals for specific transport technologies.More details on the work of the question can be found from the SG16 web page as well as from Annex G of the Mediacom Project description, also available from the SG16 web page,
26Functional view of H.323H.323 was the first VoIP protocol ever defined
28H.323 SystemThe H.323 system provides for packet-based multimedia conferencing services, including monomedia applications such as voice-over-IP. Besides H.323, the following Recommendations are part of the H.323 System:H – Describes three signalling protocols (RAS, Call Signalling, and “Annex G”)H.245 – Multimedia control protocol (common to H.310, H.323, and H.324)H.235 – Security within H.245-based systemsH.246 – Interworking with the PSTNH.350-series – MM Directory ServicesH.360 – QoS MM ArchitectureH.450.x – Supplementary servicesH.460.x – Various H.323 protocol extensionsH.501 – Protocol for mobility management and inter/intra-domain communicationH.510 – User, terminal, and service mobilityH.530 – Security specification for H.510
29Endpoint Security Provision for H.323 AVApplicationsAudioG.711G.722G.723.1G.729VideoH.261H.263EncryptionRTCPH.225.0TerminaltoGatekeeperSignaling(RAS)Terminal Control and ManagementDataSecurityCapabilitiesT.124T.125Unreliable Transport / UDP, IPXReliable Transport / TCP, SPXNetwork Layer / IP / IPSecLink Layer /......Physical Layer / .....T.123Scope of H.323Scope of H.235TLS/SSLMultimedia Applications, User InterfaceAuthenti-cationRTPScope of T.120Call(Q.931)H.245SystemControlTransport ScopeThis slide illustrates the H.323 protocol stack and components.Rec H.235 covers authentication and privacy of all real-time media streams exchanged during a conference.-the dotted areas shows the terminal part addressed in H.323 and the red parts the security features defined in H.235.-->You can find a complete presentation of the SG16 work on security in the workshop which was held in Seoul, Korea
30Secure Fax Transmission (ITU-T Rec. T.36) Encryption of end-points using HKM/HFX40 or RSASecurity services:Mutual authentication (mandatory).Security service (optional), which includes Mutual authentication, Message integrity, and Confirmation of message receipt.Security service (optional), which includes Mutual authentication, Message confidentiality (encryption), and Session Key establishment.Security service (optional), which includes Mutual authentication, Message integrity, Confirmation of message receipt, Message confidentiality (encryption), and Session Key establishment.HKM [T.30] [T.36] Hawthorne Key Management algorithmHFX [T.30] [T.36] Hawthorne Facsimile Cipher 40 refers to 40-bit session keysRSA [H.235] [T.30] [T.36] Rivest, Shamir and Adleman (public key algorithm)
32Security studies in ITU-T SG 9 (application specific) IPCablecom projectInteractive services over cable TV networks using IP protocolJ.170, IPCablecom security specificationTypes of threat in IPCablecom:Network attacksTheft of serviceEavesdroppingDenial of ServiceSecurity based on IPSec mechanismsRecommendation J.170IPCablecom security specificationThis Recommendation defines the Security Architecture, protocols, algorithms, associated functional requirements and any technological requirements that can provide for the security of the system for the IPCablecom network. Authentication, access control, message and bearer content integrity, confidentiality and non-repudiation security services must be provided as defined herein for each of the network element interfaces.
34IPCablecom Recommendations ArchitectureJ.160 ArchitectureSignallingJ.162 Network Call Signalling (NCS)J.165 IPCablecom Signalling Transport ProtocolJ.171 Trunk Gateway Control ProtocolQuality of ServiceJ.163 Dynamic QoSMedia/CodecsJ.161 Audio Codec ReqsOSSJ.164 Event MessagingJ.166 MIB FrameworkJ.167 MTA ProvisioningJ.168 MTA MIBJ.169 NCS MIBSecurityJ.170 Security
35Security studies in other SGs E.408 (ex-E.sec.1): Telecommunication networks security requirements >>E.409 (ex-E.sec.2): Incident organization and security incident handling >>Handbook on IP Policy (under development) >>SG 13Y.1271 (ex-Y.roec): Framework to support emergency communications >>Will include a clause on Security in all Recommendations to be developedSGs 4, 11, 15, SSGIncorporating security requirements in their Recommendations (see supplemental material)Draft new E.sec.1 – Telecommunication networks security requirementsThis 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.Draft new E.sec.2 – Incident Organisation and Security Incident Handling (Guidelines)The purpose of this Recommendation is to analyse, structure and suggest a method for establishing an incident management organisation, where the flow and structure of an incident are focused. The flow and the handling are useful in determining whether an event is to be classified an event, an incident, a security incident or a crisis. The flow also covers the critical first decisions that have to be made.In the trails of the heavily increased use of computer in society follows computer crime. Over the last years computer crime has literally exploded, which is confirmed by several international and national surveys. In the majority of countries there are no exact figures on the number of computer intrusions as the incidents.Most organisations or companies don’t have any organisation for handling IT security incidents. When an IT security incident occurs it is handled ad hoc, i.e. the person who detects an IT security incident have/take the responsibility to handle it the best (s)he can. In some organisations one tend to forget and cover up IT security incidents as they may affect production, availability and revenues.Oftenly when an IT security incident is detected, the person who detects it doesn’t know whom to report it to. Within the computer field this leads to that the system or networks administrator issues a workaround or quick fix just to get rid of the problem. They do not have the time to correct the system so that the IT security incident does not recur. These are the main reasons why we need a trained unit or group that can handle security incidents in a prompt and correct manner.When reporting or handling an incident, the use of different taxonomy leads to misunderstanding. This may, in turn, lead to that an IT security incident neither gets proper attention nor prompt handling that is needed in order to stop, contain and hinder the incident from recur. This may lead to serious consequences for the affected organisation (victim).To be able to succeed in incident handling and incident reporting one must have an understanding of how incidents are detected, handled and resolved. By establishing a general structure for incidents (i.e. physical, administrative or organisational, and logical incidents) it is possible to obtain a general picture of the structure and flow of an incident. A uniform terminology is the base for a common understanding of words and terms.
36Security collaboration ISO/IEC JTC 1, Information TechnologySC 6, Telecommunications and Information Exchange Between SystemsSC 27, IT Security TechniquesSC 37, BiometricsIETF
37Other ITU-T Resources Security Manual SG 17’s Catalogue of ITU-T Security RecommendationsSG 17’s Compendium of Security DefinitionsWorkshops
38ITU-T Manual on Security in Telecommunications and Information Technology A.k.a. the “Security Manual”An overview of issues and the deployment of existing ITU-T Recommendations for secure telecommunicationsPrepared by TSB with support from experts1st edition: Dec.2003; 2nd: Oct.2004
39“Security Manual” – Some Details Highlights and offers a bird’s eye view of how to use numerous ITU-T Recs to secure the communication infrastructure and associated services and applicationsValue added: how to use ITU-T Recs help to solve security issues – not a description of themFocuses on completed work, not upcoming/ ongoing workFree download:
40Catalogue of ITU-T Security Recommendations http://www. itu Example: ITU-T Rec. X.509Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks (03/00 – v4)“This Recommendation defines a framework for public-key certificates and attribute certificates, and defines a framework for the provision of authentication services by Directory to its users. It describes two levels of authentication: simple authentication, using a password as a verification of claimed identity; and strong authentication, involving credentials formed using cryptographic techniques.X.400 – Message handlingX.500 – The directoryX.800 – Open systems securityT.36 – Secure G3 facsimileJ.170 – IPCablecom security specificationM.3016 – Security requirements for TMNM Security Management for IMT-2000X.509ApprovedInformation technology - Open Systems Interconnection - The Directory: Authentication framework(1993 edition – version 2)Information technology - Open Systems Interconnection - The Directory: Authentication framework (1997 edition – version 3)Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks (03/00 – version 4)This Recommendation defines a framework for public-key certificates and attribute certificates. These frameworks may be used to profile application to Public Key Infrastructures (PKI) and Privilege Management Infrastructures (PMI). Also, this Recommendation defines a framework for the provision of authentication services by Directory to its users. It describes two levels of authentication: simple authentication, using a password as a verification of claimed identity; and strong authentication, involving credentials formed using cryptographic techniques. While simple authentication offers some limited protection against unauthorized access, only strong authentication should be used as the basis for providing secure services.X.842Information technology – Security techniques – Guidelines for the use and management of Trusted Third Party servicesThis Recommendation provides guidance for the use and management of Trusted Third Party (TTP) services, a clear definition of the basic duties and services provided, their description and their purpose, and the roles and liabilities of TTPs and entities using their services. This Recommendation identifies different major categories of TTP services including time stamping, non-repudiation, key management, certificate management, and electronic notary public.Q13/7X.843Information technology – Security techniques – Specification of TTP services to support the application of digital signaturesThis Recommendation defines the services required to support the application of digital signatures for non repudiation of creation of a document. Since this implies integrity of the document and authenticity of the creator, the services described can also be combined to implement integrity and authenticity services.T.36Security capabilities for use with Group 3 facsimile terminalsThis Recommendation defines the two independent technical solutions which may be used in the context of secure facsimile transmission. The two technical solutions are based upon the HKM/HFX40 algorithms and the RSA algorithm.SG16J.170 (J.sec)DraftIPCablecom security specificationThis Recommendation defines the Security Architecture, protocols, algorithms, associated functional requirements and any technological requirements that can provide for the security of the system for the IPCablecom network. Authentication, access control, message and bearer content integrity, confidentiality and non-repudiation security services must be provided as defined herein for each of the network element interfaces.SG9M.3016Overview of TMN SecurityThis recommendation (previously M.3sec) provides general overview and a tutorial of the security needs of the TMN.SG4M.3210Security Management for IMT-2000 (M.IMTSEC)This recommendation is one of the series of TMN Management Service recommendations that provide description of management services, goals and context for management aspects of IMT2000 networks. This recommendation describes a subset of Security Management services to provide Requirements and Analysis of the Security management and a profile for fraud management. The emphasis is on the X interface between two service providers and the management services needed between the two to detect and prevent fraud by operating the Fraud Information Gathering System (FIGS) as means to monitor a defined set of subscriber activities to limit their financial exposure to large unpaid bills produced on subscriber accounts whilst the subscriber is roaming.X.400/ F.400Message handling system and service overviewThis Recommendation defines Message Handling System (MHS) elements of service for User Agent (UA)-to-UA, Message Transfer Agent (MTA)-to-MTA, UA-to-MTA, and UA-to-Message Store (MS) security services of confidentiality, integrity, authentication, non-repudiation and access control identified as relevant to the Application Layer.Q11/7X.800Security architecture for Open Systems Interconnection for CCITT applicationsThis Recommendation defines the general security-related architectural elements which can be applied appropriately in the circumstances for which protection of communication between open systems is required. It establishes, within the framework of the Reference Model, guidelines and constraints to improve existing Recommendations or to develop new Recommendations in the context of OSI in order to allow secure communications and thus provide a consistent approach to security in OSI. This Recommendation extends the Reference Model to cover security aspects which are general architectural elements of communications protocols, but not discussed in the Reference Model. This Recommendation:provides a general description of security services and related mechanisms, which may be provided by the Reference Model; and defines the positions within the Reference Model where the services and mechanisms may be provided.
41Catalogue example: ITU-T Rec. X.509 (cont’d) While simple authentication offers some limited protection against unauthorized access, only strong authentication should be used as the basis for providing secure services. The frameworks defined may be used to profile application to Public Key Infrastructures (PKI) and Privilege Management Infrastructures (PMI). The framework for public-key certificates includes specification of data objects used to represent the certificates themselves as well as revocation notices for issued certificates that should no longer be trusted. While it defines some critical components of a PKI, it does not define a PKI in its entirety. However, it provides the foundation upon which full PMIs and their specifications would be built. Information objects for holding PKI and PMI objects in the Directory and for comparing presented values with stored values are also defined.
42Compendium of Security Definitions http://www. itu Example: Definitions of public-key3.3.43/X.509(In a public key cryptosystem) that key of a user’s key pair which is publicly known.3.3.11/X.810A key that is used with an asymmetric cryptographic algorithm and that can be made publicly available.3(26)/J.170The key used in public key cryptography that belongs to an individual entity and is distributed publicly. Other entities use this key to encrypt data to be sent to the owner of the key.Authentication1) The process of corroborating an identity. Note -- See principal and verifier and the two distinguished form of authentication (data origin auth. + entity auth.). Authentication can be unilateral or mutual. Unilateral authentication provides assurance of the identity of only one principal. Mutual authentication provides assurance of the identities of both principals.2) The provision of assurance of the claimed identity of an entity.3) See data origin authentication, and peer entity authentication. Note - In Rec. X.800 the term “authentication” is not used in connection with data integrity; the term “data integrity” is used instead.1) Int.,5.1,5.2.4 /X.8112) 3.3/X.8113) 3.3.7/X.800
43Security Workshops (Past and Future) ITU-T Workshop on Security Seoul, Korea, May 2002ITU workshop - Creating trust in critical network Infrastructures Seoul, Korea, May 2002Cybersecurity Symposium Florianópolis, Brazil, 4 October 2004
44ConclusionsITU-T has actively dealt with security issues long before IP & the InternetITU-T has significant work in the General Guidance/ Framework area as well as security for specific systems (H.323, IPCablecom, etc)Security issues are considered in relevant ITU-T Study Groups to minimize security vulnerabilities of the design and threat-model categoriesHigh-level Guidelines (WTSA, WSIS) reinforce the importance of ITU-T Security work for acceptance of ICTs and bridging the “Digital Divide”In addition to Recommendations, several ITU-T resources are available: Workshops, Manual, Glossary and Compendium
45Supplemental Material ITU-T Recommendation X.509Study Group 16 efforts on securityStudy Groups 4, 11, 15 & SSGITU-T Activities on TDR
46ITU-T Security Building Blocks Security Architecture FrameworkX.800–Security architectureX.802–Lower layers security modelX.803–Upper layers security modelX.805–Security architecture for systems providing end-to-end communicationsX.810–Security frameworks for open systems: OverviewX.811–Security frameworks for open systems: Authentication frameworkX.812–Security frameworks for open systems: Access control frameworkX.813–Security frameworks for open systems: Non-repudiation frameworkX.814–Security frameworks for open systems: Confidentiality frameworkX.815–Security frameworks for open systems: Integrity frameworkX.816–Security frameworks for open systems: Security audit and alarms frameworkNetwork Management SecurityM.3010–Principles for a telecommunications management networkM.3016–TMN Security OverviewM –TMN management services for IMT-2000 security managementM.3320–Management requirements framework for the TMN X-InterfaceM.3400–TMN management functionsSystems ManagementX.733–Alarm reporting functionX.735–Log control functionX.736–Security alarm reporting functionX.740–Security audit trail functionX.741–Objects and attributes for access controlFacsimileT.30 Annex G–Procedures for secure Group 3 document facsimile transmission using the HKM and HFX systemT.30 Annex H–Security in facsimile Group 3 based on the RSA algorithmT.36–Security capabilities for use with Group 3 facsimile terminalsT.503–Document application profile for the interchange of Group 4 facsimile documentsT.563–Terminal characteristics for Group 4 facsimile apparatusProtocolsX.273–Network layer security protocolX.274–Transport layer security protocolSecurity in Frame RelayX.272–Data compression and privacy over frame relay networksTelevisions and Cable SystemsJ.91–Technical methods for ensuring privacy in long-distance international television transmissionJ.93–Requirements for conditional access in the secondary distribution of digital television on cable television systemsJ.170–IPCablecom security specificationSecurity TechniquesX.841–Security information objects for access controlX.842–Guidelines for the use and management of trusted third party servicesX.843–Specification of TTP services to support the application of digital signaturesMultimedia CommunicationsH.233–Confidentiality system for audiovisual servicesH.234–Encryption key management and authentication system for audiovisual servicesH.235–Security and encryption for H-series (H.323 and other H.245-based) multimedia terminalsH.323 Annex J–Packet-based multimedia communications systems – Security for H.323 Annex F (Security for simple endpoint types)H.350.2–Directory services architecture for H.235H.530–Symmetric security procedures for H.323 mobility in H.510Directory Services and AuthenticationX.500–Overview of concepts, models and servicesX.501–ModelsX.509–Public-key and attribute certificate frameworksX.519–Protocol specifications
47X.509 1st edition in 1988; 5th in preparation Written to satisfy multiple needsExtensibility allows organizations to enhance as neededGood cooperation between ITU, ISO, and IETFIn products such as securing browser traffic and signing executable codeLaws enabling electronic/digital signature
48X.509 Specifies Public-key certificate binds name of entity to a public keyif certificate issuer trusted then the entity can be authenticated by the use of the associated private keyAttribute certificateasserts an entity’s privileges, i.e. its right, to access information or servicesreplaces the need for managing rights in the asset holding system
49X.509 is widely used… Public-key certificates are widely deployed prevents the classic man-in-the-middle attackused in Secure Sockets Layer (SSL) to secure browser trafficprotect content and authenticates sourcereplacing notarized signatures in some areasInitial products did not need to be puree.g. early, and some current, browsers do not check certificate revocation statusSome attribute certificate implementations are being studied
50X.805 is a Multi Part Standard Joint Project with ISO/IEC JTC 1/SC 27, “Information technology – Security techniques – IT network security”Part 1: Network security managementPart 2: Network security architecture (X.805)Part 3: Securing communications between networks using security gatewaysPart 4: Remote accessPart 5: Securing communications across networks using virtual private networks
51Security framework for mobile end-to-end data communications Mobile NetworkOpen NetworkData communicationApplication Server(ASP)Mobile Terminal(Mobile User)General Communication FrameworkGateway FrameworkMobile Security GatewaySecurity threatsRelationship of security threats and modelsSecurity requirementsRelationship of security requirements and threatsSecurity functions for satisfying requirementsX.1121
52X.1122 Secure mobile systems based on PKI General Model Gateway Model Mobile NetworkOpen NetworkApplication Server(ASP)Mobile Terminal(Mobile User)Mobile User VAASP’s VAMobile user’s side CACARARepositoryASP’s side CAGeneral ModelASP Application Service ProviderCA Certification Authority RA Registration AuthorityVA Validation AuthorityMobile NetworkOpen NetworkApplication Server(ASP)Mobile Terminal(Mobile User)Mobile User VAASP’s VAMobile user’s side CACARARepositoryASP’s side CAGateway ModelX.1122
53Q.G/16 Security of Multimedia Systems and Services Horizontal Question that deals with security issues applicable to Multimedia Systems, Services, and TerminalsPSTN terminals: H.324B-ISDN terminals: H.310 (videoconferencing)N-ISDN terminals: H.320 (videoconferencing)IP-based terminals: H.323 family (including conferencing & VoIP)Gateways: inter-MM terminals (H.246) and IP-PSTN (H.248.x/Megaco series)Data conferencingFor more details: see Annex G of the MediaCom2004 project
54Security in the MediaCom Project Q.C - MM Applications & ServicesQ.D - Interoperability of MM Systems & ServicesQ.G - Security of MM Systems & Services H.233, H.234, H.235Q.F - MM Quality of Service & E-2-E Performance in MM SystemsQ.1MM Systems, Terminals & Data ConferencingH.320H.324T.120Q.2MM over Packet Networks using H.323 systemsH.225.0H.323H.450H.460Q.3Infrastructure & Interoperability for MM over Packet Network SystemsH.245H.246H.248Q.4Video and Data conferencing using Internet supported ServicesQ.5Mobility for MM Systems & ServicesH.501H.510H.530
55Target Multimedia Applications with Security Needs Voice/Video ConferencingData ConferencingIP Telephony (Voice over IP)Media Gateway Decomposition (H.248.x/Megaco)MM MobilityInstant Messaging and MM-PresenceThis is a list of areas that have received substantial attention on the definition of security mechanisms under Q.G
56Risks in Multimedia Communication Internet PCPDANotebookPCTelephoneTVKioskTerminalOnline-Servicese.g. WWW,CompuserveRadio/Television DataDataVideoWANInternetPrivateNetworkLANIntranetPublicUnauthorized Access to Resources and ServicesIntrusionRepudiation (Data, Service)Eavesdropping, DisclosureBilling FraudMasqueradeManipulation of DataReplayMisuse of DataMisuse of ServicesDenial of ServiceTraffic AnalysisInsider ThreatsMany of the threats to Multimedia communications are shared by other communications scenarios. This picture provides an overall view of such threats.
57Specific IP Telephony Security Challenges IP Telephony is real-time, point-2-point or multi-pointsecure fast setup/connectreal-time security processing of media datareal-time certificate processingIKE security handshakes take too longSecurity measures must be integrated in proprietary platforms and in VoIP stackssecurity can best be added at application layertight interaction with voice CODECs and DSPslow overhead for security: small code size, high performance, etc“Windows 5000” is not the answer!Secure management of the systemssecure password updatesecure storage in databasesScalable security from small enterprise to large Telco environmentsSecurity should be firewall friendlyToday, the most popular topic seems to be IP Telephony, treated as a specific sub-topic of the SG 16 work under H.323. This slide illustrates several of the issues requiring attention from security experts.IP telephony, being real-time, poses latency constraints, which require efficient key exchange, encryption techniques, etc.Security measures have to be embedded in the applications, leading to greater security, efficiency, resource utilization.Other issues: Secure management, scalability, user-friendly firewall traversal.
58H.235: Security for Packet-Switched MM Builds upon ITU-T Rec. X.509Features:Cryptographic protection of control protocols & mediaNegotiation of cryptographic services, algorithms and capabilitiesIntegrated key management functions / secure point-to-point and multipoint communicationsInteroperable security profilesSophisticated security techniques (Elliptic curves, anti-spamming & AES)May use existing Internet security packages and standards (IPSec, SSL/TLS)H.235 (“Security and Encryption for H.323 and other H.245-based multimedia terminals”) is the main Recommendation for security mechanisms for IP-based MM communications defined by H.323. H.235 is currently in its version 2 and will soon be revised into V3. It is also being extended for mobility scenarios under the H.530 series.
59H.235 – “H.323 Security” Security Protocol Architecture AVApplicationsAudioG.711G.722G.723.1G.729VideoH.261H.263EncryptionRTCPH.225.0TerminaltoGatekeeperSignaling(RAS)Terminal Control and ManagementDataSecurityCapabilitiesT.124T.125Unreliable Transport / UDP, IPXReliable Transport / TCP, SPXNetwork Layer / IP / IPSecLink Layer /......Physical Layer / .....T.123Scope of H.323Scope of H.235TLS/SSLMultimedia Applications, User InterfaceAuthenti-cationRTPScope of T.120Call(Q.931)H.245SystemControlTransport ScopeThis slide illustrates the H.323 protocol stack and components.Rec H.235 covers authentication and privacy of all real-time media streams exchanged during a conference.-the dotted areas shows the terminal part addressed in H.323 and the red parts the security features defined in H.235.-->You can find a complete presentation of the SG16 work on security in the workshop which was held in Seoul, Korea
60H.530 The Security Problem of H.323 Mobility Provide secure user and terminal mobility in distributed H.323 environments beyond interdomain interconnection and limited gatekeeper zone mobilitySecurity issuesMobile Terminal/User authentication and authorization in foreign visited domainsAuthentication of visited domainSecure key managementProtection of signaling data between MT and visited domainH.530: Symmetric security procedures for H.323 mobility in H.510(H.510 defines general mobility issues for H.323)
61H.248.1 Security in decomposed Gateways (interim AH) IPSEC AH/ESPH.225.0/ H.245/ H.235SCN/SS7RTP/ H.235TDM voice trunkIKEH.248H.245 OLC/ H.235H.235 RTP payload securityMedia Gateway MGIPSECH.235 Key ManagementMedia Gateway Controller MGCSecurity in the decomposed gateway (H.248.1/MEGACO) is handled with several possible instances.The media gateway controller (MGC) will use key management and will handle encrypted communications with the Media Gateway using IPSEC/IKE. Media encryption is handled in the MG itself by encrypting the RTP traffic and using the key management features implemented in the MGC.H.235 provides plenty of options, with no mandatory settingsRAS: 11, Call Signaling: 12, Call Control: 10, Media Stream Encryption: 4SET, zBsp. IP Phone
62Security for Multimedia Terminals on circuit-switched networks H.233: “Confidentiality System for Audiovisual Services”point-to-point encryption of H.320 A/V payload data by ISO 9979 registered algorithms: FEAL, DES, IDEA, B-CRYPT or BARAS stream ciphersH.234: “Key Management and Authentication System for Audiovisual Services”uses ISO 8732 manual key managementuses extended Diffie-Hellman key distribution protocolRSA based user authentication with X.509-like certificates by 3-way X.509 protocol variant
63Security for Multimedia Conferencing – T.120 and Security – T.120 has very weak information security available (unprotected passwords), common state of the art cryptographic mechanisms are not supportedOS security features do not prevent against typical T.120 threats (especially T.128 application sharing vulnerabilities);This problem already arises in simple pt-2-pt scenariosAdditional threats exist for group-based multipoint scenarios: insider threats, lack of access control, “write token” not protected, unsecured conference management ,…The T.120 “virtual conference room” needs integral and user friendly security protection: for authentication & role-based authorization, for confidentiality, for integrity, and security policy negotiation capabilities
64Security for MM Applications and Systems in Emergency & Disaster Relief Security objectives:prevent theft of service and denial of service by unauthorized usersupport access control and authorization of ETS usersensure the confidentiality and integrity of callsprovide rapid and user-friendly authentication of ETS usersRelationship identified with QoS, network issues, robustness and reliability,...With the recent approval of Q.I/16, studies have started for provision of security in emergency & disaster relief scenarios using multimedia communications. These will be coordinated between Q.G, I & possibly other related questions, SGs, and SDOs.
65Study Groups 4, 11, 15 and SSG (1)SG 4 has developed a set of security-related Recommendations, e.g.M.3210 on TMN management services for IMT-2000 securityQ.815 on security model for message protectionQ.817 on TMN-PKI, Digital certificates and certificate revocation lists profilesWork on security is carried out in Q.7, 9, 10 & 18/4(seeSG 11 develops network signaling & control protocols incorporating appropriate security requirementsWork on security is carried out in Q.1-6 & 11/11(see
66Study Groups 4, 11, 15 and SSG (2)SG 15 contributes to security work in the areas of reliability and communication securityQ.9/15 works on SDH protection switching & OTN protection switching. Network restoration requirements will be also considered.Q.15-18/15 contain a study item on reliability.Work on communication security is carried out in Q.14/15. Refer to G.784 on SDH management & G.875 on OTN management, addressing security management functions. G.7712 includes security for management & signaling communication networks.(seeFor SSG, security is a key aspect. Are studied threats, how to address threats, security architecture, cryptography, lawful interception,… Refer to Q.3/SSG.(see
67ITU-T Studies on Telecommunications for Disaster Relief (TDR)
68TDR scope (1)During natural and manmade disasters, rapid organization and co-ordination of recovery operations is essential to save lives and restore the community infrastructureRecovery operations depend upon ready availability and access to telecommunication resources to support urgent communicationsTelecommunication networks often experience severe stress due to damaged infrastructure and very high traffic loads
69TDR scope (2)There is a need to provide specific resources for authorized users (e.g. governments, fire brigades, police, medical services, etc…)The development and standardization of TDR capabilities provides the means for disaster recovery activities to effectively communicateSpecific standardization activities are therefore required to efficiently support TDR requirementsITU-T can take advantage of its unique industry-government environment to produce relevant Recommendations
70Telecommunication networks: normal operating conditions CustomersS+AServiceApplicationsVoice S+AData S+AMM S+ADedicatedNetworksIP-based NetworksCS-Networks
72TDR scope (3) TDR is not the same thing as ETS! TDR addresses the need of authorized users in terms of facilities established on public network infrastructure, including the inter-working aspects with dedicated/private networksTDR work does not specifically address systems for the use of the public in general (Emergency numbers 112/911, broadcasting network to forward emergency relevant information to the public,…)Since ETS is more generic, TDR is the preferred term in order to avoid the confusion with the systems described above
73Key issues for TDR standardization Customers: - segmentation - requirementsServices and applications (incl. QoS) - use of existing facilities - extension (new needs?)Network capabilities for TDR supportInter-working at - Service and application level - Network levelRegulatory framework
74TDR trendsSituation in the past: -TDR are/were based on PSTN, ISDN, PLMN, 2G-mobile - Circuit switched technology - Voice centric applications - National solutions - Limited inter-workingPresent trends: - Use the possibility of multimedia (video) - New applications/services based on mobility, location-based information,… - Evolution to IP-based platforms - Needs for global solutions (international) - Improve inter-working between platforms (public/private)
75The role of standards for TDR Interworking, compatibility, evolution, economy of scale, … are the main drivers for the development of a Family of standards to ensure global interoperability of emergency communications…- maintaining foundation of existing national capabilities- enabling new national capabilities to be established- expanding communications internationally on priority basis- mapping ETS indicators code at national gateways- facilitating orderly evolution to advancing technologies and enhanced capabilities
76First steps towards TDR standardization in ITU-T Contributions submitted to several Study Groups to develop Recs. on ETS/TDR (2001)Development of first Recs. (E.106, draft Rec. F.706)Need for improved coordination and liaison with other SDOs recognizedExperiences made during the events in 2001/2002Projects on Security (SG 17) and NGN (SG 13)Needs expressed by the ITU-T membership, to develop a global and harmonized set of standards for ETS/TDR capabilities in close co-operation with other SDOsQuestionnaire on the use of public telecom services for emergency and disaster relief operations (TSB-Circular 132/ )Organized a Workshop on Telecommunications for Disaster Relief (Geneva, February 2003)Set-up of the TDR Partnership Coordination Panel (TSB-Circular 173, July 2003)
77ITU-D: Requirements of developing countries ETSI (EMTEL,…) ISO/IEC Development of TDR technical standards in close cooperation with ITU-R, ITU-D and other SDOsITU-R: RF spectrum related aspects, Inter-working with BC- and satellites networksITU-D: Requirements of developing countriesETSI (EMTEL,…)ISO/IECIETF (WG iprep,..)T1/TIA3GPP, 3GPP2,…….
78Conclusions: Key factors for success and challenges Understand users requirementsIdentify the regulatory frameworkDevelop a set of global and compatible StandardsCost aspectsEvolutionary approachNational sovereigntyPartnership between Member States, private sector, GOs and NGOsSee also