Re: [IPsec] GDOI and G-IKEv2 payloads

['Toerless Eckert']

On Wed, Feb 07, 2024 at 11:02:33AM +0300, Valery Smyslov wrote:
> Hi Toerless,

[snip]

> I don't think core specification should define how all existing extensions
> of an older protocol could be mapped to the current one, but few general
> words could be added.

I was imagining:

a) A table where each row has two columns, one showing the term for the 
IKEv1/ISAKMP
   extension point, the other the term for the IKEv2 extension point.

   explanations if the functionality achieved by using the new extension point 
is not the
   same (or better) than the old extension point.

b) Understanding whether one could even transparently support the same 
extension functionality
   for ISAKMP and IKEv2 by just using an appropriate API. Aka: The registration 
code point was
   known only to the API provider, so depending on whether ISAKMP/IKEv1 or 
IKEv2 is being used.
   If this is feasible, it would give developers a good understsanding of the 
simplicity of
   migration. If this would not be feasible, then that would point to 
functionalities
   that are not fully backward compatible and/or require more thinking in IKEv2

The solutions that depend on these extensions do also may require some 
non-extension point
"base" functionality of GDOI, so i too wonder about b) just for the GDOI base 
functionality.
For example, i could imagine that for reasons of security some crypto suite 
recommendations
would have changed, so if any deployments of GDOI solutions have some 
performance aspects,
the newer crypto profiles may make that more challenging on older hardware (but 
no idea, from
past memory, IPsec seemed to be a lot more friendly with legacy than TLS ;-).

Cheers
Toerless

> Regards,
> Valery.
> 
> > Cheers
> > Toerless
> > 
> > On Tue, Feb 06, 2024 at 10:31:43AM +0300, Valery Smyslov wrote:
> > > Hi Toerless,
> > >
> > > first G-IKEv2 should be published as RFC. The draft is currently in
> > > WGLC (for a long time), but received very few reviews so far (and many
> > > thanks to all who reviewed it!).
> > > I'm planning to publish an updated version addressing Daniel's review
> soon.
> > >
> > > Once G-IKEv2 is standardized, there is no problem (IMHO) to do the
> > > equivalent of RFC8052 with it.
> > >
> > > Regards,
> > > Valery.
> > >
> > > > How would someone today do the equivalent of RFC8052 with G-IKEv2 ?
> > > >
> > > > On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote:
> > > > > Hi,
> > > > >
> > > > > I've got a question regarding the relation of G-IKEv2 and GDOI.
> > > > >
> > > > > I realized that G-IKEv2 will be the successor of GDOI and would
> > > > > have a
> > > question
> > > > regarding backward compatibility of payloads defined for GDOI. As
> > > > the
> > > underlying
> > > > exchanges for the base key management changed from IKE to IKEv2 they
> > > > will
> > > not
> > > > be backward compatible. Nevertheless, there have been enhancements
> > > > of GDOI for protocols used in the power system domain like GOOSE and
> > > > Sampled
> > > Values,
> > > > which lead to the definition of new payloads for the ID, SA TEK and
> > > > KD
> > > payloads to
> > > > accommodate the power system protocol parameters in RFC 8052.
> > > > Likewise,
> > > using
> > > > the same approach new payloads of the same types have been defined
> > > > to distribute parameters for PTP (Precision Time Protocol) in IEC
> 62351-9.
> > > > >
> > > > > In general, I realized that there are similar payloads available
> > > > > in
> > > G-IKEv2 but I
> > > > was not quite sure, if it was a design criterion to have backward
> > > compatibility for
> > > > extensions/enhancements defined for GDOI to be usable also in G-IKEv2.
> > > Could
> > > > you please shed some light on this?
> > > > >
> > > > > Best regards
> > > > > Steffen
> > > > >
> > > > > --
> > > > > Steffen Fries
> > > > >
> > > > > Siemens AG
> > > > > Technology
> > > > > Cybersecurity & Trust
> > > > > T CST
> > > > > Otto-Hahn-Ring 6
> > > > > 81739 Munich, Germany
> > > > > Phone: +49 (89) 7805-22928
> > > > > mailto:steffen.fr...@siemens.com
> > > > > www.siemens.com
> > > > > [Logo]
> > > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > > Hagemann
> > > > Snabe; Managing Board: Roland Busch, Chairman, President and Chief
> > > Executive
> > > > Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith
> > > > Wiese; Registered offices: Berlin and Munich, Germany; Commercial
> registries:
> > > Berlin-
> > > > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE
> > > > 23691322
> > > >
> > > > ___
> > > > IPsec mailing list
> > > > IPsec@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ipsec

