“Internet Security Association and Key Management Protocol”的意思、由来-开放百科全书

ISAKMP defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques and threat mitigation (e.g. denial of service and replay attacks). As a framework,^[1] ISAKMP typically utilizes IKE for key exchange, although other methods have been implemented such as Kerberized Internet Negotiation of Keys. A Preliminary SA is formed using this protocol; later a fresh keying is done.

ISAKMP defines procedures and packet formats to establish, negotiate, modify and delete Security Associations. SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services or self-protection of negotiation traffic. ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism.

ISAKMP is distinct from key exchange protocols in order to cleanly separate the details of security association management (and key management) from the details of key exchange. There may be many different key exchange protocols, each with different security properties. However, a common framework is required for agreeing to the format of SA attributes and for negotiating, modifying and deleting SAs. ISAKMP serves as this common framework.

ISAKMP can be implemented over any transport protocol. All implementations must include send and receive capability for ISAKMP using UDP on port 500.

Implementation

OpenBSD first implemented ISAKMP in 1998 via its [https://man.openbsd.org/isakmpd.8 isakmpd(8)] software.

Vulnerabilities

Leaked NSA presentations released by Der Spiegel indicate that ISAKMP is being exploited in an unknown manner to decrypt IPSec traffic, as is IKE.^[2] The researchers who discovered the Logjam attack state that breaking a 1024-bit Diffie–Hellman group would break 66% of VPN servers, 18% of the top million HTTPS domains, and 26% of SSH servers, which is consistent with what the researchers claim is consistent with the leaks.^[3]

See also

References

1. ^¹The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
2. ^{{cite|publisher=NSA via 'Der Spiegel'|format=PDF|url=http://www.spiegel.de/media/media-35529.pdf|date=|page=5|title=Fielded Capability: End-to-end VPN SPIN9 Design Review}}
3. ^{{Cite conference| url=https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf | first1=David | last1=Adrian | first2=Karthikeyan | last2=Bhargavan | first3=Zakir | last3= Durumeric | first4=Pierrick | last4=Gaudry | first5=Matthew | last5=Green | first6=J. Alex | last6=Halderman | first7=Nadia | last7=Heninger |author7-link= Nadia Heninger | first8=Drew | last8=Springall | first9=Emmanuel | last9=Thomé | first10=Luke | last10=Valenta | first11=Benjamin | last11=VanderSloot | first12=Eric | last12=Wustrow | first13=Santiago | last13=Zanella-Béguelin | first14=Paul | last14=Zimmermann | title=Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice | conference=22nd ACM Conference on Computer and Communications Security (CCS ’15) | location=Denver | date=October 2015 | accessdate=15 June 2016}}

Overview

Implementation

Vulnerabilities

See also

References

External links