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

From: Toerless Eckert <[email-masked]>
Date: Wed, 17 Jun 2020 19:04:03 +0200

Seems as if the reply to this sub-thread was overlooked, sorry.

In the ACP, a node has multiple IPsec connection, each of which acts like a
virtual link to another node and each of them will carry IPv6 packets
with arbitrary IPv6 source and destination adresses.

So the ideal, most compact option is:

Tunnel Mode. ESP payload (Next Header) is IPv6 (41)
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

This is not IPinIP. IPinIP would be if the IPv6 packet inside the ESP
encapsulation itself would have a next header field of 41 and and we
would have another IPv6 packet there.

I guess we could set the IP protocol selector to 41, but browsing through
RFCs, i can not find a single example where this is done, instead all
TSi examples use 0.

Transport Mode: Payload = ESP Next Header is GRE (47)
TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr)
TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-addr)

These two choices are somewhat arbitrary, i am sure some vendor
not following this draft will later come and complain that he
prefers GRE in tunnel mode or IPinIP tunnel or transport mode,
but those profiles can always easily be added through later RFCs
if there is sufficient support by updating the ACP RFC and would
work proprietarily between vendor devices anyhow even today. For now i think
it is most interesting for ACP to have what is the most compact header
(tunnel mode) and one alternative showing use of ttransport mode
and hopefully useful to vendors with legacy gear that most often
has GRE tunnel interfaces but not explicit IPsec interfaces.

Here is the current tentative text, please yell if NOK:

-- native:

<t> An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41). It MUST use local and peer link-local IPv6 addresses for encapsulation.  Manual keying MUST NOT be used, see <xref target="domcert"/>. Traffic Selectors are:</t>

<t>TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)</t>
<t>TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)</t>

<t>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 (and no additional encapsulation header in the ESP payload), it would only be possible to send packets originated by the ACP node itself because the IPv6 address of the ESP must be the same as of the outer IPv6 header.</t>

-- GRE:

<t>The requirements for ESP/IPsec/IKEv2 with GRE are the same as for native IPsec (see <xref target="IPsec"/>) except that IPsec transport mode and next protocol GRE (47) are to be negotiated. Tunnel mode is not required because of GRE. Traffic Selectors are:</t>

TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr)
TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-addr)

<t>If IKEv2 initiator and responder support IPsec over GRE, it has to be preferred over native IPsec.  The ACP IPv6 traffic has to be carried across GRE according to <xref target="RFC7676"/>.</t>

--

Cheers
    Toerless

On Thu, Feb 27, 2020 at 12:41:55AM +0200, Yoav Nir wrote:
> 
> 
> > On 26 Feb 2020, at 19:56, Michael Richardson <[email-masked]> wrote:
> > 
> > 
> > Yoav Nir <[email-masked]> wrote:
> >> The draft says ???IPsec tunnel mode is required ???, so it???s not
> >> transport. What goes in the TS payloads?
> > 
> > TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41)
> 
> 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: Paul Wouters <[email-masked]>
Date: Wed, 17 Jun 2020 13:59:18 -0400 (EDT)

> prefers GRE in tunnel mode or IPinIP tunnel or transport mode,

Note that you cannot _require_ transport mode, as the IKEv2
protocol only allows you to _suggest_ transport mode. The peer
can reject that suggestion and insist the connection uses
tunnel mode.

Paul

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 17 Jun 2020 20:31:27 +0200

> can reject that suggestion and insist the connection uses

But we do define a profile of use of IPsec that both sides need to support
to ineroperate. So what specifically does prohibit a specificartion of such
a profile to require to support and prefer one mode over the other ?

This is a peer-to-peer communication solution, so no interop
with devices not confirming to this spec.

Cheers
    Toerless

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Jun 2020 16:01:25 -0400 (EDT)

> with devices not confirming to this spec.

The profile is about protocol choices you agree to set in the
profile. These choices are expected to be negotiated, eg encryption via
AES_GCM, or encryption via CHACHA20_POLY1305. Your profile can say to
pick one of these or both, because the protocol allows that.

But the protocol does not provide the profiles a way to say "MUST
do transport mode". The protocol only provides a way to say "Prefers
transport mode".

Technically, your profile could say to "request transport mode, and
refuse the connection if the other end is unwilling to use transport
mode", but that I would argue that would constitute a protocol
modification which is not what a profile should do.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jun 2020 20:36:15 -0400

> can reject that suggestion and insist the connection uses

I don't agree.

The IPsec WG does not mandate transport mode in order to be compliant to
RFC4301 and RFC7296.

If I ask for transport mode, and the other end does not agree to do it, I can
certainly drop the negotiation.

The ANIMA WG *can* write a stronger requirement, because that does not
contradict RFC7296.  We can't make something optional that IPsec requires,
(such as ESP without authentication, or other dumb thing).

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jun 2020 20:37:36 -0400

> modification which is not what a profile should do.

How is this different than:
  "request authentication with a RSA certificate known to this CA,
  and refuse the connection if the other end is unwilling to use an appropriate
  key"

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Jun 2020 20:55:12 -0400 (EDT)

>  and refuse the connection if the other end is unwilling to use an appropriate

The RFC states:

    The USE_TRANSPORT_MODE notification MAY be included in a request
    message that also includes an SA payload requesting a Child SA.  It
    requests that the Child SA use transport mode rather than tunnel mode
    for the SA created.  If the request is accepted, the response MUST
    also include a notification of type USE_TRANSPORT_MODE.  If the
    responder declines the request, the Child SA will be established in
    tunnel mode.  If this is unacceptable to the initiator, the initiator
    MUST delete the SA.

But note that the responder has already installed the IPsec SA in tunnel
mode. So if the initiator finds that unacceptable, it must send the
delete. During all this time, connectivity between the nodes will be
blocked. The intention here is that transport mode is optional and
should not be mandated by other protocols. Otherwise, the IKEv1
style negoation of transport OR tunnel mode would have been kept.

So I would recommend to follow the intention of RFC 7296 and not make
up your own restrictions.

Whether a certain CA is acceptable is a configuration matter. There is
no text in the RFC that states which certificates you must trust.

Paul

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Jun 2020 03:57:33 +0200

> style negoation of transport OR tunnel mode would have been kept.

How about my mails ask that i read this text such that the initiator will
delete the SA (not only client SA) if transport mode is not supported
be responder. Aka: the last two sentences to me describe exactly the
case where the initiator can/want only support transport mode.

Aka: i can not read your interpretation into this text.

Please answer the other questions from my reply mail.

> up your own restrictions.

Again, i had a lot of arguments in my email that i need to see answers
to so that we can make progress here.

Cheers
    Toerless

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Jun 2020 21:03:23 +0300

[talking as individual and one of RFC7296 authors, not as WG chair].

> >    responder declines the request, the Child SA will be established in

At this point the responder already created an Child SA in tunnel
mode, and when the initiator receives that message from the responder
it will also create the Child SA in tunnel mode. Responder might
already be sending traffic at this point.

This means both initiator and responder MUST implement tunnel mode, as
otherwise they cannot perform those actions. Meaning as the fallback
from the transport mode is tunnel mode, all implementations MUST
implement it even if it not explictly said in the RFC.

> > If this is unacceptable to the initiator, the initiator
> >    MUST delete the SA.

This thing happens after the Child SA is created. I.e., now the
initiator will check whether the Child SA created was following its
policy, and it is completely valid for the initiators policy to say
that must use transport mode, and then it will delete the SA as it was
not following its policy.

It still means that the initiator implementation MUST implement tunnel
mode, but it does not have to USE it if it does not feel like doing
that.

The MUST/SHOULD etc only give requirements for the implementors, i.e.,
what features MUST or SHOULD be implemented and what MAY be
implemented. In the RFCs we cannot use those keywords to instruct
adminstrators/users what they should use.

Quite often, especially in the security considerations section, we try
to give requirements to the users, but we need to be very carefull not
to do that. We can give information to users saying "do not use low
entrypy passwords as PSK as they are known to be unsafe", but we
cannot say MUST NOT use low entropy passwords, as there is no easy for
for implementor to enforce that.

For every single MUST or SHOULD and especially MUST NOT or SHOULD NOT
you are writing to the RFC, you should think how can you answer to
question from the customer who says, "show me the lines in your
implementation which implements this MUST or SHOULD". For MUST and
SHOULDs, that is usully still quite easy, but when someone asks "Show
me the lines of code where you implement: This notification MUST NOT
BE sent by an entity that may be replicated"....

(and yes, I have had incoming customer support case, where they asked
for every single MUST/SHOULD/MUST NOT/SHOULD NOT where it was
implemented in the source of our toolkit). 

> > style negoation of transport OR tunnel mode would have been kept.

Also the delete notifications might get lost, and it might takes tens
of seconds, or even minutes before the initiator can finally tell the
responder that the Child SA that didn't follow its policy is deleted.

> case where the initiator can/want only support transport mode.

Initiator and responder can delete whatever SAs they like whenever
they like. That does not matter to the actual case here. The issue
there is that if the responder does not want to do transport mode,
then SA will be created in tunnel mode, and the initiator must be able
to cope with tunnel mode ESP packets it is receiving from the
responder. I.e., it needs to be able to implement tunnel mode as much
it understands those packets and does something to them (dropping them
is fine, as if his policy says he wants to get transport mode packets
and do not allow tunnel mode packets, then it is fine to have policy
dropping all tunnel mode packets).

> Aka: i can not read your interpretation into this text.

Anyways, this discussion is not really useful. If the other end does
not support transport mode (as it is allowed to do by IKEv2, as
transport mode is optional), there is nothing you can do to make it
support transport mode, and deleting the Child SA will just cause
initiator to try again few seconds later when it gets next packet to
that direction, with exactly same bad result.

It would be much better to simply say that SHOULD use transport mode,
as it is more efficient for GRE, but if other end does not support
transport mode, using tunnel mode still gets the connectivity, even
when we are wasting few bytes.

In IPsec we had so much issues in IKEv1 where every single option and
feature knob needed to be exactly right to get any connectivity, that
in IKEv2 we tried to get rid of exact negotiation things, instead we
propose something, and we do have fallback to go if other end does not
accept our proposel.

Transport -> tunnel is one of those. IPcomp -> no IPcomp is another,
traffic selector narrowing is third, getting rid of negotiated
lifetimes for SAs was yet another one etc.

The basic idea is that when you finish IKEv2 exchange you have
"usable" child SA you can use to send and receive traffic.

Whether it was exactly what you wanted is another thing, and whether
you can accept that, is initiator choise, and if he cannot accept it,
he can delete the SA and be without connectivity compared to
non-optimal connectivity.

Also as I have understood that your nodes are security gateways (not
hosts, as they do forward packets from other nodes) the RFC4301
already says that they:

   b) A security gateway MUST support tunnel mode and MAY support
      transport mode.  If it supports transport mode, that should be
      used only when the security gateway is acting as a host, e.g., for
      network management, or to provide security between two
      intermediate systems along a path.

Meaning tunnel mode is mandatory to implement in those devices
anyways. The use of tunnel mode is completely different matter then. 

> to so that we can make progress here.

I do disagree with Paul that I think profiles can require certain
optional features to be implemented and used from the base standard,
if it makes sense in there. That does not mean that you can remove
features from the base standards, so even if you do say you use GRE
with transport mode, the IPsec implementations used still need to
implement tunnel mode too, as that is part of the base standard, but
of course you do not need to allow that to be configured, so detecting
use of that might be difficult.

So I think it is ok to say that SHOULD (or even MUST) implement
transport mode for GRE, but it is not ok to say that tunnel mode would
be OPTIONAL, as that would make it so that it cannot connect to the
conforming IKEv2 implementations not supporting transport mode.

We had similar discussion in the RFC7815 minimal IKEv2. That document
really only covered the Shared key authentication even when the base
IKEv2 do require also PKIX certificates and RSA signatures. It does
use one of the mandatory to implement features of the IKEv2, thus it
can talk to all conforming IKEv2 implementations, thus
interoperability is there, but cannot do both of the required
authentication methods, which does not cause problems as full
implementations need to support both anyways.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Jun 2020 23:19:11 +0300

[talking as another individual and co-author of RFC7296, not as the other chair]

> On 18 Jun 2020, at 21:03, Tero Kivinen <[email-masked]> wrote:
> 

I half agree. RFC 7296 describes IKEv2, not IPsec. An IKEv2 implementation must support the creation of a tunnel-mode Child SA. It may configure an IPsec layer that does not support tunnel-mode.

I think it’s compliant with the letter if not the spirit of RFC 7296 to have a specialized IKEv2 implementation that can negotiate a tunnel mode SA, but immediately deletes such an SA if it is created, and I think such an implementation will also be compliant if it rejects any CREATE_CHILD_SA request that does not include the USE_TRANSPORT_MODE notification.

Of course none of us would use such an implementation in our VPN gateway, but it can be appropriate for special uses, such as host-to-host within a datacenter.

Having said that, supporting tunnel mode as a fallback and making transport a SHOULD is still a good idea. Tunnel mode has a per-packet extra cost of 20 or 40 bytes, but it’s generally better than no communications at all.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Jun 2020 17:07:15 -0400

> adminstrators/users what they should use.

Sigh. Again.

The Autonomic Control Plane is established by automatic mechanisms,
not by "administrators". That is, we have a protocol that acts as the
"administrator" in this case.

So, yes, we (ANIMA) can use BCP14 to say what the "configured" policy will be.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 19 Jun 2020 01:36:14 +0200

THanks, Tero, inline

> [talking as individual and one of RFC7296 authors, not as WG chair].

Is there some new IETF liability insurance that make us say this ?
Ok: i am also only talking as an individual and ACP draft author and not was WG chair.  ;-))

> implement it even if it not explictly said in the RFC.

[deleted question i wanted to ask here as you answer it below.]

Sounds as if IKEv2 is effectively not built to allow optimizing the
classical transport option case. For example using IPsec for transport
connections of protocols, such as IGPs, BGP or the like. I 
did write the doc for how to use IPsec transport mode with RFC4601
PIM, alas, security was never widely used for such signaling, so
RFC7761 completely removed it. But if somebody ever wanted to write
a good profile for such use cases, they would run into this
tunnel over transport issue.

> adminstrators/users what they should use.

I guess it is left up to the implementer to figure out that
implementing support for tunnel mode in IKEv2 doesn't mean that
it does have to actually implement support for it in the
forwarding plane / ESP.

> BE sent by an entity that may be replicated"....

Yeah, and it gets more tricky with the distinction of MUST in
IKEv2 which may or may not be read to be inclusive to actual
forwarding plane / ESP requirements.

> implemented in the source of our toolkit). 

I ould like to imagine it is satisfying to be such a large customer that
you can not only answer but also make your vendor answer those questions,
but in my experience those customers than also had to write long reports
about the ansers ;-)

I would love to see "protocol implementation compliance specification"
or whatever you might call it, but i have given up asking for it in the
IETF itself, and given ho i work for a vendor it is of course
masochism ;-)

> responder that the Child SA that didn't follow its policy is deleted.

Ok.

> Anyways, this discussion is not really useful.

Well, i find your, Yoav and Pauls explanation very helpful. May i
dare to say: Also because of the lack of similar explanations in the RFCs.

> If the other end does

Well in the case of ACP we're fine with the way IKEv2 works, the
MUST is on tunnel mode without GRE (just IP in IP), and the MAY
is on GRE with transport and prefer that when available. I
primarily wanted to make sure we have enough of a basis written
to know what could be negotiated. Older router may likely prefer
and fsaster implement GRE, hence its useful. But there is not
a lot of need IMHO to have a lot of profile requirements because
most connections will be between routers from the same vendor
and they can extend the profile as they wish.

> propose something, and we do have fallback to go if other end does not

Understood. Thats also why i am worried and maybe have written more
than necessary requirements to ensure interop into ACP.

And given how the main use of IPsec are VPN across IPv4 with
all the NAT crap, it is quite useful to start with that as
the first negotiation result.

> lifetimes for SAs was yet another one etc.

Options Galore

> anyways. The use of tunnel mode is completely different matter then. 

Yepp. The 4301 text describing limitations of transport mode
does of course not cover the case where transport mode is used in
conjunction with another tunneling protocol like GRE. 

> conforming IKEv2 implementations not supporting transport mode.

Yepp. Paul and i only got into this argument because i was surprised
to learn about the IKEv2 details given my divergent experience
from practice and the (sorry) not very explanatory IKEv2 rfc text.
Luckily no conflict with the requirements in the ACP doc from what i can tell.  

> implementations need to support both anyways.

Thanks again for all the insight

Toerless

-- 
---
[email-masked]

---

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 19 Jun 2020 03:16:07 +0200

Picking up some leftover open points.

On Wed, Feb 26, 2020 at 03:10:55PM -0500, Paul Wouters wrote:
> 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.

ACP nodes would never need to talk directly to a Microsoft CA, but
an ACP registrar might. Such as a registrar using BRSKI. 

Question: Would a registrar be able to convert the encoding of the certificate
(chain) between pkcs7 towards a Microsoft CA and whatever RFC7296 prefers,
i guess "X.509 Certificate - Signature" towards the enrolling/renewing client ?

If that conversion is possible, we are done, because then its up to
each vendors registrar implementation to do this, at best we might
put a note into the non-normative part of ACP (operations of registrars)
or nothing. But given how ACP is an OPS area document, i think the
WG/area appreciates help operationalizing systems, and not only
creating strict protocol specifications.

Alas, in the pre-standard implementations of ACP i used, we always used
pkcs7 towards client, which is why i haven't been able to try to figure
out the answer to this question. Given how i hope its just container
formats, i hope the answer is yes.

Cheers
    Toerless

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Jun 2020 22:28:37 -0400

> i guess "X.509 Certificate - Signature" towards the enrolling/renewing client ?

Yes. 

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 19 Jun 2020 10:15:55 +0300

Hi Tero,

> already be sending traffic at this point.

The initiator is not obliged to actually create the Child SA if it violates
its policy (i.e. to actually load it into kernel). It's true that it should immediately 
send a Delete Payload in this case as if the SA has been created and then deleted, 
but it doesn't mean that it should actually create the Child SA to send the Delete payload.

Regards,
Valery.

---

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 19 Jun 2020 16:51:12 +0200

In ACP, we use IKEv2 between peers without assumed methods to retrieve
certificates from "external" sources like http repositories. And CA most
likely will have non-public Trust Anchor (TA) (enterptrise PKI).

Imagine a large multi-tenant network infrastructure (office building, skyscraper)
where each tenant runs their own network. It is easy to see how ACP nodes
can be misplugged and unintentionally connect to a different tenants ACP
node, or more likely, or where the building owner has not updated the
L2 segmentation of the office areas according to tenancy. In this case the
TA will not match, but the problem is how help troubleshoot the problem
by being able to identify which other tenants (PKI) is on the other
side of a non-working ACP connection.

Michael Richardson was suggesting to include the cert of the TA into the
IKEv2 certificate exchange. This was rejected by Valery/Paul and the suggestion
was to use CERTREQ instead.

In my reading of CERTREQ, it would not help in this situation, because the
hash of an unknown TA does not progress the troubleshooting much as there is 
in general no offline way to resolve it. In addition, that hash would
AFAIK already be available from the Signature of the cert (chain)
received from the peer. CERTREQ seems to only help the peer to select 
the right Cert (chain) to send back in case it has multiple, but not to
learn the peers TA details when there is no match. Pls correct me if i am wrong.

So i am tentatively adding the following text:

<t>CERTREQ MUST be used to indicate the ACP TA hashes. This helps the peer in selecting the ACP certificate in case it has certificates also from other TA. It is RECOMMENDED for IKEv2 to be set up such that it will only use the ACP certificate/TA when acting as a responder on the transport endpoints indicated in DULL GRASP for the ACP.</t>

Let me know if there is something wrong with this.

Nevertheless, this does not solve the original troubleshooting issue
Michael wanted to resolve. From what i figure i can only write
text that IKEv2 does not support this troubleshooting and that
instead this should be solved by adding diagnostics information,
such as the TA certificate to DULL GRASP (but that would be for
future work).

