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

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 17 Feb 2017 10:36:34 -0500

Hello,

Thanks for your work on draft-ietf-ipsecme-rfc7321bis.  I just have
one big question and a nit to point out.

Questions:  I see this:
5.  ESP and AH Authentication Algorithms

   Encryption without authentication MUST NOT be used.

This is a big change from RFC7321 without much explanation. What about
the case of opportunistic security?  Can you explain the change and
justification?

Nits:
Section 4, third paragraph: s/theses/these/

   Usually, the use of theses algorithms is limited to
   specific cases, and the absence of specification makes
   interoperability difficult for IPsec communications.

-- 

Best regards,
Kathleen

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Feb 2017 12:17:34 -0500 (EST)

> the case of opportunistic security?  Can you explain the change and

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.

Encryption without authentication is vulnerable to manipulation that can
cause an oracle attack to compromise the encryption key as well.

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.

>   interoperability difficult for IPsec communications.

I'll keep this in mind to correct at the RFC Editor round, unless we do
another draft round if we need to change anything else.

Thanks,

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 17 Feb 2017 15:02:42 -0500

Hi Paul,

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

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

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

> cause an oracle attack to compromise the encryption key as well.

yes.

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

> another draft round if we need to change anything else.

Thanks.  I'd want it updated before IESG review, especially adding
text for the above changes.

-- 

Best regards,
Kathleen

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Feb 2017 11:35:30 -0500 (EST)

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

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

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

> What I am saying is that it would be helpful to provide text to

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?

Paul

---

From: Sandeep Kampati <[email-masked]>
Date: Wed, 22 Feb 2017 05:10:20 +0000

RFC 7296

3.5.  Identification Payloads

ID_IPV4_ADDR                        1
      A single four (4) octet IPv4 address.

Questions:  do we need to consider "single four (4) octet IPv4 address"  as MUST point and reject the packet if we receive more length for it.

For security reason we want to add restriction the payloads what we received, and reject packet if we receive more length 

Ex:  Identification Payloads ID Type : 1) ID_IPV4_ADDR ->A single four (4) octet  2) ID_IPV6_ADDR-> A single sixteen (16) octet

It will be good if have some MAX limit for number of Proposal, CERT, So on ...,  So that we can avoid unwanted processing 

Best regards,
Sandeep kampati

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Feb 2017 16:30:23 +0200

Sandeep Kampati writes:
> Questions:  do we need to consider "single four (4) octet IPv4
> address"  as MUST point and reject the packet if we receive more
> length for it. 
> 
> For security reason we want to add restriction the payloads what we
> received, and reject packet if we receive more length  
> 
> Ex:  Identification Payloads ID Type : 1) ID_IPV4_ADDR ->A single
> four (4) octet  2) ID_IPV6_ADDR-> A single sixteen (16) octet 

The Identification Payload ID is used to search the matching policy
from the PAD, and as your PAD most likely will not add any other
lengths for the IP-addresses than 4 and 16 octets, then you can
immediately know that the matching policy will not be found from the
policy so you can reject it immediately.

The proper error code would most likely be INVALID_SYNTAX (as the ID
payload does not match the specified syntax, and if someone sends 5
octets for IPv4 address there is clearly a bug in their
implementation, and changing policy will not help)...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Feb 2017 16:53:56 +0200

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

> explain AEAD vs non-AEAD.

Again all of the above was explaining those 3 different ways of doing
confidentiality + authentication. 

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Feb 2017 13:24:04 -0500

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

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 27 Feb 2017 14:13:47 -0500

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

-- 

Best regards,
Kathleen

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Feb 2017 14:31:25 -0500 (EST)

> IPsecme draft if possible.

Yes, I'll push out an update today that includes what Tero and I said to
replace that one liner you pointed at.

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 27 Feb 2017 15:55:13 -0500

> replace that one liner you pointed at.

Great, thank you!

-- 

Best regards,
Kathleen

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 27 Feb 2017 21:04:18 +0000

Thanks Paul!

Dave

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: Monday, February 27, 2017 3:55 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Tero Kivinen
> <[email-masked]>
> Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis
> 
> >>> 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
> > Yes, I'll push out an update today that includes what Tero and I said
> > to replace that one liner you pointed at.
> 
> Great, thank you!
> >
> > Paul
> 
> 
> 
> --
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec