Skip to content

Commit

Permalink
update status for AUTH_AES_XCBC_96 to SHOULD
Browse files Browse the repository at this point in the history
AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to SHOULD. I was suprised PRF was already SHOULD. In each case explanation has been added.

Titles of the subsection shave also been updated to better fit IANA designation.
  • Loading branch information
mglt committed Nov 20, 2015
1 parent b65c722 commit 1854f98
Showing 1 changed file with 39 additions and 24 deletions.
63 changes: 39 additions & 24 deletions draft-ietf-ipsecme-rfc4307bis
Expand Up @@ -144,7 +144,8 @@
</texttable>
</section>
<section anchor="algs" title="Algorithm Selection">
<section anchor="algs_enc" title="IKEv2 Transform Type 1 Algorithms">

<section anchor="algs_enc" title="Type 1 - IKEv2 Encryption Algorithm Transforms">
<t> The algorithms in the below table are negotiated in the SA payload and used in the ENCR payload.
References to the specifications defining these algorithms and the ones in the following subsections are in
the IANA registry <xref target="IKEV2-IANA"/>. Some of these algorithms are Authenticated Encryption with
Expand Down Expand Up @@ -192,7 +193,36 @@
efficient alternative to AES.</t>
<t> ENCR_DES is known to be insecure and so MUST NOT be implemented.</t>
</section>
<section anchor="algs_integ" title="IKEv2 Transform Type 3 Algorithms">


<section anchor="algs_prf" title="Type 2 - IKEv2 Pseudo-random Function Transforms">
<t> Transform Type 2 Algorithms are pseudo-random functions used to generate random values when needed.</t>
<texttable anchor="tbl_alg2" suppress-title="true">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Status</ttcol>
<c>PRF_HMAC_SHA2_256</c><c>MUST</c>
<c>PRF_HMAC_SHA2_512</c><c>SHOULD+</c>
<c>PRF_HMAC_SHA1</c><c>MUST-</c>
<c>PRF_AES128_CBC</c><c>SHOULD</c>
</texttable>
<t> PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based authentication was mentioned.
PRF_HMAC_SHA2_256 MUST be implemented in order to replace SHA1 and PRF_HMAC_SHA1.</t>
<t> PRF_HMAC_SHA2_512 SHOULD be implemented as as a future replacement of SHA2_256 or when stronger
security is required. This value has been preferred to PRF_HMAC_SHA2_384, as the overhead of
PRF_HMAC_SHA2_512 is negligible.</t>
<t> PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307.
There is an industry-wide trend to deprecate its usage.</t>
<t> PRF_AES128_CBC has been downgraded from SHOULD in RFC4307 as it is not being deployed.
In order to provide compatibility between IKEv2 implementations, this document would not
envision to downgrade any further to a MAY for example. On the other hand, this document
considers new cases outside the VPN cases to keep it to a SHOULD status. This
document considers it SHOULD be implemented
in order to be able to interact with Internet of Things devices. Internet of Things might use
AES based pseudo-random function in order to avoid implementing SHA2, and use their implementation
of AES. As this case is not a general use case for VPNs, its status is expected to remain a SHOULD.</t>
</section>

<section anchor="algs_integ" title="Type 3 - IKEv2 Integrity Algorithm Transforms">
<t> The algorithms in the below table are negotiated in the SA payload and used in the ENCR payload. References
to the specifications defining these algorithms are in the IANA registry. When an AEAD algorithm (see <xref
target="algs_enc"/>) is used, no algorithm from this table needs to be used.</t>
Expand All @@ -202,7 +232,7 @@
<c>AUTH_HMAC_SHA2_256_128</c><c>MUST</c>
<c>AUTH_HMAC_SHA2_512_256</c><c>SHOULD+</c>
<c>AUTH_HMAC_SHA1_96</c><c>MUST-</c>
<c>AUTH_AES_XCBC_96</c><c>MAY</c>
<c>AUTH_AES_XCBC_96</c><c>SHOULD</c>
</texttable>
<t> AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based authentication was mentioned.
AUTH_HMAC_SHA2_256_128 MUST be implemented in order to replace SHA1 and AUTH_HMAC_SHA1_96.</t>
Expand All @@ -211,28 +241,13 @@
AUTH_HMAC_SHA2_512 is negligible.</t>
<t> AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307.
There is an industry-wide trend to deprecate its usage.</t>
<t> AUTH_AES-XCBC has been downgraded from SHOULD in RFC4307 as it is not widely deployed.</t>
</section>
<section anchor="algs_prf" title="IKEv2 Transform Type 2 Algorithms">
<t> Transform Type 2 Algorithms are pseudo-random functions used to generate random values when needed.</t>
<texttable anchor="tbl_alg2" suppress-title="true">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Status</ttcol>
<c>PRF_HMAC_SHA2_256</c><c>MUST</c>
<c>PRF_HMAC_SHA2_512</c><c>SHOULD+</c>
<c>PRF_HMAC_SHA1</c><c>MUST-</c>
<c>PRF_AES128_CBC</c><c>MAY</c>
</texttable>
<t> PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based authentication was mentioned.
PRF_HMAC_SHA2_256 MUST be implemented in order to replace SHA1 and PRF_HMAC_SHA1.</t>
<t> PRF_HMAC_SHA2_512 SHOULD be implemented as as a future replacement of SHA2_256 or when stronger
security is required. This value has been preferred to PRF_HMAC_SHA2_384, as the overhead of
PRF_HMAC_SHA2_512 is negligible.</t>
<t> PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307.
There is an industry-wide trend to deprecate its usage.</t>
<t> PRF_AES128_CBC has been downgraded from SHOULD in RFC4307 as it is not being deployed.</t>
<t> AUTH_AES-XCBC has been kept as SHOULD in RFC4307. This document considers it SHOULD be implemented
in order to be able to interact with Internet of Things devices. Internet of Things might use
AES based pseudo-random function in order to avoid implementing SHA2, and use their implementation
of AES. As this case is not a general use case for VPNs, its status is expected to remain a SHOULD.</t>
</section>
<section anchor="algs_dh" title="Diffie-Hellman Groups">

<section anchor="algs_dh" title="Type 4 - IKEv2 Diffie-Hellman Group Transforms">
<t> There are several Modular Exponential (MODP) groups and several Elliptic Curve groups (ECC) that are
defined for use in IKEv2. They are defined in both the [IKEv2] base document and in extensions documents.
They are identified by group number.</t>
Expand Down

0 comments on commit 1854f98

Please sign in to comment.