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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