Let me know if you can think of a way to "legally" send the full
certificate of the TA during IKEv2 exchanges.

Thanks
    Toerless

On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote:
> > > 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)?
> > 
> > I agree it should not try to dictate how certificate based IKE
> > certification works, but just reference to IKEv2 and its updates for
> > that.
> 
> That was my point :-)
> 
> > >      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.
> > 
> > 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?
> 
> Agree.
> 
> Regards,
> Valery.
> 
> > Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Jun 2020 13:10:37 -0400 (EDT)

> was to use CERTREQ instead.

Normally, you do not include the TA itself, only intermediate root's and
the EE-cert. The CERTREQ contains the hashes of _all_ trust anchors
supported by that party, not just the one it is thinking of using right
now with the exchange in progress.

> received from the peer.

Basically, in IKE_SA_INIT, before the IKE_AUTH and CERT payloads
exchange, you exchange CERTREQ. You basically give a somewhat anonymised
list of trust anchors you support. The initiator can loop through its
known TA's and if it matches one, pick the proper certificate if there
is one for that TA.

The reason sending hashes and not the root CA's is that it becomes very
easy to determine which CA's a particulat client supports. I know that
is elpful to troubleshooting, but it was deemed a security/privacy
issue.

> CERTREQ seems to only help the peer to select

That is correct.

> <t>CERTREQ MUST be used to indicate the ACP TA hashes. This helps the peer in selecting the ACP certificate in case it has certificates also from other TA. It is RECOMMENDED for IKEv2 to be set up…

I'm not sure how much of your protocol involves talking to different
parties that might have to install each others root CAs. Usually,
either everyone shares the same (private) root CA because the root CA
is an enterprise wide trust anchor, or if the connection is between
two enterprises that are independent, administrators use PSK because
neither one wants to trust a root CA maintained by the other.

So the problem you describe hardly happens. But I'm not familiar with
your uses cases.

> Let me know if there is something wrong with this.

I would not say MUST. If both parties know they have the same root CA
installed, the IKEv2 protocol does not require you send that Root CA
hashed in a CERTREQ. SHOULD would be better here?

> certificate of the TA during IKEv2 exchanges.

Nothing prevents you from including the root CA (TA) in the CERT
payload. It is perfectly valid. There is a privacy/security risk
of revealing the root your trust. But that's your risk to evaluate.

If you want to convey you are trusting many roots, then CERTREQ is
the better place. You dont want to send 150+ root CAs over IKE.
Presumbly, since you have 1 configured EE-cert to use for this
connection, it will chain back to one intermediate/root CA ? That's
the one you can just send as part of the CERT payload.

Paul

---

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 19 Jun 2020 20:40:30 +0200

> neither one wants to trust a root CA maintained by the other.

For use across ACP, all nodes MUST have the same set of TA to mutually
authenticate each other, so CERTREQ would not make sense. I am just
trying to figure out the prior suggestions on this thread by Michael et. al.
that we should use CERTREQ, but have a hard time figuring out why.

What i thought to understand is this:

Responder has a lot of different set of TA, but only one of them
for use with ACP. These sets MAY have common TA. How should the
responder select which cert to send back to initiator.

CERTREQ from the initiator would help if the set of ACP TA is
disjoint from the TA used for other IKEv2 uses on the responder.
But that may not be the case.

Aka: I think i will not bother with CERTREQ unless someone gives me
a fully worked out suggestion how to use it beneficially. But i
think i will keep the text saying that IKEv2 for ACP needs to
run on a transport endpoint where ONLY use of ACP certificate
and TA is assumed.

> hashed in a CERTREQ. SHOULD would be better here?

See above. I am inclinded to completely remove the sugestion to
use CERTREQ.

> of revealing the root your trust. But that's your risk to evaluate.

Ok. Then i will keep that text and check where to put the
discussion about the confidentiality of root CA problem.

> the better place. You dont want to send 150+ root CAs over IKE.

Sure.

> the one you can just send as part of the CERT payload.

Normally yes. But when you have M&A (Mergers and Aquisitions) you
would need to support multiple TA, but you would only send the TA cert
from which your own cert is derived. Thats sufficient for
troubleshooting.

Thanks!
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Jun 2020 13:25:59 -0400

Paul Wouters <[email-masked]> wrote:
    > exchange, you exchange CERTREQ. You basically give a somewhat
    > anonymised list of trust anchors you support. The initiator can loop
    > through its known TA's and if it matches one, pick the proper
    > certificate if there is one for that TA.

Unless we can convince various people otherwise, the TA will all be private
enterprise/ISP CAs.

    > is elpful to troubleshooting, but it was deemed a security/privacy

We are not dealing with "clients", because this is not a remote access
scenario.   Nor are these system visible in any way to the Internet.
"Physical" connectivity is required.  (In quotes, because microwaves,
satellite systems and other layer-2 transmission media)

This is an overlay network of ISP routers that use IPsec over IPv6
**Link-Layer** addresses.  The privacy considerations are significantly
different, while the need to do troubleshooting significantly higher.

Sending the *complete* trust chain solves the problem, and should never cause a
problem to any properly implemented daemon/certificate chain validator.

    > is an enterprise wide trust anchor, or if the connection is between two
    > enterprises that are independent, administrators use PSK because

At private ISP peering points, at IXPs (until discovered and disabled), and
when cables and/or systems are mis-attached, the ACP may attempt to connect
across security boundaries.    This is intended in almost all cases to fail.

Knowing what peers were rejected helps significantly in determining if some
cables were misconnected.  Since a goal of the ACP work is to reduce the
expense (dollars and CO2 emissions) of deploying new network equipment, one
can expect that over time the quality of the "remote hands" will find a new
lower bound.

(While we conceive of inter-ISP secure channels that might require
cross-installation of trust anchors, those are just talk at this point)

    > So the problem you describe hardly happens. But I'm not familiar with

...

    > payload. It is perfectly valid. There is a privacy/security risk of
    > revealing the root your trust. But that's your risk to evaluate.

Good, we are in agreement here.

---

From: 'Toerless Eckert' <[email-masked]>
Date: Mon, 22 Jun 2020 04:21:56 +0200

Thanks, Valery

let me pick up the one point i have no clear text solution for yet.

On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote:
> Hi Toerless,
[...]
> 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.

Ok, so lets assume initiator and responder being routers may have multiple
certificates for diffent purposed. The initiator knows it needs to use
the ACP certificate because the IKEv2 was triggered for the purpose of ACP.

The responder can also know that it must use the ACP certificate from the
transport address that it listens to: This are link-local scope IPv6
addresses with a UDP port number that is signalled in a discovery protocol.
That way a responder can bind an IKEv2 instance that has only the ACP
certificate available.

