S 5.76 Use of suitable tunnel protocols for RAS communication

Initiation responsibility: Head of IT Section, IT Security Management Team

Implementation responsibility: Administrator

Remote access to a LAN is effected through a data link which is generally shared with external third parties. Thus, for example, direct dial-in entails use of the network of the telecommunications provider. If the connection is established over the Internet, then the data is forwarded over the networks of the Internet service providers involved (and possibly their partners). Since logging on of the RAS client to a LAN is effected over a RAS connection, the network path used for data transmission must be protected so that the security of the data (confidentiality, integrity, authenticity) is safeguarded. This protection is achieved through encryption and digital signing of the data packets exchanged after the communications partners have been authenticated (see also S 4.34 Using encryption, checksums or digital signatures). In the RAS environment, various procedures and mechanisms for protecting the communications link (e.g. tunnelling, see below) have been developed.

The choice of which procedure to use to protect a RAS connection depends on various factors such as:

• the security requirements regarding the strength of the procedure (for example, this determines the key lengths),

• the procedures which can be used at protocol level (see below),

• the procedures supported by the RAS hardware and software.

In general, the following applies:

• The RAS product normally offers a selection of standard procedures supported for the protection of communications. The aim here should be to have the widest possible range of procedures supported.

• The actual protocols used for data transport also offer security mechanisms. These can be used by the RAS product. Alternatively, the RAS product may offer a procedure of its own.

The security mechanisms are based on different cryptographic procedures. Safeguard S 3.23 contains a brief introduction to basic cryptographic concepts.

Encryption of protocol connections: tunnelling

If an encrypted data connection is established between two communications partners, then this connection constitutes a "secure channel". Any data can be securely transmitted over this channel with the underlying communications protocol (e.g. IP). If the data transmitted is in the form of data packets of a communications protocol, then the term "tunnel" is used also. The protocol which is used to encrypt the data, transmit it through the tunnel and manage the connection is also referred to as tunnel protocol. With tunnel protocols distinctions can be made as to

• which transport protocol is used and to which protocol layer (OSI layer) they must be assigned (see also S 4.90 Use of cryptographic procedures on the various layers of the ISO/OSI reference model);

• which protocols can be transmitted over the tunnel connection;

• which cryptographic procedures for implementing the tunnel are supported;

• whether the tunnel end points are authenticated;

• and whether it is possible to have several parallel tunnels on one instance of the transport protocol used.

The tunnel protocol is essentially responsible for

• management of the tunnel(s): establishment, maintenance and termination,

• negotiation of the cryptographic procedures to be used to implement the tunnel: key exchange procedures, encryption procedures and signature procedures,

• assembly and disassembly of the data packets of the protocols which can be transmitted through the tunnel, and

• encryption and decryption of the data packets.

In the RAS environment, the following tunnel protocols have been established:

• Layer 2 protocols:

• Point to Point Tunnelling Protocol (PPTP) and

• Layer 2 Tunnelling Protocol (L2TP): L2TP is a combination of PPTP and the Layer 2 Forwarding (L2F) protocol developed by Cisco which forwards Point to Point Protocol (PPP) packets from a PPP server over a WAN connection to an L2F-capable router which then disassembles them and feeds them into a network.

• The Layer 3 specification IPsec (Internet Protocol Security).

The protocols possess the characteristics summarised in the following table.

All the protocols can establish secure connections to a LAN over an insecure switched network through the use of cryptographic procedures, thus protecting the confidentiality and integrity of the data. Depending on the particular protocol, it is possible to establish one or more tunnel connections.

Tunnelling at Layer 2: PPTP and L2TP

The Layer 2 tunnel protocols can tunnel both the most commonly used protocols, but differ as to over which underlying protocols tunnelling is possible: PPTP can only be transmitted over an IP-based network, whereas L2TP can also be transmitted over various WAN protocols and hence offers greater flexibility. The chart below shows how packets in an application are assembled by PPTP over a PPP connection. As can be seen from the table above, several independent tunnels (e.g. with different levels of quality assurance) can be generated with the more recent L2TP protocol. During user identification and encryption the security mechanisms of the underlining PPP connection make themselves felt under both protocols.

Figure: Assembly of packets of application data with the PPTP protocol

Security mechanisms of the PPP protocol

1. User authentication

Most implementations of the PPP protocol support the following standard procedures for user authentication (see also S 5.50 Authentication via PAP/CHAP):

