draft-ietf-ipsecme-rfc4307bis-18v3.original   draft-ietf-ipsecme-rfc4307bis-18v3.txt 
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Updating Algorithm Implementation Requirements and Usage 1.2. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Updating Algorithm Requirement Levels . . . . . . . . . . 4 1.3. Updating Algorithm Requirement Levels . . . . . . . . . . 4
1.4. Document Audience . . . . . . . . . . . . . . . . . . . . 5 1.4. Document Audience . . . . . . . . . . . . . . . . . . . . 5
2. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5 2. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5
2.1. Type 1 - IKEv2 Encryption Algorithm Transforms . . . . . 5 2.1. Type 1 - IKEv2 Encryption Algorithm Transforms . . . . . 5
2.2. Type 2 - IKEv2 Pseudo-random Function Transforms . . . . 7 2.2. Type 2 - IKEv2 Pseudo-random Function Transforms . . . . 7
2.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 8 2.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 8
2.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 9 2.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 9
2.5. Summary of Changes from RFC 4307 . . . . . . . . . . . . 10 2.5. Summary of Changes from RFC 4307 . . . . . . . . . . . . 11
3. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 11 3. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 11
3.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 11 3.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 12
3.1.1. Recommendations for RSA key length . . . . . . . . . 12 3.1.1. Recommendations for RSA key length . . . . . . . . . 12
3.2. Digital Signature Recommendations . . . . . . . . . . . . 12 3.2. Digital Signature Recommendations . . . . . . . . . . . . 13
4. Algorithms for Internet of Things . . . . . . . . . . . . . . 13 4. Algorithms for Internet of Things . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Internet Key Exchange (IKE) protocol [RFC7296] is used to The Internet Key Exchange (IKE) protocol [RFC7296] is used to
negotiate the parameters of the IPsec SA, such as the encryption and negotiate the parameters of the IPsec SA, such as the encryption and
authentication algorithms and the keys for the protected authentication algorithms and the keys for the protected
communications between the two endpoints. The IKE protocol itself is communications between the two endpoints. The IKE protocol itself is
also protected by cryptographic algorithms which are negotiated also protected by cryptographic algorithms which are negotiated
between the two endpoints using IKE. Different implementations of between the two endpoints using IKE. Different implementations of
IKE may negotiate different algorithms based on their individual IKE may negotiate different algorithms based on their individual
skipping to change at page 6, line 16 skipping to change at page 6, line 16
| Name | Status | AEAD? | Comment | | Name | Status | AEAD? | Comment |
+------------------------+----------+-------+---------+ +------------------------+----------+-------+---------+
| ENCR_AES_CBC | MUST | No | (1) | | ENCR_AES_CBC | MUST | No | (1) |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | |
| ENCR_AES_GCM_16 | SHOULD | Yes | (1) | | ENCR_AES_GCM_16 | SHOULD | Yes | (1) |
| ENCR_AES_CCM_8 | SHOULD | Yes | (IoT) | | ENCR_AES_CCM_8 | SHOULD | Yes | (IoT) |
| ENCR_3DES | MAY | No | | | ENCR_3DES | MAY | No | |
| ENCR_DES | MUST NOT | No | | | ENCR_DES | MUST NOT | No | |
+------------------------+----------+-------+---------+ +------------------------+----------+-------+---------+
(1) - This requirement level is for 128-bit and 256-bit keys. (1) - This requirement level is for 128-bit and 256-bit keys.
192-bit keys remain at MAY level. (IoT) - This requirement is for
interoperability with IoT. Only 128-bit keys are at SHOULD level. 192-bit keys remain at MAY level. (IoT) - This requirement is
192-bit and 256-bit remain at the MAY level. for
interoperability with IoT. Only 128-bit keys are at
SHOULD level. 192-bit and 256-bit remain at the MAY
level.
ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and MAY for ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and MAY for
256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY 256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY
level. ENCR_AES_CBC is the only shared mandatory-to-implement level. ENCR_AES_CBC is the only shared mandatory-to-implement
algorithm with RFC4307 and as a result it is necessary for algorithm with RFC4307 and as a result it is necessary for
interoperability with IKEv2 implementation compatible with RFC4307. interoperability with IKEv2 implementation compatible with RFC4307.
ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of
RFC4307. It has been recommended by the Crypto Forum Research Group RFC4307. It has been recommended by the Crypto Forum Research Group
(CFRG) of the IRTF as an alternative to AES-CBC and AES-GCM. It is (CFRG) of the IRTF as an alternative to AES-CBC and AES-GCM. It is
skipping to change at page 9, line 31 skipping to change at page 10, line 5
exchange provides keys for the session. If an attacker can retrieve exchange provides keys for the session. If an attacker can retrieve
one of the private numbers (a or b) and the complementary public one of the private numbers (a or b) and the complementary public
value (g**b or g**a), then the attacker can compute the secret and value (g**b or g**a), then the attacker can compute the secret and
the keys used and decrypt the exchange and IPsec SA created inside the keys used and decrypt the exchange and IPsec SA created inside
the IKEv2 SA. Such an attack can be performed off-line on a the IKEv2 SA. Such an attack can be performed off-line on a
previously recorded communication, years after the communication previously recorded communication, years after the communication
happened. This differs from attacks that need to be executed during happened. This differs from attacks that need to be executed during
the authentication which must be performed online and in near real- the authentication which must be performed online and in near real-
time. time.
+--------+---------------------------------------------+------------+ +--------+----------------------------------------+------------+
| Number | Description | Status | | Number | Description | Status |
+--------+---------------------------------------------+------------+ +--------+----------------------------------------+------------+
| 14 | 2048-bit MODP Group | MUST | | 14 | 2048-bit MODP Group | MUST |
| 19 | 256-bit random ECP group | SHOULD | | 19 | 256-bit random ECP group | SHOULD |
| 5 | 1536-bit MODP Group | SHOULD NOT | | 5 | 1536-bit MODP Group | SHOULD NOT |
| 2 | 1024-bit MODP Group | SHOULD NOT | | 2 | 1024-bit MODP Group | SHOULD NOT |
| 1 | 768-bit MODP Group | MUST NOT | | 1 | 768-bit MODP Group | MUST NOT |
| 22 | 1024-bit MODP Group with 160-bit Prime | MUST NOT | | 22 | 1024-bit MODP Group with 160-bit Prime | MUST NOT |
| | Order Subgroup | | | | Order Subgroup | |
| 23 | 2048-bit MODP Group with 224-bit Prime | SHOULD NOT | | 23 | 2048-bit MODP Group with 224-bit Prime | SHOULD NOT |
| | Order Subgroup | | | | Order Subgroup | |
| 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT | | 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT |
| | Order Subgroup | | | | Order Subgroup | |
+--------+---------------------------------------------+------------+ +--------+----------------------------------------+------------+
Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 to Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 to
MUST as a replacement for 1024-bit MODP Group. Group 14 is widely MUST as a replacement for 1024-bit MODP Group. Group 14 is widely
implemented and considered secure. implemented and considered secure.
Group 19 or 256-bit random ECP group was not specified in RFC4307, as Group 19 or 256-bit random ECP group was not specified in RFC4307, as
this group was not defined at that time. Group 19 is widely this group was not defined at that time. Group 19 is widely
implemented and considered secure and therefore has been promoted to implemented and considered secure and therefore has been promoted to
the SHOULD level. the SHOULD level.
skipping to change at page 11, line 4 skipping to change at page 11, line 17
Since Group 23 and 24 have small subgroups, the checks specified in Since Group 23 and 24 have small subgroups, the checks specified in
"Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section 2.2 "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section 2.2
first bullet point MUST be done when these groups are used. first bullet point MUST be done when these groups are used.
2.5. Summary of Changes from RFC 4307 2.5. Summary of Changes from RFC 4307
The following table summarizes the changes from RFC 4307. The following table summarizes the changes from RFC 4307.
RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE
TABLE BELOW WITH THE NUMBER OF THIS RFC TABLE BELOW WITH THE NUMBER OF THIS RFC
+---------------------+------------------+------------+ +---------------------+------------------+------------+
| Algorithm | RFC 4307 | RFC XXXX | | Algorithm | RFC 4307 | RFC XXXX |
+---------------------+------------------+------------+ +---------------------+------------------+------------+
| ENCR_3DES | MUST- | MAY | | ENCR_3DES | MUST- | MAY |
| ENCR_NULL | MUST NOT[errata] | MUST NOT | | ENCR_NULL | MUST NOT[errata] | MUST NOT |
| ENCR_AES_CBC | SHOULD+ | MUST | | ENCR_AES_CBC | SHOULD+ | MUST |
| ENCR_AES_CTR | SHOULD | (*) | | ENCR_AES_CTR | SHOULD | (*) |
| PRF_HMAC_MD5 | MAY | MUST NOT | | PRF_HMAC_MD5 | MAY | MUST NOT |
| PRF_HMAC_SHA1 | MUST | MUST- | | PRF_HMAC_SHA1 | MUST | MUST- |
| PRF_AES128_XCBC | SHOULD+ | SHOULD | | PRF_AES128_XCBC | SHOULD+ | SHOULD |
| AUTH_HMAC_MD5_96 | MAY | MUST NOT | | AUTH_HMAC_MD5_96 | MAY | MUST NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- | | AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_XCBC_96 | SHOULD+ | SHOULD | | AUTH_AES_XCBC_96 | SHOULD+ | SHOULD |
| Group 2 (1024-bit) | MUST- | SHOULD NOT | | Group 2 (1024-bit) | MUST- | SHOULD NOT |
| Group 14 (2048-bit) | SHOULD+ | MUST | | Group 14 (2048-bit) | SHOULD+ | MUST |
+---------------------+------------------+------------+ +---------------------+------------------+------------+
(*) This algorithm is not mentioned in the above sections, so it (*) This algorithm is not mentioned in the above sections, so it
defaults to MAY. defaults to MAY.
3. IKEv2 Authentication 3. IKEv2 Authentication
IKEv2 authentication may involve a signatures verification. IKEv2 authentication may involve a signatures verification.
Signatures may be used to validate a certificate or to check the Signatures may be used to validate a certificate or to check the
signature of the AUTH value. Cryptographic recommendations regarding signature of the AUTH value. Cryptographic recommendations regarding
certificate validation are out of scope of this document. What is certificate validation are out of scope of this document. What is
mandatory to implement is provided by the PKIX Community. This mandatory to implement is provided by the PKIX Community. This
document is mostly concerned with signature verification and document is mostly concerned with signature verification and
generation for the authentication. generation for the authentication.
skipping to change at page 13, line 34 skipping to change at page 13, line 46
+------------------------------------+----------+---------+ +------------------------------------+----------+---------+
| RSASSA-PSS with SHA-256 | MUST | | | RSASSA-PSS with SHA-256 | MUST | |
| ecdsa-with-sha256 | SHOULD | | | ecdsa-with-sha256 | SHOULD | |
| sha1WithRSAEncryption | MUST NOT | | | sha1WithRSAEncryption | MUST NOT | |
| dsa-with-sha1 | MUST NOT | | | dsa-with-sha1 | MUST NOT | |
| ecdsa-with-sha1 | MUST NOT | | | ecdsa-with-sha1 | MUST NOT | |
| RSASSA-PSS with Empty Parameters | MUST NOT | (*) | | RSASSA-PSS with Empty Parameters | MUST NOT | (*) |
| RSASSA-PSS with Default Parameters | MUST NOT | (*) | | RSASSA-PSS with Default Parameters | MUST NOT | (*) |
+------------------------------------+----------+---------+ +------------------------------------+----------+---------+
(*) Empty or Default parameters means it is using SHA1, which is at (*) Empty or Default parameters means it is using SHA1, which is
level MUST NOT. at
level MUST NOT.
4. Algorithms for Internet of Things 4. Algorithms for Internet of Things
Some algorithms in this document are marked for use with the Internet Some algorithms in this document are marked for use with the Internet
of Things (IoT). There are several reasons why IoT devices prefer a of Things (IoT). There are several reasons why IoT devices prefer a
different set of algorithms from regular IKEv2 clients. IoT devices different set of algorithms from regular IKEv2 clients. IoT devices
are usually very constrained, meaning the memory size and CPU power are usually very constrained, meaning the memory size and CPU power
is so limited, that these clients only have resources to implement is so limited, that these clients only have resources to implement
and run one set of algorithms. For example, instead of implementing and run one set of algorithms. For example, instead of implementing
AES and SHA, these devices typically use AES_XCBC as integrity AES and SHA, these devices typically use AES_XCBC as integrity
skipping to change at page 17, line 22 skipping to change at page 17, line 40
DOI 10.17487/RFC5529, April 2009, DOI 10.17487/RFC5529, April 2009,
<http://www.rfc-editor.org/info/rfc5529>. <http://www.rfc-editor.org/info/rfc5529>.
[IKEV2-IANA] [IKEV2-IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters", "Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>. <http://www.iana.org/assignments/ikev2-parameters>.
[TRANSCRIPTION] [TRANSCRIPTION]
Bhargavan, K. and G. Leurent, "Transcript Collision Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH", Attacks: Breaking Authentication in TLS, IKE, and SSH",
NDSS , feb 2016. February 2016.
[IEEE-802-15-4] [IEEE-802-15-4]
"IEEE Standard for Low-Rate Wireless Personal Area "IEEE Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", IEEE Standard 802.15.4, 2015. Networks (WPANs)", IEEE Standard 802.15.4, 2015.
[IEEE-802-15-9] [IEEE-802-15-9]
"IEEE Recommended Practice for Transport of Key Management "IEEE Recommended Practice for Transport of Key Management
Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016. Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016.
Authors' Addresses Authors' Addresses
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim st. 5 Hasolelim st.
Tel Aviv 6789735 Tel Aviv 6789735
Israel Israel
EMail: ynir.ietf@gmail.com Email: ynir.ietf@gmail.com
Tero Kivinen Tero Kivinen
INSIDE Secure INSIDE Secure
Eerikinkatu 28 Eerikinkatu 28
HELSINKI FI-00180 HELSINKI FI-00180
FI FI
EMail: kivinen@iki.fi Email: kivinen@iki.fi
Paul Wouters Paul Wouters
Red Hat Red Hat
EMail: pwouters@redhat.com Email: pwouters@redhat.com
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Phone: +1 514-452-2160 Phone: +1 514-452-2160
EMail: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
 End of changes. 17 change blocks. 
47 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/