draft-ietf-ipsecme-rfc7321bis-02.txt   draft-ietf-ipsecme-rfc7321bis-03.txt 
Network Working Group D. Migault Network Working Group D. Migault
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Obsoletes: 7321 (if approved) Ericsson Obsoletes: 7321 (if approved) Ericsson
Intended status: Standards Track P. Wouters Intended status: Standards Track P. Wouters
Expires: August 03, 2017 Red Hat Expires: August 06, 2017 Red Hat
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
January 30, 2017 February 02, 2017
Cryptographic Algorithm Implementation Requirements and Usage Guidance Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH) for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-rfc7321bis-02 draft-ietf-ipsecme-rfc7321bis-03
Abstract Abstract
This document updates the Cryptographic Algorithm Implementation This document updates the Cryptographic Algorithm Implementation
Requirements for ESP and AH. The goal of these document is to enable Requirements for ESP and AH. The goal of these document is to enable
ESP and AH to benefit from cryptography that is up to date while ESP and AH to benefit from cryptography that is up to date while
making IPsec interoperable. making IPsec interoperable.
This document obsoletes RFC 7321 on the cryptographic recommendations This document obsoletes RFC 7321 on the cryptographic recommendations
only. only.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 03, 2017. This Internet-Draft will expire on August 06, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updating Algorithm Implementation Requirements and Usage 1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5 4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5
5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7 5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7
6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9
7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9 7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 36 skipping to change at page 3, line 36
mandatory. This document attempts to identify and introduce those mandatory. This document attempts to identify and introduce those
algorithms for future mandatory-to-implement status. There is no algorithms for future mandatory-to-implement status. There is no
guarantee that the algorithms in use today may become mandatory in guarantee that the algorithms in use today may become mandatory in
the future. Published algorithms are continuously subjected to the future. Published algorithms are continuously subjected to
cryptographic attack and may become too weak or could become cryptographic attack and may become too weak or could become
completely broken before this document is updated. completely broken before this document is updated.
This document only provides recommendations for the mandatory-to- This document only provides recommendations for the mandatory-to-
implement algorithms and algorithms too weak that are recommended not implement algorithms and algorithms too weak that are recommended not
to be implemented. As a result, any algorithm listed at the IPsec to be implemented. As a result, any algorithm listed at the IPsec
IANA registry not mentioned in this document MAY be implemented. As IANA registry not mentioned in this document MAY be implemented. It
[RFC7321] omitted most of the algorithms mentioned by the IPsec IANA is expected that this document will be updated over time and next
repository, which makes it difficult to define whether non mentioned versions will only mention algorithms which status has evolved. For
algorithms are optional to implement or must not be implemented as clarification when an algorithm has been mentioned in [RFC7321], this
they are too weak. This document provides explicit guidance for all document states explicitly the update of the status.
of them. It is expected that this document will be updated over time
and next versions will only mention algorithms which status has
evolved. For clarification when an algorithm has been mentioned in
[RFC7321], this document states explicitly the update of the status.
Although this document updates the algorithms to keep the AH/ESP Although this document updates the algorithms to keep the AH/ESP
communication secure over time, it also aims at providing communication secure over time, it also aims at providing
recommendations so that AH/ESP implementations remain interoperable. recommendations so that AH/ESP implementations remain interoperable.
AH/ESP interoperability is addressed by an incremental introduction AH/ESP interoperability is addressed by an incremental introduction
or deprecation of algorithms. In addition, this document also or deprecation of algorithms. In addition, this document also
considers the new use cases for AH/ESP deployment, such as Internet considers the new use cases for AH/ESP deployment, such as Internet
of Things (IoT). of Things (IoT).
It is expected that deprecation of an algorithm is performed It is expected that deprecation of an algorithm is performed
skipping to change at page 4, line 19 skipping to change at page 4, line 15
downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. downgraded from MUST to MUST- or SHOULD, instead of MUST NOT.
Similarly, an algorithm that has not been mentioned as mandatory-to- Similarly, an algorithm that has not been mentioned as mandatory-to-
implement is expected to be introduced with a SHOULD instead of a implement is expected to be introduced with a SHOULD instead of a
MUST. MUST.
The current trend toward Internet of Things and its adoption of AH/ The current trend toward Internet of Things and its adoption of AH/
ESP requires this specific use case to be taken into account as well. ESP requires this specific use case to be taken into account as well.
IoT devices are resource constrained devices and their choice of IoT devices are resource constrained devices and their choice of
algorithms are motivated by minimizing the footprint of the code, the algorithms are motivated by minimizing the footprint of the code, the
computation effort and the size of the messages to send. This computation effort and the size of the messages to send. This
document indicates "[IoT]" when a specified algorithm is specifically document indicates "(IoT)" when a specified algorithm is specifically
listed for IoT devices. Requirement levels that are marked as "IoT" listed for IoT devices. Requirement levels that are marked as "IoT"
apply to IoT devices and to server-side implementations that might apply to IoT devices and to server-side implementations that might
presumably need to interoperate with them, including any general- presumably need to interoperate with them, including any general-
purpose VPN gateways. purpose VPN gateways.
1.3. Document Audience 1.3. Document Audience
The recommendations of this document mostly target AH/ESP The recommendations of this document mostly target AH/ESP
implementers as implementations need to meet both high security implementers as implementations need to meet both high security
expectations as well as high interoperability between various vendors expectations as well as high interoperability between various vendors
skipping to change at page 5, line 4 skipping to change at page 5, line 6
IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is
deprecated and the recommendations of this document must not be deprecated and the recommendations of this document must not be
considered for IKEv1, nor IKEv1 parameters be considered by this considered for IKEv1, nor IKEv1 parameters be considered by this
document. document.
The IANA registry for Internet Key Exchange Version 2 (IKEv2) The IANA registry for Internet Key Exchange Version 2 (IKEv2)
Parameters contains some entries that are not for use with ESP or AH. Parameters contains some entries that are not for use with ESP or AH.
This document does not modify the status of those algorithms. This document does not modify the status of those algorithms.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Following [RFC4835], we define some additional key words: We define some additional terms here:
MUST- This term means the same as MUST. However, we expect that at SHOULD+ This term means the same as SHOULD. However, it is likely
some point in the future this algorithm will no longer be a MUST. that an algorithm marked as SHOULD+ will be promoted at some
SHOULD+ This term means the same as SHOULD. However, it is likely future time to be a MUST.
that an algorithm marked as SHOULD+ will be promoted at some SHOULD- This term means the same as SHOULD. However, an algorithm
future time to be a MUST. marked as SHOULD- may be deprecated to a MAY in a future
version of this document.
MUST- This term means the same as MUST. However, we expect at some
point that this algorithm will no longer be a MUST in a
future document. Although its status will be determined at a
later time, it is reasonable to expect that if a future
revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD-
level.
IoT stands for Internet of Things.
Table 1
3. Manual Keying 3. Manual Keying
Manual Keying is not to be used as it is inherently dangerous. Manual Keying is not to be used as it is inherently dangerous.
Without any keying protocol, it does not offer Perfect Forward Without any keying protocol, it does not offer Perfect Forward
Secrecy ("PFS") protection. Deployments tend to never be Secrecy ("PFS") protection. Deployments tend to never be
reconfigured with fresh session keys. It also fails to scale and reconfigured with fresh session keys. It also fails to scale and
keeping SPI's unique amongst many servers is impractical. This keeping SPI's unique amongst many servers is impractical. This
document was written for deploying ESP/AH using IKE (RFC7298) and document was written for deploying ESP/AH using IKE ([RFC7296]) and
assumes that keying happens using IKEv2. assumes that keying happens using IKEv2.
If manual keying is used anyway, ENCR_AES_CBC MUST be used, and If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
used as these algorithms require IKE. used as these algorithms require IKE.
4. ESP Encryption Algorithms 4. ESP Encryption Algorithms
+-------------------------+------------+---------+---------------+ +-------------------------+-------------+---------+--------------+
| Name | Status | AEAD | Comment | | Name | Status | AEAD | Comment |
+-------------------------+------------+---------+---------------+ +-------------------------+-------------+---------+--------------+
| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
| ENCR_DES | MUST NOT | No | [RFC2405] | | ENCR_DES | MUST NOT | No | [RFC2405] |
| ENCR_3DES | SHOULD NOT | No | [RFC2451] | | ENCR_3DES | SHOULD NOT | No | [RFC2451] |
| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
| ENCR_NULL | MUST | No | [RFC2410] | | ENCR_NULL | MUST | No | [RFC2410] |
| ENCR_AES_CBC | MUST | No | [RFC3602][1] | | ENCR_AES_CBC | MUST | No | [RFC3602][1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] | | ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+-------------------------+------------+---------+---------------+ +-------------------------+-------------+---------+--------------+
[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 192-bit keys remain at MAY level. (IoT) - This requirement is for
interoperability with IoT. Only 128-bit keys are at MUST level. interoperability with IoT. Only 128-bit keys are at the given level.
192-bit and 256-bit keys are at the MAY level.
Table 1 Table 2
IPsec sessions may have very long life time, and carry multiple IPsec sessions may have very long life time, and carry multiple
packets, so there is a need to move to 256-bit keys in the long term. packets, so there is a need to move to 256-bit keys in the long term.
For that purpose the requirement level for 128 bit keys and 256 bit For that purpose the requirement level for 128 bit keys and 256 bit
keys are at MUST (when applicable). In that sense 256 bit keys keys are at MUST (when applicable). In that sense 256 bit keys
status has been raised from MAY in RFC7321 to MUST. status has been raised from MAY in RFC7321 to MUST.
IANA has allocated codes for cryptographic algorithms that have not IANA has allocated codes for cryptographic algorithms that have not
been specified by the IETF. Such algorithms are noted as been specified by the IETF. Such algorithms are noted as
UNSPECIFIED. Usually, the use of theses algorithms is limited to UNSPECIFIED. Usually, the use of theses algorithms is limited to
skipping to change at page 7, line 20 skipping to change at page 7, line 29
devices. As this case is not a general use case for VPNs, its status devices. As this case is not a general use case for VPNs, its status
is expected to remain as SHOULD. is expected to remain as SHOULD.
ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order
to favor the use of authenticated encryption and AEAD algorithms. to favor the use of authenticated encryption and AEAD algorithms.
ENCR_AES_GCM_16 has been widely implemented for ESP due to its ENCR_AES_GCM_16 has been widely implemented for ESP due to its
increased performance and key longevity compared to ENCR_AES_CBC. increased performance and key longevity compared to ENCR_AES_CBC.
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
RFC7321. It has been recommended by the CRFG and others as an RFC7321. It has been recommended by the CRFG and others as an
alternative to ENCR_AES_XCBC and ENCR_AES_GCM_*. It is also being alternative to AES-CBC and AES-GCM. It is also being standardized
standardized for ESP for the same reasons. At the time of writing, for ESP for the same reasons. At the time of writing, there are not
there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to
be able to introduce it at the SHOULD+ level. Its status has been introduce it at the SHOULD+ level. Its status has been set to SHOULD
set to SHOULD and is expected to become MUST in the long term. and is expected to become MUST in the long term.
5. ESP and AH Authentication Algorithms 5. ESP and AH Authentication Algorithms
Encryption without authentication MUST NOT be used. As a result, Encryption without authentication MUST NOT be used. As a result,
authentication algorithm recommendations in this section are authentication algorithm recommendations in this section are
targeting two types of communications: Firstly authenticated only targeting two types of communications: Firstly authenticated only
communications without encryption. Such communications can be ESP communications without encryption. Such communications can be ESP
with NULL encryption or AH communications. Secondly, communications with NULL encryption or AH communications. Secondly, communications
that are encrypted with non AEAD encryption algorithms mentioned that are encrypted with non AEAD encryption algorithms mentioned
above. In this case, they MUST be combined with an authentication above. In this case, they MUST be combined with an authentication
skipping to change at page 7, line 47 skipping to change at page 8, line 7
+----------------------------+-------------+------------------------+ +----------------------------+-------------+------------------------+
| Name | Status | Comment | | Name | Status | Comment |
+----------------------------+-------------+------------------------+ +----------------------------+-------------+------------------------+
| AUTH_NONE | MUST / MUST | [RFC7296] AEAD | | AUTH_NONE | MUST / MUST | [RFC7296] AEAD |
| | NOT | | | | NOT | |
| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | | AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |
| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | | AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |
| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | | AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |
| | | [IoT] | | | | (IoT) |
| AUTH_AES_128_GMAC | MAY | [RFC4543] | | AUTH_AES_128_GMAC | MAY | [RFC4543] |
| AUTH_AES_256_GMAC | MAY | [RFC4543] | | AUTH_AES_256_GMAC | MAY | [RFC4543] |
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
+----------------------------+-------------+------------------------+ +----------------------------+-------------+------------------------+
[IoT] - This requirement is for interoperability with IoT (IoT) - This requirement is for interoperability with IoT
Table 2 Table 3
AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The
only reason NULL is acceptable is when authenticated encryption only reason NULL is acceptable is when authenticated encryption
algorithms are selected from Section 4. In all other cases, NULL algorithms are selected from Section 4. In all other cases, NULL
MUST NOT be selected. As ESP and AH both provides authentication, MUST NOT be selected. As ESP and AH both provides authentication,
one may be tempted to combine these protocols to provide one may be tempted to combine these protocols to provide
authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to
use ESP with NULL authentication - with non authenticated encryption use ESP with NULL authentication - with non authenticated encryption
- in conjunction with AH; some configurations of this combination of - in conjunction with AH; some configurations of this combination of
services have been shown to be insecure [PD10]. In addition, NULL services have been shown to be insecure [PD10]. In addition, NULL
skipping to change at page 9, line 21 skipping to change at page 9, line 29
+----------------+----------+-------------+ +----------------+----------+-------------+
| Name | Status | Comment | | Name | Status | Comment |
+----------------+----------+-------------+ +----------------+----------+-------------+
| IPCOMP_OUI | MUST NOT | UNSPECIFIED | | IPCOMP_OUI | MUST NOT | UNSPECIFIED |
| IPCOMP_DEFLATE | MAY | [RFC2393] | | IPCOMP_DEFLATE | MAY | [RFC2393] |
| IPCOMP_LZS | MAY | [RFC2395] | | IPCOMP_LZS | MAY | [RFC2395] |
| IPCOMP_LZJH | MAY | [RFC3051] | | IPCOMP_LZJH | MAY | [RFC3051] |
+----------------+----------+-------------+ +----------------+----------+-------------+
[IoT] - This requirement is for interoperability with IoT (IoT) - This requirement is for interoperability with IoT
Table 3 Table 4
Compression was not mentioned in RFC7321. As it is not widely Compression was not mentioned in RFC7321. As it is not widely
deployed, it remains optional and at the MAY-level. deployed, it remains optional and at the MAY-level.
7. Summary of Changes from RFC 7321 7. Summary of Changes from RFC 7321
The following table summarizes the changes from RFC 7321. The following table summarizes the changes from RFC 7321.
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
skipping to change at page 9, line 50 skipping to change at page 10, line 9
| ENCR_AES_CTR | MAY | (*) | | ENCR_AES_CTR | MAY | (*) |
| ENCR_3DES | MAY | SHOULD NOT | | ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- | | AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY | | AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT | | AUTH_NONE | MAY | MUST / MUST NOT |
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
(*) 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.
Table 4 Table 5
8. Acknowledgements 8. Acknowledgements
Some of the wording in this document was adapted from [RFC7321], the Some of the wording in this document was adapted from [RFC7321], the
document that this one obsoletes, which was written by D. McGrew and document that this one obsoletes, which was written by D. McGrew and
P. Hoffman. P. Hoffman.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
 End of changes. 21 change blocks. 
52 lines changed or deleted 59 lines changed or added

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