• Password Authentication Protocol (PAP). The PPP-Server requests transmission of a user name and password by the PPP client. Both items are transmitted here in plaintext. This mechanism is insecure and cannot protect against "Replay" attacks, under which an unauthorised person can re-send the data intercepted at a later time. Use of the PAP authentication protocol is therefore not advised.

• Challenge-Handshake Authentication Protocol (CHAP). The PPP sends a "challenge", consisting of a session ID and a random sequence of letters, the "challenge string", to the PPP client. The client sends back the user name in plaintext as the reply, together with the MD5 hash value made out of a combination of session ID, challenge string and user password. Here the password is not sent in plaintext. The use of the random sequence of letters ensures that the protocol protects against Replay attacks.

2. Data encryption and key management

In the initialisation phase of the PPP protocol, the procedures to be used for data encryption (and compression) are negotiated between client and server. In general any procedure may be used here as long as client and server have a corresponding implementation. With regard to negotiation of the procedure, care should be taken to ensure that client and server are both configured so that only the procedures specified in the IT security guidelines are accepted. Steps must also be taken to ensure that unencrypted communication is not chosen as callback variant if no compatible procedure could be negotiated between client and server. Explicit negotiation of the unencrypted communication must also be prohibited.

Tunnelling at Layer 3: IPsec

Whereas the Layer 2 protocols make use of the security mechanisms of the underlying PPP protocol, with the IPsec Layer 3 specification separate security procedures and mechanisms are specified. One limitation of IPsec is the fact that only IP-based communication is supported. However, in most cases this is not a serious disadvantage as today most operating systems and applications are able to utilise IP-based communication.

As regards security requirements, the situation regarding IPsec is as follows:

• User authentication

Tunnel protocols at Layer 3 assume that authentication of the tunnel end points has been completed already before the tunnel is established and do not offer any separate mechanisms. The only exception here is the IPsec IKE procedure (formerly ISAKMP/Oakley), which allows mutual authentication of the tunnel end points at application level. However, authentication at user level is not possible with this. But since a Layer 3 protocol is actually transmitted over a Layer 2 protocol, in principle use can be made here of the security mechanisms of both protocol layers. When RAS is being used, the mechanisms for user authentication of the underlying Layer 2 protocol actually have to be used as otherwise an unauthorised third person could circumvent the security mechanism, for example, through a physical attack on the client.

• Data encryption

The standard IPsec prescribes that IPsec-compliant implementations must as a minimum make available the DES and Triple-DES encryption procedures as well as the MD5 and SHA-1 hash functions. However there is no reason why another procedure should not be used here, although in this case the same procedure must also be available to the communication partner. In general, only generally recognised and established procedures should be used. The keys used for symmetric encryption procedures should be at least 80 bits long.

• Key management

IPsec defines several methods for the generation, exchange and management of keys. With the "Manual IPsec" procedure, there is no automatic key management. In general keys are exchanged by the communication partners over a secure channel (e.g. courier, encrypted e-mail). The interval for the regular exchange of keys here is much larger than with the automatic procedures, such as the above-mentioned IKE (ISAKMP/Oakley), or Sun Microsystems' SKIP. Both of these latter procedures administer the certificated keys automatically.

When choosing the RAS hardware and software to be used, care should be taken to ensure that as many different, established encryption procedures are supported as possible. This will increase the probability that a suitable procedure can be negotiated between client and server.

Examples

• To use MPPE data encryption under Windows NT, the option "Accept only Microsoft encrypted authentication" must be set in the "Security" tab of Dial-Up Networking properties and the option "Require data encryption" must be enabled. Use of the option "Use current username and password" is not recommended.

• Under Windows NT, the protocol VPN Adapter (RASPPTPM) must be installed on the RAS client for establishment of a PPTP connection over an Internet connection. This is performed by selecting Control Panel, Network, Protocols. A separate entry must be created in Dial-Up Networking for the VPN connection. Here, instead of a phone number, the IP address of the remote RAS server is entered. In the "Dial using" field, the VPN adapter must be selected. Once a connection has been successfully established with an ISP, thereafter the VPN connection is established over this existing Internet connection. This process can also be automated by defining a script for the ISP connection.

• Under Windows 2000, use of IPsec-based data encryption can be enabled in the properties for the TCP/IP protocol (under Network Properties, Adapter Properties, Protocols). To achieve this, on the "Options" tab, the properties of the "IP security" entry must be changed. The "Use IP security guidelines" option must be enabled and the desired security guidelines selected.

Additional controls:

• At which protocol level should tunnelling be enabled?

• Over which protocols must the tunnel protocol be processed?

• Which protocols must be transported through the tunnel?

• Is authentication of the tunnel end points necessary?