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

[Kathleen Moriarty <[e-mail]>]

On Wed, Feb 22, 2017 at 1:24 PM, Kathleen Moriarty
<[e-mail]> wrote:
> 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.

Is there any chance this update could happen today so I can start last
call?  I'd like ot keep this on the 3/16 telechat with the other
IPsecme draft if possible.

>
> Thank you.
>
>> --
>> [e-mail]
>
>
>
> --
>
> Best regards,
> Kathleen



-- 

Best regards,
Kathleen