Subject: Re: [IPsec] RFC4307 update

From: Daniel Migault <[email-masked]>
Date: Mon, 5 Oct 2015 12:16:06 +0000

Hi, 

There is a need to have that kind of document for 3GPP/SA3. Unless someone has already written the update, I can provide one by the end of the week.

BR, 
Daniel   

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, September 28, 2015 3:41 PM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] RFC4307 update

Yoav Nir <[email-masked]> wrote:
    >> Tero Kivinen <[email-masked]> wrote:
    >>> We did update cryptographic algorithms for ESP and AH
    >>> (RFC4305->4835->7321), but we have never updated the RFC4307.
    >>
    >>> I think there should be update for that document too, as it now
    >>> defines following madantory to implement algorithms:
    >>
    >>> 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96.
    >>
    >>> And I think at least the 1024-bit MODP groupp, and perhaps the 3DES
    >>> also should be changed to something more suitable. For exmple
    >>> 2048-bit MODP group and ENCR_AES_CBC...
    >>
    >> I guess the can-o-worms called ECDSA will show up too as a SHOULD+.

    > Does it have to? 4307 does not mention any signature algorithms. ECDH
    > with NIST curves and/or the new curves might should make an appearance.

Sorry, that's what I meant to write, but my finger slipped.

    >> Does 3DES go to MAY?

    > I think so.

    >> Does SHA1 go to MUST-?
    >>
    >> We hadn't listed SHA2 at all before.  We also have no GCM/CCM things
    >> specified.
    >>
    >> Are we obligted to list them as SHOULD+ for awhile?

    > I think we should reflect what is common/best practice now. AES-GCM is
    > now widely implemented and faster than the combination of AES-CBC and
    > HMAC-SHA-something. I think it’s a prime candidate for MUST. CTR was
    > always uncommon. ChaCha20+Poly1305 is so new that it can't be MUST this
    > iteration. Maybe next time.

Agreed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Fri, 9 Oct 2015 13:57:17 +0300

> On Sep 28, 2015, at 6:10 PM, Paul Hoffman <[email-masked]> wrote:
> 
> Sure. Someone volunteer to write up the short draft, and that author should put Jeff Schiller at the top of the acknowledgements, and send it to the WG.
> 
> --Paul Hoffman

A new version of I-D, draft-nir-ipsecme-rfc4307bis-00.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.

Name:		draft-nir-ipsecme-rfc4307bis
Revision:	00
Title:		Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
Document date:	2015-10-09
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-nir-ipsecme-rfc4307bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nir-ipsecme-rfc4307bis/
Htmlized:       https://tools.ietf.org/html/draft-nir-ipsecme-rfc4307bis-00

Abstract:
  The IPsec series of protocols makes use of various cryptographic
  algorithms in order to provide security services.  The Internet Key
  Exchange protocol provides a mechanism to negotiate which algorithms
  should be used in any given association.  However, to ensure
  interoperability between disparate implementations, it is necessary
  to specify a set of mandatory-to-implement algorithms to ensure that
  there is at least one algorithm that all implementations will have
  available.  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.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Oct 2015 08:19:13 -0400 (EDT)

> has been successfully submitted by Yoav Nir and posted to the

Oops. Guess our drafts crossed the beams. I had send one to Daniel
to look at. I've attached it in case some text is useful. It was
based more on the structure of RFC 7321.

I actually like how 7321 has the tables filled with links to the
actual RFC's. (which I had not done yet myself)

Some comments on your text:

I think AES_CBC should be MUST- as it is on the way out.

I have talked with one of the AES_GCM authors and got the advise to
only use the largest octet ICV's. Why are you promoting the 8 octet
version instead of the 16 octet version? I also think AES_GCM should
be a MUST, not a SHOULD. It is the preferred algorithm at this point.

I also think 3DES probably should be a SHOULD- because it is the only
other non-AES algorithm in widespread use. While we all want it to go
away, we should do so only after chacha20-poly1305 sees more adoption.

Why is sha2-512 not a SHOULD?

Can we add a recommendation to use integ == prf for non-AEAD algorithms?