-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] GDOI and G-IKEv2 payloads

['Toerless Eckert']

Well... There may be connection between progressing the draft and these 
extensions.

Given how extensions to GDOI where also done by other SDOs, i would like to 
understand if
G-IKEv2 has done the best to make extensions as painless as possible, 
especially for adopting
extensions previously existing in GDOI. Worst case, G-IKEv2 does make any such 
extensions more
difficult than necessary (not what i would think, just thinking paranoid).

Ideally, i would even like to see a small section in G-IKEv2 that outlines how 
GDOI extensions
can be mapped to G-IKEv2 . If this waas all registry entries in RFC8052, then 
it would
IMHO even be a great exercise for progressing G-IKEv2 to see if equivalent 
registry entries for
G-IKEv2 would be sufficient. And the section i am thinking of would for example 
just be a
comparison of registry tables.

Cheers
Toerless

On Tue, Feb 06, 2024 at 10:31:43AM +0300, Valery Smyslov wrote:
> Hi Toerless,
> 
> first G-IKEv2 should be published as RFC. The draft is currently in WGLC
> (for a long time),
> but received very few reviews so far (and many thanks to all who reviewed
> it!).
> I'm planning to publish an updated version addressing Daniel's review soon.
> 
> Once G-IKEv2 is standardized, there is no problem (IMHO) to do the
> equivalent of RFC8052 with it.
> 
> Regards,
> Valery.
> 
> > How would someone today do the equivalent of RFC8052 with G-IKEv2 ?
> > 
> > On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote:
> > > Hi,
> > >
> > > I've got a question regarding the relation of G-IKEv2 and GDOI.
> > >
> > > I realized that G-IKEv2 will be the successor of GDOI and would have a
> question
> > regarding backward compatibility of payloads defined for GDOI. As the
> underlying
> > exchanges for the base key management changed from IKE to IKEv2 they will
> not
> > be backward compatible. Nevertheless, there have been enhancements of GDOI
> > for protocols used in the power system domain like GOOSE and Sampled
> Values,
> > which lead to the definition of new payloads for the ID, SA TEK and KD
> payloads to
> > accommodate the power system protocol parameters in RFC 8052. Likewise,
> using
> > the same approach new payloads of the same types have been defined to
> > distribute parameters for PTP (Precision Time Protocol) in IEC 62351-9.
> > >
> > > In general, I realized that there are similar payloads available in
> G-IKEv2 but I
> > was not quite sure, if it was a design criterion to have backward
> compatibility for
> > extensions/enhancements defined for GDOI to be usable also in G-IKEv2.
> Could
> > you please shed some light on this?
> > >
> > > Best regards
> > > Steffen
> > >
> > > --
> > > Steffen Fries
> > >
> > > Siemens AG
> > > Technology
> > > Cybersecurity & Trust
> > > T CST
> > > Otto-Hahn-Ring 6
> > > 81739 Munich, Germany
> > > Phone: +49 (89) 7805-22928
> > > mailto:steffen.fr...@siemens.com
> > > www.siemens.com
> > > [Logo]
> > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann
> > Snabe; Managing Board: Roland Busch, Chairman, President and Chief
> Executive
> > Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese;
> > Registered offices: Berlin and Munich, Germany; Commercial registries:
> Berlin-
> > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> > 
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] GDOI and G-IKEv2 payloads

[Toerless Eckert]

How would someone today do the equivalent of RFC8052 with G-IKEv2 ?

