'Toerless Eckert' writes: > > 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.
I still consider sending TA certificate ever completely useless thing, that just wastes bytes. > 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. 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. > > 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. > > 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. > 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. > 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. > > 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. I think it is better to save bytes 100% of time... If you assume that you have misconfigurations so often that you want to send few kilobytes extra stuff for every negotiation, I think there is something seriously wrong with the architecture of the system in general. > > 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 "devi...@hr.example.com" and > > "v...@example.com") 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). > 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. > > 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. 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? -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
