Forwarded from: Elizabeth Lennon <elizabeth.lennon@private> ITL BULLETIN FOR APRIL 2006 PROTECTING SENSITIVE INFORMATION TRANSMITTED IN PUBLIC NETWORKS Shirley Radack, Editor Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Technology Administration U.S. Department of Commerce The protection of sensitive information that is transmitted across interconnected networks is critical to the overall security of an organization's information and information systems. The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) recently issued guidance to assist organizations in strengthening their network security and in lessening the risks associated with the transmission of sensitive information across networks. The publication offers practical guidance on implementing security services based on Internet Protocol Security (IPsec). IPsec is a framework of open standards for ensuring private communications over public networks. IPsec is frequently used to achieve security controls in the layered protocols of network communications, and to create a virtual private network (VPN). An organization can build a VPN on top of existing physical networks to create a secure communications mechanism for the data and control information that is transmitted between networks. VPNs are used most often to protect communications carried over public networks, such as the Internet, which utilize Transmission Control Protocol/Internet Protocol (TCP/IP) network communications. When properly implemented, VPNs can protect the confidentiality and integrity of data, authenticate the origin of data, and provide data replay protection and access control. However, VPNs cannot eliminate all risks since flaws in algorithms or software, or insecure configuration settings and values may still be exploited by hackers. NIST Special Publication (SP) 800-77, Guide to IPsec VPNs Written by Sheila Frankel of NIST, and Karen Kent, Ryan Lewkowski, Angela D. Orebaugh, Ronald W. Ritchey, and Steven R. Sharma of Booz Allen Hamilton, NIST SP 800-77 helps network architects, network administrators, security staff, technical support staff, and computer security program managers who are responsible for the technical aspects of preparing, operating, and securing their organization's networks. The information discussed is general in nature and can be applied to many different hardware platforms, operating systems, and applications. Topics covered include the need for network layer security services, the services that are available at the network layer, and how IPsec can be implemented to provide these services. A case-based approach illustrates how IPsec can be used to solve common network security concerns. The guide explains IPsec planning and implementation issues; it also discusses alternatives to IPsec and the appropriate circumstances in which to deploy each alternative. The appendices discuss the need for organizations to develop their IPsec-related policies and present examples of common IPsec policy issues that should be considered. Also included in the appendices are configuration files that are referenced by the case studies, a glossary, an acronym list, and a compilation of print and online resources that may be useful for IPsec planning and implementation. The publication is available on NIST's web pages at: http://csrc.nist.gov/publications/nistpubs/index.html. The Need for Network Security Widely used throughout the world, Transmission Control Protocol/Internet Protocol (TCP/IP) network communications are composed of four layers of protocols that work together: application, transport, network, and data link. Security controls are available for network communications at each of the four layers: The application layer sends and receives data for an application. Separate controls must be established for each application. While this arrangement provides a high degree of control and flexibility for the security of the application, it may cause the organization to devote considerable resources to implement. The development of new application layer security controls can also create new vulnerabilities, and it may not be possible to develop the controls for some applications. The transport layer provides connection-oriented or connectionless services to transport application layer services across networks. Controls at this layer can protect data in a single communications session between two hosts, and must be supported by both clients and servers. The network layer routes packets across networks. Controls at this layer apply to all applications, rather than to specific applications. Applications do not have to be modified to use the controls, but this arrangement provides less control and flexibility for protecting specific applications than the transport and application layer controls. The data link layer handles communications on the physical network components. Controls at this level protect a specific physical link. Since each physical link must be secured separately, controls at this level are not feasible for protecting connections that involve several links, including most connections across the Internet. As data is prepared for transport through the network, it is passed from the highest to the lowest layer, with each layer adding more information. Security controls at a higher layer cannot provide full protection for the lower layers, because the lower layers add information to the communications after the higher-layer security controls have been applied. The lower-layer security controls are less flexible and granular than higher-layer controls. As a result, controls at the network layer are widely used to secure communications and to provide a more balanced solution than can be achieved through the application of the higher-layer and lower-layer security controls. Internet Protocol Security (IPsec) IPsec is the most commonly used network layer security control for protecting communications. It was developed by the IPsec Working Group of the Internet Engineering Task Force (IETF) as a framework of open standards. Depending upon the implementation and configuration, IPsec can provide the following types of protection: * Ensuring the confidentiality of data through the application of a cryptographic algorithm and a secret key, known only to the two parties exchanging data. The data that is transmitted can be decrypted only by someone who has the secret key. * Assuring the integrity of data through the application of a message authentication code (MAC), which is a cryptographic hash of the data. The checksum is sent with the data. The recipient can detect when the data has been changed, either intentionally or unintentionally during transit, if a new MAC is calculated on the received data and it does not match the original MAC. * Providing peer authentication to ensure that network traffic and data are sent from the expected host. The receiving IPsec endpoint can confirm the identity of the sending IPsec endpoint. * Providing replay protection to assure that the same data is not delivered multiple times and that the data is delivered in an acceptable order. IPsec cannot, however, ensure that the data has been received in the exact order that it was sent. * Providing traffic analysis protection by obscuring the identities of the endpoints and the size of the data. Those who are monitoring network traffic may not know which parties are communicating, how often communications occur, or how much data is being exchanged. * Providing access control by assuring that only authorized users can access particular network resources. IPsec endpoints can also allow or block certain types of network traffic, such as allowing web server access but denying file sharing. Components of IPsec The IPsec network layer security protocol provides protection through the following components, which are used in various combinations: Authentication Header (AH) and Encapsulating Security Payload (ESP) security protocols. ESP provides encryption and integrity protection for packets, but it cannot directly protect the outermost IP header. (It can protect it indirectly, if Internet Key Exchange (IKE) is used to negotiate the IPsec protections.) AH provides integrity protection for packet headers and data but without encryption. AH can also protect some header information that ESP cannot protect. ESP is used more frequently than AH because of its encryption capabilities and other operational advantages. Internet Key Exchange (IKE) protocol. IKE negotiates the cryptographic algorithms and related security parameters and controls that comprise the security associations (SAs) that are applied to IPsec-protected connections. Other protections provided by this protocol include mutual authentication of endpoints; negotiation of secret keys; and management, update, and deletion of IPsec-protected communication channels. An updated, streamlined IKE (version 2) has been standardized, but most current implementations adhere to the original IKE, version 1. IP Payload Compression Protocol (IPComp). IPsec uses this protocol to compress packet payloads before encrypting them. For the IPsec-applied encryption and integrity-protection processes, federal agencies are required to use cryptographic algorithms that are specified in Federal Information Processing Standards (FIPS) or in NIST Recommendations that are issued in NIST Special Publication 800 series. The FIPS-approved algorithms must be contained in cryptographic modules that have been validated for conformance to FIPS 140-2, Security Requirements for Cryptographic Modules, through the Cryptographic Module Validation Program (CMVP). Algorithms that are FIPS-approved include FIPS 197, Advanced Encryption Algorithm (AES), the strongest approved algorithm and the preferred algorithm for federal agency use. Also approved is the Triple Data Encryption Algorithm (TDEA), which is specified in American National Standard (ANSI) X9.52-1998 and validated using the tests that are contained in NIST SP 800-20, Modes of Operation Validation System for the Triple Data Encryption Algorithm. In addition, the FIPS-approved algorithm for message authentication is FIPS 198, Keyed-Hash Message Authentication Code. This algorithm is used to construct a Keyed-Hash Message Authentication Code (HMAC) using secure hash algorithms that are specified in FIPS 180-2, Secure Hash Standard. Virtual Private Networks (VPNs) The VPN is a virtual network, which is built on top of existing physical networks, and which provides a secure communications mechanism for data and IP information exchanged between public networks. This method of networking can be less expensive for an organization than utilizing dedicated private telecommunications lines to provide communications between the organization's home and branch offices, and between remote telecommuters and the main servers. There are three models for VPNs: The gateway-to-gateway model protects communications between two specific networks, such as an organization's main office network and a branch office network, or between two business partners' networks. The host-to-gateway model protects communications between one or more individual hosts and an organization's specific network, allowing hosts on unsecured networks, such as traveling employees and telecommuters, to have access to the organization's internal services. The host-to-host model protects communications between two specific computers and is most often used when a small number of users need access to a remote system. IPsec implementations can be used to support VPN services. SP 800-77 establishes the following requirements for the configuration of IPsec VPNs: * The VPN must provide confidentiality protection through encryption for any information that will traverse a VPN and that should not be seen by non-VPN users. * A VPN must use a FIPS-approved encryption algorithm. The Advanced Encryption Algorithm in Cipher Block Chaining mode (AES-CBC) is highly recommended. Triple DES in Cipher Block Chaining mode (3DES-CBC) is acceptable as well. * A VPN must always provide integrity protection. * A VPN must use a FIPS-approved algorithm to provide for integrity protection. HMAC-SHA-1 is highly recommended and is based on FIPS 198, Keyed-Hash Message Authentication Code (HMAC), and FIPS 180-2, Secure Hash Signature Standard. * A VPN should provide replay protection. * IKE security associations (SAs) for applications of IKE version 1 should have a lifetime no greater than 24 hours, and IPsec SAs should have a lifetime no greater than 8 hours. For IKE version 2, IKE SAs for the original packets should be re-keyed at least every 24 hours, and SAs for encapsulated packets associated with the original packets should be re-keyed after 8 hours at most. * The Diffie-Hellman (DH) group of values is used to specify the encryption generator type and key length to be used for generating shared secrets. The value used to establish the secret keying material for IKE and IPsec should be consistent with current security requirements. Specific DH groups are defined for use with IKE. DH group 2 should be used for Triple DES and for AES with a 128-bit key. For greater security, DH group 5 or DH group 14 may be used for AES. IPsec implementations include DH group 2; most include DH group 5; very few include DH group 14. Use of the larger DH groups results in increased processing time. IPsec Planning and Implementation NIST advises that agencies apply the principles of the System Development Life Cycle and carry out a risk-based and phased approach in planning for and implementing IPsec in their networked systems. This approach enables agencies to determine appropriate priorities for protecting their systems, to apply appropriate technologies, including the use of IPsec and VPNs, and to incorporate new technology when needed to meet changing requirements. Organizations should identify their needs to protect their networked communications and determine which computers, networks, and data are part of the networked communications. They should determine how their needs can best be met, and where and how security technology should be implemented. The next phase of the risk-based approach is to design the solution that meets the needs, taking into account four major issues: The architectural design includes consideration of host and gateway placement, IPsec client software selection, and host address space management. An authentication method, such as pre-shared key or digital signature, should be selected. The algorithms for encryption and integrity protection, and the key strength for algorithms that support multiple key lengths, should be selected. The packet filter should be determined to control the types of traffic to be permitted and denied, and to apply appropriate protection and compression measures to each type of permitted traffic, and packet filters. The decisions made regarding authentication, cryptography, and packet filters should be documented in the organization's IPsec policy. Organizations should then implement and test a prototype of the designed solution in a laboratory or test environment. The primary goals of the testing are to evaluate the functionality, performance, scalability, and security of the solution, and to identify any issues, such as compatibility and interoperability of the IPsec components. The security of the implementation is a special concern, since no protocol can be totally secure. Special attention should be paid to the security of stored keys, the traffic that passes through the packet filters, and the use of patches that are developed as new vulnerabilities are found. When the testing has been completed and all issues have been resolved, organizations should deploy the solution by migrating gradually to the use of IPsec throughout the enterprise. The gradual approach enables managers to replace the existing network infrastructure and applications, to train users, to evaluate the impact of the IPsec solution, and to resolve issues. Most of the issues that can occur during IPsec deployment are the same types of issues that occur during any large IT deployment. Service to users, the performance of the network, and client software may be affected. The last phase of the planning and implementation cycle is to manage the solution throughout its life cycle. In this phase, the IPsec architecture, policies, software, and other components of the deployed solution are maintained. Patches to IPsec software should be tested and applied as appropriate. The management phase also involves providing support for new sites and users, monitoring performance, testing the system periodically, and adapting new policies as requirements change. The life cycle process is repeated when enhancements or significant changes need to be incorporated into the solution. More Information The IPsec protocols were developed within the IPsec Working Group of the Internet Engineering Task Force (IETF). They are defined in two types of documents: Request for Comment (RFC), which are accepted standards, and Internet-Drafts, which are working documents that may become RFCs. A list of IPsec documents can be found at http://www.ietf.org/html.charters/OLD/ipsec-charter.html Federal agencies must use FIPS-approved encryption algorithms contained in validated cryptographic modules. The Cryptographic Module Validation Program (CMVP) is a joint effort of NIST and the Communications Security Establishment (CSE) of the Government of Canada. The CMVP coordinates FIPS 140-2 testing and has issued validation certificates for more than 600 cryptographic modules. The CMVP website is located at http://csrc.nist.gov/cryptval/. FIPS 140-2, Security Requirements for Cryptographic Modules, is available at http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf. See http://csrc.nist.gov/cryptval/des.htm for information on FIPS-approved symmetric key algorithms. FIPS-approved algorithms must also be used for digital signatures. See http://csrc.nist.gov/cryptval/dss.htm. The National Vulnerability Database (NVD) is a comprehensive database of cyber security vulnerabilities in information technology (IT) products. It was developed by NIST with the support of the National Cyber Security Division (NCSD) of the U.S. Department of Homeland Security. The NVD integrates all publicly available U.S. government vulnerability resources and includes references to industry resources. See http://nvd.nist.gov. NIST publications can help you in planning and implementing a comprehensive approach to IT security. For information about NIST publications and standards that are referenced in the IPsec guide, as well as other security-related publications, see http://csrc.nist.gov/publications/index.html. Disclaimer Any mention of commercial products or reference to commercial organizations is for information only; it does not imply recommendation or endorsement by NIST nor does it imply that the products mentioned are necessarily the best available for the purpose. Elizabeth B. Lennon Writer/Editor Information Technology Laboratory National Institute of Standards and Technology 100 Bureau Drive, Stop 8900 Gaithersburg, MD 20899-8900 Telephone (301) 975-2832 Fax (301) 975-2378 _________________________________ InfoSec News v2.0 - Coming Soon! http://www.infosecnews.org
This archive was generated by hypermail 2.1.3 : Wed Apr 26 2006 - 23:13:31 PDT