This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.

IPsec (Internet Protocol Security)

IPsec Algorithms And Keys

Currently IPsec is mainly described by the three followings RFCs:

* RFC4301, Security Architecture for the Internet Protocol, S. Kent, K. Seo, December 2005, PROPOSED STANDARD.

* RFC4302, IP Authentication Header, S. Kent, December 2005, PROPOSED STANDARD.

* RFC4303, IP Encapsulating Security Payload (ESP), S. Kent, December 2005, PROPOSED STANDARD.

The Algorithms to use and their requirements are described in RFC4305: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH), D. Eastlake 3rd, December 2005, PROPOSED STANDARD.

You also may use some others Cryptographic Algorithm (have a look at the IANA for some other examples).

ESP Algorithms (RFC 4305)

The ESP Format is the following:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Security Parameters Index (SPI) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Sequence Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Payload Data (variable) |

~ ~

| |

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | Padding (0-255 bytes) |

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | Pad Length | Next Header |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Authentication Data (variable) |

~ ~

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ESP Requierements

The followings tables (RFC 4305) list Encryption and Authentication algorithms for the IPsec Encapsulating Security Payload protocol.

Requirement Encryption Algorithm (notes)



MUST NULL (1) MUST- TripleDES-CBC [RFC2451] SHOULD+ AES-CBC with 128-bit keys [RFC3602] SHOULD AES-CTR [RFC3686] SHOULD NOT DES-CBC [RFC2405] (3)

Requirement Authentication Algorithm (notes)



MUST HMAC-SHA1-96 [RFC2404] MUST NULL (1) SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (2)

Notes:

(1) Since ESP Encryption and Authentication are optional, support for the two "NULL" algorithms is required to maintain consistency with the way these services are negotiated. Note that while Authentication and Encryption can each be "NULL", they MUST NOT both be "NULL". (2) Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC. (3) DES, with its small key size and publicly demonstrated and open-design special-purpose cracking hardware, is of questionable security for general use.

This dissector takes into account all these Encryption Algorithms defined in RFC 4305. I also have adapted the dissector for :

* BLOWFISH-CBC [RFC2451] with key size of only 128 bits. * TWOFISH-CBC with key of 128 or 256 bits only.

These 2 Algorithms have been developed by Counterpane Labs. Have a look to http://www.schneier.com for more information.

TripleDES-CBC [RFC2451]

According to RFC 2451, 3DES CBC uses a key of 192 bits. The first 3DES key is taken from the first 64 bits, the second from the next 64 bits, and the third from the last 64 bits. Implementations MUST take into consideration the parity bits when initially accepting a new set of keys. Each of the three keys is really 56 bits in length with the extra 8 bits used for parity. 3DES CBC uses an IV of 8 octets.

AES-CBC with 128-bit keys [RFC3602]

According to RFC 3602, AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The default key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits. AES-CBC uses an IV of 16 octets.

AES-CTR [RFC3686]

According to RFC 3686, AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The default key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits. AES-CTR uses an IV of 8 octets.

DES-CBC [RFC2405]

According to RFC 2405, DES-CBC is a symmetric secret key algorithm. The key size is 64-bits. It is commonly known as a 56-bit key as the key has 56 significant bits; the least significant bit in every byte is the parity bit. DES-CBC uses an IV of 8 octets.

BLOWFISH-CBC [RFC2451]

Bruce Schneier of Counterpane Systems developed the Blowfish cipher algorithm. RFC 2451 shows that Blowfish uses key sizes from 40 to 448 bits. The Default size is 128 bits. We will only accept key sizes of 128 bits, because libgrypt only accept this key size. Have a look to http://www.schneier.com for more information. BLOWFISH-CBC uses an IV of 8 octets.

TWOFISH-CBC

Twofish is a 128-bit block cipher developed by Counterpane Labs that accepts a variable-length key up to 256 bits. We will only accept key sizes of 128 and 256 bits. Have a look to http://www.schneier.com for more information. TWOFISH-CBC uses an IV of 16 octets.

HMAC-MD5-96 [RFC2403]

HMAC with MD5 provides data origin Authentication and integrity protection. HMAC-MD5-96 produces a 128-bit authenticator value. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 128-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by HMAC-MD5-96.

HMAC-SHA1-96 [RFC2404]

SHA-1 combined with HMAC [RFC2104] provides a keyed Authentication mechanism. HMAC-SHA-1-96 produces a 160-bit authenticator value. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 160-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by HMAC-SHA-1-96.

AES-XCBC-MAC-96 [RFC3566]

AES-XCBC-MAC-96 is a secret key algorithm. For use with either ESP or AH a fixed key length of 128-bits MUST be supported. Key lengths other than 128-bits MUST NOT be supported (i.e., only 128-bit keys are to be used by AES-XCBC-MAC-96).

AES-XCBC-MAC produces a 128-bit authenticator value. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 128-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by AES-XCBC-MAC-96.

AH Algorithms (RFC 4305)

The AH Header described in [RFC4302] is the following:

AH Requirements

The implementation conformance requirements for security algorithms for AH are given below (RFC4305). As you would suspect, all of these algorithms are authentication algorithms.

Requirement Algorithm (notes)



MUST HMAC-SHA1-96 [RFC2404] SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (1)

Note:

(1) Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC.

IPsec Modes

IPsec may be used in two Modes : tunnel or transport and concerns two kinds of nodes : End Nodes and Secure Gateways. Each kind of node may use IPsec using these two Modes. This dissector aim is to decrypt the whole packet if you have enough information concerning the different Security Associations.

Here is one of the more complex tology (if you have ESP in tunnel Mode in ESP in tunnel Mode ... it should work the same).

[192.168.0.3]


[192.168.0.2][10.0.0.1]


[10.0.0.2]

default route for 192.168.0.3 is 192.168.0.2 default route for 10.0.0.2 is 10.0.0.1 We define the following policies with the setkey syntax :

<SA1>

spdadd 192.168.0.3 10.0.0.2 any -P out ipsec esp/tunnel/10.0.0.1-10.0.0.2/use; add 10.0.0.1 10.0.0.2 esp 10 -m tunnel -E aes-cbc "aescbcencryption" -A hmac-sha1 "hmacsha1authenticati";

<SA2>

spdadd 192.168.0.3 10.0.0.2 any -P out ipsec esp/transport//require; add 192.168.0.3 10.0.0.2 esp 15 -E des-cbc "descbte" -A hmac-sha1 "hmacsha1authenticati";

It means that packets coming from N1 to N2 will be encrypted with des-cbc and tunneled from SGW1 with ESP encryption aes-cbc to N2. If we have a look at the DUMP host, we have only two SAs to decrypt the entire packet. If we have a look at the different Layers it will be :

[IP1][ESP1][ENCRYPTION1]

with [ENCRYPTION1]=[IP2][ESP2][ENCRYPTION2] and [ENCRYPTION2]=ICMP

IP1 is IP header from SGW1 to N2 ENCRYPTION2 is aes-cbc IP2 is IP header from N1 to N2 ENCRYPTION2 is des-cbc

Thus, the IPsec dissector knowing these two SAs, will decrypt first ENCRYPTION1 using SA1, will dissect it, will get ENCRYPTION2, will decrypt it using SA2 and will dissect it getting the full decrypted packet.