When we assume that initiator and responder can perfectly well constrain
themselves to their ACP certificates, it sounds almost as if we would
want to mandate to NOT USE CERTREQ, because that would cause
termination of the IKEv2 exchange before exchange of certificates
takes places. And from what i read in rfc7296, CERTREQ is optional,
so we can mandate NOT to use it.

If i take our explanation, in the absence of CERTREQ, the initiator
would send the cert chain, including TA (additional requiremement from
ACP profile), and we would have the necessary informtion on the
responder side - even if the mutual authentication then fails.

I do not fully understand the sequence of events, e.g.: if this approach
only works for one side (for the responder learning the TA of the
initiator), or if it would only work for the other side.

Pls. let me know, i can accordingly adjust the text.

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

The signaling of TA is meant to help (human) diagnostics of authentication failure,
not to make authentication successful. The candidate text for rev -25 has 4 examples.
Lots of options for misconfigurations in large enterprises, no other way to
get to the TA of a device trying to connect to you, etc. pp.

Cheers
    Toerless

> Regards,
> Valery.
> 
> > > > > 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???
> > > >
> > > > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo
> > > > (SPKI) ASN.1 object" ?
> > >
> > > 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".
> > 
> > ;-) Going once, going twice ? ... If not, i'll follow this advice
> > 
> > Thanks!
> >     Toerless
> > 
> > > Regards,
> > > Valery.
> > >
> > > > Paul
> > >
> > > _______________________________________________
> > > IPsec mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
---
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Sun, 21 Jun 2020 23:37:58 -0400

On Jun 21, 2020, at 22:22, Toerless Eckert <[email-masked]> wrote:
> the ACP certificate because the IKEv2 was triggered for the purpose of ACP

Yes.

> transport address that it listens to:

Yes 

> takes places.

What is causing termination ?

> And from what i read in rfc7296, CERTREQ is optional,

This is going to be the same discussion we had with transport mode. You should not try to modify the IKE protocol. 

The protocol allows you to send it and allows you to ignore the contents of it. That should be fine for your use case. 

> responder side - even if the mutual authentication then fails.

If you know who it is you are supposed to talking to based on an IP, why do you even need a CA chain? Seems two self signed certs configured on both ends work too. In that case, the IKE implementation would also not bother with CERTREQ (and maybe even CERT, but I’m pretty sure our implementation would still send it)

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Jun 2020 20:42:53 -0700

> If you know who it is you are supposed to talking to based on an IP, why do you even need a CA chain? Seems two self signed certs configured on both ends work too. In that case, the IKE implementat…

It's not quite "you know who you are talking to based on IP", but more of
"under this precondition, you know that the peer should be part of the same
ACP domain, and thus using the same TA as you".  But you don't know exactly
which peer in the domain, and thus which EE cert, you're going to get.

The case that (IIUC) triggered this subthread is when things are wired
badly and you end up actually talking to someone in a different ACP domain,
i.e., with a different TA.  We want to be able to report what that
"unexpected" TA is, so that the mis-wiring can be diagnosed more readily.

-Ben

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 22 Jun 2020 08:29:18 +0200

Inline

On Sun, Jun 21, 2020 at 11:37:58PM -0400, Paul Wouters wrote:
> > ???Thanks, Valery

Thats what i concluded from Valery's description to happen if the
CERTREQ sent does not contain any TA hash that the recipient can
match. If the functionality of CERTREQ is instead such that its
just advisory and the replying side would/could/should still sent
back a cert with a TA not in the CERTREQ , that would be good
to understand.

> The protocol allows you to send it and allows you to ignore the contents of it. That should be fine for your use case. 

so if the diagnostics we want would only be possible by ignoring the
CERTREQ, that seems to be an option then which should need to be
made clear in the ACP spec.

Cheers
    Toerless

> If you know who it is you are supposed to talking to based on an IP, why do you even need a CA chain? Seems two self signed certs configured on both ends work too. In that case, the IKE implementation would also not bother with CERTREQ (and maybe even CERT, but I???m pretty sure our implementation would still send it)
> 
> Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 22 Jun 2020 17:42:00 +0300

Hi Toerless,

> so we can mandate NOT to use it.

And I think that prohibiting sending CERTREQ is really bad idea for the profile.
The better idea is to require ignoring CERTREQ content on receipt if you think 
it's not useful in your use case, but not banning sending it.

> responder side - even if the mutual authentication then fails.

If I understand you correctly, you just want to include TA
in CERT payload only for diagnostic purposes, right?
Why Issuer DN from the last certificate in the chain before the TA is not sufficient?

> initiator), or if it would only work for the other side.

