rfc9227v2.txt | rfc9227.txt | |||
---|---|---|---|---|
skipping to change at line 288 ¶ | skipping to change at line 288 ¶ | |||
significant bit of the first octet of the nonce (represented as an | significant bit of the first octet of the nonce (represented as an | |||
octet string) is dropped, making the effective size of the nonce | octet string) is dropped, making the effective size of the nonce | |||
equal to n-1 bits. Note that the dropped bit is a part of the "zero" | equal to n-1 bits. Note that the dropped bit is a part of the "zero" | |||
field (see Figures 2 and 3), which is always set to 0, so no | field (see Figures 2 and 3), which is always set to 0, so no | |||
information is lost when it is dropped. | information is lost when it is dropped. | |||
4.3.1. MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher | 4.3.1. MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher | |||
For transforms based on the "Kuznyechik" cipher | For transforms based on the "Kuznyechik" cipher | |||
(ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the | (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the | |||
ICN consists of a "zero" octet, a 24-bit message counter, and a | ICN consists of a "zero" octet; a 24-bit message counter; and a | |||
96-bit secret salt, that is fixed for the SA and is not transmitted. | 96-bit secret salt, which is fixed for the SA and is not transmitted. | |||
1 2 3 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| zero | pnum | | | zero | pnum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| salt | | | salt | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at line 311 ¶ | skipping to change at line 311 ¶ | |||
Figure 2: Nonce Format for Transforms Based on the "Kuznyechik" | Figure 2: Nonce Format for Transforms Based on the "Kuznyechik" | |||
Cipher | Cipher | |||
where: | where: | |||
zero (1 octet): set to 0 | zero (1 octet): set to 0 | |||
pnum (3 octets): the counter for the messages protected by the given | pnum (3 octets): the counter for the messages protected by the given | |||
leaf key; this field MUST be equal to the pnum field in the IV | leaf key; this field MUST be equal to the pnum field in the IV | |||
salt (12 octets): secret salt | salt (12 octets): secret salt. The salt is a string of bits that | |||
are formed when the SA is created (see Section 4.4 for details). | ||||
The salt does not change during the SA's lifetime and is not | ||||
transmitted on the wire. Every SA will have its own salt. | ||||
4.3.2. MGM Nonce Format for Transforms Based on the "Magma" Cipher | 4.3.2. MGM Nonce Format for Transforms Based on the "Magma" Cipher | |||
For transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and | For transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and | |||
ENCR_MAGMA_MGM_MAC_KTREE), the ICN consists of a "zero" octet, a | ENCR_MAGMA_MGM_MAC_KTREE), the ICN consists of a "zero" octet; a | |||
24-bit message counter, and a 32-bit secret salt, that is fixed for | 24-bit message counter; and a 32-bit secret salt, which is fixed for | |||
the SA and is not transmitted. | the SA and is not transmitted. | |||
1 2 3 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| zero | pnum | | | zero | pnum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| salt | | | salt | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: Nonce Format for Transforms Based on the "Magma" Cipher | Figure 3: Nonce Format for Transforms Based on the "Magma" Cipher | |||
where: | where: | |||
zero (1 octet): set to 0 | zero (1 octet): set to 0 | |||
pnum (3 octets): the counter for the messages protected by the given | pnum (3 octets): the counter for the messages protected by the given | |||
leaf key; this field MUST be equal to the pnum field in the IV | leaf key; this field MUST be equal to the pnum field in the IV | |||
salt (4 octets): secret salt | salt (4 octets): secret salt. The salt is a string of bits that are | |||
formed when the SA is created (see Section 4.4 for details). The | ||||
salt does not change during the SA's lifetime and is not | ||||
transmitted on the wire. Every SA will have its own salt. | ||||
4.4. Keying Material | 4.4. Keying Material | |||
We'll call a string of bits that is used to initialize the transforms | We'll call a string of bits that is used to initialize the transforms | |||
defined in this specification a "transform key". The transform key | defined in this specification a "transform key". The transform key | |||
is a composite entity consisting of the root key for the tree and the | is a composite entity consisting of the root key for the tree and the | |||
secret salt. | secret salt. | |||
The transform key for the ENCR_KUZNYECHIK_MGM_KTREE and | The transform key for the ENCR_KUZNYECHIK_MGM_KTREE and | |||
ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits (44 | ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits (44 | |||
skipping to change at line 473 ¶ | skipping to change at line 479 ¶ | |||
| Padding (0-255 bytes) | | | Padding (0-255 bytes) | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Pad Length | Next Header | | | | Pad Length | Next Header | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 7: AAD for Authentication-Only Transforms with 64-Bit ESN | Figure 7: AAD for Authentication-Only Transforms with 64-Bit ESN | |||
4.7.2. IKEv2 AAD | 4.7.2. IKEv2 AAD | |||
For IKEv2, the AAD consists of the IKEv2 Header, any unencrypted | For IKEv2, the AAD consists of the IKEv2 Header, any unencrypted | |||
payloads following it (if present), and the Encrypted payload header | payloads following it (if present), and either the Encrypted payload | |||
(Section 3.14 of [RFC7296]) (or the Encrypted Fragment payload; see | header (Section 3.14 of [RFC7296]) or the Encrypted Fragment payload | |||
Section 2.5 of [RFC7383]). The AAD is constructed similarly to the | (Section 2.5 of [RFC7383]), depending on whether IKE fragmentation is | |||
AAD in [RFC5282]. | used. The AAD is constructed similarly to the AAD in [RFC5282]. | |||
1 2 3 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ IKEv2 Header ~ | ~ IKEv2 Header ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ Unencrypted IKE Payloads ~ | ~ Unencrypted IKE Payloads ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Next Payload |C| RESERVED | Payload Length | | | Next Payload |C| RESERVED | Payload Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
End of changes. 5 change blocks. | ||||
10 lines changed or deleted | 16 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/ |