Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis

[Kathleen Moriarty <[e-mail]>]

On Wed, Feb 22, 2017 at 9:53 AM, Tero Kivinen <[e-mail]> wrote:
> Paul Wouters writes:
>> On Fri, 17 Feb 2017, Kathleen Moriarty wrote:
>>
>> >> It is actually not much a change. If you look at 7321 Section 3, it states:
>> >>
>> >>         Confidentiality without authentication is not effective [DP07]
>> >>         and therefore SHOULD NOT be used.
>> >
>> > Yes, I saw that and agree security-wise that this is a bad practice.
>> > But 7321 say a lot more on both ESP and AH authentication than that
>> > one sentence.  What I am saying is that the change in this document
>> > requires more text to explain it.
>> >
>> > You also have the following text in that section:
>> >
>> >   To provide both confidentiality and authentication, an authenticated
>> >   encryption transform from Section 2.1 SHOULD be used in ESP, in
>> >   conjunction with NULL authentication.
>>
>> The way I read that section is that it tries to explain AEAD ciphers
>> versus separate ENCR+INTEG ciphers. It is not making claims about
>> using encryption without authentication, just that when using an AEAD,
>> you do not use a separate authentication algorithm and when not using
>> an AEAD you do use a separate authentication.
>
> There is 3 ways of provide both confidentiality and authentication in
> IPsec:
>
> 1) ESP with AEAD cipher
> 2) ESP with non-AEAD cipher + authentication
> 3) ESP with non-AEAD cipher + no authentication combined with AH with
>    authentication
>
> I.e.,
>
> 1) Use combined mode cipher, i.e. AEAD cipher. In that case the AEAD
> ciphers is set for the encryption algorithm, and the authentication
> algorithm is not sent. Example of this is ENCR_AES_GCM_16 or
> ENCR_CHACHA20_POLY1305.
>
> 2) Use ESP with both encryption and authentication algorithm. In this
> case we are still using only ESP, but we have separate algorithms, for
> example ENCR_AES_CBC combined with AUTH_HMAC_SHA2_256_128.
>
> 3) Use ESP for confidentiality and AH for authentication. In that case
> the ESP is used with encryption algorithm like ENCR_AES_CBC, and
> without authentication algorithm, and then there is second IPsec
> protocol AH that will provide authentication with algorithm like
> AUTH_HMAC_SHA2_256_128.
>
> The first one is preferred, i.e., RFC7321 said SHOULD for AEAD
> algorithms, and did say MAY for 2nd option (ESP with both encryption
> and authentication algorithms), and said NOT RECOMMENDED for the last
> option.
>
>> > It's fine again with the following text:
>> >
>> >   Alternatively, an ESP
>> >   encryption transform and ESP authentication transform MAY be used
>> >   together.  It is NOT RECOMMENDED to use ESP with NULL authentication
>> >   in conjunction with AH; some configurations of this combination of
>> >   services have been shown to be insecure [PD10].
>>
>> Again, the way I read it is that it (not too clearly) is trying to
>> explain AEAD vs non-AEAD.
>
> Again all of the above was explaining those 3 different ways of doing
> confidentiality + authentication.
>
>> > Then at the end of the next paragraph:
>> >
>> >   Therefore, an encryption
>> >   transform MUST NOT be used with a NULL authentication transform
>> >   (unless the encryption transform is an authenticated encryption
>> >   transform from Section 2.1).
>>
>> And again. They probably should have cut all the text and just left
>> this one paragraph in :P
>>
>> Note that this MUST NOT conflicts with the SHOULD NOT quoted above
>> that we promoted to MUST NOT that we are talking about here.
>
> Yes, the 7321 did say MUST NOT for confidentility only, after saying
> SHOULD NOT for it earlier...
>
> In the section 3 of the 7321 the second last paragraph then moves to
> explain other cases, i.e. where we only want to provide authentication
> without confidentiality, where it prefers the ESP with NULL encryption
> over AH, and then it says that encryption without authentication is
> MUST NOT, although it should point out that in addition to the AEAD
> case the ESP + AH is another exception to that rule...
>
>> >> The 7321 document was a bit unclear with respect to encryption algos
>> >> versus AEAD algos which might look like it allows a wider acceptance
>> >> of encryption without authentication, but really does not intend to.
>> >
>> > What I am saying is that it would be helpful to provide text to
>> > explain the change.
>>
>> I'm unsure what to write? 7321 should have used MUST NOT instead of
>> SHOULD NOT for the exact same unchanged reasons provided in 7321.
>> And as I pointed out above, it kind of does outside that one silly
>> paragraph.
>>
>> If really needed, I can do something like:
>>
>>       Encryption without authentication MUST NOT be used. [RFC7321]
>>       erroneously stated in Section 3 that this insecure practise
>>       is a SHOULD NOT, where elsewhere in [RFC7321] it properly
>>       stated this as MUST NOT.
>>
>> Perhaps one of my co-authors can come up with a better suggestion?
>
> Perhaps we should add bit similar text like I did earlier, i.e.,
> explain that there is 3 ways of doing confidentiality + authentication
> and add some more text about them.

I think that may help head off questions in last call and IESG review
if anyone else looks back at 7321.

Thank you.

> --
> [e-mail]



-- 

Best regards,
Kathleen