Valery Smyslov writes: > I'm very much concerned with the IKE-less option presented in the > draft. > > First, the Network Controller becomes a very attractive target for > attacks in this case, since an attacker, if attack is successful, > will gain all the keys for the whole system.
And it is big difference if you get the traffic keys, or if you get just the authentication keys used to authenticate the peers when creating traffic keys. I.e. any TLA would love to get their hands on all the traffic keys in one location, and then be able to decrypt any traffic going inside any of the IPsec tunnels. If controller only has the PSKs or similar to do the authentication between peers, then that means that the TLA needs to do active attack for each connection they want to break. Beause of this I think it is always best not to move the transport keys outside the boxes that needs them, i.e., keep them only on the nodes doing actual encryption / decryption. Also knowing that the controller most likely keeps all kind of logs and takes backup of the configurations it is keeping, this also makes the backups suitable targets for attacks, as they allow decryption previously stored flows of traffic, and this can be done years later when one of those backups accidently finds its way to wrong hands. > Then, it is not clear for me how the keys are distributed in this > case from the Network Controller to the End Entities. I presume that > they are not sent in clear, so the End Entities must already have > capabilities to run some security protocol (TLS, IPsec), and thus > they must be already provisioned out of band with some security > credentials (keys, certificates). So I don't understand what you > gain in case you don't run IKEv2 on End Entities. This I think is important question, i.e., what is the gain for not running IKEv2 between the nodes? > In general, central distribution of session keys looks much less secure, > than running IKEv2 on them. You loose PFS property, you loose > the property that no one but the peers know the session keys etc. > It is more fragile too. You must perform periodical rekey (update keys) > and this must be done synchronously. All the rekey problems that were > solved by IKE will arise again. And of course you do not know when to do rekey, as you do not know how many bytes each peers have been transmitting to be able to do rekey before there has been too much data encrypted with one key. -- [email protected] _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