Only responder will learn the TA of the initiator.
In case of misconfiguration the responder will receive 
the IKE_AUTH request that it will not be able to verify
(because it doesn't have the right TA). In this case 
the responder must send back AUTHENTICATION_FAILED
notify, and this is the only information the initiator will obtain.
The reason why authentication failed and the TA the responder
would use will remain unknown for the initiator in this case.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 22 Jun 2020 17:51:16 +0300

Hi Ben,

> "unexpected" TA is, so that the mis-wiring can be diagnosed more readily.

I still have an impression that this can be achieved without adding TA to the CERT payload.
For example, the last cert in the path before the TA will have an Issuer DN 
of TA, so you'll have some information anyway...

Regards,
Valery.

---

From: 'Toerless Eckert' <[email-masked]>
Date: Mon, 22 Jun 2020 20:47:37 +0200

> of TA, so you'll have some information anyway...

Ok, so the ask to include TA cert into the signaling was raised by Mcr fairly
late in the process, so from that side, i could argue it's too late and this
discussion here is holding back the ACP draft too much.

Then again, i spend probably a lot of time in labs and with customers
troubleshooting in networks ACP and other IPsec security-association/certificate
issues because of the security associations, so the need for actually
STANDARDIZING diagnostic capabilities is really dear to my heart,
and given how i didn't dare to bring it up, but Michael did, he has to call
timeout. And given how this is an OPS area document we should think it
is important.

To your point: I think it is prudent to design a complex system solution
with the best diagnostic we can think of upfront, instead of trying to
add step by step diagnostic only after we have witnessed and tracked
sufficient enough evidence it is needed. I call this the "how many
dead children do we need before we approve the traffic crossing"
problem.

I think examples of where DN would not be sufficient (and its in the -25
text) would be expired certs from the correct CA, or certs from
a misconfigured registrar with CA - where the operator unintentionally
re-created a CA with the same DN, instead of going to the correct CA.

But that last paragraph made me fall into the trap of me arguing the 
names of kids i am predicting to die, and i think thats not how we should
design systems wrt. diagnostics.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: 'Toerless Eckert' <[email-masked]>
Date: Mon, 22 Jun 2020 20:56:27 +0200

> it's not useful in your use case, but not banning sending it.

Yepp, figured that from Pauls response.

> in CERT payload only for diagnostic purposes, right?

Yepp.

> Why Issuer DN from the last certificate in the chain before the TA is not sufficient?

See other mail.

> would use will remain unknown for the initiator in this case.

Ok, thanks. I think ACP can deal with this. Need to heck the
text we have and see whas missing...

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 23 Jun 2020 10:10:51 +0300

Hi Toerless,

> timeout. And given how this is an OPS area document we should think it

Well, this is the essence of my concerns: it seems to me that the issues 
you describe are not explicitly anima related issues, instead they are generic IPsec 
misconfiguration issues. If you believe they are so important, then they must be addressed
in the ipsecme WG, and not by profiling IPsec explicitly for anima.
(Unless I'm missing something about specificity of these issues for anima).

> dead children do we need before we approve the traffic crossing"

I agree with this in general, but in security protocol there is always 
a tradeoff between better diagnostics and leaking additional information
to a potential attacker. Often the latter outweigh.

> re-created a CA with the same DN, instead of going to the correct CA.

Expired certs can be detected locally, I don't believe this is a problem
(I assume your clock skew is not too large). In case your TA was replaced
by the newer cert with the same DN as result of rollover, you'll
have the Authority Key Identifier from the last cert in the path,
so you'll be able to determine which particular TA with the same DN
your peer intended to use...

> design systems wrt. diagnostics.

:-)

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Jun 2020 16:40:53 +0300

Michael Richardson writes:
> Unless we can convince various people otherwise, the TA will all be
> private enterprise/ISP CAs.

And for some reason those same private enterprise/ISP people are
exactly those who say that we can't leak our CA certificates out, and
thats why we can't have publicly available repository of our
certificates or CAs, which of course lead to problem if you mandate
sending that private information whoever ever wants to ask it... 

> different, while the need to do troubleshooting significantly higher.

Ok, that clarifies some things. 

> Sending the *complete* trust chain solves the problem, and should
> never cause a problem to any properly implemented daemon/certificate
> chain validator.

That might not solve anything even when you send the final TA.

It does not really help when you get TA which has Subject name of
"CN=Root", and Issuer name of "CN=Root".

There is still no information where to go to find out who is the owner
of the TA. If those are private TAs created by private
enterprises/ISPs there is no guarantee that the TA itself has anything
useful in it that allows you to identify who created it. This is
especially true if the certificate hiearchy is created automatically
by the vendor software without any actual user interaction.

Yes, the TA might have something useful but it might not.

On the other hand the Identity the other end sent might also have
something useful or might not.

If we look at different information available during IKEv2 negotiation
to the endpoint of the exchange.

During IKE_SA_INIT we might have Vendor IDs indicating the vendor of
the implementation. This usually is hash of something, and it is
always priprietary format, meaning you can recognize familiar vendors
(i.e., you can map vendor you have seen before to vendor ID it sent
before), but you cannot map random vendor ID to vendor. Anyways this
might give you some debugging information.

Then we have CERTREQ from the responder, i.e., we know which trust
anchors it trusts, and we get hash of those keys it trust.

The main idea there is to allow initiator to select one of the
certificates he has in such way that he proposes certificate signed
by one of those trust anchors. As both ends are supposed to be
configured with trust anchors which they trust in, and from which they
have certificates from, they can map this hash to actual trust anchor
without any problems.

Creating a mapping from trust anchor hash to trust anchor is trivial
if you ever see the actual trust anchor certificate anywhere.

If you ever have more than one TA ever in normal operations you want
to mandate sending CERTREQs always. 

In the IKE_AUTH you have CERTREQ from the initiator, containing all of
the trust anchors from the initiator, even when it used certificate
from the only one of them. This allows responder to use different trust
anchor when responding, i.e., initiator might use TA1, and responder
might use TA2, but both trust in both TA1, and TA2, but they just
happen to have certificates from different TAs.

In addition to that there is CERT from to initiator, if initiator does
not already know that the responder has its certificate. In some
setups the TA hierarchy is properly made and each peer can find
certificates from somewhere else, and there is no need to send them
inside IKEv2 at all.

In most common case you always send end entity certificate inside the
IKE_AUTH so other end can verify it against its TA and match it
against the identity.

Note, that the certificate itself include Subject Name telling who
this certificate was created for, and Issure Name telling who signed
it.

If the certificate hierarchy and names in the hierarchy are properly
set there is no need to send TA. If the Subject name is "CN=device1,
OU=HR Department, O=Example Inc, C=US", and the Issuer name is
"CN=Root TA 2020, O=Example Inc, C=US", that already gives you all
information you need to find out who is the owner of the cert. If the
names are stupid like Subject name of "CN=device1231", and Issuer Name
of "CN=Root" that does not help to get TA, as the TA again just have
both Issuer Name and Subject Name of "CN=Root" which does not help
you.

Then there is still the IDi and IDr identities, those tell the
identity of the peer. Depending on what identities are in use they
might be very useful for debugging (like "[email-masked]" and
"[email-masked]") or they might be completely useless like "10.5.0.1"
and "10.1.0.1".

Anyways sending TA only helps at all if the one who created the TA
actually put some useful information in there, and if he did that,
then the same information is already in the EE, thus seeing the TA
does not really help. 

I would just put suggestion saying that whoever is creating those
certificate hierarhies, they should use proper naming and include the
name of the company etc in the Subject name of the certificates... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Jun 2020 16:56:31 +0300

> your peer intended to use...

All certificate validation issues are something that can really only
be debugged locally. In one of the implementations I was aware of
there were about half a dozen different error codes returned during
the validation problem each listing all errors it hit during the
validation, and there is no way of knowing which of them is the actual
final cause of the validation failure.

I mean you could get LDAP_UNREACHABLE, EXPIRED_CERT, SELF_SIGNED_CERT
during the same validation check. This might have been caused because
you hit expired intermediate certificate, and there happend to be
temporary failure to refetch that intermediate certificate from the
LDAP server, and because of thise LDAP failure you used another cross
signed certificate ending to the self signed trust anchor which you do
not trust.

So you get all those tree errors, and the real issue was the
LDAP_UNREACHABLE. On the other hand it might have also been that the
problem was the intermidiate certificate was expired, and there was no
new certificate issued for it because of operation problems, and the
LDAP_UNREACHABLE came because we cannot connect to the ldap server
specified in that cross signed trust anchor, i.e. the correct problem
was EXPIRED_CERT etc...

Trying to find out what was the real reason why certificate validation
failed is very complicated issue, and usually trying to do it by just
having certificate chains is not enough. The only somewhat easy way is
to look at the logs of the device and hope they are detailed enough to
tell you these kind of things...
-- 
[email-masked]

---

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 26 Jun 2020 18:10:53 +0200

> sending that private information whoever ever wants to ask it... 

I hope -25 captures this accordingly. 

   Signalling of TA certificates may not be appropriate when the
   deployment is relying on a security model where the TA certificate
   content is considered confidential and only its hash is appropriate
   for signalling.  ACP nodes SHOULD have a mechanism to select whether
   the TA certificate is signalled or not.  Assuming that both options
   are possible with a specific secure channel protocol.

Btw: i have not heard an explanation why a CA cert would have to
be secret other than the classic "security by secrecy" dogma.

Do you have an actual example why a CA cert would need to be kept secret ?

I can only think of something like oh, the Coca Cola Root Certificate
having the Coca Cola recipe in one of its fields as a human proof
of authenticity of the certificate. But i can't imagine a ral
case where this has been done. Although it sounds like a fun idea
to be able to claim in court that a cert was creted by a holder of
a particular non-cypto secret. Alas, that claim would then mean
you would hve to reveal that non-crypto secret to court.

In any case: If there is an actual crypto root CA in a company,
you can always create a non-secret TA as a subCA without any of the
secret information in the rootCA. IMHO!

> "CN=Root", and Issuer name of "CN=Root".

Of course not, but it is a lot easier to put diagnostic information
into the root-CA that you may actually have manually crafted
instead of the automatically enrolled EE or even potentially also
automatically created intermediate CA certs. Like rfc822Name
addresses of actual human contacts.

> by the vendor software without any actual user interaction.

Yes, there are no mandates whatsoever for any form of transparency
to support diagnostics. The goal of the technology choices made is to
support diagnostics if so desired by the operator deploying the
solution. Mandating any level of transparency is beyond the reach
of this spec.

> might give you some debugging information.

Yepp. As i said in before, as much as i like to do as much for
diagnostics in ACP as possible, i will not be the one asking for
anything new to be put into ACP, because the whole IETF/IESG review
goes on for years already, so it needs to finish so we can work on
all those additional good ideas via followup documents.
> have certificates from, they can map this hash to actual trust anchor

Sure. But i still fail to see an example where this would be really helpfull.

I get the idea, but the root problem is that a particular IPsec
session is opened by the initiator for a particular functional
purpose. Different VPNs, different ACP, etc. pp. As soon
as the certificates for different purposes where derived
from overlapping TA, CERTREQ does not help to identify the
purpose. And IPsec implementations are prone to not
support binding to different UDP ports for different purposes,
so there are always workarounds needed to support multiple
purposes on the same device simultaneously.

> if you ever see the actual trust anchor certificate anywhere.

Sure. You just need to have seen the actul trust anchor cert once.

> to mandate sending CERTREQs always. 

See above. To actually ensure that the other sides cert chain
is signalled even when connection fails (for diagnosstics),
the certreq must be ignored, which is fine, but given how it
was also not helpfull (IMHO) to determine the purpose and hence
valid TA in the first place, i consider it to be a well
meaning but not useful option.

But always happy to hear solutions that would only work when it is used.

> happen to have certificates from different TAs.

yepp. i think i understand how it works.

> certificates from somewhere else, and there is no need to send them

Sure. actually the more common case. Albeit also one that i think
should be avoided as much as possible because it just creates
additional compllexity / third party dependencies. TO me its just
an optimization when there are lots of possible TA (whole set of
web CA for example), or a lot of connections for which setup is to
be optimized.

> both Issuer Name and Subject Name of "CN=Root" which does not help

yepp.

> "[email-masked]") or they might be completely useless like "10.5.0.1"

