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 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. > > 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. > > 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. Sure... example (see above) would help to get a better feel of this. > > 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. > > 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. 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 > > > Creating a mapping from trust anchor hash to trust anchor is trivial > > > if you ever see the actual trust anchor certificate anywhere. > > > > Sure. You just need to have seen the actul trust anchor cert once. > > > > > If you ever have more than one TA ever in normal operations you want > > > 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. > > 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. 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. > 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. 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. > > > 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 protected]" and > > > "[email protected]") or they might be completely useless like "10.5.0.1" > > > and "10.1.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. > > 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). With our current thinking, the GeneralName would be probably something ilke: type AcpRealm: node:<ipv6addr>@<acp-domain-name> > > 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. ?? > > 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. Thanks > > > 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. > > > > Agreed. But see above, this was at least from my side the > > 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. Please take longevity and core focus of the use-case into account. > 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? 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 > -- > [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
