Subject: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

From: Toerless Eckert <[email-masked]>
Date: Mon, 24 Feb 2020 20:50:14 +0100

[hope its fine to cross-post ipsec and ipsecme given how one is concluded, but may have
 more long-time subscribers]

We're looking for opinions about an IPsec profile for "Autonomic Control Plane"
draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of:

https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt

Quick background so you do not need to read anything more than 6.7.1.1.1:

ACP builds an "overlay"  network with hop-by-hop IKEv2/ESP "tunnels". 
These hops are meant to be typical enterprise/WAN/DC software...Giga/Terrabit routers.

Hence some interest on side of the authors (me) to see how we can adopt the crypto
algorithm rementserofile of RFC8221 to minimize high-speed algorithm implementation 
requirements so that ACP would be as easy to adopt across various vendor crypto HW as
possible.

Note that ACP also supports DTLS, but we think that DLS would primarily
be used in lower-end devices, so crypto woould be done in software
there, hence we do not bother taking the step to try to optimize /
minimize the number of required algorithms.

Here is the adoption of the RFC8221 algorithms:

OTHERS                 - as in RFC8221 (MUST NOT / SHOULD NOT)
ENCR_NULL              - MUST NOT (require confidentiality of payload in ACP)
                         (was MUST in RFC8221)
ENCR_AES_GCM_16        - MUST
                         (was MUST in RFC8221)
ENCR_AES_CBC           - SHOULD if higher perf than ENCR_AES_GCM_16, else MAY                              
                         (was MUST in RFC8221)
ENCR_AES_CCM_8         - SHOULD if higher perf than ENCR_AES_GCM_16, else MAY                              
                         (was SHOULD in RFC8221)
ENCR_CHACHA20_POLY1305 - SHOULD with equal or higher perf than ENCR_AES_GCM_16, else MAY           
                         (was SHOULD in RFC8221)

To make life easy, we have one ESP MTI algo to interop, that's GCM_16.

Because packets will be hop-by-hop forwarded across multiple tunnels,

ACP has no legacy interop requirements. Aka: We only need to think about
the relevant algorithms for device types so old, that they would never
implement ACP (and we have to guess for those devices of course, but we
have some good experience of pre-standard vendor implementations).

Effectively, we downgrade and modify requirements for CBC, CCM_8 and POLY1305
acording to our understandings:

1. Given how we have one MTI (GCM_16), and no further need for legacy compatibility,
   there is no need for additional MTI (MUST), so the remaining desirable algorithms
   can be SHOULD or less.

2. A SHOULD only makes sense in the ACP use case if the actual performance is
   higher than that of the MTI, hence the opportunistic performance
   conditioned SHOULD in CBC and CCM_8. 

   Expectation is that those algos would be supported by a vendor if it
   can make it faster, and then that speed benefit would be had when
   connecting that vendors devices together.

3. POLY1305 is really desirable as crypto backup to the AES options, so
   the performance based SHOULD is not opportunistic as for CBC and
   CCM_8. Maybe the language is not 100% correct.
   
Maybe the language is not perfect. seems like i could leave out all the
"MAY" at the end and achieve the same.

Cheers
    Toerless

---

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Feb 2020 22:17:30 +0200

Hi, Toerless.

I trimmed below most of your background info.

> On 24 Feb 2020, at 21:50, Toerless Eckert <[email-masked]> wrote:
> 

ipsec is this group’s mailing list. I don’t know that there even is an [email-masked] <mailto:[email-masked]>

> Quick background so you do not need to read anything more than 6.7.1.1.1:

I read a little more. Hope you don’t mind.

The profile seems fine to me. There is one thing that I think is missing.

The profile specifies that the ACP nodes should use tunnel mode (when GRE is not used), because:
   IPsec tunnel mode is required because the ACP will route/forward
   packets received from any other ACP node across the ACP secure
   channels, and not only its own generated ACP packets.  With IPsec
   transport mode, it would only be possible to send packets originated
   by the ACP node itself.
OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, but that’s not important here) they need an IPsec policy that specifies traffic selectors so that IKEv2 can specify traffic selectors.  Nowhere in your draft do I see a specification of what traffic selectors need to be negotiated.

If I understand the above paragraph correctly, both the source of the packet and the destination can be the IP address of any ACP node, neither of which are required to be the tunnel endpoints.  This implies some sort of generic traffic selector.  The draft should specify this, IMO

Yoav

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 25 Feb 2020 21:37:51 +0100

