'Toerless Eckert' writes: > > 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 would assume most common case will be when certificates are being renewed in non-compatible way. I.e., you initially have rsa certs for both client and server, then someone decides rsa is weak, and we must move to ecdsa in the future. They will first install new TA certs on the some servers (lets say they have 1000 of those, and they do not want to do all of them immediately). Now some of the servers do have TA1, and some have both TA1, and TA2. Next clients needs to get new certificates from TA2. This process can make months, as it is possible that some of the clients are not connecting to the server for long time. If you have client which has only TA1, there is no problem, it can connect to any server which still supports TA1. If you have client which has both TA1, and TA2, and it connects to old server which only supports TA1, it needs to recognize this and use TA1 in that case. If it connects to server using both TA1, and TA2, it most likely wants to prefer TA2, as that is the direction the transition is going, so TA2 should be preferred if both are supported. When all servers have been updated to support both TA1, and TA2, then there is no longer issues, as now all clients which do have TA2, use it for all servers, and those which have not yet updated to TA1, still use that. So the idea is to allow iterative updating of the system, without the need of flag days or configuration settings to specify things. I.e., IKEv2 will automatically detect which TA is supposed to be used, and use it. > 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. Current VPNs are quite often very strictly configured to use exactly the configuration they have, and quite often they use their own IPsec implementation, i.e., they might not use the IPsec provided by the operating system. Things get more complicated if you actually want to have multiple VPNs in your system each using the same operating system provided IPsec, but just provide configuration information to that. Of course in that case you might also have overlapping configurations causing issues, and thats why I think most of the VPNs are now standalone type of implementations. > > > 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 Note, that the IDi and IDr are what is matched against the IPsec policy, i.e., nothing in the certificate will cause policy to be selected, only IDi and IDr does that. After IDi and IDr identifies the suitable policy, we can go and match the information in the policy against the certificate. That policy might include information like how to match the certificate subject alt name or subject name to identity or information in the policy. It could even include the list of trusted TAs, but this has the problem that we need to send list of TAs before we know the ID of the other end, so in that case we need to send union of all possible TAs in all of our policies. > > 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. Note, that to be able to see the TA sent you need debugging logs. The certificates are sent inside the encrypted packets, and only way to know what was there is to have IKEv2 implementation print that information to some kind of debugging log. So even if you send them inplace, that does not mean that you can actually use them when debugging. I would assume most of the mobile handset IPsec implementations do not provide such debugging logging in general, you might need to enable some kind of debugging mode or restart the system in a way where you can see console log etc. This same of course applies to the end entity certificate, and that might be issue, i.e., if the IPsec implementation does not even print that out then you have hard time debugging issues. > > 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. As I said you need other diagnostic channels even if you send the TA, as it is inside encrypted packet. Of course if you can replace the device with another device having diagnostic prints and logging using same IP-address you can make claim to be the responder, and print debugging information out from there, but it does require you act as a responder yourself. In that case your special diagnostic tool can provide much better debugging information anyways than what is normally provided by the IPsec implementations. > > 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. So you plan to have IPsec implementations actually saving that information somewhere, and providing that debugging information to that gui by some unspecified management protocol, i.e., modify the ipsec implementations you use to provide the information. Currently I think most of the implementations do not provide it in easy to use way... Luckily in IKEv2 you do need that information much less often than what happend with IKEv1, where there was lots of parameters which had to be exactly same in both ends, so only way to verify that was to have detailed debug logs and check what other end proposed, and what our policy required. > 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
