IPsec

This product was added to computer science because of the content, defects on the quality assurance side of the editor. This is done to bring the quality of the articles from the computer science subject area to an acceptable level. Help us to eliminate the substantive shortcomings of this article and take part you in the discussion! ( ) Reason: The article is too little understandable ( even in some sub-headings are likely to get many readers ), the practical application is not sufficient, and IKEv2 is marked as incomplete.

IPsec (short for Internet Protocol Security ) is a protocol suite that will enable secure communication over potentially insecure IP networks such as the Internet.

IPsec works directly on the Internet layer ( Internet layer) of the protocol stack so that it is transparent to the application.

Since the data packets are forwarded from one computer to another on the Internet, every computer can read on the way of a data packet to its content and even change. A computer can also send data packets on behalf of another computer by a " sender " entering its address ( IP spoofing ). IPsec is to make it possible to meet the protective confidentiality, authenticity and integrity in such a IP network. To a variety of mechanisms can be used, such as encryption of individual IP packets, and inserting an additional packet header with a message authentication code. IPsec can be used to build virtual private networks (VPN) or are used to protect against replay attacks.

The Internet Engineering Task Force proposes in RFC 2401 or the newer RFC 4301, the architecture of IPsec as the default before. Of these RFCs referenced RFCs mentioned below, describe the essential parts of IPsec: the Authentication Header protocol (AH), Encapsulated Security Payload (ESP ) and Internet Key Exchange ( IKE) key exchange.

  • 2.1 Protection against replay attacks
  • 4.1 IPsec in transport mode
  • 4.2 IPsec in tunnel mode
  • 5.1 Dead Peer Detection
  • 5.2 UDP Keep Alive
  • 6.1 Conceptual
  • 6.2 Putative back door ( backdoor ) in OpenBSD

Connection

IPsec manages connections and can guarantee on request, both encryption and data integrity. It uses one of two modes: The transport mode is point-to -point communication between two endpoints forth while the tunnel mode connecting two networks by two routers. Both modes are to be created in relation to the Security Associations quite similar. The following chart considers only the transport mode.

When an IP packet is to be sent, then two local databases are used:

  • SPD ( security policy database) In the SPD, for example, is stored as the connection between the communication endpoints with the specified IP addresses are 80.16.36.1 and 89.1.26.17 secured. As a backup method then AH, ESP, or both are used. To create the IKE key is usually used. The SPD is compared to the SAD (see below) rather static nature, as an entry in the SPD " stateless " is.
  • SAD (security association database) SAs between two hosts In the SAD Security Associations (SA ) are managed. These have a state (known as stateful ) and change compared to entries in the SPD quite often. SA messages contain, inter alia, the key for the protocol being used, and they have a limited validity. For AH and ESP each own SA entries exist in the SAD. An SA is usually applied via the IKE protocol and is used only in one direction: At the transmitter outputs the encryption method and the key before, at the receiver the appropriate decryption process. Deciphering is done with the use of symmetric encryption with the same key that was used for encryption. If two hosts AH and ESP use, then host four SA messages are ever necessary. This is illustrated in the picture.

In IPsec, all endpoints must be pre-configured, otherwise no trust relationship can be established.

Thus, two endpoints can establish a trust relationship, a method for key exchange is required. Replacement may be done manually or automatically.

Manual key management

The keys that are used for IPsec are pre- exchanged with the " Manual Key Distribution " and permanently configured on both endpoints.

Automated Key Management via IKEv1

The Internet Key Exchange protocol is used for automatic key management for IPsec. It uses the Diffie -Hellman key exchange for secure key exchange over an insecure computer network and is probably the most complex part of IPsec. Internet Key Exchange was originally specified in RFC 2409 and was based on the Internet Security Association and Key Management Protocol ( ISAKMP, RFC 2408 ), the IPsec Domain of Interpretation ( DOI, RFC 2407 ), Oakley (RFC 2412 ) and SKEME. The RFCs 2407, 2408 and 2409 are summarized in the current version IKEv2 RFC 4306 and therefore obsolete.

IKE defines how security parameters agreed and shared key ( shared keys ) to be replaced. What is changed is the job of a DOI document.

Before the actual start of an encrypted IPsec connection, both sides must mutually authenticate and agree on the key to be used algorithms. To this end, IKE is intended. For authentication, the method pre-shared keying ( PSK ) and Certificate may be used. IPsec works with various symmetrical and asymmetrical keys.

IKE is based on UDP and uses the default port 500 as source and destination port. If IKE and IPsec but operated behind a masquerading firewall, is used by most IPsec implementations in this case UDP port 4500. To solve the problem with IPsec connections behind a masquerading firewall, several proposals have been submitted. None of the proposals, however, was recognized as the standard, so the operation of an IPsec connection from a host through a firewall is away very unreliable. The best solution is a non- masquerading firewall with a DMZ connected. In the DMZ, then the end point of the IPsec connection.

