1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-0100024.2009(R2014) User-Network Interface (UNI) Media Plane Security Standard for Evolving VoIP/Multimedia Networks As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance th
2、e industrys most-pressing business priorities. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These prior
3、ities follow a fast-track development lifecycle from design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the
4、North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Com
5、mission (CITEL). For more information, visit. AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the
6、 judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that
7、 a concerted effort be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or pro
8、cedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American Nationa
9、l Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The proc
10、edures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. No
11、tice of Disclaimer or, in authentication, an authentication that with high assurance can be asserted to be genuine, and that can not subsequently be refuted. Non-repudiation is a signaling/control or management plane issue and does not apply to the media plane. 6.4 Audit Logging Security Dimension T
12、he creation of an audit log is critical for the incident post-mortem and resulting investigation. This section will address the unique audit logging requirements of the user plane in the UNI. Audit logging was not originally included as a security dimension in X.805 however this concept is included
13、here for completeness. Reference ITU-T X.805. Any unauthorized media plane traffic arriving at the UNI shall be logged locally or remotely Note: This objective will be considered to be met if the occurrences of “unauthorized packets” are logged. The content of the “unauthorized packet” may be captur
14、ed, however if it is, the system may be subject to DoS attacks and mechanisms to mitigate such events should be provided. Occurrences of unauthorized media plane traffic arriving at the UNI shall be tabulated. Whenever the tabulation of unauthorized media plane traffic arriving at the UNI is updated
15、, the tabulation shall be compared to a system configurable threshold. When the tabulation of unauthorized media plane traffic arriving at the UNI exceeds the threshold, an alarm shall be generated and sent to a management system. When the tabulation of unauthorized media plane traffic exceeds the t
16、hreshold, the generated alarm shall be logged locally or remotely. The IPsec ESP transform should support Null integrity RFC 4303. ATIS-0100024.2009 8The threshold for unauthorized media plane traffic arriving at the UNI shall be configurable only by authorized entities either locally or remotely. N
17、ote: Media plane traffic arriving at the UNI that is not associated with an authorized UA (as per section 6.1) is to be considered as unauthorized media plane traffic. 6.5 Data Confidentiality Security Dimension Data confidentiality of media plane traffic on an end-to-end basis between communicating
18、 UAs can be accomplished via the application of the following encryption mechanisms: - Secure Real Time Protocol (SRTP) RFC 3711, - IP Security (IPsec) RFC 4301, or - Datagram Transport Layer Security (DTLS) protocol RFC 4347. However service/access providers should be sensitive to other obligations
19、 (e.g., lawful intercept) that may conflict with end-to-end data confidentiality of medial plane traffic. End-to-end data confidentiality for media plane traffic traversing the UNI may be provided by the use of SRTP to protect media traffic such as phone conversations, video, and multimedia from una
20、uthorized access or observation. End-to-end data confidentiality for media plane traffic traversing the UNI may be provided by the use of IPsec ESP-3DES RFC 4303 or IPsec ESP-AES RFC 4303 to protect media traffic such as phone conversations, video, and multimedia from unauthorized access or observat
21、ion. End-to-end data confidentiality for media plane traffic traversing the UNI may be provided by the use of DTLS to protect media traffic such as phone conversations, video, and multimedia from unauthorized access or observation. Different access technologies used to connect the end user device to
22、 the network may have different inherent security capabilities. For example, a DSL line from a service provider connecting a single residential SIP user to the service providers domain may have a similar level of security for the user to network connection as a traditional phone connection. However
23、a service provider connecting a SIP user via a wireless access technology without air interface security enabled may be less secure than a traditional phone connection. As such, it is recommended that all end user terminals connecting to networks via wireless access technology employ some form of co
24、nfidentiality mechanism ATIS-0100024.2009 9Wireless access data confidentiality for media plane traffic arriving at the UNI should be provided by the use of 802.11i IEEE 802.11i to protect media traffic such as phone conversations, video, and multimedia from unauthorized access or observation. Wirel
25、ess access data confidentiality for media plane traffic arriving at the UNI may be provided by the use of WPA WPA or WPA2 WPA2 to protect media traffic such as phone conversations, video, and multimedia from unauthorized access or observation. It should be noted that WPA TKIP is considered weak and
26、thus this mode no longer is no longer recommended and its use should be deprecated. Instead, it is recommended that WPA2 be used with the AES encryption mode. 6.6 Communication Security Dimension No additional requirements to address the Communication Security dimension have been identified beyond t
27、hose specified in the Authentication Security (Section 6.2) and Data Integrity (Section 6.6) dimensions in this standard. 6.7 Data Integrity Security Dimension Data integrity of media plane traffic to protect it from transmission errors or errors from malicious actions can be accomplished via the ap
28、plication of the following mechanisms: - User Datagram Protocol (UDP) RFC 768 (error protection only) - SRTP - IPsec - DTLS However service/access providers should be sensitive to other obligations (e.g., lawful intercept) that may conflict with SRTP, IPsec or DTLS provided data integrity of media p
29、lane traffic. Additionally, UDP checksum does not protect against unauthorized malicious and intentional data modification where an attacker adapts the checksum according to the made data manipulation. Data integrity protection against media plane traffic transmission errors across the UNI may be pr
30、ovided by the use of the UDP checksum. Data integrity against malicious actions for media plane traffic traversing the UNI may be provided by the use of SRTP to protect media traffic such as phone conversations, video, and multimedia from undetected modification. Data integrity against malicious act
31、ions for media plane traffic traversing the UNI may be provided by the use of IPsec ESP-3DES RFC 4303 or IPsec ESP-AES RFC 4303 to protect media traffic such as phone conversations, video, and multimedia from undetected modification. ATIS-0100024.2009 10 Data integrity against malicious actions for
32、media plane traffic traversing the UNI may be provided by the use of IPsec ESP-nul RFC 4303 to protect media traffic such as phone conversations, video, and multimedia from undetected modification. Data integrity against malicious actions media plane traffic traversing the UNI may be provided by the
33、 use of DTLS to protect media traffic such as phone conversations, video, and multimedia from undetected modification. 6.8 Availability Security Dimension As a best practice, network entities communicating across the UNI should implement mechanisms to detect and mitigate IP media plane DoS attacks.
34、Both application layer flooding attacks, network layer flooding attacks, and malformed packet attacks should be mitigated by the DoS protection mechanisms. Attacks directly against the SIP media plane are not necessarily required to break or disable the service entirely. Where SIP relies upon ancill
35、ary services, such as DNS, RSVP, SNMP, and others, attacks against these underlying infrastructure services should also be mitigated by security and DoS protection mechanisms. 6.9 Privacy Security Dimension Privacy is the right of individuals to control or influence what information related to them
36、may be collected and stored and by whom and to whom that information may be disclosed. Reference ITU X.800. Privacy, as it relates to the media plane, involves the right of individuals to control or influence the media plane information sent or received such as VoIP and/or Multimedia user informatio
37、n. Users have no mechanisms to influence the disclosure or collection of media plane information once it has left the UA. The best protection mechanism a user may employ is to ensure that media plane information is protected by a confidentiality security mechanism as per so that only desired end UA
38、may receive this information. This will help ensure that any media plane information collected remains confidential to all but the desired end UA, however it is still possible for the end UA (or any other party that obtains the session encryption key) to collect or disclose the media plane informati
39、on. Please note that ITU X.800 goes on to qualify privacy in the following manner; “Because this term relates to the right of individuals, it cannot be very precise and its use should be avoided except as a motivation for requiring security”. Reference ITU X.800. 7 LAWFUL INTERCEPT Data confidential
40、ity or data integrity of media plane traffic are provided by any of the following encryption mechanisms: - SRTP, - IPsec ESP-3DES, - IPsec ESP-AES, or - DTLS, Use of encryption algorithms may interfere with other service/access provider obligations (e.g., lawful intercept). ATIS-0100024.2009 11 8 CR
41、YPTOGRAPHY WHEN DATA CONFIDENTIALITY OR DATA INTEGRITY OF MEDIA PLANE TRAFFIC ARE PROVIDED BY ANY OF THE FOLLOWING MECHANISMS: - SRTP, - IPsec ESP-3DES, - IPsec ESP-AES, - IPsec ESP-nul, or - DTLS, There are a number of important configuration attributes that need be considered. The following sub-cl
42、auses address these considerations for each of the above mechanisms. 8.1 SRTP Configuration 8.1.1 SRTP Algorithms At the time of writing of this document, SRTP implementation should minimally support the following cryptographic parameters as per RFC 3711: If SRTP is selected as the option by which s
43、ecurity is to be invoked then the following requirements are to be met: The SRTP Encryption Algorithm shall be AES_CM The SRTP Authentication Algorithm shall be HMAC_SHA1 The SRTP Key derivation function shall be AES_CM The SRTP Master key length shall be at least 128 bits The SRTP Master salt key l
44、ength shall be at least 112 bit s The SRTP Session encryption key length shall be at least 128 bit s ATIS-0100024.2009 12 The SRTP Session authentication key length shall be at least 160 bits The SRTP Session salt key length shall be at least 112 bits The SRTP packet maximum lifetime shall be 248 pa
45、ckets The SRTP SRTCP packet maximum lifetime shall be 231 packets The SRTP authentication tag length shall be at least 80 bits The SRTP SRTCP authentication tag length shall be at least 80 bits 8.1.2 SRTP Key Management Key exchange for SRTP is currently conducted over the signaling and control plan
46、e (for example via the “Session Description Protocol”) and as such it is beyond the scope of this document. There is work being conducted at the IETF which may result in key exchange performed over the media plane, however at the time of writing of this document no standardized methods are available
47、. Key exchange mechanisms over the media plane may have implications for Lawful Intercept. See Reference RFC 4568 for more information on the Session Description Protocol. 8.2 IPsec Configuration If IPsec is selected as the option by which security is to be invoked then the following requirements ar
48、e to be met: At the time of writing of this document, IPsec implementations should minimally support the following capabilities and cryptographic parameters: IPsec implementations shall conform to Crypto Suites for IPsec RFC 4308, RFC 4869 ATIS-0100024.2009 13 IPsec usage of HMAC-SHA1-96 should be u
49、sed rather than HMAC-MD5-96 Use of pre-shared keys with IKE should not be used. IPsec implementations should use secure random number generators if available. IPsec implementations shall use strong pseudo-random number generator software conforming with the IETF informational RFC Randomness Requirements for Security RFC 4086. 8.2.1 IPsec Modes IPsec Tunnel mode should be used when IPsec has to traverse NAT functional entities. IPsec Transport mode should be used when NAT is not encountered. 8.2.2 IPsec Transforms The IPsec ESP-nul transform
