Network Layer (Layer 3) VPNs
| This section covers the following topics:
Layer 3 TunnelingBecause of the abundance of available literature about Layer 3 tunneling, only a short description is provided in the following sections to cover the basics of the technology. A more in-depth analysis would require a separate book. Layer 3 VPN technologies are designed to run at the network layer of the OSI model. Typically, these VPNs use the IP protocol as the network layer protocol, and they can include Layer 3 VPNs such as Multiprotocol Label Switching (MPLS) or IPSec, which is the IETF standard for encryption and encrypted tunnels. MPLS was covered earlier in this chapter. IPSec on Layer 3 is covered in the following sections. RFC 2764 defines the framework for VPNs running across IP backbones. An IP tunnel operates as an overlay across the IP backbone, and the traffic sent through the tunnel is incomprehensible to the underlying IP backbone. In effect, the IP backbone is used as a link-layer technology, and the tunnel forms a point-to-point connection. Numerous IP tunneling mechanisms exist because Layer 3 tunneling is not a new technology. In fact, GRE with RFC 1701 has existed for a long time. Some protocols were initially not considered as tunneling protocols, such as IP/IP, GRE, and L2TP. Cisco first supported tunneling technology in Cisco IOS version 9.21, and provided IPSec support in Cisco IOS version 11.3(3)T and later versions. Originally, IPSec was conceived as an extension for IPv4 with added security features. Now, IPSec is a framework of open standards for ensuring secure private communications over IP networks. It is based on an architecture model defined in RFC 2401, which covers the security features and architecture model for IPv4 and IPv6.[6] Now, IPSec VPNs use the services defined within IPSec to ensure confidentiality, integrity, and authenticity of data communications across public networks. Security Associations and Security Policy for IKE and IPSecIPSec operates in a peer-to-peer relationship, rather than a client/server relationship. The security association (SA) is a convention (contract) between two parties that facilitates an IPSec-based conversation between two communicating parties. Each party (device, software client) must agree to the policies or rules of their conversation by negotiating these policies with their potential peer. There are two types of SAs: ISAKMP SAs (also known as IKE SAs) and IPSec SAs (see RFC 2408 and 2409 for more details). The IKE SA is bidirectional and provides a secure communication channel between the two parties that can negotiate further communications. The term bidirectional means that once established, either party can start Quick Mode, Informational, and New Group Mode exchanges. IKE SA is identified by the initiator's cookie, followed by the responder's cookie, and the role of each party in the Phase 1 exchange dictates what cookie is the initiator's. The cookie order established by the phase 1 exchange continues to identify the IKE SA, regardless of its direction. The main function of IKE is to establish and maintain the SAs. The following attributes are a minimal set that must be negotiated as part of the ISAKMP SA:
IKE provides negotiation, peer authentication, key management, and key exchange. IKE negotiates a contract between the two IPSec endpoints and the SA keeps track of all elements of the negotiation for a single IPSec session. After the successful negotiation, the active (valid) SA parameters are stored in the SA Database (SAD). NOTE To enable ISAKMP functionality, UDP port 500 must be open on the corporate firewalls. The ISAKMP is strongly tied to policy management, which offers a different level of granularity. The ability to push or change policies on the user's CPE from the corporate concentrator is a major feature of the enterprise VPN design. The VPN 3000 Series Concentrator provides a configuration mode, which enables sending the remote user centrally controlled policies including Domain Name System (DNS), Windows Internet Naming Service (WINS), IP Address, and default domain name. This mode also provides functionality for save connection password, split tunneling, local LAN access control, remote access load balancing, centralized protection policy (firewall), personal firewall capability (are you there?), and software update notification. The IPSec SA is unidirectional and is used for the actual communication between devices. Therefore, two-way communication between devices requires at least two IPSec SAs, one in each direction, because IPSec SA is a simplex data connection. For example, when a bidirectional TCP session exists between two systems, A and B, there is one SA from A to B and a separate SA from B to A. If both security protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP), are applied to a unidirectional traffic stream, two SAs are created for the traffic stream. NOTE A SA is uniquely identified by an IP destination address, a security protocol (AH or ESP) identifier, and a unique security parameter index (SPI) value. A SPI is a 32-bit number assigned to the initiator of the SA request by the receiving IPSec endpoint. The SPIs for AH and ESP are not the same for a given traffic flow. The SPI value is a field in both the AH and ESP headers, and it identifies the appropriate SA for all the communications between the two end nodes. The three elements of a SA allow the receiving party to associate the received packet appropriately. Negotiations of ISAKMP and IPSec Phases and ModesSAs for both IKE and IPSec are negotiated by IKE over various phases and modes. The terms phases and modes denote the steps involved in establishing an IPSec connection. Key exchange and management is an important part of IPSec because of the number of keys that must be exchanged for parties to communicate securely. Two methods of handling key exchange and management that are specified within IPSec include manual keying and IKE, which is based on ISAKMP/Oakley. IKE provides three modes for exchanging key information and setting up SAs: main, aggressive, and quick modes. The first two modes are phase 1 exchanges (main and aggressive), which set up the initial secure channelIKE SA. The other mode is the phase 2 exchange (quick), which negotiates IPSec SAs. When identity protection is not required, only the aggressive mode can be used to reduce the time required for negotiation. In ISAKMP, phase 1 occurs when the two ISAKMP peers establish a secure, authenticated channel for communication. Main and aggressive modes each accomplish a phase 1 exchange, and are only related to phase 1. Phase 2 occurs when SAs are negotiated on behalf of services such as IPSec or other services that require key material or parameter negotiation. Quick mode accomplishes a phase 2 exchange and is used only in phase 2. In IPSec, phase 1 IKE negotiates IPSec SAs. Two modes can be used for this phase: main mode is used in the vast majority of situations, and aggressive mode is used under some circumstances, given the particular configuration parameters between the two systems. The aggressive mode is typical for situations when authentication is not necessary, or was already performed earlier. (Cisco VPN Client 3.0.4 mainly uses aggressive mode). The user has no control over what mode is chosen; it is automatic and depends on the configuration parameters set up by both peers. In phase 2, IKE negotiates IPSec SAs and the exchange only uses quick mode. The elements and functions of the IKE and IPSec negotiation, and the differences between modes are shown in Figure 19-10. (Some of the terms are discussed later.) Figure 19-10. Elements and Functions of IKE and IPSec
IPSec SAs terminate through deletion or by timing out. When the SAs terminate, the keys are discarded. When subsequent IPSec SAs are needed for flow, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire, so a given flow can continue uninterrupted. Mutable and Immutable Fields and the ICVOne of the services of IPSec is to provide access control and data integrity, so that no one can change any bits in the packet exchange between the two parties. The service, called connectionless data integrity, ensures that the original IP packet is not modified in transit from the source to the destination. However, any packet to be routed can undergo several transformations (changes to the content) to be delivered to the destination. The ability to read the header of packets for routing purposes, while maintaining security of the data, is a controversy that is addressed by the calculation of the ICV. The ICV is a keyed hash that uses a shared secret value. The computation uses IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the SA. The upper-layer protocol data is assumed to be immutable in transit. For the purposes of this computation, the IP datagram fields are divided into three groups: immutable, mutable but predictable, and mutable. Figure 19-11 shows the original IPv4 packet and the breakdown. The IP datagram is a variable-length packet that can be split into two major parts: the header (20-60 bytes), and the total size of 20-65,536 bytes. The header is designed in a way to provide the necessary information for delivery and routing. Figure 19-11. Mutable and Immutable Fields of IPv4 (The Mutable Fields Are in White, the Destination IP Address Is in Light Gray, and the Immutable Fields Are in Dark Gray)
Note the following about Figure 19-11:
Fragmentation, Path MTU Discovery, and ICMP ProcessingThe fragmentation in VPN, path MTU discovery, and IPSec-related ICMP messages are discussed in detail in RFC 2401, "Security Architecture for the Internet Protocol." Some other studies, such as IETF MTU Discovery Working Group, and in particular RFC 1191, propose a technique for dynamically discovering the MTU of an arbitrary Internet path. The fragmentation of the IP datagrams, if required, occurs after IPSec processing within an IPSec implementation. Thus, transport mode AH or ESP is applied only to entire IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied can itself be fragmented by intermediate routers, but such fragments must be reassembled prior to IPSec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which can be a fragmented IP packet. Of course, the official minimum MTU (see RFC 791) can process the IP packets, but that would be wasting Internet resources in most cases. In fact, this results in the use of smaller datagrams than necessary because many paths have a Path MTU (PMTU) greater than 576. Furthermore, current practice does not prevent fragmentation in all cases because some path's PMTU is less than 576. These realities essentially emphasize the importance of the fragmentations and related MTU issues. The key suggestion here is that "when one IP host has a large amount of data to send to another host, the data is transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the MTUs of each hop in the path. A shortcoming of the current Internet protocol suite is the lack of a standard mechanism for a host to discover the PMTU of an arbitrary path." [7] The PMTU depends on the different modes and protocols applied to the remote access VPN solution because different protocols and modes add different overhead to the IP datagrams. See the section, "IPSec Protocols" for more details about IPSec protocols. For the purposes of this explanation, the general format of the datagrams in the tunnel mode, in terms of the TCP/IP stack, look similar to the following. The AH datagram includes the following:
The ESP datagram includes the following:
Information is provided in Chapter 4, "Troubleshooting Approaches, Models, and Tools," about using the ping utility and ICMP protocol to perform the reachibility test between two hops in the network. The same ICMP protocol can perform additional functionality about PMTU discovery. The term PMTU Discovery or ICMP PMTU refers to an ICMP message used for PMTU Discovery. The suggested approach in RFC 1191 is based on the interaction between certain unused fields in the ICMP header and the maximum segment size (MSS) field of the TCP protocol. After the original IP datagram is encapsulated by any of the IPSec protocols, it changes its format. Also, when used with the ICMP protocol, the format changes in the following fashion:
To make this possible, the ICMP protocol must include the MTU of that next-hop network in the low-order 16 bits of the ICMP header field that is labeled unused" in the ICMP specification. The high-order 16 bits remain unused, and must be set to 0. The format of the ICMP header is shown in Figure 19-12. Figure 19-12. ICMP Header Format
Another approach to the MTU discovery process is based on a simple suggestion that, regardless of the content of the IP datagram after the IPSec encapsulation (MD5-ESP-3DES), the ICMP overhead is always 28 bytes when it is used with ICMP: Type = 0 (Echo reply) and ICMP: Code = 0. For more explanations about approach and how to use it for troubleshooting, see the section, "Determining a Functional MTU Between the VPN Host and Concentrator," in Chapter 21, "Remote Access VPN Troubleshooting," and Case 4 of Chapter 22, "Remote Access VPN Troubleshooting Scenarios." Both solutions provide successful solutions in most cases. However, they can become complicated if you consider some realities in the existing networks. One reality is the blocking of ICMP messages from most providers, or enterprise firewalls. Another obstacle for implementation can be the existence of black hole routers. A black hole router does not return ICMP destination unreachable messages when it needs to fragment a TCP packet with the DF bit set. TCP depends on receiving these messages to perform PMTU Discovery. One possible approach here is to modify the TCP in a way that TCP tries to send segments without the DF bit set, if several retransmissions of a segment go unacknowledged. If the segment is acknowledged as a result, the MSS is decreased and the DF bit is set in future packets on the connection. Enabling black hole detection increases the maximum number of retransmissions performed for a given segment. It is disabled by default in Windows. IPSec ModesIPSec provides secure communication between two hosts, from a host to a security gateway, or between two security gateways. A security gateway is a device, such as a router, firewall, or a dedicated VPN concentrator, which provides IPSec services (that is, terminates the IPSec connection) and passes traffic through the tunnel to the other side. IPSec can operate in one of two modes to accommodate different types of connections: transport mode and tunnel mode. With transport mode, the AH or ESP is placed after the original IP header, so only the IP payload is encrypted and the original IP headers are left intact. Transport mode can be used when both end hosts support IPSec. This mode has the advantage of adding only a few bytes to each packet and it also allows devices on the public network to see the final source and destination of the packet. This capability enables special processing (for example, quality of service) in the intermediate network, based on the information on the IP header. However, the Layer 4 header is encrypted, which limits the examination of the packet (see Figure 19-14 and Figure 19-17 later in this chapter). Figure 19-14. The IP Packet Before and After Applying the AH in Transport Mode
Figure 19-17. The IP Packet Before and After Applying the ESP in Transport Mode
With tunnel mode, the entire original IP packet is encapsulated within AH or ESP, and a new IP header is placed around it. So, the original IP datagram is encrypted and becomes the payload in a new IP packet. This mode allows a network device, such as a router, to act as an IPSec proxy that performs encryption on behalf of the host. The source's router encrypts packets and forwards them along the IPSec tunnel. The destination's router decrypts the original IP datagram and forwards it on to the destination system. Therefore, the new IP header has the source address of the gateway itself. With tunnel mode operating between two security gateways, the original source and destination addresses can be hidden through the use of encryption. Tunnel mode is used when one or both sides of the IPSec connection are a security gateway and the actual destination hosts behind it do not support IPSec (see Figure 19-15 and Figure 19-18 later in this chapter). Figure 19-15. The IP Packet Before and After Applying the AH in Tunnel Mode
Figure 19-18. The IP Packet Before and After Applying the ESP in Tunnel Mode
IPSec ProtocolsIn a TCP/IP environment, IPSec protocols offer security services at the network layer. These services include the following:
Because both AH and ESP provide access control, the main decision to make when choosing security services is whether you need authentication or both authentication and encryption. To give you a better feel for the issues surrounding IPSec protocols, the discussion is divided into the following topics:
IP Authentication Header and RFC 2402The AH provides connectionless data integrity and data origin authentication as part of the authentication of IP packets. Connectionless data integrity means that the original IP packet was not modified in transit from the source to the destination. AH provides authentication for as much of the IP header as possible, and for upper-level protocol data. However, some IP header fields can change in transit and the value of these fields might not be predictable by the sender, when the packet arrives at the receiver. The values of such fields cannot be protected by AH; therefore, the protection provided to the IP header by AH is not considered strong enough. AH can be applied alone, in combination with the IP ESP, or in a nested fashion. Security services can be provided between a pair of communicating hosts, security gateways, or between a security gateway and a host. ESP can provide the same security services as AH, but it also provides a confidentiality (encryption) service. The AH header is shown in Figure 19-13. Figure 19-13. Authentication Header (AH) Format
NOTE To ensure AH functionality, protocol 51 must be open in the corporate firewalls. The AH is inserted into the IP packet between the IP header and the rest of the packet's contents. It contains a cryptographic checksum of the packet's contents, including the parts of the IP header itself that are immutable in transit. Figure 19-14 shows the IP packet before and after applying the AH in transport mode. Figure 19-15 shows the IP packet before and after applying the AH in tunnel mode. The default cryptographic algorithms for calculating the checksum are hash-based message authentication code (HMAC) coupled with the Message Digest 5 (MD5) hash function, or HMAC coupled with the Secure Hash Algorithm (SHA-1) function. When taking a received message and calculating the same cryptographic checksum, then comparing it with the value received, the receiver can verify that the message has not been altered in transit. Calculation of ICV in AHThe ICV calculation includes the following components of AH: next header, payload length, reserved, SPI, sequence number, authentication data (which is set to 0 for this computation), and explicit padding bytes (if any) (see Figure 19-13). AH also provides a limited anti-replay service that counters a denial of service (DoS) attack, based on an attacker intercepting a series of packets and then replaying them. It should be noted that the anti-replay service can affect performance, if the network reorders packets to provide higher QoS for certain types of traffic. If the packets arrive outside the anti-replay window, IPSec rejects them. AH is not widely used for IPSec implementations across the Internet because it does nothing to keep the packet contents confidential. For confidentiality, ESP must be used. IP ESP and RFC 2406The ESP header is designed to provide a mix of security services in IPv4 and IPv6. ESP can be applied alone, in combination with AH, or in a nested fashion. Security services can be provided between a pair of communicating hosts, a pair of communicating security gateways, or a security gateway and a host. The ESP objectives reflect the ESP header format that is shown in Figure 19-16. Figure 19-16. ESP Header Format
NOTE To enable ESP functionality, protocol 50 must be open in the corporate firewalls. ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services enabled depends on the options selected at the time of SA establishment. The ESP header is inserted after the IP header and before the upper-layer protocol header (in transport mode), or before an encapsulated IP header (in tunnel mode). Figure 19-17 shows how the IPv4 packet is modified in transport mode, and Figure 19-18 shows the IPv4 packet transformation in tunnel mode. Confidentiality in ESP is achieved through encryption. Encryption is the process of taking a clear text message, and passing it through a mathematical algorithm to produce what is known as ciphertext. Decryption is the reverse process. Encryption algorithms typically rely on a value, called a key, to encrypt and decrypt the data. Two major forms of encryption are used today: symmetric encryption (also known as shared-key encryption) and asymmetric encryption (know as public/private key encryption). Symmetric encryption is approximately 1000 times faster than asymmetric encryption, and is therefore used for the bulk encryption of data. Generally, with well-designed encryption algorithms, longer keys result in a higher degree of security because more brute force is required to try every possible key (known as the key space) to decrypt a message. ESP supports a variety of symmetric encryption algorithms for data encryption. The Data Encryption Standard (DES) is the default algorithm that uses a 56-bit key and has been in use for about 20 years. However, DES has been susceptible to brute-force attacks, so Triple DES (3DES) is now the standard algorithm recommended for most business use because it encrypts the data three times with up to three different keys. ESP encrypts the higher-level protocol information (such as the TCP header) and the actual data itself. The authentication services of ESP do not protect the new IP header of the packet. On May 26, 2002, the Advanced Encryption Standard (AES) became a finalized Federal Information Processing Standard (FIPS)-approved cryptographic algorithm for purposes of protecting transmissions of electronic data (see FIPS PUB 197). AES is a new, faster, and more secure standard encryption algorithm, and it is being considered by Cisco for future two-phase implementations. The first phase includes the software (IOS) version and the second phase includes the hardware version. AES is expected to be considered as a baseline functionality in mid 2002 and early 2003, and VPN solutions and devices without high-speed AES support will not be considered for many VPN deployments. The underlying algorithm for AES is called Rijndael. AES specifies three key sizes: 128, 192, and 256 bits. In decimal terms, this indicates that there are approximately the following:
In comparison, DES keys are 56-bits long, which indicates that there are approximately 7.2 x 1016 possible DES keys. Hence, there are on the order of 1021 times more AES 128-bit keys than DES 56-bit keys. For more information, see the article, "AES an Approved Cryptographic Algorithm" (Cisco Packet Magazine, Q3 2002; also available at www.cisco.com/warp/public/784/packet/standards.html). NOTE In the late 1990s, specialized DES Cracker machines were built that could recover a DES key after a few hours. Assuming that someone could build a machine that could recover a DES key in a second (that is, try 255 keys per second), it would take that machine approximately 149 trillion years to crack a 128-bit AES key. To put this in perspective, the universe is believed to be less than 20 billion years old. The anti-replay service can be used only if data origin authentication is selected, and its election is solely at the discretion of the receiver. However the default requires the sender to increment the sequence number used for anti-replay, and the service is effective only if the receiver checks the sequence number. Traffic flow confidentiality requires the selection of tunnel mode, and it is most effective if implemented at a security gateway, where traffic aggregation can mask true source-destination patterns. Although both confidentiality and authentication are optional, at least one must be selected. Most IPSec VPN implementations today use ESP. Calculation of ICV in ESPIf authentication is selected for the SA, the ICV calculation includes the following components: SPI, sequence number, payload data, padding (if present), pad length, and next header. In general, the sender computes the ICV over the ESP packet, except for the authentication data. The last four fields are in ciphertext form because encryption is performed prior to authentication. Authentication in VPNAuthentication in VPN has several aspects that include the following:
The text discusses each in turn. Client Authentication, VPN Group Name, and Group PasswordThe group name and group password approach simplifies policy enforcement because a user can be a member of a group of users who have common policy requirements. For example, a single change can be made to a group that affects hundreds of users versus making changes for every single user. Groups and users are core components in managing the security of VPNs, and in configuring the Cisco VPN 3000 Concentrator. They have attributes that determine their access to and use of the VPN. Users are members of groups and groups are members of the base group. Users inherit attributes from groups and groups inherit attributes from the base group. The VPN client can be configured with an active group name and group password to provide a user prompt, and be authenticated by a RADIUS server if the Group Lock feature on the concentrator is turned on. Groups simplify system management. By configuring the base group first, then specific groups, and finally users as members of groups, you can quickly manage access and usage rights for large numbers of users. Associating users with specific groups simplifies the configuration of the VPN, while providing granular control over who has access to certain resources. When configuring groups and users, only the attributes that differ from those defined in the base group need to be defined and all other attributes are inherited from the base group. The group name and group password for VPN users are stored locally on the concentrator or server. When the client tries to connect to the concentrator, it has to provide the same group name and password to be recognized as an eligible user. After a successful negotiation, a typical message from the log of both peers is Peer Is a Cisco Unity Compliant Peer, which indicates a successful group name and password authentication. Another important feature allows the VPN administrator to group different user requirements into different client groups. For example, some users have Network Address Translation (NAT) configured within their home LAN, so that when they connect to the concentrator, it must recognize that the user is NATing and adjust. The concentrator can determine if the user is NATing or not based on the group name and password they used to connect. User/Identity AuthenticationOne of the basic functions for key exchange is to ensure that the exchange occurs between trusted sources. This requires user identity verification and it is related to the non-repudiation feature, which prevents a communicating party from later denying having participated. User identity requires proof of identity of the sender and it is based on digital signatures and authentication mechanisms. The Cisco VPN Client (Unity) supports the following digital certificates:
Supported authentication mechanisms are as follows:
External User AuthenticationRADIUSIndividual user authentication information, such as user name and password, can be stored locally, which is more appropriate for small installations. Larger installations must use RADIUS or Terminal Access Controller Access Control System Plus (TACACS+), with an external database capable of supporting a large number of remote users. Larger sites with thousands of users are only limited or restricted by the authentication, authorization, and accounting (AAA) server's capacity. NOTE The RADIUS server is based on a protocol for AAA that was developed by Livingston Enterprises, Inc. (see RFC 2866). Cisco has incorporated the RADIUS client into Cisco IOS 11.1. TACACS was introduced with Cisco products and has been in use for many years. The extension of the original TACACS was commonly called Extended TACACS or XTACACS, and was introduced in 1990. Both are documented in RFC 1492. The third is TACACS+, which despite the name, is a completely new protocol and is not compatible with TACACS or XTACACS. RADIUS is the main choice for external user authentication in existing VPNs. It is composed of a protocol with a frame format that uses UDP/IP, a server, and a client. The RADIUS server runs on a central computer, usually at the customer's site, and the clients reside in the access servers that can be distributed throughout the network. The RADIUS client is typically a NAS and the RADIUS server is usually a daemon process, which runs on a UNIX or Windows NT machine. The client passes user information to designated RADIUS servers, and acts on the response that is returned. RADIUS servers receive user connection requests, authenticate the user, and return the configuration information necessary for the client to deliver service to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers. Packet EncryptionRADIUS only encrypts the password in the access-request packet from the client to the server. The remainder of the packet is in clear text. Information other than the encrypted password, such as username, authorized services, and accounting, can be intercepted by a third party. RADIUS can use encrypted passwords by using UNIX /etc/passwd file; however, this process is slow because of the time consuming linear file searches. Authentication and AuthorizationRADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contains authorization information, which makes it difficult to separate authentication from authorization. NOTE Starting with release 3.0 of the VPN 3000 Concentrator, you can use TACACS+ for administrative authentication. After configuring TACACS+, ensure that you test authentication before logging out. An incorrect configuration of TACACS+ can lock you out, and require a console port login to disable TACACS+ and rectify the problem. VPN and RADIUSVPN uses server authentication that is similar to a dialup environment. The client passes user information to designated RADIUS servers, and acts on the response that is returned. The RADIUS server receives user connection requests, authenticates the user, and returns the configuration information necessary for the client to deliver service to the user (see Figure 19-19). Figure 19-19. The VPN Authentication Process Using RADIUS
The following summarizes the process:
Every authentication method deserves special attention, which exceeds the objectives of this book. However, the XAUTH within IKE is extensively used by Cisco VPN solutions, and deserves more attention here. XAUTHIKE enables a device to set up a secure session by using a bidirectional authentication method, which uses either preshared keys or digital certificates. However, IKE does not provide a method to leverage legacy authentication methods that are widely deployed today. XAUTH is not designed to replace or enhance existing authentication mechanisms, but rather to enable them to be extended by using legacy unidirectional authentication mechanisms such as RADIUS, SecurID, and one-time password (OTP) within IPSec's ISAKMP protocol.[8] This XAUTH protocol is designed so that the authentication can be accomplished by using any mode of operation for phase 1 (such as main mode or aggressive mode), and as any authentication method supported by IKE. This protocol can also be easily extended to support new modes of authentication methods, but it does require that the phase 1 authentication method be fully secure. XAUTH adds a vendor ID that must be authenticated whenever possible. The vendor ID for this revision of XAUTH is the following 8 bytes:
XAUTH provides a mechanism for five basic types of authentication:
An example of an authentication mechanism, where the user password is hidden by an encryption mechanism, follows (see Figure 19-20). Figure 19-20. XAUTH Authentication When the Password Is Encrypted
Designed for future use, XAUTH supports the following authentication types: 0Generic, 1-RADIUS-CHAP, 2-OTP, and 3-S/Key. Types 4-32767 are reserved for future use, and types 32768-65545 are reserved for private use. Key Management, DH Algorithm, and MethodologyConfidentiality services can be selected independent of other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH), might subject traffic to certain forms of active attacks that can undermine the confidentiality service. Therefore, authentication is offered as an option in conjunction with confidentiality. RFC 2401 defines two methods of authentication and key management: manual keying, and automated keying through IKE. Valid authentication methods include the following:
A DH exponential algorithm generates a strong initial key. NOTE The Diffie-Hellman key agreement protocol (also called an exponential key agreement) was developed by Whitfield Diffie and Martin Hellman in 1976, and was published in New Directions in Cryptography. The protocol enables two users to exchange a secret key over an insecure medium without any prior secrets. Before IKE proceeds, the parties must agree on how to authenticate themselves to each other. This authentication method is negotiated during the IKE phase main mode exchange. The following mechanisms are in use today:
When remote access clients are involved, a second level of user authentication occurs after device authentication, which occurs through the IKE SA. The headend starts an XAUTH request to the remote user, which prompts for the username-password/passcode pair.[9] After authentication is completed in the first phase, the second phase connects the remote and local networks. The DH algorithm is still considered the strongest by the cryptographic society. In the DH key agreement, the two parties, without any prior arrangements, can agree upon a secret key that is known only to them (often called a shared secret or a key encryption key). This secret key can then encrypt further communications between the parties. The shared secret encrypts the symmetric key (or data encryption keysuch as DES, Triple DES, CAST, International Data Encryption Algorithm [IDEA], or Blowfish) for secure transmission. Asymmetric key systems use two keys: the private key, which the user keeps secret, and the public key, which can be shared with the world. Unfortunately, the asymmetric key calculation is extremely slow. Today, it is a typical practice to use a symmetric system to encrypt the data, and an asymmetric system to encrypt the symmetric keys. This is how you use DH. The basis for the DH algorithm is the difficulty of calculating logs in modular arithmetic (see the following Note). The process begins when each side of the communication generates a private key. Each side then generates a public key, which is a derivative of the private key. The two systems then exchange their public keys, so that each side of the communication now has its own private key and the other system's public key. Because of the complexity of the algorithm, its explanation goes beyond the scope of this book. The methodology of the DH algorithm can be found in the article "IPSec-Based VPNs and Related Algorithms," by P. Nedeltchev and R. Ratchkov (Cisco Packet Magazine, Q2 2002; and at www.cisco.com/warp/public/784/packet/apr02/pdfs/plamen.pdf). NOTE The expression x = y (mod m) reads as "x is equivalent to y, modulo m." The statement a + kp = a (mod p) should be fairly obvious. The Chinese Remainder Theorem states that x = y (mod p) and x = y (mod q) is the same as x = y (mod pq), if p and q are coprimes. The Fermat/Euler Theorem rules that if p is prime, xp 1 = 1 (mod p). RSA correctness rules that if d and e are generated in a way that de = k(p 1)(q 1) + 1, and k is an integer, the encryption/decryption process can be written as xed % pq. [10] The cost of some methods for computing discrete logarithms depends on the length of the prime, and the cost of others depends on the length of the private value. The intention of selecting a private-value length is to reduce the computation time for key agreement, while maintaining a given level of security. The time to execute the algorithm by software is proportional to D3, where D is the number of bits of p. Therefore, increasing from 200 to 800 bits raises the complexity by a factor of 64. The length of the primes that defined DH-Groups, or Oakley Default Groups, are as follows:
NOTE The Cisco VPN 3000 Concentrator uses DH group 7 as well. The DH group 7 generates IPSec SA keys that are based on an elliptical curve field (ECC) size of 163 bits. You can use this option with any encryption algorithm and any peer that supports ECC group 7, but it is intended for use with the movianVPN (wireless) client. The DH key exchange is vulnerable to a man-in-the-middle (MIM) attack because it does not authenticate the participants. The attack consists of someone intercepting both public keys and forwarding bogus public keys of their own. The MIM can potentially intercept encrypted traffic, decrypt it, copy or modify it, re-encrypt it with the bogus key, and forward it on to its destination. If successful, the parties on each end have no idea that there was an unauthorized intermediary. The authenticated DH key agreement protocol, or Station-to-Station (STS) protocol, was developed by Diffie, van Oorschot, and Wiener in 1992, to defeat the MIM attack on the DH key agreement protocol.[11] Immunity is achieved by allowing the two parties to authenticate themselves to each other through the use of digital signatures and public-key certificates. NOTE The MIM is addressed in ISAKMP (see RFC 2408), where not only MIM, but two other types of ISAKMP protection, including anti-clogging (DOS) and connection hijacking are addressed. The longer that a symmetric key is in use, the easier it is to perform a successful crypto-analytic attack against it. Therefore, changing keys frequently is important. Both sides of the communication still have the shared secret and it can be used to encrypt future keys at any time and for any frequency desired. RFC 2401 defines perfect forward secrecy (PFS), where a shared secret encryption key refresh involves combining the current key with a random number to create a new key. PFS enforces the recalculation of the shared secret key from scratch by using the public and private key generation and DH techniques. It recalculates to avoid the situation where a hacker might have derived a particular secret key. PFS allows a new key to be calculated that has no relationship to the preceding key. The PFS is closely related to SA Lifetime, where an SA Lifetime determines the period of time that a security association is valid. It also determines how often a key is refreshed or recalculated. A lifetime can be measured in seconds or kilobytes and is applied to both the IKE SA and IPSec SAs. Cisco and IPSec Message Authentication (Integrity) and ConfidentialityIPSec provides numerous security features that are based on a family of algorithms, which perform transformations over different fields of packets. The content transformation of the packet is governed by HMAC, as defined by RFC 2104. As previously mentioned, it is based on a secret key that is available to both parties and the key material generation precedes the packet content transformation. Codes based on cryptographic hash functions are called HMAC. RFC 2104 defines HMAC as the following:
HMAC can use any cryptographic hash function, such as MD5 and SHA-1, and it is at least as strong as the hash function it uses. This also allows for easy cryptographic analysis of the HMAC, where only the underlying hash function is analyzed. Assuming that H is a cryptographic hash function that iterates over a block of data, with byte length B for each block, ipad and opad are fixed length strings that are defined as follows:
The enterprise can define the policy and implement a high level of granularity by using different algorithms. The algorithm's parameters are configurable and include type of data encryption, device authentication and credentials, data integrity, address hiding, and SA key aging. The IPSec standard requires the use of either data integrity or data encryption, and using both is optional. Cisco highly recommends using both encryption and integritysee the site www.cisco.com/go/safe. Do not use hash functions for encryption. Cisco recommends the use of 3DES for data encryption, and either MD5 or SHA-1 for data integrity (message authentication). Because of the greater bit strength of SHA-1, it is considered more secure. Cisco recommends the use of SHA-1 mainly for S2S VPNs because the increased security outweighs the slight increase in processor overhead (in fact, SHA-1 is sometimes faster than MD5 in certain hardware implementations).[12] Both IPSec phases offer the ability to change the lifetime of the SA. You might consider changing the lifetime from the default setting, when the sensitivity of the tunneled data demands replacing the encryption keys and re-authenticating each device on a more aggressive basis. For more information about transformation, hashing, and encryption techniques, see the IPSec family of standards that recommends certain mandatory choices, which are called conformance requirements. The valid choices, supported and recommended by Cisco, are documented in Table 19-2.
In conclusion, Cisco announced major new capabilities in March 2002, for a Unified VPN (UVPN) suite of protocols that will increase service provider reach, and allow enterprises greater choices and flexibility. A first in the industry, UVPN was introduced with complete support for Layer 2 and Layer 3 VPN technologies. The second phase of Unified VPN Suite will support Multiprotocol Label Switching/Border Gateway Protocol based (MPLS/BGP) VPNs, IPSec, and generic routing encapsulation (GRE). It will integrate Layer 2 access VPNs and simplify deployment. As the latest addition to Cisco IOS Software, L2TP version 3 appears to offer a promising path to efficiently deliver Layer 2 services. One of the features in the UVPN is Cisco's EasyVPN, which is discussed in detail in the following chapters. |
EAN: 2147483647
Pages: 235