Re: [IPsec] #122: Integrity proposals with combined algorithms

[Paul Hoffman <[e-mail]>]

At 4:08 PM +0200 11/24/09, Tero Kivinen wrote:
>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.

I'm pretty sure others have read this the other way: you must give a transform of "none".

Are people OK with wording that says "MUST either offer an integrity algorithm or a single integrity algorithm of 'none'"?

>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).

Good catch; fixed in the next draft.

>
>> 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.

I still don't think NONE is not allowed, but I want to hear from others. If no one implemented sending 'none', I'm happy to remove it, but I don't want to break anyone's implementation.


--Paul Hoffman, Director
--VPN Consortium