IKE operates in two phases:

A Security Association (SA ) is an agreement between the two communicating sides and consists of the following points:

Phase 1 ( Main Mode Variant)

The main mode is used in the first phase of the agreement encryption and authentication ( Internet Key Exchange). He should be preferred to the aggressive mode.

In Main Mode, the initiator and the responder ( the responder ) act (the one who wants to take the connection) with each other from an ISAKMP SA. This negotiation is done in the following steps:

Now that both ( the responder and initiator ) known to the public parts for the Diffie- Hellman key exchange, this method is used to calculate the secret key. This is then used for the encryption key according to the agreed procedures for the following steps. Calculated ( Diffie-Hellman ) key is also used for the generation of a further key which is used for authentication.

Step 5 is the authentication. In this case both parties must identify themselves as authorized to access. Two different methods are used:

Certificate-based authentication uses X.509 certificates and is essentially a public-key infrastructure, as it is also used for SSL and S / MIME. PGP certificates are a different approach and can not be used for this purpose.

The authentication methods to differ, but the basic procedure is always the same: It is always a hash value generated by the Diffie -Hellman key exchange secret the identity of the negotiated cryptographic method and the previously sent messages formed, encrypted and sent. ( In the literature sometimes cookies are mentioned: a hash value of a generated secret, IP address and time stamp. ) However, the key that is used here for the encryption is not over from the Diffie -Hellman key exchange, but a hash value, these as well as the messages sent.

PSK authentication ( pre-shared keying):

In this method, the authentication is carried out based on a single shared secret. It can be used when a limited amount of subscriber is connected to the IPsec VPN. The main disadvantage is: Is someone unauthorized access to that key, the key must be replaced on all involved hosts to restore security. Should grow a computer network, this method can also be rejected if at first only a few nodes are involved. The additional cost for certificate-based authentication will pay for itself usually within a short time.

Certificate-based authentication:

This authentication has a different approach. This X.509 certificates are used. This system is based on trusted CAs ( Certification Authorities, such as eTrust ) or a hierarchy of these. The principle here is that every single endpoint his CAs ( trust centers ) and knows all the certificates that are signed by these trust points as valid recognizes. In practice, this means that all certificates are imported from trusted CAs and thus all issued by these CAs certificates have access. Certificates can be obtained from well-known CAs ( VeriSign, eTrust, etc.. ). This can be ensured that unknown VPN partner can be authenticated. Unfortunately, this is in practice not so easy, because other parameters (eg, computer network addresses ) play a role and can collide with already existing VPN connections. It has therefore enforced to use a private PKI (Public Key Infrastructure). With its own PKI but are only known and trusted hosts have access to the VPN.

Certificate-based authentication is the same as the PSK authentication, with one difference: Depending on your connection, another certificate to be used, and who is not released its CA certificate that can selectively control who is allowed to access.

Another advantage of a certificate-based authentication: The CA may revoke individual certificates. In the so-called CRL (Certificate Revocation List), all certificates that have somehow become invalid locked. In a PSK authentication, however, the replacement of all key is required.

Phase 1 ( Aggressive Mode Variant)

In Aggressive mode, the above steps are summarized in three. Here, then falls off the encryption of the above fifth step. Instead, the hash values ​​of the pre-shared keys are transmitted in plain text. The safety of the procedure is closely tied to the strength of the pre-shared keys and the hash process used. Since, in practice strong keys are not often used for convenience, one should use this mode with caution.

However, a reason for the use of this mode can be given if the address of the initiator to the responder is not known a priori, and want to use both sides of pre-shared keys for authentication.

Further application scenarios are given, if a faster connection is desired and the guidelines (policies ) of the responder are well known.

Example: An employee wants to access the corporate network remotely. The guidelines ( for example, encryption with AES, hashing with SHA and authentication with RSA signatures that are signed by the certification body of the company ) are known.

Phase 2

In the second phase of the IKE Quick Mode is used (protection by the IKE SA). All communication in this phase is encrypted. As in the first phase, a proposal ( Proposal) is first made ​​and transmitted together with a hash and the nonce. Later, the keys are re-calculated and it contains no information from the previously generated SAs. This ensures that no one can shut of the previously generated keys to the new ( Perfect Forward Secrecy). This is achieved by providing an additional Diffie -Hellman exchange is taking place. The secrets to key education be discarded as soon as the exchange is complete.

Several "quick mode " can take place at the same time and be protected by the same IKE SA. In order to distinguish the various changes, the Message - ID field of the ISAKMP header is used. The status of such an exchange is identified by the cookie.

