Addendum to the Security for Management Interfaces to Network Elements
Addendum to the Security for Management Interfaces to Network Elements IA # OIF-SMI-02.1 March 31, 2006 Implementation Agreement created and approved by the Optical Internetworking Forum www.oiforum.com The OIF is an international non profit organization with over 100 member companies, including the world’s leading carriers and vendors. Being an industry group uniting representatives of the data and optical worlds, OIF’s purpose is to accelerate the deployment of interoperable, cost-effective and robust optical internetworks and their associated technologies. Optical internetworks are data networks composed of routers and data switches interconnected by optical networking elements. With the goal of promoting worldwide compatibility of optical internetworking products, the OIF actively supports and extends the work of national and international standards bodies. Formal liaisons have been established with The ATM Forum, IEEE 802.3, IETF, ITU-T Study Group 13, ITU-T Study Group 15, MEF, NPF, T1M1, T1X1, TMF, UXPi and the XFP MSA Group. For additional information contact: The Optical Internetworking Forum, 39355 California Street, Suite 307, Fremont, CA 94538 510-608-5928 Φ [email protected] www.oiforum.com Notice: This Technical Document has been created by the Optical Internetworking Forum (OIF). This document is offered to the OIF Membership solely as a basis for agreement and is not a binding proposal on the companies listed as resources above. The OIF reserves the rights to at any time to add, amend, or withdraw statements contained herein. Nothing in this document is in any way binding on the OIF or any of its members. The user's attention is called to the possibility that implementation of the OIF implementation agreement contained herein may require the use of inventions covered by the patent rights held by third parties. By publication of this OIF implementation agreement, the OIF makes no representation or warranty whatsoever, whether expressed or implied, that implementation of the specification will not infringe any third party rights, nor does the OIF make any representation or warranty whatsoever, whether expressed or implied, with respect to any claim that has been or may be asserted by any third party, the validity of any patent rights related to any such claim, or the extent to which a license to use any such rights may or may not be available or the terms hereof. © 2005 Optical Internetworking Forum 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 other than the following, (1) the above copyright notice and this paragraph must be included on all such copies and derivative works, and (2) this document itself may not be modified in any way, such as by removing the copyright notice or references to the OIF, except as needed for the purpose of developing OIF Implementation Agreements. By downloading, copying, or using this document in any manner, the user consents to the terms and conditions of this notice. Unless the terms and conditions of this notice are breached by the user, the limited permissions granted above are perpetual and will not be revoked by the OIF or its successors or assigns. This document and the information contained herein is provided on an “AS IS” basis and THE OIF 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, TITLE OR FITNESS FOR A PARTICULAR PURPOSE. www.oiforum.com 2 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 1 Table of Contents 1 2 3 4 Table of Contents ................................................................................................. 3 List of Figures ....................................................................................................... 4 List of Tables ......................................................................................................... 4 Document Summary............................................................................................ 6 4.1 Working Group ............................................................................................ 6 4.2 Problem Statement....................................................................................... 6 4.3 Scope .............................................................................................................. 6 4.4 Expected Outcome ....................................................................................... 6 4.5 Value to OIF .................................................................................................. 7 4.6 Relationship to Other Standards Bodies................................................... 7 4.7 Viewpoint...................................................................................................... 7 4.8 Acknowledgements ..................................................................................... 7 5 Introduction .......................................................................................................... 7 5.1 Outline of the Implementation Agreement.............................................. 8 5.2 How to Use this Implementation Agreement.......................................... 8 6 Terminology and Acronyms .............................................................................. 8 6.1 Keywords ...................................................................................................... 8 6.2 Acronyms ...................................................................................................... 9 7 Updates to the Scope and Security Objectives............................................... 11 8 Updates to the Specifications of Security Systems........................................ 11 8.1 IPsec ............................................................................................................. 11 8.2 SSL and TLS ................................................................................................ 15 8.3 SNMP and SNMPv3 .................................................................................. 15 8.4 Secure Shell (SSH) ...................................................................................... 16 8.5 Kerberos....................................................................................................... 16 9 Specification of XML-Based Security for Network Management ............... 17 9.1 Components of Web Services................................................................... 17 9.2 SDOs for Web Services.............................................................................. 18 9.3 Web Services Security Overview............................................................. 19 9.4 Web Services Security Protocol Stack ..................................................... 21 9.5 Web Services Security Profile................................................................. 210 9.6 OASIS........................................................................................................... 25 9.7 ANSI, NIST, and ITU-T ............................................................................. 27 10 Alignment with Other Network Management Security Standards........ 27 11 Relationship between Security Objectives and Security Systems........... 29 12 References ....................................................................................................... 31 12.1 Normative References ............................................................................... 32 12.2 Informative References ............................................................................. 39 Appendix A: Open Issues / current work items................................................... 41 Appendix B: List of companies belonging to OIF when document was approved ..................................................................................................................... 41 www.oiforum.com 3 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 2 List of Figures None. 3 List of Tables Table 1: Applicability of Security Solutions to Different Interfaces 28 Table 2: Mapping of Objectives to Security Systems 29 www.oiforum.com 4 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Document Revision History Working Group: OAM&P SOURCE: Editors Renée Esposito Department of Defense [email protected] Working Group Chair Doug Zuckerman Telcordia Technologies [email protected] Richard Graveman Department of Defense [email protected] DATE: OIF-SMI-02.0 November 11, 2005 OIF-SMI-02.1 March 31, 2006 4 www.oiforum.com 5 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Document Summary This addendum brings the Security for Management Interfaces to Network Elements [SecMgmt] IA up to date with (1) new work in the OIF on UNI, NNI, routing, discovery, and control plane security; (2) new work in the IETF on IPsec, IKE, TLS, SSH, Kerberos, and SNMP security; and (3) ongoing work in other SDOs on security for network management. It also adds specifications for securing management interfaces based on Web Services and XML. 4.1 Working Group OAM&P Working Group. 4.2 Problem Statement Since the publication of the Security for Management Interfaces to Network Elements [SecMgmt], (1) the OIF has completed new work on the UNI, NNI and control plane security; (2) the IETF has continued to revise IPsec, IKE, the list of associated IPsec transforms, TLS, SSH, Kerberos, and SNMP security; (3) new interest in using XML-based Web Services for network management has emerged; and (4) new work on security for network management in ATIS-TMOC and ITU-T is underway. This IA keeps [SecExt] up to date and aligned with current practice by addressing these four items. 4.3 Scope This IA modifies the optional security for management interfaces to network elements in [SecMgmt]. It also aligns network management security with control plane security as updated in [SecAdd]. 4.4 Expected Outcome [SecMgmt] specifies optional security systems for use with network management interfaces to network elements. This addendum contains both mandatory and optional requirements for compliance with [SecMgmt] as well as informational material to clarify items in [SecMgmt] and promote the development of interoperable implementations. www.oiforum.com 6 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 4.5 Value to OIF This IA extends the value of [SecMgmt] to new and updated network management security protocols, keeps [SecMgmt] up to date with current work in the IETF, and clarifies aspects of the use of [SecMgmt]. 4.6 Relationship to Other Standards Bodies This IA is based upon the ATM Forum’s work on securely managing ATM Network Elements. It uses the RFCs written by the IETF and standards for Web Services security from the W3C and OASIS as normative references to almost all of the work described herein. It also takes into account work on security for network management in ATIS-TMOC and ITU-T. 4.7 Viewpoint This document defines no new protocols. It consolidates, profiles, and applies many aspects of work done at other standards bodies, particularly the IETF. It updates and modifies the optional security services in [SecMgmt]. 4.8 Acknowledgements Jim Jones from Alcatel provided helpful inputs during balloting. 5 Introduction Since the completion of the Security for Management Interfaces to Network Elements IA [SecMgmt], there has been new work in the OIF on UNI, NNI, routing, and discovery, and the OIF has completed an addendum to the Security Extension for UNI and NNI. There have also been updates in the IETF to the security protocols covered in the original Security for Management Interfaces to Network Elements IA. This Addendum takes into account this new work as well as management interfaces based on Web Services and XML. This Addendum is, as far as practical, aligned with complementary efforts in other SDOs. The goals of [SecMgmt] are to define security objectives for OAM&P access to NEs and to specify how different security systems can be used to satisfy many of these objectives. This IA brings [SecMgmt] up to date with work in the IETF and OIF and incorporates standards for Web Services security. www.oiforum.com 7 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 5.1 Outline of the Implementation Agreement This document is organized as follows: • Section 4 provides a summary of this addendum. • Section 5 describes the organization of this document. • Section 6 defines the terminology, keywords, and acronyms used. • Section 7 addresses scope and security objectives. • Section 8 brings [SecMgmt] up to date with work in the IETF and the OIF’s control plane security. • Section 9 covers XML-based security for management interfaces based on Web Services • Section 10 discusses the relationship of this document to NM security work in other SDOs. • Section 11 updates the mapping between security objectives and specifications of security systems. • Section 12 contains normative and informative references. 5.2 How to Use this Implementation Agreement This IA is an addendum to [SecMgmt]. To apply it, it must be used together with [SecMgmt]. It is not a self-contained replacement for [SecMgmt]. Applying this IA also depends on using the normative references from the IETF and OIF listed in Section 12. 6 6.1 Terminology and Acronyms Keywords When written in ALL CAPITALS, 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 IETF RFC 2119 [Bra97]. In addition, as defined in [Sch04], the following terms and their respective interpretations are used: SHOULD+ www.oiforum.com This term means the same as SHOULD. However it is likely that a requirement marked as SHOULD+ will be promoted at some future time to be a MUST. 8 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements SHOULD– This terms means the same as SHOULD. However a requirement marked as SHOULD– may be deprecated to a MAY in a future version of this IA. MUST– This term means the same as MUST. However it is expected that at some point this requirement will no longer be a MUST in a future version of this IA. 6.2 Acronyms The following acronyms or abbreviations are used in this implementation agreement: AES Advanced Encryption Standard AH Authentication Header CA Certification Authority CBC Cipher Block Chaining (Mode) CCM Counter with CBC-MAC (Mode) CFB Cipher Feedback (Mode) CRC Cyclic Redundancy Check CTR Counter (Mode) CTS Ciphertext Stealing (Mode) DES Data Encryption Standard DH Diffie-Hellman DNS Domain Name System E-NNI Exterior Network Node Interface ESP Encapsulating Security Payload GCM Galois Counter Mode HMAC Hashed Message Authentication Code HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol ICMP Internet Control Message Protocol IESG Internet Engineering Steering Group IETF Internet Engineering Task Force IKE Internet Key Exchange IP Internet Protocol IPsec IP Security KDC Key Distribution Center MAC Message Authentication Code www.oiforum.com 9 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements MIB MTU NA Management Information Base Maximum Transmission Unit Network Administrator NAT Network Address Translation NE Network Element NM Network Management NNI Network Node Interface OASIS Organization for the Advancement of Structured Information Standards PAD Peer Authentication Database PKI Public Key Infrastructure PS Proposed Standard RFC Request for Comments RSA Rivest, Shamir, and Adleman RFC Request for Comments SA Security Association SAD Security Association Database SAML Security Assertion Markup Language SHA Secure Hash Algorithm SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SPD Security Policy Database SPML Service Provisioning Markup Language TCP TNE UDDI UDP UNI UNI-C URI URL VPN W3C WS Transmission Control Protocol Transport Network Element Universal Description, Discovery and Integration User Datagram Protocol User-Network Interface UNI Client Uniform Resource Identifier Uniform Resource Locator Virtual Private Network World Wide Web Consortium Web Services www.oiforum.com 10 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements WSDL Web Service Definition Language WSDM Web Services Distributed Management WSS Web Services Security XACML Extensible Access Control Markup Language XML Common Biometric Format XCBF X-KISS XML Key Information Service Specification XKMS XML Key Management Specification X-KRSS XML Key Registration Service Specification XML Extensible Markup Language XML-DSIG XML Digital Signature XML-ENC XML Encryption 7 Updates to the Scope and Security Objectives The scope of this IA is defined in [SecMgmt]. In particular, this IA and [SecMgmt] define security that may be applied at any NE or component of a NE with an OAM&P interface. This IA applies, for example, to UNI clients, TNEs, and control plane devices which may be separate from clients or TNEs (see Figure 2 in [SecExt]). The Security Objectives are contained in [SecMgmt]. No updates to these security objectives are contained in this Addendum. 8 Updates to the Specifications of Security Systems 8.1 IPsec To minimize implementation effort and code size, the profile of IPsec defined in this document is intended to be aligned with that in [SecAdd]. Since the OIF approved the predecessor to this document, [SecMgmt], the IETF has made several major modifications to IPsec (all approved as Proposed Standard): • The Security Architecture for the Internet Protocol has been updated ([KS05]) • The Internet Key Exchange (IKE) Protocol has been replaced by a simpler, stronger version, IKEv2 [Kau05] www.oiforum.com 11 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements • The Encapsulating Security Protocol (ESP) version 3 ([Ken05a]) adds longer sequence numbers, better protection against traffic analysis, and support for more efficient algorithms • A stronger and more efficient set of cryptographic transforms has been standardized (while, at the same time, weaknesses in older algorithms, particularly hash functions, have been found) The use of IPsec defined in Section 4 of [SecAdd] applies in its entirety and is authoritative for this Addendum. Therefore, for implementations of IKEv2 [Kau05] with the corresponding updates to the IPsec Architecture [KS05] and ESP [Ken05a], the use of IPsec as defined in [SecMgmt] is updated as follows: • A Security Association in the updated architecture is identified by a SPI and destination address. • When IKEv2 is used instead of IKEv1, the references to Phase 1 and Phase 2 are no longer relevant. • When ESP is used with IPv6, it is implemented in an IPv6 Extension Header. See Section 4.4 of [SecAdd] for additional IPv6 considerations. • The lists of REQUIRED and RECOMMENDED transforms are updated in [SecAdd], and use of MD5 is no longer recommended. Sections 5.1.1 and 5.1.2 contain additional information on the new transforms for the new version of ESP and on IKEv2. 8.1.1 IPsec Transforms [Eas05] specifies the encryption and authentication algorithms for ESP and the authentication algorithms for AH. [SecAdd] cites [Hof05a], which uses most of the algorithms specified in [Eas05] to define two suites of algorithms and attributes that can be implemented and are commonly used for IPsec. The suites in [Hof05a] are recommended for implementation: Suite A is MUST– and Suite B is SHOULD +. Suite A IPsec: Protocol ESP encryption ESP integrity ESP [KA98c] or [Ken05a] TripleDES in CBC Mode [PA98] HMAC-SHA1-96 [MG98] Suite A IKE and IKEv2: Encryption TripleDES in CBC Mode [PA98] Pseudo-random function HMAC-SHA1 [MG98] Integrity HMAC-SHA1-96 [MG98] www.oiforum.com 12 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Diffie-Hellman group www.oiforum.com 1024-bit MODP [HC98] 13 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Suite B IPsec: Protocol ESP encryption ESP integrity ESP [KA98c] or [Ken05a] AES with 128-bit keys in CBC Mode [FGK03] AES-XCBC-MAC-96 [FH03] Suite B IKE and IKEv2: Encryption AES with 128-bit keys in CBC Mode [FGK03] Pseudo-random function AES-XCBC-PRF-128 [Hof04] and [Hof06] Integrity AES-XCBC-MAC-96 [FH03] Diffie-Hellman group 2048-bit MODP [KK03] Other IPsec transforms and algorithms MAY also be implemented. Implementations must contain a (non-NULL) confidentiality algorithm that is able to be used with manually configured SAs. The strength of cryptography depends on the algorithms and key sizes chosen. Single DES has been broken and MUST NOT be used. The confidentiality algorithms for ESP and IKEv2 are shifting towards the use of AES due to the increased security levels offered. AES can provide different security services (integrity or confidentiality), can be used in different modes, and is defined with three different key sizes. AES in CBC Mode with 128-bit keys is specified as both the integrity and confidentiality transform in Suite B of [Hof05a]. AES is also defined with modes of operation that offer a combination of confidentiality and integrity. For instance, AES in Counter Mode (CTR) [Hou04] is recommended as the preferred encryption method for high-speed implementations. However, Counter Mode does not provide data origin authentication and data integrity. AES in Galois/Counter Mode (GCM), AESGCM-ESP [VM05], combines AES-CTR Mode with a secure integrity mechanism. AES-GCM can be implemented with the revised ESP [Ken05a] (AES-GCM-ESP) to provide confidentiality and integrity (data origin authentication). It is suitable for implementation at speeds of 10 Gb/s and higher in hardware. Such hardware implementations can flexibly support any of the AES key sizes. AES-GCM-ESP requires a 12-octet nonce versus the 11-octet nonce required by AES-CCM-ESP, and therefore AES-GCM-ESP offers the most practical alternative for high-speed, hardware-based combined confidentiality and integrity. 8.1.2 IKEv2 The IKEv2 RFC ([Kau05]) was issued as Proposed Standard in December 2005. It is expected that it will obsolete IKEv1 and become the required key management system. The current IKE version 1, as described in [SecExt] and modified by [Hof05b], is MUST–, but implementors are encouraged to move to IKEv2 as quickly as practical. www.oiforum.com 14 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements The RECOMMENDED and REQUIRED IKEv2 transforms for this IA are specified in [SecAdd]. 8.2 SSL and TLS The specifications for TLS in Section 6.2.2.2 of [SecMgmt] are updated as follows: • Implementations of TLS MUST support the AES cipher suites in [Cho02]. • Implementations of TLS SHOULD support the pre-shared secret mechanisms in [ET05]. • Implementations of TLS MAY support the compression mechanism in [Hol04]. When the changes in the TLS 1.1 protocol are approved (now in draft [DR05]), implementations should support this new version because it does mitigate attacks against CBC-Mode encryption. TLS 1.1 is version Major 3, Minor 2. With TLS 1.1, use of AES is encouraged and use of RC4 is discouraged. This applies also to the cipher suites used with pre-shared secrets [ET05] and other extensions. Implementors are also encouraged to include, when approved, the secure remote password mechanism in [TWMP05] and the elliptic curve cipher suites in [Gup05]. 8.3 SNMP and SNMPv3 SNMPv3 provides data integrity and data origin authentication (called authentication), data confidentiality, and message timeliness. Note that the authentication service must be used if the confidentiality service is used. Timeliness should also be used to protect against message replay, delay, or redirection. The message timeliness check is performed only if data integrity and data origin authentication are applied to the message. In this case, the complete message is checked for integrity, including the timeliness values. If a message does not have a recent time indicator, then the message is not considered authentic. The time of the SNMP engine is maintained by the two values snmpEngineBoots and snmpEngineTime. Each SNMP engine is authoritative for these values. The following specifications update the use of SNMPv3 as defined in [SecMgmt]: • An SNMP engine MUST discard SNMP Response messages that do not correspond to a Request message. • Confidentiality, when used, MUST be applied to SNMP packets as described in [Blu04]. [Blu04] updates [Blu02] and specifies the use of AES www.oiforum.com 15 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements in Cipher Feedback Mode (CFB) with a key size of 128 bits. DES-CBC MUST NOT be used. • When confidentiality is used, the accompanying authentication protocol SHOULD be HMAC-SHA-96. Use of HMAC-MD5-96 should be phased out as quickly as practical. Note also that new work on SNMP security has been started in the IETF’s Integrated Security Model for SNMP (isms) WG. Results from this work may be incorporated into a future version of this IA. The current direction of this work is to run SNMP over SSH and TCP. Because of this work, implementors of SNMP over TCP who are considering adding security at the transport layer are encouraged to consider SSH rather than TLS. 8.4 Secure Shell (SSH) SSH2 has been approved by the IETF and the five RFCs ([LL06], [YL06d], [YL06a], [YL06b], and [YL06c]) describing it are now Proposed Standards. Because of the improved security of SSH2, the widespread availability of client and server implementations of SSH2, and the now-approved standards status of SSH2, use of SSH1 is deprecated. Management interfaces protected with SSH MUST use SSH2 and MUST NOT use SSH1. Implementations SHOULD include Generic Message Exchange Authentication for SSH [CF06] and Diffie-Hellman Group Exchange for the Transport Protocol [FPS05]. Implementations MAY use DNS to publish SSH key fingerprints [SG06] and include the Session Channel BREAK in [GL06], the PKI extensions in [GT06] and [GVMB05], and the rekeying in [BKN06]. Implementation of the GSS-API extensions [HSGW05] is also OPTIONAL. Implementors are referred also to [ESC05] as well as to [Gut98] and [KSF99] (all Informative) for guidance on generation and use of randomness and pseudorandomness. Implementations and users SHOULD prefer 128-bit AES in CBC Mode to 3-DES and avoid using MD5 in favor of SHA-1 in HMAC constructions. 8.5 Kerberos Kerberos is an authentication protocol for user and machine authentication. It verifies the identity of principals on a network. The IETF has revised the core Kerberos Specification, “The Kerberos Network Authentication Service, www.oiforum.com 16 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Version 5” [Kerb05], which reflects implementation experience, provides for easier deployment and uses new cryptographic algorithms. [Kerb05] has been approved by the IESG for publication as a standards-track RFC. It adds support for TCP transport. When using Kerberos, Kerberos servers supporting IP transports MUST accept UDP or TCP requests. [Kerb05] also adds support for using DNS to store location information for Key Distribution Centers (KDCs). The use of DNS addresses scalability issues as DNS provides a case insensitive method for querying realm names. The session keys established using Kerberos are used to protect traffic. This protection may provide integrity only or confidentiality and integrity. AES is the algorithm specified for use in “Advanced Encryption Standard (AES) Encryption for Kerberos 5” [Rae04]. [Rae04] specifies using Ciphertext Stealing Mode (CTS). Therefore, encryption with AES-128-cts-hmac-sha1-96 MUST be implemented. AES-256-cts-hmac-sha1-96 SHOULD also be implemented. Public Key Initialization, PKINIT [Tung06], describes protocol extensions to provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signatures or encryption algorithms in pre-authentication data fields. PKINIT SHOULD be supported. If implementing PKINIT, then AES-256-cts-hmac-sha1-96 MUST be supported. 9 9.1 Specification of XML-Based Security for Network Management Components of Web Services When Web Services become more complicated than what can be accomplished with a single server, the need exists for multiple “back end systems” to communicate with each other to provide these Web services securely. Security services needed for this type of architecture include authorization, access control, and single sign-on as well as identification, authentication, message integrity, and confidentiality. This section describes some of the components and terminology associated with such Web Services. A Web Service is identified with a URI [Ber05]. Extensible Markup Language (XML) [XML04, XMLS004, XMLS104, XMLS204] is a platform-independent data format that uses HTML-like tags to describe information. It allows structured data to be shared among heterogeneous applications and systems without requiring translation. www.oiforum.com 17 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Simple Object Access Protocol (SOAP) [SOAP003, SOAP103, SOAP203, SOAPT03] is an XML- and HTTP-based protocol [Fie99, KL00, Res00] for networked procedure calls between application components. SOAP 1.2 is a product of the W3C XML Protocol (XP) Working Group. It uses many W3C and IETF specifications, particularly those for XML. SOAP is normally used with automatically generated, machine-to-machine transactions. Generally, HTTP is allowed through packet filters, and most proxies cannot filter based on SOAP content. A SOAP message is an XML document with a single root element named “Envelope” in the SOAP envelope namespace. The envelope identifies the SOAP version, and holds the SOAP header and body. Typical SOAP prefixes are: • SOAP Envelope env: • SOAP encoding (SOAP 1.1) enc: • XML Schema (datatypes) xsd: • XML Schema instance xsi: • WSDL wsdl: • XML digital signatures ds: • Web Service security wsse: Web Services Description Language (WSDL) [WSDLp06, WSDL106, WSDL206, WSDL306] describes, in XML, how to develop a Web Services client. It includes the URI of the service, target objects, methods for those objects, parameter names and types, and return value types. WSDL uses object-oriented constructions to define services, ports, port types, operations, message values, and types. It does not have ways to define security constraints or access requirements. UDDI (Universal Description, Discovery, and Integration) [UDDI04] is the commonly used discovery protocol for Web Services. 9.2 SDOs for Web Services Multiple standards development organizations are developing open standards for Web Services (WS) and Web Services Security (WSS): 1. The Internet Engineering Task Force (IETF) has specified standards for HTTP 1.0/1.1 (RFC 2616), LDAPv3, TLS (SSL v3.0 preceded TLS), and URIs. www.oiforum.com 18 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 2. The W3C (World Wide Web Consortium) has written standards for Extensible Markup Language (XML), XML-Signature Syntax and Processing (XMLDSIG), XML Encryption Syntax and Processing (XMLENC), Simple Object Access Protocol (SOAP), XML Key Management Specification (XKMS), Web Services Description Language (WSDL), Canonical XML, Exclusive XML Canonicalization, and XML Schema. 3. The Organization for the Advancement of Structured Information Standards (OASIS) has developed UDDI, Web Services Security (WSSecurity), Security Association Markup Language (SAML), Web Services Reliable Messaging (WSRM), Extensible Access Control Markup Language (XACML), and a variety of PKI-oriented documents. They are also developing Web Services Distributed Management of Web Services (WSDM-MOWS) and using Web Services (WSDM-MUWS). 4. Liberty Alliance, which works on federated identity and single sign-on, is a vendor consortium involved in WSS. Also, the Web Services Interoperability Organization (WS-I), ANSI, and ISO have also written standards that are potentially relevant. 9.3 Web Services Security Overview Threats against Web Services (SOAP) include: • Eavesdropping on transactions by tapping into LAN or WAN connections, compromising SOAP intermediaries, or compromising servers • Modifying requests or responses by compromising SOAP intermediaries, compromising clients, or TCP hijacking • Compromising clients’ passwords • IP address spoofing or TCP hijacking • Impersonating a WS server through DNS cache poisoning, DNS spoofing, or posting bogus WSDL files • Replay of requests or responses • Denial of service against servers or specific clients • Traffic analysis Three viable approaches to SOAP security exist: 1. SOAP and WS can run over IPsec VPNs. This can achieve host-to-host communications security. www.oiforum.com 19 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 2. SOAP over HTTP can use SSL 3.0 or TLS, either of which provides communications security from SOAP application to SOAP application. 3. SOAP can use the XML Security standards for fine-grained, application-layer security, end to end. The main drawback of the first two approaches is that they do not provide end-to-end security for portions of a message sent to multiple servers or backend systems. WS-Security [WSsec05] provides mechanisms implemented in SOAP to enhance SOAP messaging security with authentication, integrity, and confidentiality services. The first component of WS-Security is XML signatures. An XML-Signature [XMLSIG02, CXML03] can be applied to any portion of an XML document. It can be based on shared secret keys and a MAC (typically a keyed hash) or on public-key-based digital signatures (e.g., RSA). WS-Security defines security tokens that may specify identities or claims about possession of a key. They can be signed with XML-Signature. XML-Encryption [XMLENC02] defines a mechanism to provide confidentiality for portions of an XML document. It is designed to work together with XML-Signature. Security Assertion Markup Language (SAML) [SAML05, SAMLbp03, SAMLco05, SAMLgl05, SAMLsp05, SAMLto05] consists of XML and SOAP services, data structures, and protocols for exchanging identification, authentication, and authorization information. It is based on XML and SOAP, and it defines requests, responses, and faults. It does not use SOAP remote procedure calls. A typical use of SAML is to support access control decisions based on an identity. XACML (XML Access Control Markup Language) [XACML05] is an OASIS standard for expressing access controls in terms of subjects, resources, and actions. XKMS (XML Key Management Specification) [XKMS05] is a W3C specification that defines abstract interfaces to an underlying PKI. It has two parts: (1) X-KRSS (XML Key Registration Service Specification) for public key registration and revocation and (2) X-KISS (XML Key Information Service Specification) for locating and validating keys. Because Web Services typically use multiple servers, single sign-on, which avoids requiring users to re-authenticate to each server, is often an important requirement. www.oiforum.com 20 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 9.4 Web Services Security Protocol Stack The following list specifies the different places where security fits into a WS protocol stack: 9.5 • At the Application Layer, security for Web Services based management using XML MUST consist of XML digital signatures (XML-DSIG), XML encryption (XML-ENC), and XML key management (XKMS). • At the Network Layer, IPsec MAY be used with IPv4 or IPv6. • At the Transport Layer, SSL 3.0 or TLS MAY be run over TCP. • Application Transport usually consists of running everything over HTTP, so the usual firewall settings for the Web SHOULD be applied. • Many WS applications rely on the Domain Name System (DNS) to discover servers, store and retrieve certificates or schemas, and perform other operations. Therefore, secure operation of the DNS and protection of DNS servers against denial of service attacks is a critical component of WS security. The deployment of DNS SHOULD follow the guidelines in [NIST05]. • Application Descriptions written in WSDL MUST be secured with XMLDSIG. • Application Messaging with SOAP over XML MUST be secured with XML-DSIG, XML-ENC, and XKMS. They SHOULD be secured with WSSecurity, SAML (for identity management, authentication, and authorization), and XACML (for Application Layer access control) where these protocols apply. They MAY also be secured with WS-Security WSDL. • Discovery with UDDI over XML MUST be secured with IPsec, TLS, or XML-DSIG and XML-ENC. • For PKI, the IETF’s Internet X.509 PKIX [HFP99] MUST be used. Web Services Security Profile This section identifies WS and WSS standards. Each sub-section identifies the working group leading the development of the standard. Internet Engineering Task Force (IETF) Standard www.oiforum.com Type Status References 21 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements HTTP 1.0 and 1.1 Core Stable RFC 2616 LDAPv3 Support Stable RFC 3673 SysLog Support Revision OIF draft IA IPsec Security Revision OIF IAs [SecExt], [SecAdd] TLS (and SSL v3.0) Security Extensions OIF IA [SecMgmt] URI Core Stable RFC 3617 World Wide Web Consortium (W3C) Standard Type Status References XML Core Stable [XML04], [CXML01] SOAP Core Version 2.0 in progress [SOAP003], [SOAP103], [SOAP203], [SOAPT03] WSDL Core Stable [WSDLP06], [WSDL106], [WSDL106], [WSDL106] XML Schema Core Stable [XMLS004], [XMLS104], [XMLS204] XML-DSIG Security Stable [XMLSIG02] XML-ENC Security Stable [XMLENC02] XKMS Security Support Stable [XKMS05] 9.5.1 Profile of XML-DSIG All of the stipulations in this standard [XMLSIG02] apply. In addition, the following notes profile the XML-DSIG specification for use in securing Web Services based management systems: • See RFC 2807 for XML signature requirements. • See http://www.w3.org/2001/10/xmldsig-errata for clarifications and updates to the specification. • The reference to FIPS 180-1 is updated to FIPS 180-2. • The reference to RFC 1750 is updated to RFC 4086 [ESC05]. • The URI reference to RFC 2396 is updated to RFC 3986 [BFM05]. www.oiforum.com 22 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements • This specification defines both a MAC based on HMAC-SHA-1 and a shared secret and a digital signature scheme based on a hash function and a public key system. The former is more efficient and ideally suited to protecting messages on communications channels between two parties, but it needs a shared secret. The latter is more suitable to authenticating messages in store-and-forward systems, messages that may exist persistently and need to be authenticated at undetermined future times, and messages that may need to be authenticated by multiple parties. • In all cases, MD5 MUST NOT be used. • Applications SHOULD use time stamps or increasing message IDs to help identify replays. • Implementation of Base64 [FB96], XPath node-sets [XPath99], and XMLC14N canonicalization [Boy01] is REQUIRED. • URI attributes MUST NOT include fragment identifiers. • The PGPData, SPKIData, and MgmtData elements SHOULD NOT be used. For public-key based signatures: • DSA signatures are RECOMMENDED over RSA signatures because they are shorter, are more efficient for the signer, and allow pre-computation. RSA signatures have more flexible key sizes and are more efficient for the verifier. They MAY be used if these characteristics are critical for the security or application requirements. • Applications are encouraged to use the Manifest element together with multiple reference objects to reduce the number of more computationally expensive public key operations required. • Applications SHOULD use keyInfo with type X509Data. The RetrievalMethod element is RECOMMENDED to keep messages short. 9.5.2 Profile of XML Encryption Syntax and Processing All of the stipulations in this standard [XMLENC02] apply. In addition, the following notes profile the XML-ENC specification for use in securing Web Services based management systems: • See http://www.w3.org/TR/xml-encryption-req for XML encryption requirements. • See http://www.w3.org/Encryption/2002/12-xmlenc-errata for clarifications and updates to the [XMLENC02] specification. www.oiforum.com 23 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements • Compliance with the XML Namespace Specification [XMLNS99] is REQUIRED. • Decryption MUST allow up to 255 bytes of padding. • An integrity check [XMLSIG02] MUST be applied to data encrypted with this standard. • Implementation of Base64 [FB96], XPath node-sets [XPath99], and XMLC14N canonicalization [Boy01] is REQUIRED. • Users are cautioned that the EncryptionMethod, KeyInfo, and EncryptionProperties elements may reveal some information about the encryption process. • The following algorithms MUST be implemented: o Block Encryption: AES-128 o Key Transport: RSA-OAEP o Symmetric Key Wrap: AES-128 o Message Digest: SHA-1 9.5.3 Profile of XKMS 2.0 • See http://www.w3.org/TR/2003/NOTE-xkms2-req-20030505 for the XML Key management requirements. • Note that this document describes an information service and a registration service for public keys used with XML-DSIG and XML Encryption. It does not address PKI issues and trust models directly. • Clients MUST be configured securely with the FQDNs or IP addresses of all servers they use and with the keys used to authenticate responses. Without other means of verification, clients MUST NOT rely on a DNS SRV RR to discover a server. For example, if the client uses the KISS Locate service to parse a certificate and obtain a name and key, it has to trust the server to return the correct name. The same considerations apply to the KISS validate service. • Similarly, servers MUST authenticate clients of the Registration service. • Communications between clients and servers MUST use message-level integrity and replay detection (secured, for example, with XML-DSIG, Secure HTTP, TLS, or IPsec). Message confidentiality is OPTIONAL, except for the transmission of private keys, in which case it is REQUIRED. www.oiforum.com 24 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements • Clients and servers MUST implement the two-phase request protocol, which servers SHOULD use when they detect a possible denial of service attack, even if signed requests are used. • Servers MUST require clients of the Registration service to provide proof of possession of the private key. • Clients SHOULD generate keys used for digital signatures themselves. 9.6 OASIS Standard Type Status References UDDI Core Stable [UDDI04] Web Services Security (WS-Security) Security Version 1.1 in public review [WSsec05] SAML Security v2.0 released [SAML05], [SAMLco05], [SAMLsp05], [SAMLsp05] XACML Security Revised 2005 [XACML05] WSS X.509 Certificate Token Profile Security Stable [WSSctp05] 9.6.1 Profile of WS-Security • This profile applies to version 1.1, [WSsec05], which is currently in review. • Note that this specification defines SOAP data structures intended to be building blocks for security protocols. It does not define the security protocols themselves, and, therefore, significant effort is still required to verify that protocols using these methods are secure. See, in particular, the Security Considerations in Section 13 of [WSsec05]. • This specification covers a wide variety of security methods, so use of the subset of these methods does not ensure interoperability. • The URI reference to RFC 2396 is updated to RFC 3986 [BFM05]. • If the same data are to be encrypted and signed, it is usually preferable to sign the encrypted data to protect against attacks that tamper with the ciphertext. www.oiforum.com 25 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements • 9.6.2 Inclusive canonicalization SHOULD be used, except in the case that signed information will be inserted into another XML document, in which case exclusive canonicalization SHOULD be used. Profile of SAML • Enveloped XML digital signatures MUST be implemented as the primary authentication and integrity method for SAML. • SAML protocol messages MUST be signed by the original sender. • SAML implementations MUST support RSA as an XML Digital Signature mechanism. • SAML messages MUST use and verify Time values to detect replay attacks. SAML assertions SHOULD contain valid lifetimes. • Because of the cost of verifying digital signatures, SAML is vulnerable to Denial of Service attacks. Therefore, the origin and integrity of SAML protocol messages SHOULD be protected by a lower-layer security system, e.g., TLS or IPsec. • SSL-TLS MUST be used with HTTP Basic Authentication. 9.6.3 Profile of XACML • XACML messages MUST be authenticated and protected with respect to integrity and replay detection. • XACML messages SHOULD be encrypted to protect confidentiality as well. • XACML policies MUST be signed by the issuer of the policy. • A “not applicable” response from a Policy Decision Point MUST be treated as a “deny.” www.oiforum.com 26 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 9.7 ANSI, NIST, and ITU-T Standard Type Status ANSI X9.84 (XCBF) Security Stable ANSI X9.96 (XCMS) Security Stable ANSI X9.73 (CMS) Core Stable NIST SP 800-81 Security Support Draft ITU-T X.509 Core Stable 10 References [NIST05] Alignment with Other Network Management Security Standards This Implementation Agreement relies entirely on specifications of security developed in other SDOs. It consolidates, profiles, and applies many aspects of the work done in other SDOs to specify how different security systems can be used to satisfy management security objectives. The IETF has developed numerous systems for security (IPsec, TLS, SSH, and Kerberos) and management security protocols (SNMPv3) that are used in this IA. Section 6.2 discusses the additional SDOs that are developing standards for Web Services and Web Services Security, in particular, W3C and OASIS. Management Security has been an ongoing activity in several other SDO’s. The American National Standard T1.276-2003, Baseline Security Requirements for the Management Plane was originally submitted by Committee T1 to ATIS T1M1.5 and approved as a standard for providing security requirements to allow for the implementation of a secure network management for management systems. The original IA, [SecMgmt], which this document updates, was aligned with this ATIS-T1 standard with respect to the terminology and reference model. The International Organization for Standardization (ISO) has developed Guidelines for the Management of IT Security (GMITS). Five separate documents have been developed on various aspects of managing IT security. Part 1: Concepts and models for IT Security Part 2: Managing and planning IT Security www.oiforum.com 27 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Part 3: Techniques for the management of IT Security Part 4: Selection of safeguards Part 5: Management guidance on network security ITU-T SG 15 is the study group for optical and transport network infrastructures. They have produced G.7718 and G.7718.1, ASON Control Plane Management. The ITU-T SG 4 is the lead study group on telecommunication, network and next generation networks management. This study group established the NGN Management Focus Group in September in 2004. They have also worked to produce a series of Security of the Management Plane, M.3016, documents. The M.3016 series are: M.3016.0: Overview M.3016.1: Requirements M.3016.2: Services M.3016.3: Mechanisms M.3016.4: Profile proforma Question 18 of Study Group 3 is working on revising these recommendations. They are incorporating concepts from ITU-T Recommendation X.805 and ANSI T1.276-2003. 3GPP SA 5 has a series of documents as well for NGN Management: 32.101/32.102: Principles and architecture, 32.150 series: IRP methodology, 32.111 series: alarm IRP, 32.200 series: subset for IMS charging and billing, 32.300: Common Management Series, 32.400: Performance Management series The TeleManagement Forum (TMF) has worked on developing Multi-technology Network Management (MTNM), but this work has not addressed security. This work in the OIF complements these activities by filling in security objectives and specifying how complete security systems can be applied to network management. www.oiforum.com 28 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 11 Relationship between Security Objectives and Security Systems Table 1 in [SecMgmt] is updated as follows, in which the “WS Security” column has been added and a + denotes a new entry: Table 1: Applicability of Security Solutions to Different Interfaces. Interface Web or CORBA MIB based over TCP MIB based over UDP Command Line www.oiforum.com Kerberos SNMPv3 SSL/TLS SSH √ √ √ + √ √ WS Security + IPsec √ √ √ √ √ √ 29 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Table 2 in [SecMgmt] is updated with a new column titled “WS Security:” Objective C-1 C-2 C-3 C-4 I-1 I-2 I-3 I-4 K-1 K-2 K-3 K-4 A-1 A-2 N-1 N-2 R-1 AC-1 AC-2 L-1 L-2 L-3 L-4 L-5 L-6 D-1 D-2 T-1 T-2 Kerberos √ √ May May √ √ May SNMPv3 √ May √ Note 1 SSL-TLS √ √ May May √ Note 2 May SSH √ √ May May √ √ May Note 1 √ √ √ Note 3 Note 3 Note 3 Note 4 √ √ √ Note 5 √ √ √ Note 6 Note 2 Note 2 May May May √ Note 2 May May May May √ √ Note 8 Note 8 May √ Note 8 Note 8 May √ √ √, using resume session √ √ May √ Note 2 Note 2 May May May May May √ Note 8 Note 8 May √ √ May √ √ May √ Note 2 Note 2 May May May May May Note 8 Note 8 May IPsec √ √ May √ √ √ May √, within preset window √ √ √ √ √ √ √ √ Note 7 May √ Note 8 Note 8 √ Note 9 WSS √ √ May May √ √ May √ √ √ √, key lifetimes √ √ May May √ √ √ May May √ √ May Note 8 Note 8 May Table 2: Mapping of Objectives to Security Systems (Cont.). Note 1: This objective can be satisfied by using the Timeliness Value. Note 2: This objective can be satisfied by using TCP Wrappers at the server. Note 3: To satisfy this objective, a secure key distribution protocol (Kerberos or IKE) needs to be implemented: Kerberos can satisfy K-1 and K-2, IKE can satisfy K-1, K-2, and K-3. www.oiforum.com 30 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Note 4: This objective can be satisfied by using pre-placed initial keys and the rekeying option. Note 5: This objective can be satisfied by using the negotiation protocol for GSSAPI for the application. Note 6: N-2 may be satisfied, fully or partially, by using certain key management protocols (e.g., IKE) with SNMPv3. Note 7: Support for non-repudiation of message origin can be provided by using an asymmetric (digital signature) algorithm for the integrity check (which has been proposed for multicast groups). Note 8: In all cases of denial of service objectives D-1 and D-2, the degree to which these objectives are satisfied depends upon the implementation, not the protocol. In the design of IPsec and WSS, certain explicit choices were made to reduce the impact of denial of service attacks. Kerberos and SNMPv3 have the potential advantage over the others that they do not rely on the costly public key computations that can overload processing capability. Note 9: The current version of IPsec provides some support for this objective; a newer version, still in draft [April 2003], provides much greater support. 12 www.oiforum.com 31 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements References 12.1 Normative References [BFM05] [BKN06] [Bla03] [Boy01] [Bra97] [Blu04] [BW00] [CF06] [CHPW00] [Cho02] [CXML01] [DA99] [DR05] [Eas05] www.oiforum.com Berners-Lee, T., R. Fielding, and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” IETF RFC 3986, January 2005. Bellare, M., T. Kohno, and C. Namprempre, “The Secure Shell (SSH) Transport Layer Encryption Modes,” IETF RFC 4344, January 2006. Blake-Wilson, S., et al., “Transport Layer Security (TLS) Extensions,” IETF RFC 3546, June 2003. Boyer, J., “Canonical XML Version 1.0,” IETF RFC 3076, March 2001. Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” IETF RFC 2119, March 1997. Blumenthal, B, F. Maino, and K. McCloghrie, “Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model,” IETF RFC 3826, June 2004. Blumenthal, U., and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3),” IETF RFC 3414, December 2002. Cusack, F., and M. Forssen, “Generic Message Exchange Authentication for the Secure Shell Protocol (SSH),” IETF RFC 4256, January 2006. Case, J., D. Harrington, R. Presuhn, and B. Wijnen, “Message Processing and Dispatching for the Simple Network Management Protocol (SNMP),” IETF RFC 3412, December 2002. Chown, P., “Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS),” IETF RFC 3268, June 2003. Boyar, J., “Canonical XML, Version 1.0,” W3C Recommendation 15 March 2001, http://www.w3.org/TR/2001/REC-xml-c14n20010315. Dierks, T., and C. Allen, “The TLS Protocol,” IETF RFC 2246, January 1999. Dierks, T., and E. Rescorla, “The TLS Protocol, Version1.1,” IETF Work in Progress, draft-ietf-tls-rfc2246bis-13, June 2005. Eastlake, D., “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH),” IETF RFC 4305, December, 2005. 32 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [E-NNI] [ET05] [FB96] [FCK96] [FGK03] [FH03] [Fie99] [FPS05] [GHM04] [GK98] [GL06] [GT06] [Gup05] [GVMB05] [HBR04] [HC98] www.oiforum.com Optical Internetworking Forum Implementation Agreement, “Intra-Carrier E-NNI Signaling Specification,” OIF-E-NNI-Sig01.0, February 27, 2004. Eronen, P., and H. Tschofenig, “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS),” IETF RFC 4279, December 2005. Freed, N., and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” IETF RFC 2045, November 1996. Freier, A.O., P. Carlton, and P.C. Kocher, “The SSL Protocol Version 3.0,” http://home.netscape.com/eng/ssl3/draft302.txt, November 1996. Frankel, S., R. Glenn, and S. Kelly, “The AES-CBC Cipher Algorithm and Its Use with IPsec,” IETF RFC 3602, September 2003. Frankel, S., and H. Herbert, “The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec,” IETF RFC 3566, September 2003. Fielding, R., et al., “Hypertext Transfer Protocol -- HTTP/1.1,” IETF RFC 2616, June 1999. Friedl, M., N. Provos, and W. Simpson, “Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol,” IETF Work in Progress draft-ietf-secsh-dh-group-exchange-05, July 2005. Gill, V., J. Heasley, and D. Meyer, “The Generalized TTL Security Mechanism (GTSM),” IETF RFC 3682, February 2004. Glenn, R., and S. Kent, “The NULL Encryption Algorithm and Its Use With IPsec,” RFC 2410, November 1998. Galbraith, J., and P. Remaker, “The Secure Shell (SSH) Session Channel Break Extension,” IETF RFC 4335, January 2006. Galbraith, J., and R. Thayer, “SSH Public Key File Format,” IETF Work in Progress draft-ietf-secsh-publickeyfile-13, March 2006. Gupta, V., et al., “ECC Cipher Suites for TLS,” IETF Work in Progress draft-ietf-tls-ecc-12, October 2005. Galbraith, J., J. Van Dyke, B. McClure, and J. Bright, “Secure Shell Public-Key Subsystem,” IETF Work in Progress draft-ietfsecsh-publickey-subsystem-05, September 2005. Huang, G., S. Beaulieu, and D. Rochefort, “A Traffic-Based Method of Detecting Dead IKE Peers,” IETF RFC 3706, February 2004. Harkins, D., and D. Carrel, “The Internet Key Exchange (IKE),” IETF RFC 2409, November 1998. 33 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [HFPS99] [Hof04] [Hof05a] [Hof05b] [Hof06] [Hol04] [Hou04] [Hou05] [HPW00] [HSGW05] [Hut05] [KA98a] [KA98b] [KA98c] [Kau05] [KBC97] [Ken05a] [Ken05b] www.oiforum.com Housley, R., W. Ford, W. Polk, and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” IETF RFC 3280, April 2002. Hoffman, P., “The AES-XCBC-PRF-128 algorithm for IKE,” IETF RFC 3664, January 2004. Hoffman, P., “Cryptographic Suites for IPsec,” IETF RFC 4308, December 2005. Hoffman, P., “Algorithms for Internet Key Exchange version 1 (IKEv1),” IETF RFC 4109, May 2005. Hoffman, P., “The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE),” IETF RFC 4434, February 2006. Hollenbeck, S., “Transport Layer Security Protocol Compression Methods,” IETF RFC 3749, May 2004. Housley, R., “Using AES Counter Mode With IPsec ESP,” IETF RFC 3686, January 2004. Housley, R., “Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP),” IETF RFC 4309, December 2005. Harrington, D., R. Presuhn, and B., Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” IETF RFC 3411, December 2002. Hutzelman, J., J. Salowey, J. Galbraith, and V. Welch, “GSSAPI Authentication and Key Exchange for the Secure Shell Protocol,” IETF Work in Progress draft-ietf-secsh-gsskeyex-10, August 2005. Huttunen, A., et al., “UDP Encapsulation of IPsec Packets,” IETF RFC 3948, January 2005. Kent, S., and R. Atkinson, “Security Architecture for the Internet Protocol,” IETF RFC 2401, November 1998. Kent, S., and R. Atkinson, “IP Authentication Header,” IETF RFC 2402, November 1998. Kent, S., and R. Atkinson, “IP Encapsulating Security Payload (ESP),” IETF RFC 2406, November 1998. Kaufman, C., ed., “Internet Key Exchange (IKEv2) Protocol,” IETF RFC 4306, December 2005. Krawczyk, H., M. Bellare, and R. Canetti, “HMAC: KeyedHashing for Message Authentication,” IETF RFC 2104, February 1997. Kent, S., “IP Encapsulating Security Payload (ESP),” IETF RFC 4303, December 2005. Kent, S., “Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security 34 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [Ken05c] [Kerb05] [Kiv05] [KK03] [KL00] [Kor06] [KS05] [LA03] [LL06] [LMS00] [LogAud] [MG98] [MH99] [MSST98] [Mil92] [Mur97] [NIST05] www.oiforum.com Association and Key Management Protocol (ISAKMP),” IETF RFC 4304, December 2005. Kent, S., “IP Authentication Header,” IETF RFC 4302, December 2005. Yu, T., “The Kerberos Network Authentication Service (Version 5),” IETF RFC 4121, July 2005. Kivinen, T., et al., “Negotiation of NAT-Traversal in the IKE, RFC 3947, January 2005. Kivenen, T., and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE),” IETF RFC 3526, May 2003. Khare, R., and S. Lawrence, “Upgrading to TLS Within HTTP/1.1,” IETF RFC 2817, May 2000. Korver, B., “The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX,” IETF Work in Progress, draft-ietf-pki4ipsec-ikecert-profile-08, February 2006. Kent, S., and K. Seo, “Security Architecture for the Internet Protocol,” IETF RFC 4301, December 2005. Li, T., and R. Atkinson, “Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication,” IETF RFC 3567, July 2003 (Informational). S. Lehtinen, S., and C. Lonvick, “The Secure Shell (SSH) Protocol Assigned Numbers,” IETF RFC 4250, January 2006. Levi, D., P. Meyer, and B. Stewart, “Simple Network Management Protocol (SNMP) Applications,” IETF RFC 3413, December 2002. Optical Internetworking Forum Work in Progress, “OIF Control Plane Logging and Auditing with Syslog,” July 2005. Madson, C., and R. Glenn, “The Use of HMAC-SHA-1-96 within ESP and AH,” IETF RFC 2404, November 1998. Medvinsky, A., and M. Hur, “Addition of Kerberos Cipher Suites to Transport Layer Security (TLS),” IETF RFC 2712, October 1999. Maughan, D., M. Schertler, M. Schneider, and J. Turner, “Internet Security Association and Key Management Protocol (ISAKMP),” IETF RFC 2408, November 1998. Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” IETF RFC 1305, March 1992. Murphy, S., et al., “OSPF with Digital Signatures,” RFC 2154, June 1997. Chandramouli, R., and S. Rose, “Secure Domain Name System (DNS) Deployment Guide,” NIST Special Publication 800-81, Draft, August 2005. 35 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [NNI-OSPF] Optical Internetworking Forum Work in Progress, NNI Routing with OSPF. [NNI-IS-IS] Optical Internetworking Forum Work in Progress, NNI Routing with IS-IS. [PA98] Pereira, R., and R. Adams, “The ESP CBC-Mode Cipher Algorithms,” IETF RFC 2451, November 1998. [Pip98] Piper, D., “The Internet IP Security Domain of Interpretation for ISAKMP,” IETF RFC 2407, November 1998. [Rae04] Raeburn, K., “AES Encryption for Kerberos 5,” RFC 3962, February 2005. [Res00] Rescorla, E., “HTTP over TLS,” IETF RFC 2818, May 2000. [Rig00] Rigney, C., et al., “Remote Authentication Dial In User Service (RADIUS),” IETF RFC 2865, June 2000. [SAML05] Cantor, S., et al., “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard, March 2005, oasis-saml-core-2.0-os, http://docs.oasisopen.org/security/saml/v2.0/saml-core-2.0-os.pdf . [SAMLbp05] Cantor, S., et al., “Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard, March 2005, saml-bindings-2.0-os, http://docs.oasisopen.org/security/saml/v2.0/saml-bindings-2.0-os.pdf. [SAMLco05] Mishra, P., R. Philpott, and E. Maler, “Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard, March 2005, saml-conformance-2.0-os, http://docs.oasis-open.org/security/saml/v2.0/samlconformance-2.0-os.pdf. [SAMLsp05] Hirsch, F., R. Philpott, and E. Maler,, “Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard, March 2005, Document identifier oasis-sstc-saml-sec-consider-2.0-os, http://docs.oasisopen.org/security/saml/ v2.0/saml-sec-consider-2.0-os.pdf [Sch04] Schiller, J., “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),” IETF RFC 4307, December 2005. [SecAdd] Optical Internetworking Forum, “Addendum to the Security Extension for UNI and NNI,” OIF-SEP-02.1, March 2006. [SecExt] Optical Internetworking Forum Implementation Agreement, “Security Extension for UNI and NNI,” OIF-SEP-01.1, May 8, 2003. [SecMgmt] Optical Internetworking Forum Implementation Agreement, “Security for Management Interfaces to Network Elements,” OIF-SMI-01.0, September 4, 2003. www.oiforum.com 36 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [SG06] Shelter, J., and W. Griffin, “Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints,” IETF RFC 4255, January 2006. [T1M1] “Operations, Administration, Maintenance, and Provisioning Security Requirements for the Public Telecommunications Network: A Baseline of Security Requirements for the Management Plane,” T1.276-2003, July 2003. [Tung06] Tung, B., “Public Key Cryptography for Initial Authentication in Kerberos,” draft-ietf-cat-kerberos-pk-init-34, February 2006. [TWMP05] Taylor, D., T. Wu, N. Mavroyanopoulos, and T. Perrin, “Using SRP for TLS Authentication,” IETF Work in Progress draft-ietftls-srp-10, October 2005. [UDDI04] Clement, L., et al., “UDDI Version 3.0.2,” OASIS UDDI Spec Technical Committee Draft, October 2004, http://uddi.org/pubs/uddi-v3.0.2-20041019.htm. [UNI1.0] Optical Internetworking Forum Implementation Agreement, “User Network Interface (UNI) 1.0 Signaling Specification,” OIF-UNI-01.1, October 1, 2001. [UNI1.0r2] OIF Implementation Agreement, “OIF-UNI-01.0-R2-Common User Network Interface (UNI) 1.0 Signaling Specification, Release 2: Common Part,” OIF-UNI-01.0-R2-Common, February 27, 2004. [UNI1.0r2r] OIF Implementation Agreement, “OIF-UNI-01.0-R2-RSVP - RSVP Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2,” OIF-UNI-01.0-R2-RSVP, February 27, 2004. [VM05] Viega, J., D. McGrew, “The Use of Galois/Counter Mode (GCM) in IPsec ESP,” IETF RFC 4106, June 2005. [WPM00] Wijnen, B., R. Presuhn, and K. McCloghrie, “View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP),” IETF RFC 3415, December 2002. [WSsec05] Nadalin, A., et al., “Web Services Security: SOAP Message Security 1.1 (WS-Security 2004),” OASIS public review document, June 2005, http://docs.oasisopen.org/wss/2005/xx/wss-v1.1-spec-prSOAPMessageSecurity-01. [WSDLp06] Booth, D., and C. Liu, “Web Services Description Language (WSDL) Version 2.0 Part 0: Primer,” W3C Candidate Recommendation, January 2006, http://www.w3.org/TR/2006/CR-wsdl20-primer-20060106. [WSDL106] Chinnici, R., et al., “Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language,” W3C Candidate Recommendation, January 2006,, http://www.w3.org/TR/2006/CR-wsdl20-20060106. www.oiforum.com 37 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [WSDL206] Chinnici, R., et al., “Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts,” W3C Candidate Recommendation, January 2006, http://www.w3.org/TR/2006/CR-wsdl20-adjuncts20060106. [WSDL306] Vedamuthu, A., “Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding,” W3C Working Draft 3, January 2006, http://www.w3.org/TR/2006/WD-wsdl20-soap11-binding20060106/. [WSSctp05] Nadalin, A.., et al., “Web Services Security X.509 Certificate Token Profile 1.1,” OASIS Public Review Draft, June 2005, http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-prx509TokenProfile-01.pdf. [XACML05] Moses, T., “eXtensible Access Control Markup Language (XACML) Version 2.0,” OASIS Standard oasis-access_control-xacml-2.0-corespec-os, February 2005, http://docs.oasisopen.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf. [XKMS05] Hallam-Baker, P., “XML Key Management Specification (XKMS 2.0) Version 2.0,” W3C Recommendation 5, June 2005, http://www.w3.org/TR/2005/REC-xkms2-20050628/ . [XML04] Bray, T., “Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04, February 2004, http://www.w3.org/TR/2004/REC-xml-20040204/. [XMLENC02] Imamura, T., et al., “XML Encryption Syntax and Processing,” W3C Recommendation 10 December 2002, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/. [XMLNS99] Bray, T., D. Hollander, and A. Layman, “Namespaces in XML,” W3C Recommendation 14, January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114. [XMLSIG02] Bartel, M., et al., “XML-Signature Syntax and Processing,” W3C Recommendation 12, February 2002, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/. See also RFC 3275. [XPath99] Clark, J., and S. De Rose, “XML Path Language (XPath) Version 1.0,” W3C Recommendation 16, November 1999. [YL06a] Ylönen, T., and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” IETF RFC 4251, January 2006. [YL06b] Ylönen, T., and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” IETF RFC 4253, January 2006. [YL06c] Ylönen, T., and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” IETF RFC 4252, January 2006. [YL06d] Ylönen, T., and C. Lonvick, “The Secure Shell (SSH) Connection Protocol,” IETF RFC 4254, January 2006. www.oiforum.com 38 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements 12.2 Informative References [AD04] [ANSI95] [ATMF02] [Ber05] [BLS01] [Bon03] [DH98] [EH06] [ESC05] [Gut98] [IATF] [ITUDCN] [Kra03] [KSF99] www.oiforum.com Aboba, B., and W. Dixon, “IPsec-Network Address Translation (NAT) Compatibility Requirements,” IETF RFC 3715, March 2004. (Informational) “Synchronous Optical Network (SONET) Data Communications Channel Protocols and Architectures,” ANSI T1-105-04, 1995. Methods for Securely Managing ATM Network Elements— Implementation Agreement, The ATM Forum, AF-SEC-0179.000, April 2002. Berners-Lee, T., et al., “Uniform Resource Identifiers (URI): Generic Syntax,” IETF RFC 3986, January 2005. Boneh, D., B. Lynn, and H. Shacham, “Short Signatures from the Weil Pairing,” Advances in Cryptology—Asiacrypt 2001, LNCS Vol. 2248, Springer-Verlag, 2001. Boneh, D., et al., “Aggregate and Verifiably Encrypted Signatures from Bilinear Maps,” Advances in Cryptology— Eurocrypt 2003, Springer-Verlag, 2003. Deering, S., and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” IETF RFC 2460, December, 1998. Eronen, P., and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” IETF Work in Progress drafteronen-ipsec-ikev2-clarifications-08, February 2006. Eastlake, D., J. Schiller, and S. Crocker, “Randomness Requirements for Security,” IETF RFC 4086, June 2005. Gutmann, P., “Software Generation of Practically Strong Random Numbers,” Seventh USENIX Security Symposium Proceedings, The USENIX Association, 1998, pp. 243–257. Information Assurance Technical Framework Forum, http://www.iatf.net/protection_profiles/profiles.cfm. Architecture and Specification of Data Communication Network, ITU-T G.7712/Y.1703, March 2003. Krawczyk, H., “SIGMA: The SIGn-and-MAc approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols,” Advances in Cryptology—Crypto 2003, Springer-Verlag LNCS Vol. 2729, pp. 400-425. See also http://www.ee.technion.ac.il/~hugo/sigma.html. Kelsey, J., B. Schneier, and N. Ferguson, “Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator,” Sixth Annual Workshop on Selected Areas in Cryptography, Springer-Verlag, 1999. 39 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [NIST01] “Recommendation for Block Cipher Modes of Operation,” NIST Special Publication 800-38A, CODEN: NSPUE2, U.S. Government Printing Office, Washington, DC, December 2001. [Resc01] Rescorla, E., SSL and TLS, Addison-Wesley, 2001. [SAMLgl05] Hodges, J., R. Philpott, and E. Maler, “Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard, March 2005, saml-glossary-2.0-os, http://docs.oasisopen.org/security/saml/v2.0/ saml-glossary-2.0-os.pdf. [SAMLto05] Hughes, J., and E. Maler, “Security Assertion Markup Language (SAML) Technical Overview V2.0,” OASIS Working Draft 08, September 2005, sstc-saml-tech-overview-2.0-draft-08, http://www.oasis-open.org/committees/download.php/ 14361/sstc-saml-tech-overview-2.0-draft-08.pdf. [SOAP003] Mitra, N., “SOAP Version 1.2 Part 0: Primer,” W3C Recommendation 24, June 2003, http://www.w3.org/TR/2003/REC-soap12-part0-20030624/. [SOAP103] Gudgin, M., “SOAP Version 1.2 Part 1: Messaging Framework,” W3C Recommendation 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. [SOAP203] Gudgin, M., “SOAP Version 1.2 Part 2: Adjuncts,” W3C Recommendation 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part2-20030624/. [SOAPT03] Haas, H., “SOAP Version 1.2 Specification Assertions and Test Collection,” W3C Recommendation 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-testcollection20030624/. [SysL] IETF Syslog Working Group, http://www.ietf.org/html.charters/syslog-charter.html. [Tel1] Generic Requirements for Network Element/Network System Security, Telcordia GR815, March 2002. [Tel2] Generic Requirements for Data Network Security, Telcordia GR1332, April 1996. [XML04] Bray, T., et al., “Extensible Markup Language (XML) 1.1, W3C Recommendation 04 February 2004, edited in place 15 April 2004, http://www.w3.org/TR/2004/REC-xml11-20040204/. [XMLS004] Fallside, D., and P. Walmsley, “XML Schema Part 0: Primer Second Edition,” W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/. [XMLS104] Thompson, H., et al., “XML Schema Part 1: Structures Second Edition,” W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. www.oiforum.com 40 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements [XMLS204] [Yl96] Biron, P., and A. Malhotra, “XML Schema Part 2: Datatypes Second Edition,” W3C Recommendation 28, October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Ylönen, T., “SSH—Secure Login Connections over the Internet,” Proceedings of the Sixth USENIX Security Symposium, July 1996, pp. 37–42. Appendix A: Open Issues / current work items • None. Appendix B: List of companies belonging to OIF when document was approved ADVA Optical Networking Aevix Systems Agere Systems Agilent Technologies Alcatel Altera AMCC Analog Devices Anritsu Apogee Photonics, Inc. AT&T Avici Systems Azna Big Bear Networks Bookham Booz-Allen & Hamilton Broadcom China Telecom Ciena Corporation Cisco Systems CoreOptics Cortina Systems Cypress Semiconductor Data Connection Department of Defense Deutsche Telekom Elisa Communications www.oiforum.com 41 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Essex Corporation Finisar Corporation Flextronics Force 10 Networks Foxconn France Telecom Freescale Semiconductor Fujitsu Furukawa America Harris Corporation Hi/fn Huawei Technologies IBM Corporation IDT Infinera Intel JDS Uniphase KDDI R&D Laboratories Kodeos Communications KT Corporation Lambda Optical Systems Lattice Semiconductor LSI Logic Lucent Marconi Communications MCI MergeOptics GmbH Mindspeed MITRE Corporation Mitsubishi Electric Corporation Molex NEC Nortel Networks Northrop Grumman NTT Corporation Opnext Optovia OpVista Inc PMC Sierra Quake Technologies RedC Optical Networks Ltd. Redfern Integrated Optics, Inc. www.oiforum.com 42 OIF-SMI-02.1 Addendum to the Security for Management Interfaces to Network Elements Sandia National Laboratories Santur SBC Scintera Networks Siemens Silicon Laboratories Silicon Logic Engineering StrataLight Communications Sycamore Networks Syntune Tektronix Telcordia Technologies Telecom Italia Lab Tellabs TeraSea Texas Instruments Time Warner Cable Toshiba Corporation Tyco Electronics Verizon Vitesse Semiconductor Xilinx www.oiforum.com 43
© Copyright 2024