A dynamic VPN provides additional security for your communications
by using the Internet Key Exchange (IKE) protocol for key management. IKE
allows the VPN servers on each end of the connection to negotiate new keys
at specified intervals.
With each successful negotiation, the VPN servers regenerate the keys that
protect a connection, thus making it more difficult for an attacker to capture
information from the connection. Additionally, if you use perfect forward
secrecy, attackers cannot derive future keys based on past keying information.
The VPN key manager is IBM's implementation of the Internet Key Exchange
(IKE) protocol. The key manager supports the automatic negotiation of security
associations (SAs), as well as the automatic generation and refresh of cryptographic
keys.
A security association (SA) contains information
that is necessary to use the IPSec protocols. For example, an SA identifies
algorithm types, key lengths and lifetimes, participating parties, and encapsulation
modes.
Cryptographic keys, as the name implies, lock, or protect, your information
until it safely reaches its final destination.
Note: Securely generating your keys is the most important factor in establishing
a secure and private connection. If your keys are compromised, then your authentication
and encryption efforts, no matter how strong, become worthless.
- Phases of key management
- The VPN key manager uses two distinct phases in its implementation.
- Phase 1
- Phase 1 establishes a master secret from which subsequent cryptographic
keys are derived in order to protect user data traffic. This is true even
if no security protection yet exists between the two endpoints. VPN uses either
RSA signature mode or preshared keys to authenticate phase 1 negotiations,
as well as to establish the keys that protect the IKE messages that flow during
the subsequent phase 2 negotiations.
A preshared key is a nontrivial
string up to 128 characters long. Both ends of a connection must agree on
the preshared key. The advantage of using preshared keys is their simplicity,
the disadvantage is that a shared secret must be distributed out-of-band,
for example over the telephone or through registered mail, before IKE negotiations.
Treat your preshared key like a password.
RSA Signature authentication
provides more security than preshared keys because this mode uses digital
certificates to provide authentication. You must configure your digital certificates
by using Digital Certificate Manager (5722-SS1 Option 34). In addition, some
VPN solutions require RSA Signature for interoperability. For example, Windows® 2000 VPN uses RSA Signature as its
default authentication method. Finally, RSA Signature provides more scalability
than preshared keys. The certificates that you use must come from certificate
authorities that both key servers trust.
- Phase 2
- Phase 2, however, negotiates the security associations and keys that protect
the actual application data exchanges. Remember, up to this point, no application
data has actually been sent. Phase 1 protects the phase 2 IKE messages.
Once
phase 2 negotiations are complete, your VPN establishes a secure, dynamic
connection over the network and between the endpoints that you defined for
your connection. All data that flows across the VPN is delivered with the
degree of security and efficiency that was agreed on by the key servers during
the phase 1 and phase 2 negotiation processes.
In general, phase 1 negotiations
are negotiated once a day, while phase 2 negotiations are refreshed every
60 minutes or as often as every five minutes. Higher refresh rates increase
your data security, but decrease system performance. Use short key lifetimes
to protect your most sensitive data.
When you create a dynamic VPN by using iSeries™ Navigator,
you must define an IKE policy to enable phase 1 negotiations and a data policy
to govern phase 2 negotiations. Optionally, you can use the New Connection
wizard. The wizard automatically creates each of the configuration objects
VPN requires to work properly, including an IKE policy, data policy.
Suggested reading
If you want to read more about
the Internet Key Exchange (IKE) protocol and key management, review these
Internet Engineering Task Force (IETF) Request for Comments (RFC):
- RFC 2407, The Internet IP Security Domain of Interpretation for
ISAKMP
- RFC 2408, Internet Security Association and Key Management Protocol
(ISAKMP)
- RFC 2409, The Internet Key Exchange (IKE)
You can view these RFCs on the Internet at the following Web site:
http://www.rfc-editor.org.