Hi,
I think the idea of introducing "implicit IV" also in IPsec is great and
something that absolutely should be done. Some comments:
- The abstract/introduction/security consideration gives the idea that it
defines implicit IV for ENCR_AES_CTR which is does not. I think AES-CTR could
be removed from the document.
- I think the the terminology of IV, nonce etc. in this document is very
confusing. At least RFC 4106 defines IV to be the 8 octet ESP IV, while nonce
is used for the 12 octet AEAD nonce, aligning with RFC 5116. I think this
document should also follow this convention. e.g. I think the sentences should
talk about IV instead of nonce.
"but all of the algorithms mentioned above take an 8-octet nonce."
"Currently this nonce is sent in each ESP packet"
- "Nonce generation for these algorithms has not been explicitly defined.
It has been left to the implementation"
I do not understand how implementation specific nonce (or IV) generation could
be interoperable between implementation? If I understand correctly, the only
thing sent in the ESP packet is the sequence number.
- If we go to the trouble of designing new encryption algorithms for ESP, I
think this document does too little and misses opportunities to with very
little work also make the algorithms stronger cryptographically as was done
with TLS 1.2 -> TLS 1.3. I stongly suggest to change the nonce generation to
follow current best practices established by e.g. TLS 1.3. Suggestion (here
examplified for AES-128 in GCM mode)
1. The KEYMAT requested for each AES-GCM key is 28 octets. The first
16 octets are the 128-bit AES key, and the remaining 12 octets
are used as the salt value in the nonce.
2. The nonce format is changed to a format following Section 4.4 of
draft-mcgrew-iv-gen [XX] where IV = implicit IV
0 1 2 3 4 5 6 7 8 9 10 11
+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|00|00| IV |---+
+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+ |
| salt |->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+ |
| nonce |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+
Figure: Nonce Format
3. The salt is kept secret
In [YY] it is shown that this can be understood as a key-length extension
that essentially extends the 128-bit key of AES-GCM to a 224-bit key giving
significatntly better multi-user security (and single-user security)
- A large secret salt is useful for IKEv2 as well, I think the algorithms
should be defined for IKEv2 as but with IV = explicit IV.
Cheers,
John
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