IKEv1 and IKEv2 difference between

Since IKEv1 is quite complex, many implementations of IPsec were incompatible with each other. IKEv1 is the use of dynamic IP addresses, such as for DSL connections is common, not very suitable. IKEv2 solves these problems. In IKEv2 the IKEv1 of known phases were fundamentally changed. To a Security Association ( SA) create, one needs instead of nine, now only four UDP messages. This requires a faster connection, which can have a positive impact especially in disorders. Moreover, in IKEv2 no need for a preventive cookie exchange, since only few problems arose with denial-of -service attacks against the VPN gateway in recent years. While in IKEv1, the responsibilities were not regulated in packet losses, under IPKv2 the responsibilities of the peers were more clearly defined. This allowed the connection stability can be improved. In addition, NAT traversal integral part of IKEv2, which also connections via NAT router can be built.

Authentication Header (AH)

The Authentication Header (AH) to ensure the authenticity and integrity of transmitted packets and authenticate the sender. Furthermore, it protects against replay attacks. AH protects the invariant part of an IP datagram; IP header fields can be changed on the way of an IP network of routers (such as TTL), are not considered. If on the path through the network router with an enabled Network Address Translation ( NAT) happens, so change this actually invariant parts of an IP datagram from, hence authentication is no longer possible - NAT and AH are therefore by design, incompatible - only a combination NAT and ESP (see RFC 3948 - UDP Encapsulation of IPsec ESP Packets ) is possible. The user data is encrypted during AH and can therefore be read for everyone. AH is directly based on IP and uses the IP protocol number 51

An AH- package looks like this:

Authenticity of data (variable)

Meaning of the fields:

Protection against replay attacks

To protect against replay attacks, the receiver of an AH packet can not rely on the fact that the sequence number is always higher than in the previous package. IP packets may have been on the road can also be reversed. Therefore, it is - on the basis of received the highest sequence number so far - also accept a fixed number of smaller sequence numbers. If a sequence number within that amount received for the second time, the corresponding packet is discarded. This also applies to packets with smaller sequence number ( ie below the specified number of smaller sequence numbers ).

Encapsulating Security Payload ( ESP)

Encapsulating Security Payload (ESP ) provides mechanisms to ensure the authenticity, integrity and confidentiality of the transmitted IP packets. In contrast to the AH header of the IP packet from the ICV ( Integrity check value) is not considered, but the payload is encrypted. ESP is directly based on IP and uses the IP protocol number 50

An ESP packet looks like this:

Payload * (variable)

Authenticity of data (variable)

Meaning of the fields:

The protection against replay attacks corresponds to the mechanism of AH.

Compare transport and tunnel mode

In transport mode, IPsec connects two endpoints directly with each other (peer -to-peer ), for example, an installed software on the peers.

In the tunnel mode, however, two IP networks are connected. The endpoints are here formed by two routers and VPN gateways between which the tunnel is established.

IPsec in transport mode

In transport mode, the IPsec header between the IP header and the user data is inserted. The IP header remains unchanged and continues to serve to route packets from sender to receiver. The transport mode is used when the " cryptographic endpoints " and the " communication end points " are. After receiving the IPsec packet, the original data ( TCP / UDP ) packets are unpacked and passed to the higher layer above. The transport mode is mainly used for host-to- host or host-to- router connections, such as network management.

IPsec in tunnel mode

In tunnel mode, the original packet is encapsulated and the security services of IPsec applied to the entire package. The new (outer) IP header is used, the tunnel end (the cryptographic endpoints) to be addressed, whereas the actual addresses of the end points of communication are available in the inner IP header. The original (internal ) IP header is for routers, and so on the way between the tunnel ends only payload (payload ) is and will only be used again if the receiving security gateway ( the end of the tunnel on the receiving side ) has the IP encapsulation removed and the package delivers the intended recipient.

In tunnel mode, the gateway -to- gateway or the peer - to-gateway connections are possible. As can coincide on the same computer on one side each end of the tunnel and endpoint communication, peer -to -peer connections are also possible in tunnel mode. One advantage of tunnel mode is that needs to be implemented and configured in the gateway-to- gateway connection only in the gateway ( tunnel ends ) IPsec. Attacker can only bring the tunnel end points of IPsec tunnel to determine, but not the entire path of the connection.

Keepalives

To ensure that the connection between the endpoints was not interrupted before this exchange at regular intervals keepalive messages, which can also be used to automatically build a lost by disconnection tunnel again.

Dead Peer Detection