Hah. Ok, so this is an interesting point. I didn't try to
understand this part so far and was just taking in the advice
to use the ID_IPV6_ADDR from the certs ACP domain informatin field
The more complete ID would have actually been the complete
ACP domain information field, which would be possible too because
IKEv2 also supports ID_RFC822_ADDR, which is the forward we have
for the domain information field. Alas, there are IMHO unjustified
dogmatic concerns about using rfc822addr at all, so it wouldn't
really help to suggest using this also as the ID in IKEv2 for
our case - however logical and iseful IMHO that would be.

Are there actual configs in typical IKEv2 implementations
that would allow to tie policies to flexibly matched peer
identifies. And by that i men not IPv4/IPv6 peer identities
but any of the other identitites, all of which are more
descriptive than IPv4/IPv6. ??

> then the same information is already in the EE, thus seeing the TA

Agreed. But see above, this was at least from my side the
intent anyhow (allow CA certs to have diagnostic info).

> name of the company etc in the Subject name of the certificates... 

Yes. Good point to explicitly indicate that signaling TA
is only more useful than not when it has additional
useful diagnostics, sch as e.g.: contact person email or the like.

Cheers
    Toerless

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Jun 2020 22:26:26 +0300

>    are possible with a specific secure channel protocol.

I still consider sending TA certificate ever completely useless
thing, that just wastes bytes. 

Yes.

> Do you have an actual example why a CA cert would need to be kept secret ?

No. I do not think there us any real reason to keep CA secret.

The reason IKEv2 uses hashes is not really about the security it is
about using handle for CA which is small enough that we can send them
in the first packet without causing fragmentation. Happily this same
method also satisifies those same people who think there might be
valid reasons to keep CA cert secret. 

> addresses of actual human contacts.

I do not really belive that. In some systems either everything is
generated automatically (including the TA), or there is some
configuration parts when automatically creating hierarchy and then you
can put things both to EE and CA. Also CA Subject Name is visible in
the EE, so you do not need to put anything specific to EE, you just
need to use useful Subject Name for CA.

> Sure. But i still fail to see an example where this would be really helpfull.

If you ever need to talk to devices that are not part of same
authorization domain you need that feature (unless you want to
provide lots of manual configuration to IKE). 

I.e., if you connect to SGW1, you need to use public/private key pair
and certificate from CA1 to authenticate. And if you connect to SGW2
you need to use different public/private key pair and different
certificate which is from CA2.

You could manually list all possible SGW ip-addresses or names and
configure that they must use specific CA, but that gets diffucult when
the number of SGWs raise, can cause problems when certificates are
renewed, as then you need to update your configuration again.

So what IKEv2 does is that it will connect to the SGW, and SGW will
tell that it requires you to use certificate signed by list of CAs and
that list include for example CA1. Then initiator can select
his own certificate from CA1, and the associated private key and use
that when sending the IKE_AUTH to the other end. If he picks wrong CA,
meaning wrong private key the responder will fail the authentication
and connection is not established.

Note, that the initiator does not really care which of his own private
keys and associated certificate it uses, as all of them identify
himself, he just need to pick something that is suitable for the
remote peer.

What the initiator needs to manually configure is that what kind of
certificates are required by remote peer, i.e., which CA must have
signed the certificate responder used. This is required for security
so SGW1 cannot do IP or DNS hijack and claim to be SGW2 even when
using CA1. Good thing for this is that we just configure that SGW1
needs to authenticate himself with cert from CA1, and SGW2 needs to
use cert from CA2.

