IP Security Protocol
Protocol IKE (36), [81], based on ISAKMP, Oakley, and SKEME ([115,140,102]) is a quite complex protocol with two different phases. It is a combination of 13 different subprotocols: in Phase I there are 8 different subprotocols, with 2 choices for mode, and 4 choices for authentication mechanism; in Phase II there are 4 different subprotocols with the choice of perfect forward secrecy or not and the inclusion of explicit identity information or not; lastly, there is a new group subprotocol. There are also variants depending on the types of credentials to be used.
In Phase I, the two peers establish a secure channel for further communication by negotiating ISAKMP SAs. In Phase II, protected by the SA negotiated in Phase I, the peers negotiate SAs that can be used to protect real communication; that is, the IPsec SA. IKE defines two Phase I modes: main mode gives authenticated key exchange with identity protection. Aggressive mode gives quicker authenticated key exchange without identity protection. For Phase I, IKE defines (for main and aggressive modes) four different authentication methods: 1. authentication with digital signatures; 2. authentication with public key encryption; 3. authentication with a revised mode of public key encryption; and 4. authentication with a pre-shared key.
IKE is perceived as being too complex and it is believed that it is only a matter of time before more analyses show more serious security issues and problems become apparent. Contradictions between the different documents defining IKE have become evident (In particular the rekeying issue: multiple SAs may be pre-negotiated and used at will?) Also possible interaction of the different subprotocols, which use similar formats, could lead to new insecurities. (This has been shown to be the case for an early version of SSL, draft-benaloh-pct-00.txt, 1995)
Protocol IKE should provide Fresh Key Agreement, PFS, DoS Resilience, secure Negotiation, and ID Protection (Eavesdropper and Peer) (G1-3,7,9-15).
Protocol IKEv2 (37), the Internet Key Exchange Version 2 (IKEv2) Protocol, [95] consists of two exchanges:
The first is an authentication and key exchange protocol which establishes an IKE-SA.
The second one consists of messages and payloads which focus on the negotiation of parameters in order to establish IPsec security associations (i.e., Child-SAs). These payloads contain algorithm parameters and traffic selector fields.
In addition to the above-mentioned parts IKEv2 also includes some payloads and messages which allow configuration parameters to be exchanged primarily for remote access scenarios.
Protocol IKEv2 should provide Fresh Key Agreement, PFS, DoS Resilience, secure Negotiation (G1-3,7,9-11,15).
Protocol KINK (38), Kerberized Internet Negotiation of Keys, (defined in [182] and [181]) is a command/response protocol which can create, delete and maintain IPsec security associations ([98]), as an alternative to IKE ([81]). Participating nodes use Kerberos ([101]) for key management, mutual authentication, and replay protection. KINK's design mitigates denial of service attacks by requiring authenticated exchanges before the use of any public key operations and the installation of any state.
Protocol KINK should provide Fresh Key Agreement, 3P-Authorization, and ID Protection (Eavesdropper and Peer) (G1-3,6,7,10,12-14).
In the Ipsra (IP Security Remote Access) scenario (remote users that use personal portable computing devices, or who use Internet kiosks to access private networks on the other side of an IPSEC gateway), [145] (together with the authentication for DHCP messages, [56]) defines Protocol DHCP-IPSec-tunnel (39), an exchange that is secured using IPsec, and as a result the DHCP packets flowing between the remote host and the security gateway are authenticated and integrity protected.
Protocol DHCP-IPSec-tunnel should provide Authentication and Secrecy (G1,2,12).