On Tue, Feb 25, 2020 at 10:17:30PM +0200, Yoav Nir wrote:
> ipsec is this group???s mailing list. I don???t know that there even is an [email-masked] <mailto:[email-masked]>

Yepp. Silly me. Didn't check that ipsecme was keeping the old mailing list name.

> I read a little more. Hope you don???t mind.
> 
> The profile seems fine to me.

Great!

> There is one thing that I think is missing.
> 

> OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, but that???s not important here) they need an IPsec policy that specifies traffic selectors so that IKEv2 can specify traffic selectors.  Nowhere in your draft do I see a specification of what traffic selectors need to be negotiated.
> 

Great catch.

How about:

The traffic selector for the SA MUST be set to IPv6 ANY ANY (::/0, ::/0).

(was trying to find an RFC with the same requirement, but to difficult to grep ;-)

Cheers
    toerless

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Feb 2020 17:44:10 -0500

Yoav Nir <[email-masked]> wrote:
    > The profile specifies that the ACP nodes should use tunnel mode (when
    > GRE is not used), because: IPsec tunnel mode is required because the
    > ACP will route/forward packets received from any other ACP node across
    > the ACP secure channels, and not only its own generated ACP packets.

It's a VTI-type interface.
The TS should be for hostA<->hostB with protocol GRE.
It could be in tunnel or transport mode.
hostA and hostB are identified, btw, with IPv6 LL addresses.

    > If I understand the above paragraph correctly, both the source of the
    > packet and the destination can be the IP address of any ACP node,
    > neither of which are required to be the tunnel endpoints.  This implies
    > some sort of generic traffic selector.  The draft should specify this,
    > IMO

The GRE layer and the routing protocol would take care of the ::/0<->::/0
needs, not IPsec.

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 26 Feb 2020 01:03:18 +0100

Michael: Yoav talked about the non-GRE case.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Feb 2020 20:20:23 -0500

> Michael: Yoav talked about the non-GRE case.

In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode.
Which is literally the VTI case.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Feb 2020 07:51:19 +0200

The draft says “IPsec tunnel mode is required ”, so it’s not transport. What goes in the TS payloads?

> On 26 Feb 2020, at 3:20, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 26 Feb 2020 17:03:08 +0300

Hi,

a couple of comments.

I think that the profile is generally OK, but it seems to me that a few issues persist.

1. The

   Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be

   supported.  See [IKEV2IANA] for this and other IANA IKEv2 parameter

   names used in this text.

    “PKCS #7 wrapped X.509 certificate” certificate encoding is deprecated and is not used in IKEv2 

     (see https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-11).

     Generally, I see no need for the text that imposes requirements on certificate encoding at all – 

     we never run into the interoperability problems with this? as far as I remember. I suggest to remove this text.

2.   If certificate chains are used, all intermediate certificates up to,

   and including the locally provisioned trust anchor certificate MUST

   be signaled.  See Section 6.10.7 for the sub-CA example in which

   certificate chains are used.

    This is confusing. I read this text as the “MUST” is imposed only if 

    “certificate chains are used”. Does it mean that implementations 

    may skip this “MUST” if EE certificate is directly signed by CA certificate

    and there is no intermediate certificates? Or is it still a chain

    and “if” is relevant to the case when there is no CA and there is a direct trust to EE certificates

    (in which case PKI is not needed at all and you can use RAW public keys)?

     Another point: trust anchors certificates usually are not included in CERT payload in IKEv2.

     I see draft’s a reasoning that this inclusion would allow better network debugging,

     but I’m not sure I can buy this argument. Probably more detailed

     explanation is needed.

3.   IKEv2 authentication MUST use authentication method 14 ("Digital

   Signature") for ACP certificates; this authentication method can be

   used with both RSA and ECDSA certificates, as indicated by a PKIX-

   style OID.

    I think it’s better to rephrase this more accurately: “indicated by an ASN.1 object AlgorithmIdentifier”

    (which may include parameters besides OID).

A typo in the title of 6.7.1.1.2.:  s/RFC847/RFC8247

Regards,

Valery.

From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Tuesday, February 25, 2020 11:18 PM
To: Toerless Eckert
Cc: [email-masked] WG; Michael Richardson; [email-masked]
Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Hi, Toerless.

ipsec is this group’s mailing list. I don’t know that there even is an [email-masked]

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2020 11:18:15 -0500 (EST)

> The TS should be for hostA<->hostB with protocol GRE.

Only if you want to create a routing based VPN. If you do a GRE tunnel,
then you should really stick to transport mode plus GRE traffic
selectors (assuming no NAT - if NAT is involved, transport mode should
be avoided). If you do a non-GRE tunnel, then tunnel mode makes sense if
you still expect trffic from other ACP nodes that need to go through the
tunnel.

> It could be in tunnel or transport mode.

If using GRE, there is likely no need for tunnel mode.

> The GRE layer and the routing protocol would take care of the ::/0<->::/0

Building 0/0 to 0/0 IPsec tunnels based on routing is the least secure
option you can use. So I agree here that in the GRE case, one should not
build 0/0 to 0/0 IPsec policy tunnels.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Feb 2020 12:56:08 -0500

> transport. What goes in the TS payloads?

TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41)

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2020 15:10:55 -0500 (EST)

