3.1.1 Abstract Data Model

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with the behavior that is described in this document.

The flags bit semantics used by this document are as follows: For a flag, its "value" signifies a mask which, when its bitwise logical AND with the flags field is computed, yields either a zero value (all zero bits) if the flag is unset (set to FALSE), and a nonzero value otherwise. For example, a flag mask/value of 0x01 signifies that the bitwise logical AND of a single-byte flag field with 0x01 is zero if and only if the flag is set to FALSE. Assuming no other flag masks/values for this field, then, both 0x00 and 0x01 are valid values for this single-byte flag field--the former corresponding to the flag being unset, and the latter to the flag being set.

The main data elements that are required by any implementation are:

  • Main mode security association (MM SA) database: A database that contains the operational state for each MM SA. The entry for each MM SA contains the following data elements:

    • Current role: type: flag. Used to store the current role (initiator or responder) for use in a key generation algorithm as described in 3.1.7.4.

    • Current state: type: DWORD. Stores the current message number within a negotiation, for use in header construction as described in 2.2.1.

    • Per-negotiation timers: type: System timer. Authentication protocol timers as described in 3.1.2.

    • Sequence numbers: type: DWORD. Stores sequence numbers for main mode (MM), quick mode, extended mode (EM), and notification exchange types. The sequence numbers MUST start at zero and MUST be incremented for each exchange. The sequence number is used as the seqNUM field of the Crypto payload.

    • Cryptographic parameters: type: array of {Authentication attribute (type: DWORD)}. Stores Cryptographic parameters for the MM SA as described in the attribute class table in [RFC2409] appendix A. The attributes used are: encryption algorithm, hash algorithm, group description, life type, and life duration. In addition, a set of one or more authentication methods (defined as in the same table) is included.

    • Auth methods: type: array of {AuthMethodType (type: DWORD)}. A set of one or more authentication methods (as defined in [RFC2409] Appendix A and section 1.7) for main mode (MM).

    • Auth methods (EM): type: array of {AuthMethodType (type: DWORD)}. A set of one or more authentication methods (as defined in [RFC2409] Appendix A and section 1.7) for extended mode (EM).

    • Quick mode Pointers: type: array of indexes into the SAD described below. A list of indexes for SAD entries corresponding to QM SAs established under the protection of the MM SA.

    • NAT traversal state. See [RFC3947] section 3.2. The state contains a BOOLEAN: isNatPresent. This MUST be initialized to FALSE. It is set to true if NAT is detected as described in [RFC3947] section 3.2.

    • Negotiation retransmission timer context: This timer context keeps track of the packet being retransmitted, and how many retransmissions have currently been sent.

    • Request Non-notify Message pending Queue: When there is an outstanding notify request any non-notify request generated will be queued here until an ACK arrives (see section 3.1.7.5).

    • DoS protection mode bit:  A BOOLEAN value indicating whether the host is in DoS protection mode (see section 3.1.7.6).

    • Explicit credentials MM: A BOOLEAN value indicating whether explicit credentials were used in the MM negotiation (see section 3.8.7.1).

    • Explicit credentials EM: A BOOLEAN value indicating whether explicit credentials were used in the EM negotiation (see section 3.8.7.1).

    • Impersonation active MM: A BOOLEAN value indicating whether Impersonation is enabled  in the MM negotiation (see section 2.2.3.1).

    • Impersonation active EM: A BOOLEAN value indicating whether Impersonation is enabled  in the EM negotiation (see section 2.2.3.1).

    • ImpersonationHandle: A handle {DWORD} that represents the user corresponding to this MM SA.

    • Connection state table: Stores a set of connection entries. This table manages the connection state necessary to perform an authFW mode. These connection entries correspond to active TCP/UDP/ICMP, or protocol-only connections.

      The possible connection entries are:

      • V4 TCP/UDP state entry: {IPv4 source address {DWORD}, IPv4 destination address {DWORD}, IP protocol {DWORD}, source port {DWORD}, destination port {DWORD}.

      • V6 TCP/UDP state entry: {IPv6 source address {16 bytes}, IPv6 destination address {16 bytes}, IP protocol {DWORD}, source port {DWORD}, destination port {DWORD}.

      • V4 ICMP state entry: {IPv4 source address {DWORD}, IPv4 destination address {DWORD}, IP protocol {DWORD}, ICMP type {DWORD}, ICMP code {DWORD}} [RFC792].

      • V6 ICMP state entry: {IPv6 source address {16 bytes}, IPv6 destination address {16 bytes}, IP protocol {DWORD}, ICMP type {DWORD}, ICMP code {DWORD}} [RFC792].

      • V4 protocol-only state entry: {IPv4 source address {DWORD}, IPv4 destination address {DWORD}, IP protocol {DWORD}}.

      • V6 protocol-only state entry: {IPv6 source address {16 bytes}, IPv6 destination address {16 bytes}, IP protocol {DWORD}.

        Every connection state entry also includes:

      • IsAuthenticatedFirewallConnection Type: BOOLEAN. Indicates whether the connection uses Authenticated Firewall Mode (section 3.10).

      • AuthFWAuthorized Type: BOOLEAN. In the case of an Authenticated Firewall Mode connection, indicates whether an authenticated packet has been received (see section 3.10.5.1).

      • PeerIsNegotiationDiscoveryCapable: Type: BOOLEAN.  Indicates whether the peer associated with the connection has indicated support for Negotiation Discovery (See [MS-IKEE], section 3.7).

      • ImpersonationHandle: Type {DWORD} A handle that represents the user corresponding to the MM SA associated with the connection.

      • IsImpersonationConnection: Type: BOOLEAN. Indicates whether impersonation was used in the EM negotiation for the MM SA associated with the connection.

        The MM SA is indexed by the local and peer IP address and the initiator and responder cookies that are found in the ISAKMP header, as in IKEv1.

  • Security policy database (SPD): The SPD and its management operations are specified in [RFC4301] section 4.4.1. The SPD that is referred to in this specification contains rules that describe whether and how IPsec protection is applied to inbound or outbound IP traffic. The SPD is looked up by using tuples that contain flow information for the packet. The encapsulation type is already a part of the SPD. This specification adds two new encapsulation values to the encapsulation type. See section 3.10.4.2.

    This specification also adds a policy option to enable impersonation, which is configurable per-SPD entry. The corresponding state consists of two Boolean values: RequireImpersonationMM and RequireImpersonationEM. It also adds a BOOLEAN LocalKeyDictationAttempt, which indicates whether the local end is attempting to be the key dictator. When set, an additional DWORD KeyDictationWeight stores the local weight used to negotiate the key dictator with the peer.

    This specification adds a policy option that SHOULD<11> enable Kerberos authentication via proxy, which is configurable per SPD entry. The corresponding option consists of a STRING value: UseKerberosProxyURL.

  • The EM authentication SPD adds local and remote ports to the SPD selector. See [RFC4301], section 4.4.1.1. Associated with each selector are the EM Auth methods. These are an array of {AuthMethodType (type: DWORD)}, which is a set of one or more authentication methods (as defined in [RFC2409] Appendix A and section 1.7) for extended mode (EM). Each authentication method's specific configuration is specified in that authentication method's documentation. For instance, 1-way certificate authentication versus mutual certificate authentication configuration is covered in [RFC5246].

  • Peer authentication database (PAD): The PAD and its management operations are specified in [RFC4301] section 4.4.3. The PAD that is referred to in this specification contains rules that describe whether and how the Authenticated Internet Protocol negotiates SAs with a remote peer. The PAD is looked up by using tuples that are composed of local and remote IP addresses.

    This specification adds:

    • Allow Explicit credentials MM: Type: BOOLEAN. Indicates whether the use of explicit credentials is permitted during main mode security association (MM SA) negotiation.

    • Allow Explicit credentials EM: Type: BOOLEAN. Indicates whether the use of explicit credentials is permitted during extended mode (EM) SA negotiation.

  • Security association database (SAD): The SAD contains the parameters of each QM SA. The SAD and its management operations are specified in [RFC4301] section 4.4.2.

    This specification adds:

    • IsAuthenticatedFWSA: Type: BOOLEAN. This flag, when set, indicates that the SA is an authFW mode SA.

    • ImpersonationHandle: Type: DWORD. A handle to the impersonated identity associated with the selector of each SAD entry. See [RFC4301] section 4.4.1.1.

    • The NAT traversal state in the MM SA is propagated from the MM SA to all SAD entries established using that MM SA.

    • KeyDictationWtLocal: Type: DWORD Set if the local end wants to dictate quick mode keys to peer.

    • KeyDictationWtRemote: Type: DWORD Set if, during negotiation, it is discovered that the peer end wants to dictate quick mode keys to peer.

    • LocalEndWantsToDictateKey: Type: BOOLEAN Set if, during negotiation, it is discovered that the local end wants to dictate the key. The KeyDictationWtLocal value is valid only when this is set.

    • KeyDictationLocalWinner: Type: BOOLEAN Set if, during negotiation, it is discovered that the local end has a higher Key Dictation Weight.

    • KeyDictationRemoteWinner: Type: BOOLEAN Set if, during negotiation, it is discovered that the remote end has a higher Key Dictation Weight.