Note, that initiator might not have any certificate from CA1 or CA2,
it might actually use completely different CAs, i.e., the list of
certificate authorities can be asymmetric.

> purpose.

It is not supposed to identify the purpose, it is supposed to identify
the CA which the other end is willing to trust, i.e., if you received
CERTREQ you know that other end should accept certificate signed by
those CAs, as the other end trusts those CAs, and trusts the identity
mapping that certificate provides.

> And IPsec implementations are prone to not

In IKEv2 there is IDi, and IDr for specifying purposes mostly. When
initiator connects to the host, it can send both IDi (who he is), and
IDr (who he wants to talk to). Then responder can see that if he
understands IDr (it might be FQDN like example.com or
company2.com), and if so, it will return same IDr for its own
identity. Initiator tells his own identity in the IDi.

Responder can also return something completely different for IDr, if
it does no recognize the IDr, or even if it recognizes, i.e. it might
actually return IDr of mail.example.com when initiator send IDr of
example.com.

This is similar to what TLS and SNI does, or Host-header in the http.

Again this is only hint, and responder can use that information, or it
might ignore it if it feels like so.

> meaning but not useful option.

If you think CERTREQ is not helpful you have not understood how it
works.

Sending full chain including TA is not helpful at all in normal case,
and is only marginally helpful for failure cases. The question is that
do you want to waste resources 99.99% of time so that in the 0.01%
cases there might be slight change that it might be helpful for when
someone starts actually doing debugging.

I think it is better to save bytes 100% of time...

If you assume that you have misconfigurations so often that you want
to send few kilobytes extra stuff for every negotiation, I think there
is something seriously wrong with the architecture of the system in
general. 

> our case - however logical and iseful IMHO that would be.

The identity should be something that identifies the other end. I.e.,
IP address is fine if you are just connecting between ip-addresses.
Random KEY_ID is fine, if you simply map that to something in your
architecture (it could for example be MAC-address).

> descriptive than IPv4/IPv6. ??

I do not think there is typical thing to do. Some implementation do
allow very complex mapping between identity and policy, even perhaps
calling some external API call to do the mapping. Some implemntations
simply make sure that the ID and some field in certificate match.

All this depends where IPsec is used. In VPN setups the identities
usually match either IP-addresses (site to site vpn between fixed
ip-addresses), FQDN (site to site, or host to host), email address
(roaming user to sgw) etc. 

> intent anyhow (allow CA certs to have diagnostic info).

I do not like when we optimize for failure cases and waste
resources just to provide information that might be useful when
debugging. Especially when the content you are sending is binary blob
which is quite meaningless unless you first decode it and show it to
user somehow. What kind of user is going to see these debug printouts
printing out the CA?
-- 
[email-masked]

---

From: 'Toerless Eckert' <[email-masked]>
Date: Tue, 30 Jun 2020 22:28:12 +0200

Thanks a lot, Tero for all your time responding, inline

> thing, that just wastes bytes. 

Luckily it was not me alone who wanted that feature but it was
triggered by Michael, i just was happy to jump to it.

As long as we're fine with the security evaluation i am happy
if something we explore turns out to be useless wrt. diagnostics help.
As i said i am really mostly paranoid about good diagnostics.

> No. I do not think there us any real reason to keep CA secret.

Great.

Sure.

> need to use useful Subject Name for CA.

You because i am paranoid does not mean they are not after me ;-)

I am not able right now to invest the time to compare all
the fileds in a CA cert with what is available in the certs it
signs.

> certificate authorities can be asymmetric.

Good explanation. So, whats the most simple example for this ?
I have a single VPN but multiple geographic headends and
there is an obfuscated logic what certs each headends accepts,
so i do have multiple and certreq helps me to choose ?

I am sure everything is possible, i am just looking for the
most simple example where that is actually used. I think for
a specific VPN all my VPN clients always only had one cert.

> mapping that certificate provides.

Sure... example (see above) would help to get a better feel of this.

> might ignore it if it feels like so.

Ok, so i hope i am correct to state that in general we could have
ignored specifying IDi/IDr in our profile as its not necessary.

I forgot who proposed we put our nodes IPv6 address into this
field, but the IPv6 address itself doesn't seem to be very
useful to identify whether the nodes are in the same network.

The full name of a node was so far an rfc822Name, now i need to
fix it to become what i think is going to be a GeneralName,
and hence it might best be to signal IDi/IDr as ID_DER_ASN1_GN

> someone starts actually doing debugging.

The use-case are long-lived IPsec connections between routers
that would stay up until a node reboots, a link fails or somebody
misplugs a cable. We had network operators that plugged in a UPS
to a router when they moved routers to a new building after 10 years,
just because they wanted to keep their router-uptime record.

For all i care, IKEv2 could be performed by two dancing turtles
singing the packets. There is no advertisement revenue in this
use-case in faster IKEv2 handshake. Not even an annoyed toerless
waiting for his notebook VPN to come up ;-). Sure at some point
in time after this is sucessfull in enterprise SP backbone networks,
we will have to revisit optimizing for low-end IoT, but this particular
issue is by far not the only one for that space.

We disagree on your surely scientifically analyzed benefit of
0.001%. Even a 0.1 % of cases benefit could be a huge benefit.
In big, badly manaed pops, some link diagnostics is taking weeks
for folks to bring in better diagnostics gear. Can i promise
our idea for better IKEv2 diagnostic will help ? No, we can't but
we only need to establish IMHO that it does not hurt, and i think
it does not.

> I think it is better to save bytes 100% of time...

You assume that you have other diagnostics channels, and if you
do, i do agree. In our case we're at the lowest level/first stuff
that establishes connectivity.

> is something seriously wrong with the architecture of the system in

Again, these are not QUIC pages where every msec faster display
of advertisement URLs makes a lot of money. Or annoyed users
like myself waiting for a VPN tunnel to cume up on my laptop.

> architecture (it could for example be MAC-address).

With our current thinking, the GeneralName would be probably something ilke:

  type AcpRealm: node:<ipv6addr>@<acp-domain-name>

Thanks

> debugging.

Please take longevity and core focus of the use-case into account.

> Especially when the content you are sending is binary blob

I imagine a GUI at the NOC of a network operator:

Unauthenticated ACP neigbhor on NodeXXX/InterfaceYYY:
      node:<ipv6addr>@<acp-domain-name>
   Click <here> to see cert chain diagnostics

And <here> would show similar decode of the cert chain including TA
as you would get from e.g.: clicking on the trust icon on a browser.  

Thats about the minimum. I wish we would have not been called back
using rfc822Name for our solution, because then we could have
even easily authenticated such a peer from a different domain
by relying on ACME certificates. Oh well.

Cheers
    Toerless