[IPsec] #122: Integrity proposals with combined algorithms

[Tero Kivinen <[e-mail]>]

Paul Hoffman writes:
> The 4th paragraph of section 3.3 says "If an algorithm that combines
> encryption and integrity protection is proposed, it MUST be proposed
> as an encryption algorithm and an integrity protection algorithm
> MUST NOT be proposed." This means that an integrity protection
> algorithm can only be proposed with a Transform ID equal to NONE,
> given that a few paragraphs above, it says: "Combined-mode ciphers
> include both integrity and encryption in a single encryption
> algorithm, and are not allowed to be offered with a separate
> integrity algorithm other than "none"." We should thus make this
> clear in the 4th paragraph. 

I interpreted the text "integrity protection algorithm MUST NOT be
proposed" to mean that there is no transform type 3 (Integrity
algorithm) at all in the proposal, i.e. it is left out completely.

Accepting proposal having transform type 3 (Integrity algorithm) with
value 0 (none) is ok, but I think we should prefer for not including
it at all, as it makes packets shorter.

I agree that the text earlier would indicate that you send "NONE", but
RFC5282 says:

  This document updates [RFC4306] to require that when an
  authenticated encryption algorithm is selected as the encryption
  algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT
  be selected for that SA. This document further updates [RFC4306] to
  require that if all of the encryption algorithms in any proposal are
  authenticated encryption algorithms, then the proposal MUST NOT
  propose any integrity transforms.

where I read the "MUST NOT propose any ingerity tranforms" to also
include integrity transform for value 0 (NONE).

So I would change the section 3.3 text where it says

			      Combined-mode ciphers include both
   integrity and encryption in a single encryption algorithm, and are
   not allowed to be offered with a separate integrity algorithm other
   than "none".

to say

			      Combined-mode ciphers include both
   integrity and encryption in a single encryption algorithm, and are
   not allowed to be offered with a separate integrity algorithm.

to align with the RFC5282. 

Also note that the [AEAD] reference to the RFC5116 in IKEv2bis is
wrong, it should point to the RFC5282, which defines how AEAD modes
are used in IKE (all those references refer to IKEv2 used of AEAD).

> HOWEVER, in section 3.3.2, in the table for transform types, it says:
>    Integrity Algorithm (INTEG)     3       IKE*, AH, optional in ESP
>   (*) Negotiating an integrity algorithm is mandatory for the
>   Encrypted payload format specified in this document. For example,
>   [AEAD] specifies additional formats based on authenticated
>   encryption, in which a separate integrity algorithm is not
>   negotiated.
> The second sentence seems wrong. Proposed rewording:
>   For example,
>   [AEAD] specifies additional formats based on authenticated
>   encryption, in which the integrity algorithm is an inherent
>   part of the combined algorithm; in this case, the
>   integrity algorithm is specified as "none".

When you fix the reference from RFC5116 to RFC5282, then you notice
that NONE is not allowed, thus the original text was correct and your
new text is incorrect, as NONE cannot be proposed or accepted. 
-- 
[e-mail]