| < draft-ietf-ipsec-ciph-aes-ccm-04.txt | draft-ietf-ipsec-ciph-aes-ccm-05.txt > | |||
|---|---|---|---|---|
| IPsec Working Group R. Housley | IPsec Working Group R. Housley | |||
| Internet Draft Vigil Security | Internet Draft Vigil Security | |||
| expires in six months July 2003 | expires in six months November 2003 | |||
| Using AES CCM Mode With IPsec ESP | Using AES CCM Mode With IPsec ESP | |||
| <draft-ietf-ipsec-ciph-aes-ccm-04.txt> | <draft-ietf-ipsec-ciph-aes-ccm-05.txt> | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with all | This document is an Internet-Draft and is in full conformance with all | |||
| provisions of Section 10 of RFC2026. | provisions of Section 10 of RFC2026. | |||
| Internet-Drafts are working documents of the Internet Engineering Task | Internet-Drafts are working documents of the Internet Engineering Task | |||
| Force (IETF), its areas, and its working groups. Note that other | Force (IETF), its areas, and its working groups. Note that other | |||
| groups may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This document is a submission to the IETF Internet Protocol Security | This document is a submission to the IETF Internet Protocol Security | |||
| (IPsec) Working Group. Please send comments on this document to the | (IPsec) Working Group. Please send comments on this document to the | |||
| working group mailing list (ipsec@lists.tislabs.com). | working group mailing list (ipsec@lists.tislabs.com). | |||
| Distribution of this memo is unlimited. | Distribution of this memo is unlimited. | |||
| Abstract | Abstract | |||
| This document describes the use of AES CCM Mode, with an explicit | This document describes the use of Advanced Encryption Standard (AES) | |||
| initialization vector, as an IPsec Encapsulating Security Payload | in Counter with CBC-MAC (CCM) Mode, with an explicit initialization | |||
| (ESP) mechanism to provide confidentiality, data origin | vector (IV), as an IPsec Encapsulating Security Payload (ESP) | |||
| authentication, connectionless integrity. | mechanism to provide confidentiality, data origin authentication, | |||
| connectionless integrity. | ||||
| Table of Contents | Table of Contents | |||
| 1 Introduction .............................................. 3 | 1 Introduction .............................................. 3 | |||
| 1.1 Conventions Used In This Document ......................... 3 | 1.1 Conventions Used In This Document ......................... 3 | |||
| 2 AES-CCM Mode .............................................. 3 | 2 AES CCM Mode .............................................. 3 | |||
| 3 ESP Payload ............................................... 5 | 3 ESP Payload ............................................... 5 | |||
| 3.1 Initialization Vector ..................................... 5 | 3.1 Initialization Vector ..................................... 5 | |||
| 3.2 Encrypted Payload ......................................... 5 | 3.2 Encrypted Payload ......................................... 5 | |||
| 3.3 Authentication Data ....................................... 6 | 3.3 Authentication Data ....................................... 6 | |||
| 4 Nonce Format .............................................. 6 | 4 Nonce Format .............................................. 6 | |||
| 5 AAD Construction .......................................... 7 | 5 AAD Construction .......................................... 7 | |||
| 6 Packet Expansion .......................................... 7 | 6 Packet Expansion .......................................... 7 | |||
| 7 IKE Conventions ........................................... 7 | 7 IKE Conventions ........................................... 7 | |||
| 7.1 Keying Material and Salt Values ........................... 8 | 7.1 Keying Material and Salt Values ........................... 8 | |||
| 7.2 Phase 1 Identifier ........................................ 8 | 7.2 Phase 1 Identifier ........................................ 8 | |||
| skipping to change at page 3, line 9 ¶ | skipping to change at page 3, line 9 ¶ | |||
| 13 References ................................................ 12 | 13 References ................................................ 12 | |||
| 13.1 Normative References ...................................... 12 | 13.1 Normative References ...................................... 12 | |||
| 13.2 Informative References .................................... 12 | 13.2 Informative References .................................... 12 | |||
| 14 Author's Address .......................................... 14 | 14 Author's Address .......................................... 14 | |||
| 13 Full Copyright Statement .................................. 14 | 13 Full Copyright Statement .................................. 14 | |||
| 1. Introduction | 1. Introduction | |||
| The Advanced Encryption Standard (AES) [AES] is a block cipher, and | The Advanced Encryption Standard (AES) [AES] is a block cipher, and | |||
| it can be used in many different modes. This document describes the | it can be used in many different modes. This document describes the | |||
| use of AES in CCM (Counter with CBC-MAC) mode (AES-CCM), with an | use of AES in CCM (Counter with CBC-MAC) mode (AES CCM), with an | |||
| explicit initialization vector (IV), as an IPsec Encapsulating | explicit initialization vector (IV), as an IPsec Encapsulating | |||
| Security Payload (ESP) [ESP] mechanism to provide confidentiality, | Security Payload (ESP) [ESP] mechanism to provide confidentiality, | |||
| data origin authentication, connectionless integrity. | data origin authentication, connectionless integrity. | |||
| This document does not provide an overview of IPsec. However, | This document does not provide an overview of IPsec. However, | |||
| information about how the various components of IPsec and the way in | information about how the various components of IPsec and the way in | |||
| which they collectively provide security services is available in | which they collectively provide security services is available in | |||
| [ARCH] and [ROAD]. | [ARCH] and [ROAD]. | |||
| 1.1. Conventions Used In This Document | 1.1. Conventions Used In This Document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [STDWORDS]. | document are to be interpreted as described in [STDWORDS]. | |||
| 2. AES-CCM Mode | 2. AES CCM Mode | |||
| CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. | CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. | |||
| In this specification, CCM is used with the AES [AES] block cipher. | In this specification, CCM is used with the AES [AES] block cipher. | |||
| AES-CCM has two parameters: | AES CCM has two parameters: | |||
| M M indicates the size of the integrity check value (ICV). | M M indicates the size of the integrity check value (ICV). | |||
| CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets; | CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets; | |||
| However, to maintain alignment and provide adequate | However, to maintain alignment and provide adequate | |||
| security, only the values that are a multiple of four and | security, only the values that are a multiple of four and | |||
| are at least eight are permitted. Implementations MUST | are at least eight are permitted. Implementations MUST | |||
| support M values of 8 octets and 16 octets, and | support M values of 8 octets and 16 octets, and | |||
| implementations MAY support an M value of 12 octets. | implementations MAY support an M value of 12 octets. | |||
| L L indicates the size of the length field in octets. CCM | L L indicates the size of the length field in octets. CCM | |||
| skipping to change at page 4, line 29 ¶ | skipping to change at page 4, line 29 ¶ | |||
| AAD | AAD | |||
| CCM provides data integrity and data origin authentication for | CCM provides data integrity and data origin authentication for | |||
| some data outside the payload. CCM does not allow additional | some data outside the payload. CCM does not allow additional | |||
| authenticated data (AAD) to be longer than | authenticated data (AAD) to be longer than | |||
| 18,446,744,073,709,551,615 octets. The ICV is computed from | 18,446,744,073,709,551,615 octets. The ICV is computed from | |||
| the ESP header, Payload, and ESP trailer fields, which is | the ESP header, Payload, and ESP trailer fields, which is | |||
| significantly smaller than the CCM imposed limit. The | significantly smaller than the CCM imposed limit. The | |||
| construction of the AAD described in section 5. | construction of the AAD described in section 5. | |||
| AES-CCM requires the encryptor to generate a unique per-packet value, | AES CCM requires the encryptor to generate a unique per-packet value, | |||
| and communicate this value to the decryptor. This per-packet value | and communicate this value to the decryptor. This per-packet value | |||
| is one of the component parts of the nonce, and it is referred to as | is one of the component parts of the nonce, and it is referred to as | |||
| the initialization vector (IV). The same IV and key combination MUST | the initialization vector (IV). The same IV and key combination MUST | |||
| NOT be used more than once. The encryptor can generate the IV in any | NOT be used more than once. The encryptor can generate the IV in any | |||
| manner that ensures uniqueness. Common approaches to IV generation | manner that ensures uniqueness. Common approaches to IV generation | |||
| include incrementing a counter for each packet and linear feedback | include incrementing a counter for each packet and linear feedback | |||
| shift registers (LFSRs). | shift registers (LFSRs). | |||
| AES-CCM employs counter mode for encryption. As with any stream | AES CCM employs counter mode for encryption. As with any stream | |||
| cipher, reuse of the IV same value with the same key is catastrophic. | cipher, reuse of the IV same value with the same key is catastrophic. | |||
| An IV collision immediately leaks information about the plaintext in | An IV collision immediately leaks information about the plaintext in | |||
| both packets. For this reason, it is inappropriate to use this CCM | both packets. For this reason, it is inappropriate to use this CCM | |||
| with statically configured keys. Extraordinary measures would be | with statically configured keys. Extraordinary measures would be | |||
| needed to prevent reuse of an IV value with the static key across | needed to prevent reuse of an IV value with the static key across | |||
| power cycles. To be safe, implementations MUST use fresh keys with | power cycles. To be safe, implementations MUST use fresh keys with | |||
| AES-CCM. The Internet Key Exchange (IKE) [IKE] protocol can be used | AES CCM. The Internet Key Exchange (IKE) [IKE] protocol can be used | |||
| to establish fresh keys. | to establish fresh keys. | |||
| 3. ESP Payload | 3. ESP Payload | |||
| The ESP payload is comprised of the IV followed by the ciphertext. | The ESP payload is comprised of the IV followed by the ciphertext. | |||
| The payload field, as defined in [ESP], is structured as shown in | The payload field, as defined in [ESP], is structured as shown in | |||
| Figure 1. | Figure 1. | |||
| 0 1 2 3 | 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 | 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 | |||
| skipping to change at page 5, line 26 ¶ | skipping to change at page 5, line 26 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| ~ Encrypted Payload (variable) ~ | ~ Encrypted Payload (variable) ~ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| ~ Authentication Data (variable) ~ | ~ Authentication Data (variable) ~ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1. ESP Payload Encrypted with AES-CCM | Figure 1. ESP Payload Encrypted with AES CCM | |||
| 3.1. Initialization Vector (IV) | 3.1. Initialization Vector (IV) | |||
| The AES-CCM IV field MUST be eight octets. The IV MUST be chosen by | The AES CCM IV field MUST be eight octets. The IV MUST be chosen by | |||
| the encryptor in a manner that ensures that the same IV value is used | the encryptor in a manner that ensures that the same IV value is used | |||
| only once for a given key. The encryptor can generate the IV in any | only once for a given key. The encryptor can generate the IV in any | |||
| manner that ensures uniqueness. Common approaches to IV generation | manner that ensures uniqueness. Common approaches to IV generation | |||
| include incrementing a counter for each packet and linear feedback | include incrementing a counter for each packet and linear feedback | |||
| shift registers (LFSRs). | shift registers (LFSRs). | |||
| Including the IV in each packet ensures that the decryptor can | Including the IV in each packet ensures that the decryptor can | |||
| generate the key stream needed for decryption, even when some | generate the key stream needed for decryption, even when some | |||
| datagrams are lost or reordered. | datagrams are lost or reordered. | |||
| 3.2. Encrypted Payload | 3.2. Encrypted Payload | |||
| The encrypted payload contains the ciphertext. | The encrypted payload contains the ciphertext. | |||
| AES-CCM mode does not require plaintext padding. However, ESP does | AES CCM mode does not require plaintext padding. However, ESP does | |||
| require padding to 32-bit word-align the authentication data. The | require padding to 32-bit word-align the authentication data. The | |||
| Padding, Pad Length, and Next Header fields MUST be concatenated with | Padding, Pad Length, and Next Header fields MUST be concatenated with | |||
| the plaintext before performing encryption, as described in [ESP]. | the plaintext before performing encryption, as described in [ESP]. | |||
| 3.3. Authentication Data | 3.3. Authentication Data | |||
| AES-CCM provides an encrypted ICV. The ICV provided by CCM is | AES CCM provides an encrypted ICV. The ICV provided by CCM is | |||
| carried in the Authentication Data fields without further encryption. | carried in the Authentication Data fields without further encryption. | |||
| Implementations MUST support ICV sizes of 8 octets and 16 octets. | Implementations MUST support ICV sizes of 8 octets and 16 octets. | |||
| Implementations MAY also support ICV 12 octets. | Implementations MAY also support ICV 12 octets. | |||
| 4. Nonce Format | 4. Nonce Format | |||
| Each packet conveys the IV that is necessary to construct the | Each packet conveys the IV that is necessary to construct the | |||
| sequence of counter blocks used by counter mode to generate the key | sequence of counter blocks used by counter mode to generate the key | |||
| stream. The AES counter block 16 octets. One octet is used for the | stream. The AES counter block 16 octets. One octet is used for the | |||
| CCM Flags, and 4 octets are used for the block counter, as specified | CCM Flags, and 4 octets are used for the block counter, as specified | |||
| skipping to change at page 7, line 48 ¶ | skipping to change at page 7, line 48 ¶ | |||
| The initialization vector (IV) and the integrity check value (ICV) is | The initialization vector (IV) and the integrity check value (ICV) is | |||
| the only sources of packet expansion. The IV always adds 8 octets to | the only sources of packet expansion. The IV always adds 8 octets to | |||
| the front of the payload. The ICV is added at the end of the | the front of the payload. The ICV is added at the end of the | |||
| payload, and the CCM parameter M determines the size of the ICV. | payload, and the CCM parameter M determines the size of the ICV. | |||
| Implementations MUST support M values of 8 octets and 16 octets, and | Implementations MUST support M values of 8 octets and 16 octets, and | |||
| implementations MAY also support an M value of 12 octets. | implementations MAY also support an M value of 12 octets. | |||
| 7. IKE Conventions | 7. IKE Conventions | |||
| This section describes the conventions used to generate keying | This section describes the conventions used to generate keying | |||
| material and salt values for use with AES-CCM using the Internet Key | material and salt values for use with AES CCM using the Internet Key | |||
| Exchange (IKE) [IKE] protocol. The identifiers and attributes needed | Exchange (IKE) [IKE] protocol. The identifiers and attributes needed | |||
| to negotiate a security association which uses AES-CCM are also | to negotiate a security association which uses AES CCM are also | |||
| defined. | defined. | |||
| 7.1. Keying Material and Salt Values | 7.1. Keying Material and Salt Values | |||
| As previously described, implementations MUST use fresh keys with | As previously described, implementations MUST use fresh keys with AES | |||
| AES-CCM. IKE can be used to establish fresh keys. This section | CCM. IKE can be used to establish fresh keys. This section | |||
| describes the conventions for obtaining the unpredictable salt value | describes the conventions for obtaining the unpredictable salt value | |||
| for use in the nonce from IKE. Note that this convention provides a | for use in the nonce from IKE. Note that this convention provides a | |||
| salt value that is secret as well as unpredictable. | salt value that is secret as well as unpredictable. | |||
| IKE makes use of a pseudo-random function (PRF) to derive keying | IKE makes use of a pseudo-random function (PRF) to derive keying | |||
| material. The PRF is used iteratively to derive keying material of | material. The PRF is used iteratively to derive keying material of | |||
| arbitrary size, called KEYMAT. Keying material is extracted from the | arbitrary size, called KEYMAT. Keying material is extracted from the | |||
| output string without regard to boundaries. | output string without regard to boundaries. | |||
| The size of KEYMAT MUST be three octets longer than is needed for the | The size of KEYMAT MUST be three octets longer than is needed for the | |||
| associated AES key. The keying material is used as follows: | associated AES key. The keying material is used as follows: | |||
| AES-CCM with a 128 bit key | AES CCM with a 128 bit key | |||
| The KEYMAT requested for each AES-CCM key is 19 octets. The | The KEYMAT requested for each AES CCM key is 19 octets. The | |||
| first 16 octets are the 128-bit AES key, and the remaining | first 16 octets are the 128-bit AES key, and the remaining | |||
| three octets are used as the salt value in the counter block. | three octets are used as the salt value in the counter block. | |||
| AES-CCM with a 192 bit key | AES CCM with a 192 bit key | |||
| The KEYMAT requested for each AES-CCM key is 27 octets. The | The KEYMAT requested for each AES CCM key is 27 octets. The | |||
| first 24 octets are the 192-bit AES key, and the remaining | first 24 octets are the 192-bit AES key, and the remaining | |||
| three octets are used as the salt value in the counter block. | three octets are used as the salt value in the counter block. | |||
| AES-CCM with a 256 bit key | AES CCM with a 256 bit key | |||
| The KEYMAT requested for each AES-CCM key is 35 octets. The | The KEYMAT requested for each AES CCM key is 35 octets. The | |||
| first 32 octets are the 256-bit AES key, and the remaining | first 32 octets are the 256-bit AES key, and the remaining | |||
| three octets are used as the salt value in the counter block. | three octets are used as the salt value in the counter block. | |||
| 7.2. Phase 1 Identifier | 7.2. Phase 1 Identifier | |||
| This document does not specify the conventions for using AES-CCM for | This document does not specify the conventions for using AES CCM for | |||
| IKE Phase 1 negotiations. For AES-CCM to be used in this manner, a | IKE Phase 1 negotiations. For AES CCM to be used in this manner, a | |||
| separate specification is needed, and an Encryption Algorithm | separate specification is needed, and an Encryption Algorithm | |||
| Identifier needs to be assigned. | Identifier needs to be assigned. | |||
| 7.3. Phase 2 Identifier | 7.3. Phase 2 Identifier | |||
| For IKE Phase 2 negotiations, IANA has assigned three ESP Transform | For IKE Phase 2 negotiations, IANA has assigned three ESP Transform | |||
| Identifiers for AES-CCM with an explicit IV: | Identifiers for AES CCM with an explicit IV: | |||
| <TBD1> for AES-CCM with an 8 octet ICV; | <TBD1> for AES CCM with an 8 octet ICV; | |||
| <TBD2> for AES-CCM with a 12 octet ICV; and | <TBD2> for AES CCM with a 12 octet ICV; and | |||
| <TBD3> for AES-CCM with a 16 octet ICV. | <TBD3> for AES CCM with a 16 octet ICV. | |||
| 7.4. Key Length Attribute | 7.4. Key Length Attribute | |||
| Since the AES supports three key lengths, the Key Length attribute | Since the AES supports three key lengths, the Key Length attribute | |||
| MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length | MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length | |||
| attribute MUST have a value of 128, 192, or 256. | attribute MUST have a value of 128, 192, or 256. | |||
| 8. Test Vectors | 8. Test Vectors | |||
| Section 8 of [CCM] provides test vectors that will assist | Section 8 of [CCM] provides test vectors that will assist | |||
| implementers with AES-CCM mode. | implementers with AES CCM mode. | |||
| 9. Security Considerations | 9. Security Considerations | |||
| AES-CCM employs counter (CTR) mode for confidentiality. If a counter | AES CCM employs counter (CTR) mode for confidentiality. If a counter | |||
| value is ever used for more that one packet with the same key, then | value is ever used for more that one packet with the same key, then | |||
| the same key stream will be used to encrypt both packets, and the | the same key stream will be used to encrypt both packets, and the | |||
| confidentiality guarantees are voided. | confidentiality guarantees are voided. | |||
| What happens if the encryptor XORs the same key stream with two | What happens if the encryptor XORs the same key stream with two | |||
| different packet plaintexts? Suppose two packets are defined by two | different packet plaintexts? Suppose two packets are defined by two | |||
| plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are | plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are | |||
| encrypted with key stream K1, K2, K3. The two corresponding | encrypted with key stream K1, K2, K3. The two corresponding | |||
| ciphertexts are: | ciphertexts are: | |||
| skipping to change at page 9, line 39 ¶ | skipping to change at page 9, line 39 ¶ | |||
| If both of these two ciphertext streams are exposed to an attacker, | If both of these two ciphertext streams are exposed to an attacker, | |||
| then a catastrophic failure of confidentiality results, since: | then a catastrophic failure of confidentiality results, since: | |||
| (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1 | (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1 | |||
| (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2 | (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2 | |||
| (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3 | (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3 | |||
| Once the attacker obtains the two plaintexts XORed together, it is | Once the attacker obtains the two plaintexts XORed together, it is | |||
| relatively straightforward to separate them. Thus, using any stream | relatively straightforward to separate them. Thus, using any stream | |||
| cipher, including AES-CTR, to encrypt two plaintexts under the same | cipher, including AES CTR, to encrypt two plaintexts under the same | |||
| key stream leaks the plaintext. | key stream leaks the plaintext. | |||
| Therefore, AES-CCM should not be used with statically configured | Therefore, AES CCM should not be used with statically configured | |||
| keys. Extraordinary measures would be needed to prevent the reuse of | keys. Extraordinary measures would be needed to prevent the reuse of | |||
| a counter block value with the static key across power cycles. To be | a counter block value with the static key across power cycles. To be | |||
| safe, implementations MUST use fresh keys with AES-CCM. The Internet | safe, implementations MUST use fresh keys with AES CCM. The Internet | |||
| Key Exchange (IKE) [IKE] protocol can be used to establish fresh | Key Exchange (IKE) [IKE] protocol can be used to establish fresh | |||
| keys. | keys. | |||
| When IKE is used to establish fresh keys between two peer entities, | When IKE is used to establish fresh keys between two peer entities, | |||
| separate keys are established for the two traffic flows. If a | separate keys are established for the two traffic flows. If a | |||
| different mechanism is used to establish fresh keys, one that | different mechanism is used to establish fresh keys, one that | |||
| establishes only a single key to encrypt packets, then there is a | establishes only a single key to encrypt packets, then there is a | |||
| high probability that the peers will select the same IV values for | high probability that the peers will select the same IV values for | |||
| some packets. Thus, to avoid counter block collisions, ESP | some packets. Thus, to avoid counter block collisions, ESP | |||
| implementations that permit use of the same key for encrypting and | implementations that permit use of the same key for encrypting and | |||
| skipping to change at page 11, line 24 ¶ | skipping to change at page 11, line 24 ¶ | |||
| 6. By decoupling the IV and the sequence number, architectures | 6. By decoupling the IV and the sequence number, architectures | |||
| where the sequence number assignment is performed outside the | where the sequence number assignment is performed outside the | |||
| assurance boundary are accommodated. | assurance boundary are accommodated. | |||
| The use of an explicit IV field directly follows from the decoupling | The use of an explicit IV field directly follows from the decoupling | |||
| of the sequence number and the per-packet counter block value. The | of the sequence number and the per-packet counter block value. The | |||
| additional overhead (64 bits for the IV field) is acceptable. This | additional overhead (64 bits for the IV field) is acceptable. This | |||
| overhead is significantly less overhead associated with Cipher Block | overhead is significantly less overhead associated with Cipher Block | |||
| Chaining (CBC) mode. As normally employed, CBC requires a full block | Chaining (CBC) mode. As normally employed, CBC requires a full block | |||
| for the IV and, on average, half of a block for padding. AES-CCM | for the IV and, on average, half of a block for padding. AES CCM | |||
| confidentiality processing with an explicit IV has about one-third of | confidentiality processing with an explicit IV has about one-third of | |||
| the overhead as AES-CBC, and the overhead is constant for each | the overhead as AES CBC, and the overhead is constant for each | |||
| packet. | packet. | |||
| 11. IANA Considerations | 11. IANA Considerations | |||
| IANA has assigned nine ESP transform numbers for use with AES-CCM | IANA has assigned nine ESP transform numbers for use with AES CCM | |||
| with an explicit IV: | with an explicit IV: | |||
| <TBD1> for AES-CCM with an 8 octet ICV; | <TBD1> for AES CCM with an 8 octet ICV; | |||
| <TBD2> for AES-CCM with a 12 octet ICV; and | <TBD2> for AES CCM with a 12 octet ICV; and | |||
| <TBD3> for AES-CCM with a 16 octet ICV. | <TBD3> for AES CCM with a 16 octet ICV. | |||
| 12. Acknowledgements | 12. Acknowledgements | |||
| Doug Whiting and Niels Ferguson worked with me to develop CCM mode. | Doug Whiting and Niels Ferguson worked with me to develop CCM mode. | |||
| We developed CCM mode as part of the IEEE 802.11i security effort. | We developed CCM mode as part of the IEEE 802.11i security effort. | |||
| One of the most attractive aspects of CCM mode is that it is | One of the most attractive aspects of CCM mode is that it is | |||
| unencumbered by patents. I acknowledge the companies that supported | unencumbered by patents. I acknowledge the companies that supported | |||
| the development of an unencumbered authenticated encryption mode (in | the development of an unencumbered authenticated encryption mode (in | |||
| alphabetical order): | alphabetical order): | |||
| End of changes. 32 change blocks. | ||||
| 44 lines changed or deleted | 45 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||