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

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]