On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote:
> Hi,
> 
> I've got a question regarding the relation of G-IKEv2 and GDOI.
> 
> I realized that G-IKEv2 will be the successor of GDOI and would have a 
> question regarding backward compatibility of payloads defined for GDOI. As 
> the underlying exchanges for the base key management changed from IKE to 
> IKEv2 they will not be backward compatible. Nevertheless, there have been 
> enhancements of GDOI for protocols used in the power system domain like GOOSE 
> and Sampled Values, which lead to the definition of new payloads for the ID, 
> SA TEK and KD payloads to accommodate the power system protocol parameters in 
> RFC 8052. Likewise, using the same approach new payloads of the same types 
> have been defined to distribute parameters for PTP (Precision Time Protocol) 
> in IEC 62351-9.
> 
> In general, I realized that there are similar payloads available in G-IKEv2 
> but I was not quite sure, if it was a design criterion to have backward 
> compatibility for extensions/enhancements defined for GDOI to be usable also 
> in G-IKEv2. Could you please shed some light on this?
> 
> Best regards
> Steffen
> 
> --
> Steffen Fries
> 
> Siemens AG
> Technology
> Cybersecurity & Trust
> T CST
> Otto-Hahn-Ring 6
> 81739 Munich, Germany
> Phone: +49 (89) 7805-22928
> mailto:steffen.fr...@siemens.com
> www.siemens.com
> [Logo]
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
> Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive 
> Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; 
> Registered offices: Berlin and Munich, Germany; Commercial registries: 
> Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] leading versus trailing ICV

[Toerless Eckert]

On Thu, Aug 06, 2020 at 08:22:28PM +0300, Tero Kivinen wrote:
> William Allen Simpson writes:
> > > So it might make sense to have the ICV at the end because it is
> > > likely cache hot when needed.
> > 
> > But after removing padding for these stream algorithms, then the ICV is
> > very likely not aligned.  For zero-copy RDMA, it is rather inconvenient.
> > And the IP header cache lines are likely still hot.
> > 
> > Anyway, that's why I'd like to consider at least a negotiated option --
> > as long as it's possible to implement efficiently in Linux and others.
> > We need to hear from more implementers.
> 
> I think it would be a bad idea to have such option. Yes, it might
> offer small gains on environments where the option is picked exactly
> when both ends like it, but when one ends pick it in a way which other
> end does not like, we usually end up big performance penalties.

If IKEv2/IPsec will not allow to negotiate the mutually best option,
then IMHO IKEv2/IPsec option negotiation needs to be improved.

But for a new option, i can not see short-term issues: Nodes for whom the new 
option
will not provide performance enhancements will simply not implement them.
Of course, when the mayority of implementations get a benefit of a new option 
and
the next profile for IPsec makes it mandatory, then those other implementation
will start having a challenge without better negotiations.

> And also it again multiples the testing effort as now you need to add
> to your test suites this combined with all posible ciphers etc.
> 
> This is was one of the main problems with IKEv1, there were so many
> different combinations of different options that to be able to test
> all of them required thousands or tens of thousands of test cases.

Automated regression testing. 

There is certainly the need to distinguish profiling of options between more
agile managed implementations and those who are not.

> Example of similar optimzation causing problems was found during
> interop events when some version (I think it was Linux) was sending
> fragmented packets in reverse order, so the first network packet
> sent/received was the last fragment. The idea was that when receiver
> saw that last fragment it can immediately know how big the final
> packet will be and it can allocate big enough buffer for the packet.
> 
> Then when you combined that with IPsec with per flow policy, meaning
> each TCP/UDP flow might be using different SA, that meant that SGW
> required to store all fragments in memory until it got the last packet
> from the network, which was the first fragment, and only after that it
> could check whether this packet is allowed to pass, and which SA it
> needs to use.
> 
> Then it sent the fragments out, but there was lots of added latency
> because of this. Actually I think there were also implementations
> which did not even store the later fragments, they simply checked the
> later fragments, and found out that they have not seen the first
> fragment that would allow them to be passed, so they dropped them.
>
> The SGW of course then sent the frames out in order, so that the
> receiving SGW can efficently do exit tunnel checks (i.e., check from
> the first fragment that this packet should be allowed, and match later
> fragments with same fragment id to that, and allow them to passed),
> and it then did not need to do same buffering. Of course the final
> destination host now did not benefit at all from this optimization as
> it was negatied by the SGWs in the middle.

If insights like there would be documented more prominentaly, like in a
living IETF document, then they would fsater trickle through implementers.

> So immediately when the options to use start to depend on the
> platform, implementation etc it gets harder and harder to find out
> which will be the optimal combination between two devices, and they
> might end up using suboptimal feature set. And all of those add more
> complexity and combinations that needs to be tested.