Windows uses 8192 modp, which I think should be a SHOULD. I think we
should mention modp 1536 as SHOULD- or MAY.

Can we recommend that the initial exchanges and create child sa use
the same MODP group? and that we recommend PFS for create_child_sa.

Can we recommend that a default proposal set should have at least one
MUST algorithm for each type?

Can we recommend not to apply these recommendations for IKEv1 because
that will cause more interop problems (see my draft for text)

Paul

---

From: Daniel Migault <[email-masked]>
Date: Fri, 9 Oct 2015 10:17:47 -0400

Hi,

Here are my comments on the draft:

I would thought:
AES_CBC is no more than MUST- for interoperability but could be dowgraded
also to SHOULD.

In addition I would also have recommend max length IV for AES-GCM unless
there is special constrains like IoT devices.
AES-GCM with a 16 octet ICV MUST
AES-CCM with a 16 octet ICV MUST

Especially thinking of constrained devices.
AES-GCM with 8 octet SHOULD : the reason for not having SHOULD+ is that
most IoT devices seems to use CCM
AES-CCM with 8 octet SHOULD+

I would have thought of 3DES with similar or slightly less weight as
CHACHA20_POLY1025 so
CHACHA20_POLY1025 SHOULD
3DES SHOULD or SHOULD-

I also agree we should mentionned that recommendation only applies to
IKEv2.

BR,
Daniel

On Fri, Oct 9, 2015 at 8:19 AM, Paul Wouters <[email-masked]> wrote:

>>> Sure. Someone volunteer to write up the short draft, and that author
>>> should put Jeff Schiller at the top of the acknowledgements, and send it to
>>> the WG.
>>>
>>> --Paul Hoffman
>>>
>>
>>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Oct 2015 10:52:32 -0400 (EDT)

On Fri, 9 Oct 2015, Daniel Migault wrote:

> AES-GCM with 8 octet SHOULD : the reason for not having SHOULD+ is that most IoT devices seems to use CCM

I would prefer that constrained devices put their specs in draft-ietf-lwig-ikev2-minimal

https://tools.ietf.org/html/draft-ietf-lwig-ikev2-minimal-03

Or that we list that those versions should only be used if the server is
talking to constrained devices. But maybe that's too much text, and we
should stick to SHOULD (as most implementations handle all octet sizes
anyway)

> I would have thought of 3DES with similar or slightly less weight as CHACHA20_POLY1025 so

Without actual interop and deployment experience, I would not yet want
to officially prefer CHACHA20_POLY1025 over 3DES.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Fri, 9 Oct 2015 18:04:00 +0300

Hi.

I’ll reply to Daniel’s and Paul’s comments. Note that this draft is a starting point to feed into discussion. Just like this kind of discussion.

Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only one algorithm, the choice for maximum interoperability would be AES-CBC. This is the same as 3DES-CBC when RFC 4307 was published. I didn’t make it a MUST- because I don’t know what the next MUST is going to be.

AES-GCM: “8 octet ICV” vs “16 octet ICV” - that was a mistake. Of course I meant 16, and I will fix it in -01. As for requirement level, as far as I know, AES-GCM got a lot of adoption for IPsec, but not so much for IKE. Why? Because it is only defined since RFC 5282, and also because it cannot be used in IKEv1, and also because its speed advantage doesn’t matter much in IKE. My implementation does not have it for IKE (just an example)

AES-CCM: Why a MUST?  I don’t have any interest in implementing it. 

So with no clear direction on what the next “go to” algorithm is going to be, I don’t think it’s time yet to hint at AES-CBC’s deprecation.

SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm. Do we need it? The future seems to be AEAD algorithms, so do we really need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be the future?

"Can we add a recommendation to use integ == prf for non-AEAD algorithms?” - I don’t thin we can in this document. That would be changing IKE, no?

Group 18 (8192 bits) - IMO this is so slow that I don’t like making it a SHOULD.

"Can we recommend that the initial exchanges and create child sa use
the same MODP group? and that we recommend PFS for create_child_sa.”