Dead Peer Detection ( DPD) was adopted in February 2004. Through the use of DPD can be detected whether an IPsec connection (especially the ISAKMP tunnel ) was terminated unintentionally and unexpectedly. In case of error the remote sites degrade the security associations (SAs ) to allow a reconstruction of the ISAKMP tunnel and the ESP-/AH-Tunnel. Without the use of DPD an endpoint is to ward off with a still existing tunnel rebuilding because the SPIs ( Security Payload Identifier) ​​no longer fit. A reconstruction of the tunnel is otherwise possible only after the re-keying timer.

DPD is a Notify message in the ISAKMP protocol ( UDP: 500) transferred (message values ​​: RU- THERE - 36136/RU-THERE-ACK - 36137 ). The DPD function, however, ensures a continuous review of the connection to the remote and provides an automatic reconstruction in accidental disconnection. The specification is defined in RFC 3706 and is also called ISAKMP keepalive.

UDP Keep Alive

It prevents (for NAT traversal ) of NAT usually initiated automatically time-out at longer time delays in data entry. The specification is defined in RFC 3519 and is also called NAT Keep Alive.

Criticism of IPsec

Conceptual

"IPsec was a great disappointment to us. Given the quality of the people did worked on it and the time spent on it did what, we expected a much better result. "

"IPsec was a big disappointment for us. Given the qualifications of the people who have worked and the time it was applied for, we have a much better result expected. "

The cryptographer Bruce Schneier and Niels Ferguson evaluated several times the IPsec protocol and found several criticisms. In addition to the way it was, especially the high complexity and error-proneness is criticized. However, both noted also that the original IP IPsec best hedges at the time.

Putative back door ( backdoor ) in OpenBSD

In December 2010, Gregory Perry claimed that had been installed in the IPsec implementation in OpenBSD ( and some derivatives) funded by the FBI backdoors and side channel attacks, which could allow unauthorized access or getting the key. Technical details were not disclosed, and the developer accused deny the charges. The OpenBSD developers did not notice any signs of backdoors in a first code review.

Relevant RFCs

IPsec arose during the development of IPv6 and is specified in a number of recent RFCs:

  • RFC 2367 - PF_KEY Interface
  • RFC 2403 - The Use of HMAC -MD5 -96 within ESP and AH
  • RFC 2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
  • RFC 2410 - The NULL Encryption Algorithm and Its Use With IPsec
  • RFC 2411 - IP Security Document Roadmap
  • RFC 2412 - The OAKLEY Key Determination Protocol
  • RFC 2451 - The ESP CBC -Mode Cipher Algorithms
  • RFC 2857 - The Use of HMAC- RIPEMD- 160-96 within ESP and AH
  • RFC 3526 - More Modular Exponential ( MODP ) Diffie- Hellman groups for Internet Key Exchange ( IKE)
  • RFC 3602 - The AES - CBC Cipher Algorithm and Its Use with IPsec
  • RFC 3686 - Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload ( ESP)
  • RFC 3706 - A Traffic -Based Method of Detecting Dead Internet Key Exchange ( IKE) Peers
  • RFC 3715 - IPsec - Network Address Translation ( NAT) Compatibility Requirements
  • RFC 3947 - Negotiation of NAT -Traversal in the IKE
  • RFC 3948 - UDP Encapsulation of IPsec ESP Packets
  • RFC 4106 - The Use of Galois / Counter Mode (GCM ) in IPsec Encapsulating Security Payload ( ESP)
  • RFC 4301 - Security Architecture for the Internet Protocol
  • RFC 4302 - IP Authentication Header
  • RFC 4303 - IP Encapsulating Security Payload ( ESP)
  • RFC 4304 - Extended Sequence Number (ESN ) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol ( ISAKMP )
  • RFC 4306 - Internet Key Exchange ( IKEv2 ) Protocol
  • RFC 4307 - Cryptographic Algorithms for Use in the Internet Key Exchange version 2 ( IKEv2 )
  • RFC 4308 - Cryptographic Suites for IPsec
  • RFC 4309 - Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload ( ESP)
  • RFC 4478 - Repeated Authentication in Internet Key Exchange ( IKEv2 ) Protocol
  • RFC 4543 - The Use of Galois Message Authentication Code ( GMAC ) in IPsec ESP and AH
  • RFC 4555 - IKEv2 Mobility and Multihoming Protocol ( MOBIKE )
  • RFC 4621 - Design of the IKEv2 Mobility and Multihoming ( MOBIKE ) Protocol
  • RFC 4718 - IKEv2 Clarifications and Implementation Guidelines
  • RFC 4806 - Online Certificate Status Protocol (OCSP ) Extensions to IKEv2
  • RFC 4809 - Requirements for on IPsec Certificate Management Profile
  • RFC 4835 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload ( ESP) and Authentication Header (AH)
  • RFC 4945 - The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
  • RFC 5996 - Internet Key Exchange Protocol Version 2 ( IKEv2 )
91356
de