Before the next profile changes as to what options SOULD/MUST be supported,
there could be a collection round of evidence: If a new protocol option
has documented performance results in comparison to prior MUST options
that show e.g.: double performance, you will have a hard time to reject
it. If it doesn't have such data, you will have an easy way to reject it.

> Of course if this option is added, it should be something like IPCOMP
> or transport mode, meaning it is off by default, and everybody MUST
> implement case where it is not enabled, then you would only implement
> (and propose) it on cases where it actually benefits you, and
> everybody else would never ever implement it.

I think thats what i also said above.

Cheers
Toerless

> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
---
t...@cs.fau.de

___

[IPsec] Tero: Re: Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

[Toerless Eckert]

On Tue, Jul 21, 2020 at 10:54:25AM -0400, Michael Richardson wrote:
> > Sometimes the problem is that there are devices there which do not
> > support ECDSA at all, which means you are stuck with RSA for both root
> > and EE for all devices. With CERTREQ some parts of the network can
> > start use full ECDSA TA and EE and still interoperate with those
> > devices which support both and get the "coolness" factor of not using
> > RSA at all :-)
> 
> I think that we say that we will tolerate RSA :-)
> So you are right: there could be devices which do not do ECDSA on day one,
> and in which case, you can't switch the keys at all.

I don't think this issue applies to ACP because both RSA and ECC / ECDSA
certificates are mandatory. Please check 
draft-ietf-anima-autonomic-control-plane-27,
section 6.1.1. I hope this should be sufficient, if not, then any text
fixes welcome.

Remember that ACP is not only summetric (no dedicated client/servers), but
also greenfield: aka: no need to think about IN THIS REVISION OF ACP about
legacy compatibility. IF/WHEN in the future we do provide update/extensions
to ACP, THEN we may get into considerations for two generations of nodes
talking to each other.

> > Other similar cases comes when you merge authorization domains
> > together, i.e., two companies merge and they both had their own CAs
> > before, and not all devices support both CAs, so you need to pick
> > correct certificate one when talking to one or another device.
> 
> Yes, this is an important case.

Right now, draft-ietf-anima-autonomic-control-plane-27 does only specify to 
still
send a certificate, even if a CERTREQ was received from the peer, and no 
certificate
would match the TA in the CERTREQ. We discussed how this was for diagnostics.
See section 6.7.3.1.2.

There is nothing in the current ACP text to say whether or not to send CERTREQ
right now. Given how the ACP just provides a refinement profile in section
6.7.3.1.2. on top of RFC8247, and given how RFC8247 does not mention CERTREQ,
that leaves is with a "MAY send CERTREQ" (i paraphrase) from RFC7296 section
3.8.

The domain merge is also of interest in ACP, so we could add a stronger
requirement against CERTREQ, but given how the documents we reference
(RFC8247/RFC7296), i am a bit suspicious about doing so. If CERTREQ is
so useful in non-ACP use caes, why is there no stronger than MAY in RFC7296
or RFC8247 ? Oversight in those IKEv2 RFCs ? Or are there some downsides
coming with it ?

I don't think i will add suc a requirement in this ACP spec because it
may be necessary to make the merge case work, but it is not sufficient,
and the set of components sufficient to support that use case is is
beyond the scope of this ACP base spec.

To give a hint: We only mandate use of EST, and if i wanted to support
a merge, or in general any use case where CERTREQ was useful, then i would
need to have nodes that would have two or more certs and CERTREQ is a
way to pick one of those multiple certs. And EST to the best of my
understandig does not allow to hand out more than one cert to a single
node. At least thats what i remember from having asked the quesrtion a few
times over the last 5 years.

We can still make merge work through extension documents, even without
fixing that EST limitation itself through other extensions of ACP, but
i think we would want a discuss first whether to rater do that or fix EST.

Or someone comes around and tells me this time that EST can be somehow
tricked to provide multiple certs to a single node.