The former is a sensible recommendation, but it belongs in 7296, not here. 
As for recommending PFS, I’m not sure. This is not the same as TLS. PFS in TLS prevents exposing encryption keys with the future exposure of a long-term secret - the private key.
In IKE the IPsec encryption key depends not on the long term secret, but on another ephemeral value - the SK_d. This is far less problematic, so I’m not sure such a recommendation is worth the cost.

"Can we recommend that a default proposal set should have at least one
MUST algorithm for each type?”

I didn’t understand this. What is a default proposal set?

"Can we recommend not to apply these recommendations for IKEv1 because
that will cause more interop problems (see my draft for text)”

I think we should just ignore IKEv1 at this point. You definitely should not use AES-GCM with IKEv1.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 9 Oct 2015 18:16:51 +0300

RFC 4307 just barely mentions key lengths, by implying that ENCR_AES_CBC 
really means AES-128-CBC. I think the new document should be clear about 
recommended key lengths for the relevant algorithms. This may be opening 
a can of worms, but you don't have interoperability without it.

Thanks,
	Yaron

On 10/09/2015 06:04 PM, Yoav Nir wrote:
> Hi.
>
> I’ll reply to Daniel’s and Paul’s comments. Note that this draft is a
> starting point to feed into discussion. Just like this kind of discussion.
>
> Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation
> with only one algorithm, the choice for maximum interoperability would
> be AES-CBC. This is the same as 3DES-CBC when RFC 4307 was published. I
> didn’t make it a MUST- because I don’t know what the next MUST is going
> to be.
>
> AES-GCM: “8 octet ICV” vs “16 octet ICV” - that was a mistake. Of course
> I meant 16, and I will fix it in -01. As for requirement level, as far
> as I know, AES-GCM got a lot of adoption for IPsec, but not so much for
> IKE. Why? Because it is only defined since RFC 5282, and also because it
> cannot be used in IKEv1, and also because its speed advantage doesn’t
> matter much in IKE. My implementation does not have it for IKE (just an
> example)
>
> So with no clear direction on what the next “go to” algorithm is going
> to be, I don’t think it’s time yet to hint at AES-CBC’s deprecation.
>
> SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm.
> Do we need it? The future seems to be AEAD algorithms, so do we really
> need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be
> the future?
>
> "Can we add a recommendation to use integ == prf for non-AEAD
> algorithms?” - I don’t thin we can in this document. That would be
> changing IKE, no?
>
> As for recommending PFS, I’m not sure. This is not the same as TLS. PFS
> in TLS prevents exposing encryption keys with the future exposure of a
> long-term secret - the private key.
> In IKE the IPsec encryption key depends not on the long term secret, but
> on another ephemeral value - the SK_d. This is far less problematic, so
> I’m not sure such a recommendation is worth the cost.
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Oct 2015 11:32:43 -0400 (EDT)

On Fri, 9 Oct 2015, Yoav Nir wrote:

> Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only one algorithm, the choice for maximum
> interoperability would be AES-CBC. This is the same as 3DES-CBC when RFC 4307 was published. I didn’t make it a MUST- because
> I don’t know what the next MUST is going to be.

Fair enough.

> AES-GCM: “8 octet ICV” vs “16 octet ICV” - that was a mistake. Of course I meant 16

Good.

> requirement level, as far as I know, AES-GCM got a lot of adoption for IPsec, but not so much for IKE. Why? Because it is
> only defined since RFC 5282, and also because it cannot be used in IKEv1, and also because its speed advantage doesn’t matter
> much in IKE. My implementation does not have it for IKE (just an example)

For us (libreswan) it was stalled because the codebase had a bunch of
CBC assumptions in the code. It took more time to change those and so
CTR and GCM stalled. I was actually surprised that when we were ready
with ikev2, that ikev1 didn't even specify it. I guess I agree there
is no real advantage that we know of, except the general statement
about AEAD security versus ENCR+INTEG being better. If we can avoid
timing based attacjs or oracles that would be a plus?

> AES-CCM: Why a MUST?  I don’t have any interest in implementing it.

That came in via the MUST for ESP in RFC7321. I don't particularly want
it.

> So with no clear direction on what the next “go to” algorithm is going to be, I don’t think it’s time yet to hint at

Fair enough. But I think these discussions should be summarized
similarly to RFC 7321 - which is why I also had written a "Rationale"
section.

> SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm. Do we need it? The future seems to be AEAD
> algorithms, so do we really need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be the future?

For non-AEAD I'm a little nervous to only have HMAC-SHA-256. I think we
might want to have HMAC-SHA-512 as a temporary stopgap in the future,
although once we have SHA-3 we could again drop it for a SHA-3 version.

> "Can we add a recommendation to use integ == prf for non-AEAD algorithms?” - I don’t thin we can in this document. That would

Well, our algo/cipher changes also modifies IKE (7296) doesn't it? I
don't think 7296 makes any recommendations. (also I did put in "updates
7296" in my text :) The reason I'm asking was that we ran into this
because libreswan only supports specifing PRF for AEAD and otherwise
picks the INTEG as PRF. This caused us to fail a TAHI test. I had to
argue about that failure, and I'd rather have some RFC text to do the
arguing for me.

> Group 18 (8192 bits) - IMO this is so slow that I don’t like making it a SHOULD.

hmm, okay. I would like something non-ECC that's larger than 2048
though.

> The former is a sensible recommendation, but it belongs in 7296, not here. 

Same as above. I would be good to have it somewhere, because I've had
this discussion a few times as well. Why not here, where we talk about
IKE crypto recommendations specifically. It seems the right place to me.

> As for recommending PFS, I’m not sure. This is not the same as TLS. PFS in TLS prevents exposing encryption keys with the
> future exposure of a long-term secret - the private key.
> In IKE the IPsec encryption key depends not on the long term secret, but on another ephemeral value - the SK_d. This is far
> less problematic, so I’m not sure such a recommendation is worth the cost.

Then we wasn't it dropped from CREATE_CHILD_SA? What we have now is that
different implementations with different defaults cause interop issues
on CREATE_CHILD_SA. (which is nasty when problems only show up at rekey
time)

> I didn’t understand this. What is a default proposal set?

The defaults in the configuration. If the administrator sets no explicit
proposals or proposal elements. So if the software starts negotiating
the admin forcing the algorithms, there is guaranteed to be a proposal
that will work because it only uses MUST's. Again, this is to enhance
interoperability.

> I think we should just ignore IKEv1 at this point. You definitely should not use AES-GCM with IKEv1.

Again, as implementor/vendor it really helps me to have RFC text somewhere
that makes this clear so I don't have to argue with customers on why we
don't support GCM for IKEv1.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Oct 2015 11:43:25 -0400 (EDT)

On Fri, 9 Oct 2015, Yaron Sheffer wrote:

> recommended key lengths for the relevant algorithms. This may be opening a 
> can of worms, but you don't have interoperability without it.

If we do, I suggest recommending 128/256 and demoting 192 to MAY. No one
uses 192 that I know, although I dont enter TLA datacenters much :P

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 10 Oct 2015 08:07:19 -0700

<co-chair hat on>

There seems to be interest in the WG in adopting this work, and it seems 
that draft-nir-ipsecme-rfc4307bis is a reasonable starting point 
(although there is already some good debate about the specifics).

Yoav and Tero: please resumbit this document as 
draft-ietf-ipsecme-rfc4307bis with any changes you have seen from the 
past few days that you want.

WG: we will make this an active topic of discussion (along with our 
other topic, closing out the DDoS document).

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 12 Oct 2015 16:50:34 +0300

> That came in via the MUST for ESP in RFC7321. I don't particularly want

I think AES-CCM is useful to have as SHOULD, as it is useful in
certain environments, but I do not want to mark it as MUST, as it is
not used in other environments.

On the other hand I assume that in practice those IoT implementations
are going to ignore this completely, and only implement the ciphers
they use, and they will not be implementing all mandatory to implement
ciphers, as they do not have space for them. 

> > SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity
> > algorithm. Do we need it? The future seems to be AEAD algorithms,
> > so do we really need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3
> > based is going to be the future?
> 
> For non-AEAD I'm a little nervous to only have HMAC-SHA-256. I think
> we might want to have HMAC-SHA-512 as a temporary stopgap in the
> future, although once we have SHA-3 we could again drop it for a
> SHA-3 version.

I think having HMAC-SHA2-256 now, and adding longer SHA3 based PRF in
future might be better. 

> Well, our algo/cipher changes also modifies IKE (7296) doesn't it?

No this document does not change RFC 7296. The RFC 7296 does not
specify mandatory to implement algorithms just for this reason. I.e.
they are left out from the IKEv2 rfc, and moved to this separate RFC.

> I don't think 7296 makes any recommendations. (also I did put in
> "updates 7296" in my text :) The reason I'm asking was that we ran
> into this because libreswan only supports specifing PRF for AEAD and
> otherwise picks the INTEG as PRF. This caused us to fail a TAHI
> test. I had to argue about that failure, and I'd rather have some
> RFC text to do the arguing for me.

I think adding text that would say INTEG == PRF in this document would
be changing the IKEv2, and would make several implementations
non-complient with the this RFC, or at least go against SHOULD in here
if they do allow INTEG != PRF.

Also there is no need that INTEG would need to be same as PRF. Even if
the AUTH_AES_XCBC_96 is fine for the integrity algorithm, I am much
more happy to use HMAC_SHA2 as PRF, than to use the AES128_CBC as PRF
(there are some concerns about how good PRF it really is).

Oh, btw we need to fix the name of the PRF_AES128_CBC, it should be
called PRF_AES128_XCBC. It is XCBC not CBC (the title of RFC4434 says
AES-XCBC-PRF-128).

And we could make IANA action in this draft to fix the name in iana
registry too. 

> hmm, okay. I would like something non-ECC that's larger than 2048

We are writing mandatory to implement algorithms list, you are free to
implement longer groups. If you have implemented 2048-bit group,
adding longer groups is not an issue. On the other hand if we want to
make any other group as SHOULD, we should stick to the 3072 or 4096
bit groups, which provide more than enough security when you take in
to account of memory required to crack those groups. 

> IKE crypto recommendations specifically. It seems the right place to me.

Actually I can see that people might want to use long Diffie-Hellman
for the IKEv2 SA, just to get maximal protection for all traffic, and
then do fast Diffie-Hellman every few minutes when they rekey their
traffic keys.

So I do not think such recommendation would be good.

> > As for recommending PFS, I’m not sure. This is not the same as
> > TLS. PFS in TLS prevents exposing encryption keys with the future
> > exposure of a long-term secret - the private key. In IKE the IPsec
> > encryption key depends not on the long term secret, but on another
> > ephemeral value - the SK_d. This is far less problematic, so I’m
> > not sure such a recommendation is worth the cost.
> 

If one end has unsecure policy which you do not want to accept, the
right fix is to either allow that policy which you consider unsecure,
or fix the configuration of the other end.

Yes, there can still be misconfigurations with IKEv2 too... 

> > "Can we recommend that a default proposal set should have at least
> > one MUST algorithm for each type?” I didn’t understand this. What
> > is a default proposal set?
> 

We do not have default configuration. Also nothing we write here does
not affect anybody USING ciphers. We only specify what must be
implemented, we do not specify what will be used.

It seems you would like to write profile document describing default
configuration for IKEv2? I do not think such profile belongs to this
document, but you can write new UI Suite document and define your
default cipher settings, and other configuration parameter settings.
Then you can refer to that... :-)

And yes, we might want to specify new UI suites especially for the
CHACHA20_POLY1305...

> don't support GCM for IKEv1.

You should argue, that as IKEv1 was obsoleted 10 years ago, it needs
to be obsoleted from the implementations too...

Or at least it should be disabled by default for all configurations,
and it can only be enabled in the configuration by explitly adding the
value of "Pre-Shared key for the Internet Protocol" in configuration
file, and if you do not know the key listed in that draft, there is no
way to enable ikev1... :-)
-- 
[email-masked]