Hi Paul,
We have kept key lengths out of the tables on purpose. It matches the
tables at IANA that also do not list separate items for different key
lengths. Would "This requirement" instead of "This requirement level"
make that more clear?
If you don't want to add key length column to the table,
(what I think is a preferred way) then I suggest to add some
words to corresponding paras that will reiterate:
"these requirements are for those key sizes".
And the comment (IoT) brings even more confusion. It states that
"only 128-bit keys are at MUST level", while the line it refers to
(ENCR_AES_CCM_8) indicates SHOULD level.
That is an error. It should read "only 128-bit keys are at the SHOULD level"
OK.
And again I think it should be reiterated in the text below the table (besides
the comment).
Note that I was hoping the (1) and (IoT) comments would appear similarly
indented so it becomes a little more clear and was planning to ask the
RFC Editor to ensure that.
I was thinking of complaining about their current appearance
(idented would be definitely better), but then I decided
that it is a feature of xml2rfc. But you are right that RFC Editor
can make them more better-looking.
ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST. It is the
only shared mandatory-to-implement algorithm with RFC4307 and as a
result it is necessary for interoperability with IKEv2 implementation
compatible with RFC4307.
However, it is not exactly true. The comment (1) indicates that both
AES-128-CBC and AEC-256-CBC are now MUST, while in RFC4307 AES-256-CBC wasn't
mentioned at all, so it definitely wasn't SHOULD+.
So, this statement is true for AES-128-CBC and not true for AES-256-CBC.
It is only because you do not want to see ENCR_AES_CBC without a key
size. We are talking about updating IANA entries, and the IANA entries
are not separate for keysize.
We are talking about updating RFC4307 and it does include key size for AES-CBC
(Section 3.1.1):
For confidentiality, implementations
MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For
integrity, HMAC-SHA1 MUST be implemented.
Note, that it explicitely references AES-CBC with 128 bit key length, not any
other.
Section 3.2
If an algorithm is selected as the integrity algorithm, it SHOULD
also be used as the PRF.
That requirement isn't clear for me. Where it comes from?
How it is justified? Is the document in the position to make such restrictive
requirement? Isn't it a local policy matter?
It came from me, after having talked to Tero about a TAHI test suite
test case. From what I understand from Tero, historically it was not
mandated in the IKEv2 RFC to use the same algorithm, although there is
really no argument in favour of using two different algorithms. If the
algo is good enough for INTEG, it is good enough for PRF. If one algo
is not good enough for either INTEG or PRF, then it is also not good
enough for the other.
Our implementation does not allow one to specify a PRF different from
INTEG (unless INTEG is AUTH_NONE with an AEAD ENCR)
I believe we ended up on SHOULD instead of MUST so this could be seen
as advise, and not a hard requirement. So it does not update the IKEv2
core RFC in that respect.
Do you have any use case where it makes sense that PRF != INTEG ?
Sure.
First, not any good MAC is a good PRF (but vice versa is true).
Secondly, besides cryptographic properties there are also other
considerations, like performance. For example, in Russia
there is a standard MAC that is based on GOST cipher
with reduced number of rounds. It is very fast, but it cannot
be used as PRF.
Coming back from Russian quirks, I can imagine the situation when
I want to use SHA2-512 for PRF (because I don't want my conversation
to be hacked offline in the future), but SHA1-HMAC-96 for MAC
(because ICV tags are smaller comparing to SHA2 and I'm pretty
confident in HMAC SHA1 security against _real_time_ attacks).
And finally, I strongly oppose including such a restriction in
this document, because from my point of view it is out of scope
of the document. It has nothing with defining requirement
levels for algorithms. Moreover SHOULD is a pretty strong requirement...
PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as
their is an industry-wide trend to deprecate its usage.
I think some more reasons should be given besides "an industry-wide trend".
Industry usually follows standards, so it's a bit silly to refer to industry
trends
as a reason here. I think some words about current concerns in the security
of SHA1 should be added (like for PRF_HMAC_MD5 below).
How about:
"as cryptographic attacks against SHA1 are increasing, resulting in an
industry-wide trend to deprecate its usage"
OK.
Section 3.3
AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST-
as there is an industry-wide trend to deprecate its usage.
See my comment above to the similar sentence in Section 3.2
Same.
OK.
It has been recommended by the CRFG and others as an
alternative to AES-CBC and AES-GCM.
What "others" mean? Isn't it too vague wording for Standards Track RFC?
Either list these "others" (at least some of them) or remove reference to
them.
Agreed. I will propose removing "and others".
OK.
Section 3.2
PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based
transforms were mentioned.
This sentence makes little sence for me. Shouldn't second "mentioned" be
"defined at that time"?
They might have been defined, but what matters is that the document did
not reference them. Perhaps:
As no SHA2 based transforms were referenced in RFC4307, PRF_HMAC_SHA2_256
was not mentioned in RFC4307.
Works for me.
AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of
Things deployments tend to prefer AES based pseudo-random functions
in order to avoid implementing SHA2.
s/AUTH_AES-XCBC/AUTH_AES-XCBC_96 (as in IANA Registry)
Actually, we should add this to section 9 for renaming and call it
AUTH_AES_XCBC_96.
Actually, it is already called AUTH_AES_XCBC_96 in the IANA registry.
I wanted to point that it is erroneously called AUTH_AES-XCBC in this paragraph.
Section 3.4
Group 19 or 256-bit random ECP group was not specified in RFC4307, as
this group were not specified at that time.
See my comment above about similar sentence in Section 3.2
The second "specified" here could be changed to "define" ?
OK.
Paul
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