> >> So, we've been forced to use otherName, and this will cause new code 
> in some
> >> of the IKEv2 daemon that we need to use :-(
> 
> > No, you are not forced to use anything. Your ID could be KEY_ID with
> 
> No, the ACP document has been forced to use otherName in it's
> certificates. That's nothing to do with IPsec/IKEv2.
> But, that that's what IKEv2 will have to deal with.

Actually, the ACP text currently says to use ID_IPV6_ADDR, but given how
the name of the ACP node is now an otherName, we _could_ signal it
via ID_DER_ASN1_GN, but IMHO ID_IPV6_ADDR is better.

Cheers
Toerless

> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsec NSA recommendations 108

[Toerless Eckert]

https://media.defense.gov/2020/Jul/02/2002355501/-1/-1/0/CONFIGURING_IPSEC_VIRTUAL_PRIVATE_NETWORKS_2020_07_01_FINAL_RELEASE.PDF

No Swans mentioned ;-(

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

['Toerless Eckert']

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

On Tue, Jun 30, 2020 at 10:26:26PM +0300, Tero Kivinen wrote:
> I still consider sending TA certificate ever completely useless
> 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.

> > Btw: i have not heard an explanation why a CA cert would have to
> > be secret other than the classic "security by secrecy" dogma.
> 
> 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.

Great.

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

Sure.

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

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.

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

Good explanation. So, whats the most simple example for this ?
I have a single VPN 

Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

['Toerless Eckert']

On Fri, Jun 26, 2020 at 04:40:53PM +0300, Tero Kivinen wrote:
> 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... 

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!

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

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.

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

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

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

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 

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

['Toerless Eckert']

On Mon, Jun 22, 2020 at 05:42:00PM +0300, Valery Smyslov wrote:
> 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.

Yepp, figured that from Pauls response.

> > 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.
> 
> If I understand you correctly, you just want to include TA
> 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.

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

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

Cheers
Toerless

> Regards,
> Valery.
> 
> > 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
> > > > > IPsec@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ipsec
> > >
> > > ___
> > > IPsec mailing list
> > > IPsec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ipsec
> > 
> > --
> > ---
> > t...@cs.fau.de

-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

['Toerless Eckert']

On Mon, Jun 22, 2020 at 05:51:16PM +0300, Valery Smyslov wrote:
> Hi Ben,
> 
> > 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.
> 
> 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...

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

> Regards,
> Valery.
> 
> > -Ben

-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Toerless Eckert]

Inline

On Sun, Jun 21, 2020 at 11:37:58PM -0400, Paul Wouters wrote:
> On Jun 21, 2020, at 22:22, Toerless Eckert  wrote:
> > 
> > ???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
> 
> Yes.
> 
> 
> > The responder can also know that it must use the ACP certificate from the
> > transport address that it listens to:
> 
> Yes 
> 
> > 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.
> 
> What is causing termination ?

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.

> > And from what i read in rfc7296, CERTREQ is optional,
> > so we can mandate NOT to use it.
> 
> 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 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.
> 
> 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

['Toerless Eckert']

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
> > > IPsec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ipsec
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

['Toerless Eckert']

On Fri, Jun 19, 2020 at 01:10:37PM -0400, Paul Wouters wrote:
> > So i am tentatively adding the following text:
> > 
> > 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.
> 
> 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.

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.

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

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

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

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

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

Sure.

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

Normally yes. But when you have M (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
> Paul

-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

['Toerless Eckert']

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:

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.

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Interop with microsoft CA (was: IPsec profile feedback wanted (draft autonomic control) plane)

['Toerless Eckert']

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Toerless Eckert]

THanks, Tero, inline

On Thu, Jun 18, 2020 at 09:03:23PM +0300, Tero Kivinen wrote:
> [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.  ;-))

> Toerless Eckert writes:
> > On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
> > > 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.
> 
> 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.

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


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

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.

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

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.

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

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

> > > But note that the res

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

[Toerless Eckert]

On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
> 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.

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.

> So I would recommend to follow the intention of RFC 7296 and not make
> 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Toerless Eckert]

On Wed, Jun 17, 2020 at 05:07:48PM -0400, Paul Wouters wrote:
> On Wed, 17 Jun 2020, Toerless Eckert wrote:
> 
> > Given how you are focussing on this aspect,
> > can i assume that you are happy with the everything
> > else in the suggested text ?
> 
> I don't know yet. I have to re-read the last draft version.

Just about the text i sent today on this thread. Still finalizing
the -25 version of the actual draft.

