Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

From: John Mattsson <[email-masked]>
Date: Mon, 2 Nov 2015 14:35:33 +0000

Some comments on draft-ietf-ipsecme-rfc4307bis-00

In general, very good and very needed.

- Abstract says:
“This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time.”

The introduction also only talks about MTI and believed to be future MTI. ENCR_DES does not fit in either of these categories. I am all for specifying MUST NOT for such algorithms, but the abstract and introduction should be updated.

- BTW, What does it mean that an algorithm like ENCR_RC5 is not listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”?

- Section 3.2. says “When an AEAD algorithm (see Section 3.1) is used, no algorithm from this table needs to be used.” Shouldn’t this be “MUST NOT be used”.

- Section 3.1. I think AES_CCM_8 should somehow be restricted to IoT, as using 64 bit tags in IKE does not sound like general good advise. Also IoT implementations would probably just implement “ENCR_AES_CCM_8”, “PRF_HMAC_SHA2_256", and "256-bit random ECP group" and skip everything else. It seem to make more sense to specify an IoT profile in a separate section.

- Section 3.4. The Diffie-Hellman group table diverges heavily from the rest with only 112-bit security as MUST, and no group offering 128-bit security as even SHOULD+. This may be ok, but I think the ipsecme group should try to fulfill general recommendations on security levels (NIST, ECRYPT) and have a plan on how to make 2048-bit MOPD a MUST NOT before 2030. Not being able to forbid 1024-bit MOPD is this draft is a failure, let’s not repeat it.

- At least “AES-XCBC-PRF-128” and “256-bit random ECP group” should have references to point out which of the RFCs that are MTI.

Cheers,
John

-------------------------------------
John Mattsson
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator 
Senior Researcher, Security

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Nov 2015 02:42:01 +0200

John Mattsson writes:
> - BTW, What does it mean that an algorithm like ENCR_RC5 is not
> listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”?

It means this document does not specify whether they should be used or
not, i.e. MAY.

> - Section 3.2. says “When an AEAD algorithm (see Section 3.1) is
> used, no algorithm from this table needs to be used.” Shouldn’t this
> be “MUST NOT be used”.

This document just states the fact, the actual MUST NOT is in the
RFC5282, and I do not think we should repeat that here. I.e. this text
just states the fact of life based on the RFC5282, but does not make
any requirements. 

> - Section 3.1. I think AES_CCM_8 should somehow be restricted to
> IoT, as using 64 bit tags in IKE does not sound like general good
> advise. Also IoT implementations would probably just implement
> “ENCR_AES_CCM_8”, “PRF_HMAC_SHA2_256", and "256-bit random ECP
> group" and skip everything else. It seem to make more sense to
> specify an IoT profile in a separate section.

The IoT devices talk to each other, but also to more general purpose
servers, i.e., in your home you might have some kind home area network
server, where all the IoT devices connect to. In that case those
bigger boxes do want to implement the same AES_CCM_8 just so that
those IoT devices which didn't implement anything else can talk to
them.

I.e. I think it is good thing to require real systems to have SHOULD
for the AES_CCM_8. Of couse if your implementation is never expected
to talk to IoT devices, then that is good reason to go against the
SHOULD and leave the AES_CCM_8 implementation out.

> - Section 3.4. The Diffie-Hellman group table diverges heavily from
> the rest with only 112-bit security as MUST, and no group offering
> 128-bit security as even SHOULD+.

That depends how you calculate the securities of the Diffie-Hellman
groups. If you check RFC3526 that gives two strengh estimates for
2014-bit group, 110 and 160 bits. The 160 bit strength takes also
account the memory prices in the calculations, the 110 assumes memory
is free, and CPU cost is only thing that matters. 

> This may be ok, but I think the ipsecme group should try to fulfill
> general recommendations on security levels (NIST, ECRYPT) and have a
> plan on how to make 2048-bit MOPD a MUST NOT before 2030.

I think we are going to replace this document several times before
2030. We actually should have replaced this already few years ago, so
this update is already bit late, but I would assume we might make new
version after we get those new EC groups now being defined to the
implementations. On the other hand there are lots of people still
running IKEv1, so getting them to implementations might get time.

> Not being able to forbid 1024-bit MOPD is this draft is a failure,
> let’s not repeat it.

We should move it to MUST NOT in next update, and then we can also
revisit the discussion of 2048-bit MODP group. 
-- 
[email-masked]

---

From: John Mattsson <[email-masked]>
Date: Tue, 3 Nov 2015 01:43:29 +0000

>just states the fact of life based on the RFC5282, but does not make

Then you should probably remove the ‘MUST' in "Algorithms that are not
AEAD MUST be used in conjunction with the integrity algorithms in Section
3.2.”

>SHOULD and leave the AES_CCM_8 implementation out.

That sound reasonable, but shouldn’t the IoT devices have some guidelines
(maybe just a sentence) on what they should implement? We know that they
will not implement everything, and if they chose different subsets, they
will not be able to talk to each other.

>is free, and CPU cost is only thing that matters.

There is also:
- Lenstra (http://infoscience.epfl.ch/record/164539/files/NPDF-32.pdf)
giving the estimate 95 bit strength
- The IETF BCP (RFC3766) giving the estimate 103 bit strength
- ECRYPT giving the estimate 103 bit strength

So if anything, I would say the general consensus is that 2048 MODP may
not even give 112 bits security…

>implementations.

That sounds really good. It’s very important that both this and RFC7321
gets updated regularly.

> On the other hand there are lots of people still

But IKEv1 is not in scope for RFC4307 or RFC4307bis so what they implement
or not should not be taken into consideration.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Nov 2015 10:57:15 +0900

> On 3 Nov 2015, at 9:42 AM, Tero Kivinen <[email-masked]> wrote:
> 
> John Mattsson writes:

To elaborate a bit: there are a whole bunch of algorithms in each category, and we didn’t want to grab the entire table from IANA. 

The document lists the MUSTs and SHOULDs. That is the purpose of the document. Other algorithms are mentioned only if they’re ones that have previously been widely implemented and widely deployed, and that we believe it is time for them to no longer be so widely deployed. That is why DES, 3DES, MD5 and Group 2 get special mention. RC5 has never been very popular in IPSec, and the same can be said for Blowfish, Tiger, KPDK_MD5, and brainpoolP512r1. So we don’t mention those.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Nov 2015 11:04:11 +0900

> will not be able to talk to each other.

I'd rather point to the minimal-IKE

https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-00

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Nov 2015 11:04:50 +0900

But we should explain that in the introduction :)

Sent from my iPhone

> On Nov 3, 2015, at 10:57, Yoav Nir <[email-masked]> wrote:
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Nov 2015 06:30:00 +0200

> https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-00

Minimal IKEv2 cannot modify the mandatory to implement algorithms.
LWIG charter says that:

	The group shall focus only on techniques that have been used
	in actual implementations and do not impact interoperability
	with other devices. The techniques shall also not affect
	conformance to the relevant specifications.

I.e. the minimal IKEv2 should still be interoperable with any IKEv2
client. We had this discussion there when we said that even when
certificates are mandatory to implement in IKEv2, they are not
mandatory to use, i.e. you can also use shared key authentication
(which is also mandatory to implement).

The minimal IKEv2 cannot say that implementations should use some
specific algorithm unless that is mandatory to implement, as otherwise
it would not be interoperable to existing IKEv2 implementations
implementing only mandatory to implement algorithms.

Thats why minimal IKEv2 will not say anything about the algorithms, as
that would not be in charter with LWIG WG.

Here in the IPsecME WG, we can do that, i.e. I think adding separate
section for constrained devices, and list what algorithms they should
implement is good idea. 
-- 
[email-masked]