This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.
Differences between revisions 1 and 24 (spanning 23 versions)
Revision 1 as of 2006-03-29 12:32:35
Size: 11143
Comment:
Revision 24 as of 2006-06-05 03:19:17
Size: 1292
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
A set of protocols developed by the IETF to support secure exchange of packets at the IP layer.
Line 5: Line 6:
= IPsec Algorithms And Keys = == IPsec Algorithms And Keys ==
Line 7: Line 8:
Currently IPsec is mainly described by the three followings RFCs: Currently IPsec is mainly described by the three following RFCs:
Line 9: Line 10:
- 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.
 * [http://www.ietf.org/rfc/rfc4301.txt RFC4301], Security Architecture for the Internet Protocol, S. Kent, K. Seo, December 2005, PROPOSED STANDARD.
Line 16: Line 12:
 * [http://www.ietf.org/rfc/rfc4302.txt RFC4302], IP Authentication Header, S. Kent, December 2005, PROPOSED STANDARD.
Line 17: Line 14:
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.
 * [http://www.ietf.org/rfc/rfc4303.txt RFC4303], IP Encapsulating Security Payload (ESP), S. Kent, December 2005, PROPOSED STANDARD.
Line 22: Line 16:
You also may use some others Cryptographic Algorithm (have a look
at the IANA for some other examples).
The Algorithms to use and their requirements are described in [http://www.ietf.org/rfc/rfc4305.txt RFC4305]: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (["ESP"]) and Authentication Header (["AH"]), D. Eastlake 3rd, December 2005, PROPOSED STANDARD.
Line 25: Line 18:
You also may use some other Cryptographic Algorithms (have a look at the IANA for some other examples).
Line 26: Line 20:
= ESP Algorithms (RFC 4305) = == Wireshark ==
If linked with Libcrypt Wireshark provides some advanced features such as Decryption of ESP Payloads and/or Authentication Checking. see ["ESP_Preferences"]
Line 28: Line 23:
The ESP Format is the following:

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:


    0 1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header | Payload Len | RESERVED |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Security Parameters Index (SPI) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sequence Number Field |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | |
   + Authentication Data (variable) |
   | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= 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).


                                              DUMP
                                               |
    N1 SGW1 | N2
[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>
########## For 192.168.0.2 (SGW1)
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>
########## For 192.168.0.3 (N1)
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.
Is this true for Win32? ''UlfLamping''

IPsec (Internet Protocol Security)

A set of protocols developed by the IETF to support secure exchange of packets at the IP layer.

IPsec Algorithms And Keys

Currently IPsec is mainly described by the three following RFCs:

The Algorithms to use and their requirements are described in [http://www.ietf.org/rfc/rfc4305.txt 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 other Cryptographic Algorithms (have a look at the IANA for some other examples).

Wireshark

If linked with Libcrypt Wireshark provides some advanced features such as Decryption of ESP Payloads and/or Authentication Checking. see ["ESP_Preferences"]

Is this true for Win32? UlfLamping

IPsec (last edited 2008-04-12 17:51:29 by localhost)