> > Wrt to tunnel vs. transport mode:
> > 
> > If you can, please propose specific text that would improve
> > the quality of the doc wrt. to your point.
> > 
> > I can only observe:
> > 
> > a) I have not found the word "profile" in neither rfc4301
> > nor rfc5996, so i have no basis from which to argue what could
> > or could not be called permissible for a "profile"
> 
> I don't think we have an official IETF definition of a profile, but it
> usually means a collection of protocol parameters that are normally
> negotiated. For an example IPsec profile, see:
> 
> https://www.rfc-editor.org/rfc/rfc6380.html
> 
> Another more recent one is the draft for the updated CNDSA profile:
> 
> https://tools.ietf.org/html/draft-corcoran-cnsa-ipsec-profile-00
> 
> > b) I have not seen MUST support transport and MUST support
> > tunnel mode, so being "incapable" of either option will
> > lead to closing the connection, and those implementatoins
> > are i think compliant with the IPsec/IKEv2 RFCs.
> 
> Tunnel Mode is Mandatory To Implement. Transpode Mode is not.
> 
> > b) All router implementations i know that can do tunnel
> > and transport mode allow you to configure which option
> > specifically to use and they too will close a connection
> > is there is a mismatch. One could call that configuration
> > "unwilling".
> 
> Yes. In IKEv1, one was allowed to require Tunnel OR Transport
> mode, but for IKEv2 it was a conscious decision to make
> transport mode something a responder could refuse, without
> breaking the IPsec connection. This was done specifically to
> move most scenarios (especially over the internet, especially
> when NAT is involved) to Tunnel Mode. Transport Mode can be
> used but really should only be used if there is no NAT.

The ACP tunnels are across link-local scope IPv6 addresses
inside a LAN. Hence no issue. And for manual configured tunnel
there is the GRE tunnel option.

> And those reasons are also why I now bring this up. I want to
> avoid a new RFC that requires Transport Mode. It is fine to
> recommend it, as long as the responder is still allowed to
> refuse this, and be ensured that tunnel mode will be used instead.
> A connection MUST NOT hard fail on not getting Transport Mode.

Where does in say in RFC7296 that you MUST implement tunnel
mode  and SHOULD/MAY implement transport mode ?

RFC7296:

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

The last two sentences read to me as if it is fine to only
support transport but not tunnel mode, at least for the initiator:
closing the connection ("deleting SA") if the initiator is only willing
 to do tansport mode, but not tunnel mode.

What do you read from that ?

> > ACP draft does not even have a notion of "unwilling",
> > just "incapable".
> 
> My comments were triggered based on the texts in this email thread.
> As I said, I still need to reread the latest draft version.

Sure, it was just clarification, but logically its hard to
argue protocol violation based on attempting to distinguish
unwilling and incapable. Sounds like a good court soap opera:

DA: "Sir.IKEv2, Where you incapable or unwilling" ?
IKEv2: "Incapable, it's not my fault" !
DA: "But i see your source code which makes you capable".
IKEv2: "But the operator disabled it"
DA: "You should not listen to what the operator says, you are an autonomous 
system"

;-))

But seriously: Whats the technical reasoning ? Just be sure to
have an MTI ? 

Clearly for the use-case of automatic ACP secure channel,
the transport mode option is the one with least packet header /
MTU loss overhead. 

In 6.7.5 are the actual requirments and it does say for the
ACP baseline profile "MUST transport", "MAY GRE". 

Give or take disagremement about whats tec

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

[Toerless Eckert]

Thank, Paul

Given how you are focussing on this aspect,
can i assume that you are happy with the everything
else in the suggested text ?

Wrt to tunnel vs. transport mode:

If you can, please propose specific text that would improve
the quality of the doc wrt. to your point.

I can only observe:

a) I have not found the word "profile" in neither rfc4301
nor rfc5996, so i have no basis from which to argue what could
or could not be called permissible for a "profile"

b) I have not seen MUST support transport and MUST support
tunnel mode, so being "incapable" of either option will
lead to closing the connection, and those implementatoins
are i think compliant with the IPsec/IKEv2 RFCs.

b) All router implementations i know that can do tunnel
and transport mode allow you to configure which option
specifically to use and they too will close a connection
is there is a mismatch. One could call that configuration
"unwilling".

