1.1 Glossary
This document uses the following terms:
anonymous authentication: An authentication mode in which neither party verifies the identity of the other party.
Authenticated Firewall (authFW): A mode of operation for IPsec and AuthIP in which SAs are negotiated as specified in section 3.1, but with all traffic on the SA sent in cleartext, except the first packet which is sent both in cleartext and with encapsulation, as specified in section 3.10.4.2. The encapsulated packet serves as an authenticated signal to the remote host to accept packets from the sending IP address and port. This mode of operation allows IPsec to be used strictly for host access control, based on the policies defined in the PAD (See [RFC4301], section 4.4.3), rather than for in-transit data protection. See section 3.10 for more details.
Authenticated IP (AuthIP): An Internet Key Exchange (IKE) protocol extension, as specified in [MS-AIPS].
authentication header (AH): An Internet Protocol Security (IPsec) encapsulation mode that provides authentication and message integrity. For more information, see [RFC4302] section 1.
authentication mode: One of several modes in which an authentication exchange can be performed.
domain of interpretation (DOI): A domain that defines the manner in which a group of protocols uses the ISAKMP (as specified in[RFC2408]) framework to negotiate security associations (SAs) (for example, identifiers for cryptographic algorithms, interpretation of payload contents, and so on). For example, the Internet Protocol security (IPsec) DOI (as specified in [RFC2407]) defines the use of the ISAKMP framework for protocols that negotiate main mode (MM) and quick mode security associations (SAs). Both Internet Key Exchange (IKE) and AuthIP fall under the IPsec DOI.
Encapsulating Security Payload (ESP): An Internet Protocol security (IPsec) encapsulation mode that provides authentication, data confidentiality, and message integrity. For more information, see [RFC4303] section 1.
exchange: A pair of messages, consisting of a request and a response.
exchange type: A specification of the format and number of messages in each phase of the Internet Key Exchange (IKE) protocol.
explicit credentials: User credentials that are passed as input to the GSS-API [GSS].
extended mode (EM): An optional phase of AuthIP negotiation during which the peers perform a second round of authentication. This phase does not exist in the Internet Key Exchange (IKE) protocol.
flow: A TCP session or User Datagram Protocol (UDP) pseudo session, identified by a 5-tuple (source and destination IP and ports, and protocol). By extension, a request/response Internet Control Message Protocol (ICMP) exchange (for example, ICMP echo) is also a flow.
Generic Security Services (GSS): An Internet standard, as described in [RFC2743], for providing security services to applications. It consists of an application programming interface (GSS-API) set, as well as standards that describe the structure of the security data.
Hash-based Message Authentication Code (HMAC): A mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function (for example, MD5 and SHA-1) in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function.
initiator: The party that sends the first message of an Internet Key Exchange (IKE).
Internet Key Exchange (IKE): The protocol that is used to negotiate and provide authenticated keying material for security associations (SAs) in a protected manner. For more information, see [RFC2409].
Internet Key Exchange (IKEv2): The protocol that is used to negotiate and provide authenticated keying material for security associations (SA) in a protected manner. For more information, see [RFC4306].
Internet Protocol security (IPsec): A framework of open standards for ensuring private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPsec supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.
Internet Protocol version 4 (IPv4): An Internet protocol that has 32-bit source and destination addresses. IPv4 is the predecessor of IPv6.
Internet Protocol version 6 (IPv6): A revised version of the Internet Protocol (IP) designed to address growth on the Internet. Improvements include a 128-bit IP address size, expanded routing capabilities, and support for authentication and privacy.
Internet Security Association and Key Management Protocol (ISAKMP): A cryptographic protocol specified in [RFC2408] that defines procedures and packet formats to establish, negotiate, modify and delete security associations (SAs). It forms the basis of the Internet Key Exchange (IKE) protocol, as specified in [RFC2409].
key exchange: A synonym for key establishment. The procedure that results in shared secret keying material among different parties. Key agreement and key transport are two forms of key exchange. For more information, see [CRYPTO] section 1.11, [SP800-56A] section 3.1, and [IEEE1363] section 3.
keying material: The data from which the main mode (MM) and quick mode security association (SA) authentication and encryption keys are generated.
main mode (MM): The first phase of an Internet Key Exchange (IKE) negotiation that performs authentication and negotiates a main mode security association (MM SA) between the peers. For more information, see [RFC2409] section 5.
main mode security association (MM SA): A security association that is used to protect Internet Key Exchange (IKE) traffic between two peers. For more information, see [RFC2408] section 2.
main mode security association database (MMSAD): A database that contains operational state for each main mode (MM) security association (SA). For more information, see [MS-AIPS] section 3.1.1 and [MS-IKEE] section 3.1.1.
mutual authentication: A mode in which each party verifies the identity of the other party, as described in [RFC3748] section 7.2.1.
negotiation: A series of exchanges. The successful outcome of a negotiation is the establishment of one or more security associations (SAs). For more information, see [RFC2408] section 2.
negotiation discovery: An Internet Key Exchange (IKE) extension that improves interoperation between Internet Protocol security (IPsec) and non-IPsec-aware hosts. Detecting that the peer host is not capable of IPsec usually involves waiting for the IKE negotiation to time out, then sending traffic in the clear. With negotiation discovery, the host starts the IKE negotiation and sends clear text traffic in parallel. If the IKE negotiation succeeds and security associations (SAs) are established, further traffic is secured.
network address translation (NAT): The process of converting between IP addresses used within an intranet, or other private network, and Internet IP addresses.
nonce: A number that is used only once. This is typically implemented as a random number large enough that the probability of number reuse is extremely small. A nonce is used in authentication protocols to prevent replay attacks. For more information, see [RFC2617].
NT LAN Manager (NTLM) Authentication Protocol: A protocol using a challenge-response mechanism for authentication in which clients are able to verify their identities without sending a password to the server. It consists of three messages, commonly referred to as Type 1 (negotiation), Type 2 (challenge) and Type 3 (authentication).
one-way authentication: An authentication mode in which only one party verifies the identity of the other party.
perfect forward secrecy (PFS): A property of key exchange protocols, which holds when session keys from previous communications are not compromised by the disclosure of longer-term keying material. In the context of Internet Protocol security (IPsec), PFS requires a Diffie-Hellman exchange to generate the keys for each quick mode security association (SA).
phase: A series of exchanges that provide a particular set of security services (for example, authentication or creation of security associations (SAs)).
quick mode: The second phase of an Internet Key Exchange (IKE) negotiation, during which the peers negotiate quick mode security associations (QM SAs). For more information, see [RFC2409] section 5.5.
quick mode security association (QM SA): A security association (SA) that is used to protect IP packets between peers (the Internet Key Exchange (IKE) traffic is protected by the main mode security association (MM SA)). For more information, see [RFC2409] section 5.5.
responder: The party that responds to the first message of an AuthIP exchange.
security association (SA): A simplex "connection" that provides security services to the traffic carried by it. See [RFC4301] for more information.
security association database (SAD): A database that contains parameters that are associated with each established (keyed) security association.
security policy database (SPD): A database that specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host or security gateway.
security principal name (SPN): The name that identifies a security principal (for example, machinename$@domainname for a machine joined to a domain or username@domainname for a user). Domainname is resolved using the Domain Name System (DNS).
Security Support Provider Interface (SSPI): An API that allows connected applications to call one of several security providers to establish authenticated connections and to exchange data securely over those connections. It is equivalent to Generic Security Services (GSS)-API, and the two are on-the-wire compatible.
Simple and Protected GSS-API Negotiation Mechanism (SPNEGO): An authentication mechanism that allows Generic Security Services (GSS) peers to determine whether their credentials support a common set of GSS-API security mechanisms, to negotiate different options within a given security mechanism or different options from several security mechanisms, to select a service, and to establish a security context among themselves using that service. SPNEGO is specified in [RFC4178].
Transport Layer Security (TLS): A security protocol that supports confidentiality and integrity of messages in client and server applications communicating over open networks. TLS supports server and, optionally, client authentication by using X.509 certificates (as specified in [X509]). TLS is standardized in the IETF TLS working group.
transport mode: An IP encapsulation mechanism, as specified in [RFC4301], that provides Internet Protocol security (IPsec) security for host-to-host communication.
tunnel mode: An IP encapsulation mechanism, as specified in [RFC4301], that provides Internet Protocol security (IPsec) security to tunneled IP packets. IPsec processing is performed by the tunnel endpoints, which can be (but are typically not) the end hosts.
Unicode string: A Unicode 8-bit string is an ordered sequence of 8-bit units, a Unicode 16-bit string is an ordered sequence of 16-bit code units, and a Unicode 32-bit string is an ordered sequence of 32-bit code units. In some cases, it could be acceptable not to terminate with a terminating null character. Unless otherwise specified, all Unicode strings follow the UTF-16LE encoding scheme with no Byte Order Mark (BOM).
unique identifier (UID): A pair consisting of a GUID and a version sequence number to identify each resource uniquely. The UID is used to track the object for its entire lifetime through any number of times that the object is modified or renamed.
User Datagram Protocol (UDP): The connectionless protocol within TCP/IP that corresponds to the transport layer in the ISO/OSI reference model.
vendor ID payload: A particular type of ISAKMP payload that contains a vendor-defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backward compatibility. For more information, see [RFC2408] section 3.16.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.