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

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Nov 2009 16:32:43 -0800

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.

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

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Mon, 23 Nov 2009 20:09:33 -0500

>   integrity algorithm is specified as "none".

Yes, this is much clearer, given we have a well-defined "none" value for
integrity.

Dan

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Nov 2009 16:08:13 +0200

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

>   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. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Nov 2009 10:13:59 -0800

>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'"?

>are used in IKE (all those references refer to IKEv2 used of AEAD).

Good catch; fixed in the next draft.

>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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 15:04:22 +0200

> I'm pretty sure others have read this the other way: you must give a

I do not see any point why I should send none, when it is better to
just leave it out, this is what you normally do for ESP when you use
combined mode ciphers. Leaving it out makes packets smaller...

The problem is that in IKEv2 you are explicitly FORBIDDEN of using
integrity algorithm of NONE:

5.  Security Considerations
...
   choices in this protocol, see [SIGMA] and [SKEME].  Though the
   security of negotiated CHILD_SAs does not depend on the strength of
   the encryption and integrity protection negotiated in the IKE_SA,
   implementations MUST NOT negotiate NONE as the IKE integrity
   protection algorithm or ENCR_NULL as the IKE encryption algorithm.

And someone might interpret that there cannot be Integrity algorithm
NONE in any proposal for IKEv2 SA (in a sense there is no separate IKE
integrity protection algorithm at all, but integrity protection is
provided by the encryption algorithm). 

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

If you add "no" somewhere there (i.e. MUST either offer no integrity
algorithm...) then I can accept it.

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

We do not support combined modes for IKEv2 SA yet (only for ESP, and
in ESP we do not send integrity algorithm at all, but we do accept
other ends proposal if they send none).
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Nov 2009 08:30:48 -0800

>algorithm...) then I can accept it.

Er, right.

MUST either offer no integrity algorithm or a single integrity algorithm of "none"

Does anyone have a problem with this new wording?

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 25 Nov 2009 11:34:54 -0500

> Does anyone have a problem with this new wording?

I suggest we specify that one or the other as the preferred approach. 
Maybe add an additional sentence saying SHOULD for no transform and MAY 
for transform=none?

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Paul Hoffman <[email-masked]>
To:
Tero Kivinen <[email-masked]>
Cc:
IPsecme WG <[email-masked]>
Date:
11/25/2009 11:31 AM
Subject:
Re: [IPsec] #122: Integrity proposals with combined algorithms

Er, right.

MUST either offer no integrity algorithm or a single integrity algorithm 
of "none"

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Nov 2009 09:29:10 -0800

At 11:34 AM -0500 11/25/09, Scott C Moonen wrote:
>I suggest we specify that one or the other as the preferred approach.  Maybe add an additional sentence saying SHOULD for no transform and MAY for transform=none?

I hate honing down that far: it confuses future developers. How about:

MUST either offer no integrity algorithm or a single integrity algorithm of "none", with no integrity algorithm being the preferred method

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 25 Nov 2009 12:47:19 -0500

> MUST either offer no integrity algorithm or a single integrity algorithm 
of "none", with no integrity algorithm being the preferred method

Sounds good, thanks,

From:
Paul Hoffman <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
IPsecme WG <[email-masked]>, [email-masked], Tero Kivinen 
<[email-masked]>
Date:
11/25/2009 12:29 PM
Subject:
Re: [IPsec] #122: Integrity proposals with combined algorithms

MUST either offer no integrity algorithm or a single integrity algorithm 
of "none", with no integrity algorithm being the preferred method

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Nov 2009 13:16:48 +0200

Paul Hoffman writes:
> MUST either offer no integrity algorithm or a single integrity
> algorithm of "none", with no integrity algorithm being the preferred
> method 

That is fine for me.

It would also be fine for me to change "preferred" with "RECOMMENDED"
(RFC2119 synonym for SHOULD), but I can accept on not using RFC2119
language too. 
-- 
[email-masked]