ACP draft does not even have a notion of "unwilling",
just "incapable".

Cheers
Toerless

Every router allows you to configure whether an 
On Wed, Jun 17, 2020 at 04:01:25PM -0400, Paul Wouters wrote:
> On Wed, 17 Jun 2020, Toerless Eckert wrote:
> 
> > > 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.
> > 
> > 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.
> 
> 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

-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Toerless Eckert]

On Wed, Jun 17, 2020 at 01:59:18PM -0400, Paul Wouters wrote:
> On Wed, 17 Jun 2020, Toerless Eckert wrote:
> 
> > 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,
> 
> 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.

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Toerless Eckert]

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, :: - :::::::)
TSr = (0, 0-65535, :: - :::::::)

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:

 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 . Traffic Selectors 
are:

TSi = (0, 0-65535, :: - :::::::)
TSr = (0, 0-65535, :: - :::::::)

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.

-- GRE:

The requirements for ESP/IPsec/IKEv2 with GRE are the same as for native 
IPsec (see ) 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:

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

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 .

--

Cheers
Toerless

On Thu, Feb 27, 2020 at 12:41:55AM +0200, Yoav Nir wrote:
> 
> 
> > On 26 Feb 2020, at 19:56, Michael Richardson  wrote:
> > 
> > 
> > Yoav Nir  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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] terminology check: "modern IPsec protocol suite"

[Toerless Eckert]

Haha. So you have to choose whether you want a title that a Muggle understand 
or not ;-)

Cheers
   Toerless

On Thu, Apr 09, 2020 at 07:07:00PM -0400, Paul Wouters wrote:
> L
> > On Apr 9, 2020, at 18:56, Toerless Eckert  wrote:
> > 
> > ???Does IPsec not also include AH as an option still ?
> 
> We don???t mention the Protocol That Shall Not Be Named, and recommend 
> ESP-NULL instead.
> 
> Paul

-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] terminology check: "modern IPsec protocol suite"

[Toerless Eckert]

Does IPsec not also include AH as an option still ?

On Thu, Apr 09, 2020 at 09:02:12AM +0300, Valery Smyslov wrote:
> Hi,
> 
> > > draft-ietf-taps-transport-security is currently in IESG evaluation, and in
> > > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP
> > > [RFC4303] together form the modern IPsec protocol suite that encrypts
> > and
> > > authenticates IP packets, either for creating tunnels (tunnel-mode) or for
> > > direct transport connections (transport-mode)."
> > > (https://tools.ietf.org/html/draft-ietf-taps-transport-security-11#section-
> > 3.4.1).
> > > I don't think I see a problem with that description, but wanted to run it
> > > by the WG for a quick sanity check before the document gets approved, in
> > > case there's something I'm forgetting.
> > 
> > Looks correct and appropriate to me.
> 
> I concur. 
> 
> However, I'd suggest changing the title of the section from "IKEv2 with ESP" 
> to "IPsec".
> 
> Regards,
> Valery.
> 
> > Paul
> > 
> > 
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

['Toerless Eckert']

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:
> Hi Paul,
> 
> > > 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.
> > 
> > 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.
> 
> We do support PKCS#7 too, but officially it's not specified for IKEv2 and
> thus must not be specified in the profile. 

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

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

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

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

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 

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

[Toerless Eckert]

Michael: Yoav talked about the non-GRE case.

On Tue, Feb 25, 2020 at 05:44:10PM -0500, Michael Richardson wrote:
> 
> Yoav Nir  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 , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


-- 
---
t...@cs.fau.de

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Toerless Eckert]

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 
> ipse...@ietf.org 

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

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Toerless Eckert]

[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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Multi-access interfaces (with IPsec)

[Toerless Eckert]

I want to describe (in some draft) the use of a virtual multi-access
interface that is mapped to multiple p2p associations (eg: IPsec). 
Which i think is a pretty standard option in industry implementations, eg:
in hub routers for hub & spoke deployments.

Is there any good RFC reference that explains how this works, eg:
replicate ll-multicast to all p2p associations, learn peer addresses
from received packets or specific IPv6 signaling packets, use that
to send unicast into right p2p association, etc. pp.

I could not find a good reference RFC for this ;-(

Thanks!
Toerless

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec