IPsec
In computing, Internet Protocol Security(IPsec) is a network protocol suite thatauthenticates and encrypts the packets of data sent over a network. IPsec includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation ofcryptographic keys to use during the session. IPsec can protect data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host).[1] Internet Protocol security (IPsec) uses cryptographic security services to protect communications over Internet Protocol (IP) networks. IPsec supports network-level peer authentication, data-origin authentication, data integrity, data confidentiality (encryption), and replay protection.
IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite, while some other Internet security systems in widespread use, such asTransport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers at the Transport Layer (TLS) and the Application layer (SSH). IPsec can automatically secure applications at the IP layer.
History
In the late 1980s, US NIST developed a set of security protocols for the Internet. One of these, Security Protocol at layer-3 (SP3) was implemented in IP encryption devices sold by Motorola. The IPsec Encapsulating Security Payload (ESP) is a direct derivative of the SP3 protocol. In 1992, both research and implementation began at the US Naval Research Laboratory (NRL) on IP encryption. Later, in December 1993, the Software IP Encryption protocol swIPe (protocol) was researched on SunOS at Columbia Universityand AT&T Bell Labs by John Ioannidis and others. Funded by the White House in 1993, Wei Xu at Trusted Information Systems took over this research, enhanced the IP security protocols, and developed the plug-and-playTriple DES hardware encryption on the BSDI platform in July 1994, which successfully enabled the IP Security capable of the commercial products integrated with Gauntlet Firewall at the throughput over T1 speed. Practically, it was first time in history securing networks between the US East and West coasts since December 1994. These achievements ultimately led to the IP Security protocols standardized by the Internet Engineering Task Force (IETF) between 1995 and 1998.
In July 1992, the IETF started to create an open, freely available set of security extensions to the Internet protocol. This became the IETF IP Security (IPsec) Working Group in 1995. The SDNS project had defined a Security Protocol Layer 3 (SP3) that had been published by NIST and was also the basis of the ISO Network Layer Security Protocol (NLSP).[2] Key management for SP3 was provided by the Key Management Protocol (KMP) that provided a baseline of ideas for subsequent work in the IPsec committee.
IPsec is officially standardised by the Internet Engineering Task Force (IETF) in a series ofRequest for Comments documents addressing various components and extensions. The original IETF specifications are in RFC-1825 through RFC-1827, which published in 1995. The official spelling of the protocol name is IPsec.[3]
Security architecture
The IPsec suite is an open standard. IPsec uses the following protocols to perform various functions:[4][5]
- Authentication Headers (AH) provides connectionless data integrity and data origin authentication for IP datagrams and provides protection against replay attacks.[6][7]
- Encapsulating Security Payloads (ESP)provides confidentiality, data-originauthentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic-flow confidentiality.[1]
- Security Associations (SA) provides the bundle of algorithms and data that provide the parameters necessary for AH and/or ESP operations. The Internet Security Association and Key Management Protocol(ISAKMP) provides a framework for authentication and key exchange,[8] with actual authenticated keying material provided either by manual configuration with pre-shared keys, Internet Key Exchange(IKE and IKEv2), Kerberized Internet Negotiation of Keys (KINK), or IPSECKEYDNS records.[9][10][11][12]
Authentication Header
The Security Authentication Header (AH) is derived partially from previous IETF standards work for authentication of the Simple Network Management Protocol (SNMP) version 2. Authentication Header (AH) is a member of the IPsec protocol suite. AH ensures connectionless integrity by using a hash function and a secret shared key in the AH algorithm. AH also guarantees the data origin by authenticating IP packets. Optionally a sequence number can protect the IP sec packet's contents against replay attacks,[13]using the sliding window technique and discarding old packets.
- In IPv4, AH prevents option-insertion attacks. In IPv6, AH protects both against header insertion attacks and option insertion attacks.
- In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for mutable fields (i.e. those that might be altered in transit), and also IP options such as the IP Security Option (RFC 1108). Mutable (and therefore unauthenticated) IPv4 header fields are DSCP/ToS, ECN, Flags, Fragment Offset, TTL and Header Checksum.[7]
- In IPv6, the AH protects most of the IPv6 base header, AH itself, non-mutable extension headers after the AH, and the IP payload. Protection for the IPv6 header excludes the mutable fields: DSCP, ECN, Flow Label, and Hop Limit.[7]
AH operates directly on top of IP, using IP protocol number 51.[14]
- Next Header (8 bits)
- Type of the next header, indicating what upper-layer protocol was protected. The value is taken from the list of IP protocol numbers.
- Payload Len (8 bits)
- The length of this Authentication Header in 4-octet units, minus 2. For example, an AH value of 4 equals 3×(32-bit fixed-length AH fields) + 3×(32-bit ICV fields) − 2 and thus an AH value of 4 means 24 octets. Although the size is measured in 4-octet units, the length of this header needs to be a multiple of 8 octets if carried in an IPv6 packet. This restriction does not apply to anAuthentication Header carried in an IPv4 packet.
- Reserved (16 bits)
- Reserved for future use (all zeroes until then).
- Security Parameters Index (32 bits)
- Arbitrary value which is used (together with the destination IP address) to identify thesecurity association of the receiving party.
- Sequence Number (32 bits)
- A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to prevent replay attacks. When replay detection is enabled, sequence numbers are never reused, because a new security association must be renegotiated before an attempt to increment the sequence number beyond its maximum value.[7]
- Integrity Check Value (multiple of 32 bits)
- Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary forIPv4.
Encapsulating Security Payload
The IP Encapsulating Security Payload (ESP)[15] was researched at the Naval Research Laboratory starting in 1992 as part of a DARPA-sponsored research project, and was openly published by IETF SIPP[16]Working Group drafted in December 1993 as a security extension for SIPP. This ESP was originally derived from the US Department of Defense SP3D protocol, rather than being derived from the ISO Network-Layer Security Protocol (NLSP). The SP3D protocol specification was published by NIST in the late 1980s, but designed by the Secure Data Network System project of the US Department of Defense. Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. It provides origin authenticity through sourceauthentication, data integrity through hash functions and confidentiality throughencryption protection for IP packets. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure.[17][18][19]
Unlike Authentication Header (AH), ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP operates directly on top of IP, using IP protocol number 50.[14]
- Security Parameters Index (32 bits)
- Arbitrary value used (together with the destination IP address) to identify thesecurity association of the receiving party.
- Sequence Number (32 bits)
- A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against replay attacks. There is a separate counter kept for every security association.
- Payload data (variable)
- The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.
- Padding (0-255 octets)
- Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block size, and to align the next field.
- Pad Length (8 bits)
- Size of the padding (in octets).
- Next Header (8 bits)
- Type of the next header. The value is taken from the list of IP protocol numbers.
- Integrity Check Value (multiple of 32 bits)
- Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary forIPv4.
Security association
The IPsec protocols use a security association, where the communicating parties establish shared security attributes such asalgorithms and keys. As such IPsec provides a range of options once it has been determined whether AH or ESP is used. Before exchanging data the two hosts agree on which algorithm is used to encrypt the IP packet, for example DES or IDEA, and which hash function is used to ensure the integrity of the data, such as MD5 or SHA. These parameters are agreed for the particular session, for which a lifetime must be agreed and a session key.[21]
The algorithm for authentication is also agreed before the data transfer takes place and IPsec supports a range of methods. Authentication is possible through pre-shared key, where a symmetric key is already in the possession of both hosts, and the hosts send each other hashes of the shared key to prove that they are in possession of the same key. IPsec also supports public key encryption, where each host has a public and a private key, they exchange their public keys and each host sends the other a nonce encrypted with the other host's public key. Alternatively if both hosts hold a public key certificate from acertificate authority, this can be used for IPsec authentication.[22]
The security associations of IPsec are established using the Internet Security Association and Key Management Protocol(ISAKMP). ISAKMP is implemented by manual configuration with pre-shared secrets, Internet Key Exchange (IKE and IKEv2), Kerberized Internet Negotiation of Keys (KINK), and the use of IPSECKEY DNS records.[12][23][24] RFC 5386 defines Better-Than-Nothing Security (BTNS) as an unauthenticated mode of IPsec using an extended IKE protocol.
In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index (SPI), an index to the security association database (SADB), along with the destination address in a packet header, which together uniquely identifies a security association for that packet. A similar procedure is performed for an incoming packet, where IPsec gathers decryption and verification keys from the security association database.
For IP multicast a security association is provided for the group, and is duplicated across all authorized receivers of the group. There may be more than one security association for a group, using different SPIs, thereby allowing multiple levels and sets of security within a group. Indeed, each sender can have multiple security associations, allowing authentication, since a receiver can only know that someone knowing the keys sent the data. Note that the relevant standard does not describe how the association is chosen and duplicated across the group; it is assumed that a responsible party will have made the choice.
Modes of Operation
IPsec protocols AH and ESP can be applied in Transport or Tunnel mode.
IPsec - Modes of Operation - Transport or Tunnel
Transport Mode
In transport mode, only the payload of the IP packet is usually encrypted or authenticated. The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IP addresses cannot be modified by network address translation, as this always invalidates the hash value. The transport and applicationlayers are always secured by a hash, so they cannot be modified in any way, for example bytranslating the port numbers.
A means to encapsulate IPsec messages forNAT traversal has been defined by RFCdocuments describing the NAT-T mechanism.
Tunnel Mode
In tunnel mode, the entire IP packet is encrypted and authenticated. It is then encapsulated into a new IP packet with a new IP header. Tunnel mode is used to createvirtual private networks for network-to-network communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access) and host-to-host communications (e.g. private chat).[25]
Tunnel mode supports NAT traversal.
Comments
Post a Comment