(See the previous section or the top level if you're wondering what this is.)
If you really want to dig into the key exchange protocol, RFC 7296 (Oct. 2014) is the most modern reference. Unless you're actually manually configuring or implementing the stuff, you probably won't care about the differences between it and the older versions.
But you might want to start with RFC 4301 (Dec. 2005) (also a proposed standard), which is titled, "Security Architecture for the Internet Protocol."
IPsec has a couple of modes, but let's stick to what's called tunnel mode. Two boxes, known as gateways, build one or more Security Associations (SAs). An SA describes which packets passing between the gateways are to be encrypted and how. Those that are encrypted are encrypted in their entirety (packet headers and all), and sent as the payload of another IP packet, to be decrypted at the far end. Tunnel mode is most often used to connect together via the Internet two networks (e.g., two offices of the same company) that are each considered to be relatively secure networks. The packets between computers in one network and those in the other network are encrypted only during their transit from gateway to gateway. Of course, these days, much (most?) data is also encrypted by the end hosts, especially for the two major applications of web and email, so much of the traffic in the tunnel will be double-encrypted.
The first SA created is the IKE SA itself, used only to carry the messages that govern the tunnel. The first exchange of messages negotiates some security parameters, and carries random nonces used to "add freshness" to the cryptographic exchange and the parameters to be used for the Diffie-Hellman key exchange. I believe this is where the preferred choice for the bulk encryption (3-DES v. AES v. whatever) is also negotiated. Since we have not yet established the tunnel, these messages are necessarily sent as plaintext.
A block of material called SKEYSEED is calculated independently by both ends using the nonces generated by both ends and the shared secret generated by the Diffie-Hellman exchange in the INIT. Building SKEYSEED involves the use of a pseudorandom function (PRF) also agreed upon...in the first exchange? I'm having trouble tracking where that's chosen.
SKEYSEED is used first to generate a key for the next message exchange, and then later to make keys for the Child SAs (below).
Next, there is an encrypted exchange that is used to authenticate the parties. The authentication may be via an RSA digital signature, a shared (symmetric) key message integrity code, or a DSS digital signature. In all three methods, each party signs a block of data using the secret, in a fashion that can be verified by the partner. (This could again be vulnerable to Shor's algorithm if it uses one of the public key methods, but keep in mind the messages containing this information are also encrypted; however, as we are just now
authenticating, it's possible that, up to this point, the partner at the other end of this connection is not who they claim to be!)
The IKE SA is used to create Child SAs, which carry the actual traffic. The keys used for the Child SAs, therefore, are the obvious target for traffic-based attacks, though the real prize is the keys for the IKE SA. I'm having a hard time imagining how to mount an effective attack against the IKE SA.
The key material for the Child SA is generated via a complex mechanism involving a new nonce and the PRF previously specified. The initiator of the creation may also, optionally, specify that an entirely new Diffie-Hellman exchange be performed. I'm very unclear on how often that option is used in practice.
Each SA, whether IKE or Child, can (and should) have a lifetime. That lifetime can be specified in either seconds or in bytes that have been encrypted as they pass through the tunnel. Once the lifetime has expired, the two gateways must create a new Child SA with new keys. This ultimately is the heart of what we're looking for here: what is that recommended lifetime today, and what should it be in the light of quantum computing?
No comments:
Post a Comment