>      we never run into the interoperability problems with this? as far as I remember. I suggest to remove

Actually we do. We had to add pkcs7 to ikev2 to be compatible with some
windows deployments when intermediate certificates were being sent. On
top of that, Microsoft did it wrong, as the format does not allow a
chain but they added more than one anyway. So if anything, we DO NOT
want to see more pkcs7 in IKEv2.

>     (in which case PKI is not needed at all and you can use RAW public keys)?

I agree it should not try to dictate how certificate based IKE
certification works, but just reference to IKEv2 and its updates for
that.

>      but I’m not sure I can buy this argument. Probably more detailed

They could suggest that for easier debuggint a CERTREQ payload is
included. That has the hash of the CA, which should be good enough.
But again, IKEv2 already specifies this. Why is this document trying
to change IKEv2 certificate processing?

>     I think it’s better to rephrase this more accurately: “indicated by an ASN.1 object

Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo
(SPKI) ASN.1 object" ?

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Feb 2020 15:20:16 -0500

> certification works, but just reference to IKEv2 and its updates for

+1

    >>      Another point: trust anchors certificates usually are not
    >> included in CERT payload in IKEv2.       I see draft’s a reasoning
    >> that this inclusion would allow better network debugging,      but I’m
    >> not sure I can buy this argument. Probably more detailed     
    >> explanation is needed.

    > But again, IKEv2 already specifies this. Why is this document trying to
    > change IKEv2 certificate processing?

By construction, all the certificates in the ACP should be from the same CA.
But, there may be edges that connect to other domains (ISP peering points,
for instance), and it could be that they attempt to connect.  That ought to fail.
What I want, is the knowledge of what the anchors were.
I agree, we could instead include a CERTREQ.

    >>    style OID.        I think it’s better to rephrase this more
    >> accurately: “indicated by an ASN.1 object AlgorithmIdentifier”

    > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo

I have no opinion here.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Feb 2020 00:41:55 +0200

> On 26 Feb 2020, at 19:56, Michael Richardson <[email-masked]> wrote:
> 
> 

If that’s the intention, I don’t see why this should be tunnel mode. Both GRE and IPIP are tunnels, and they do not require ESP tunnel mode to add yet another IP header.

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 27 Feb 2020 11:58:53 +0300

Hi Paul,

> want to see more pkcs7 in IKEv2.

We do support PKCS#7 too, but officially it's not specified for IKEv2 and
thus must not be specified in the profile. 

> certification works, but just reference to IKEv2 and its updates for

That was my point :-)

> to change IKEv2 certificate processing?

Agree.

> Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo

No, as far as I understand the text, it tells that the particular
signing algorithm is indicated in the AUTH payload by inclusion its OID. 
That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1 object 
(and not SubjectPublicKeyInfo or pure OID).

It's probably better to just delete the text in the last sentence "as indicated by a PKIX-style OID".

Regards,
Valery.

---

From: 'Toerless Eckert' <[email-masked]>
Date: Thu, 27 Feb 2020 19:32:25 +0100

Thanks.

I think ACP has no specific encoding preference for the
exchanged certificates, but we do of course MUST support BRSKI
enrolled certificate (chains), and i think PKS#7 is MTI there (Michael ?).

Can PKS#7 certificate chains be converted locally into any potential
other possible IKEv2 supported encoding format ? Then i think ACP
is open to pick any encoding you could suggest to us. Othewise
PKCS#7 is the safe ACP requirement.

More inline.

On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote:
> > >     ???PKCS #7 wrapped X.509 certificate??? certificate encoding is deprecated and is not used in IKEv2
> > >      Generally, I see no need for the text that imposes requirements on certificate encoding at all ???

Ok. Great. I read this as you think this requirement is necessary
to ensure peers can interoperate in exchaning their cert chains
during IKEv2.

> > >     This is confusing. I read this text as the ???MUST??? is imposed only if
> > >     ???certificate chains are used???. Does it mean that implementations
> > >     may skip this ???MUST??? if EE certificate is directly signed by CA certificate
> > >     and ???if??? is relevant to the case when there is no CA and there is a direct trust to EE certificates

There are two things here:

-> Originally i wrote the text without need to include TA in the
   signaled cert chain. Reason: I worked with IPsc implementations
   that did not signal/verify cert chains, and i also think to remember
   that i discussed and was told that the specs do not mandate this,
   so that behavor was a valid option. If you can confirm, that
   compliance with IKEv2 MANDATES the need to signal cert chain
   (eg: through MUST in one of the MANDATORY normative PKI
    references), then i could remove the text if we wanted just to
    have "standard behavior".

-> Michael wanted the additional signaling of the TA for diagnostic
   purposes. When this was added, the original text was not correctly
   adjusted, so now it sounds as if this all only applies IF there is
   more than the node cert and a root (no intermediate CA). That of
   course is wrong. We would always want to signal the cert chain
   including TA (remove "if..." condition).

> > >      I see draft???s a reasoning that this inclusion would allow better network debugging,
> > >      but I???m not sure I can buy this argument. Probably more detailed
> > >      explanation is needed.
> > 

It seems to me as if standard cert processing is primarily concerned
with the minimum mandatory signaling for security. Maybe there
is even the thinking that its a possible security feature that if
you don't know the TA hash, you can not learn the TA cert.

In the case of ACP, we do not care about such possible strange
TA cert hiding security feature.

An ACP can potentially have a bunch of TAs, for example under
mergers & aquisitions. And especially if BRSKI is not used, these
may be provisioned by all type of flawed mechanisms, like broken
SDN controllers. Or incorrectly refreshed. Just think of the
simple local diagnostics when a peer fails to connect and it
for example has the correct TA, but unfortunately an expired
cert for it. TA cert hash mismatch, but easily diagnosed when the TA
cert iss signaled. Without having to go to a possible non-existant
archive of prior TE certs from a company just aquired 9 months ago,
where ACPs where merged.

> > >     I think it???s better to rephrase this more accurately: ???indicated by an ASN.1 object
> > > AlgorithmIdentifier???
> > 

;-) Going once, going twice ? ... If not, i'll follow this advice

Thanks!
    Toerless

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 28 Feb 2020 10:52:02 +0300

Hi Toerless,

> PKCS#7 is the safe ACP requirement.

I believe it's possible to convert. The encoding most widely used
is "X.509 Certificate - Signature", so it's just a certificate without
any envelopes. You may include as many CERT payloads as you wish,
each containing a single certificate. The is also an encoding
for CRLs ("Certificate Revocation List (CRL)").

But as others have already suggested, I'd rather remove all this
certificates stuff from the draft and just point to the RFC7296.

> > > >      (see https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-
> parameters-
> > > 11).

No, we just inherited this support from IKEv1 and didn't removed it from IKEv2 code,
thus slightly violating IKEv2 spec. It's just an implementation feature and I object 
if any IKEv2 based profile will allow it.

>    including TA (remove "if..." condition).

Again, as Paul and others have suggested, I'd remove all certificates-transfer-in-IKEv2 stuff
from the profile and just reference RFC7296. This part of IKEv2 never caused
interoperability problems (AFAIK), so I see no need to mandate IKEv2 behavior here.

> archive of prior TE certs from a company just aquired 9 months ago,

Well, the example you provided doesn't work. In IKEv2 first
the responder sends a list of TA (hashes) he has in a CERTREQ payload.
When the initiator receives it, he checks the list trying to find
a corresponding TA that signed his certificate (or a chain) and if he finds one, then he sends 
back a bunch of his certificates starting from EE and up to (but not including) this TA. 
If the initiator fails to find a proper TA, then the SA fails and no more exchanges take place. 
If he finds one, then there is absolutely no point to send it back
to the responder, as the responder has indicated already that he has it.
The same happens in the opposite direction.

So I still cannot buy this argument.

More general thought: each side performs validation of peer's cert by his own,
using his own trust assumptions. If peer sends you his TA that he will be using while validating your 
identity, then it sounds strange to me, because it's his trust anchor, not yours.
You even cannot check whether it's expired, because peer's clock may skew from yours...

Regards,
Valery.