3.1 Common Details

  • Article

This section specifies details common to all roles in AuthIP.

Exchange State Machine

The state diagrams for a single exchange in a negotiation with the initiator and the responder are shown in the following figure.

Single exchange state

Figure 1: Single exchange state

The initiator MUST start a retransmission timer when it sends the first packet of an exchange. If the timer expires before a response is received, the initiator retransmits the message and restarts the timer. After a predefined number of retransmissions, the exchange is aborted. See section 3.1.2 for more information on retransmission timers.

Authentication Retry State Machine

The logic for authentication retry is triggered within a negotiation when the current authentication method fails and there are remaining authentication methods (or remaining authentication parameters for the current methods) that can be tried before failing the negotiation. Authenticated Internet Protocol implementations MUST support authentication retry.

The state diagrams for authentication retry for the initiator and responder are shown in the following figure.

Authentication retry state (initiator and responder)

Figure 2: Authentication retry state (initiator and responder)

In processing the protocol error transition, the peer encountering the error MUST send a notify message of type NOTIFY_STATUS containing the error code corresponding to the error to the peer. See section 2.2.3.5 for details.

Authentication retry state (negotiation)

Figure 3: Authentication retry state (negotiation)

Analyze the figure "Authentication retry state (negotiation)" in combination with the figure "Authentication retry state (initiator and responder)". The "Local first failure", "GSS-API started", and "Responder complete" states in the figure "Authentication retry state (negotiation)" correspond to the "Wait for response" state in the figure "Authentication retry state (initiator and responder)". In processing the "send next GSS-API payload", AuthIP sends a message with a GSS-API payload as specified in sections 2.2.3.1 and 3.8.

As specified in [RFC3546], TLS performs certificate-based authentication. The TLS protocol can be used by the Authenticated Internet Protocol as an authentication method, in which case the TLS packets are wrapped within GSS-API packets. The local certificate to use for the exchange is a parameter to TLS. When multiple certificates and certification authorities are available to be matched in order to get a successful authentication, each Authenticated Internet Protocol peer MUST retry all its applicable credentials (for example, certificates) before failing the TLS negotiation and moving to the next authentication method. The authentication retry is controlled by flags on the GSS-API payload.

The rules for setting the GSS-API payload flags are as follows:

  • The GSS-API flags (GSS_RETRY_CURRENT_AUTHENTICATION and GSS_NEW_GSS_EXCHANGE, as specified in section 2.2.3.1) MUST be set by the initiator to signal that it is retrying the TLS negotiation.

  • The GSS-API flag GSS_NEW_GSS_EXCHANGE MUST be set by the initiator when TLS negotiation has failed, to advance to the next authentication method.

  • The Status field in the GSS-API payload MUST be set to a nonzero value by the responder if no other TLS credentials are acceptable. When this field is set, the initiator MUST advance to the next authentication method.

  • The Status field in the GSS-API payload MUST be set to a nonzero value and the GSS_RETRY_CURRENT_AUTHENTICATION flag MUST be set by the responder to instruct the initiator that it MUST retry TLS with a different credential, if available. When the initiator retries TLS with a different credential, it MUST set the Status field by using the nonzero value that is received from the responder in the GSS-API payload.

Notation used to describe common details and specific roles in the remainder of section 3

This specification uses the same notation that is specified in [RFC2409] section 3.2, with a few additions that are noted as "additional notation" in this topic:

  • HDR: An ISAKMP header whose exchange type is the method. When written as HDR*, it indicates payload encryption.

  • Security Association (SA): An SA negotiation payload that embeds one or more Proposal and Transform payloads. See [RFC2409] section 3.4.

  • CKY-I and CKY-R: The initiator cookie and responder cookie, respectively, from the ISAKMP header. These are used together with initiator and responder IP addresses as a unique key for looking up each session.

  • g^xy: The Diffie-Hellman shared secret.

  • g(qm)^xy (additional notation): The Diffie-Hellman secret in the quick mode negotiation phase.

  • KE: The Key Exchange payload that contains the public information that is exchanged in a Diffie-Hellman exchange.

  • Nx: The Nonce payload. x can be "I" or "r" for the ISAKMP initiator and responder, respectively. x(qm) is the quick-mode nonce.

  • IDx: The Identity payload for "X". x can be: "I" or "r" for the ISAKMP initiator and responder, respectively. The Identity payload format for the Internet DOI is specified in [RFC2407] section 4.6.2.

  • hash(msg) (additional notation): The negotiated hash algorithm for the main mode security association (MM SA). Msg is the quantity to hash.

  • sha1 (additional notation): The SHA-1 hash function, as specified in [FIPS180]. [SHA256] is used until the hash function has been negotiated.

  • prf(key, msg): The keyed pseudorandom function (PRF) that is used to generate a deterministic output that appears pseudorandom. PRF is used both for key derivations and for authentication (for example, as a keyed MAC). PRF is implemented as an HMAC of the negotiated hash algorithm, as defined in [RFC2104].

  • SKEYID: A string that is derived from a secret that is known only to the active players in the exchange.

  • SKEYID_e: The keying material that is used by the ISAKMP SA to protect its messages.

  • SKEYID_a: The keying material that is used by the ISAKMP SA to authenticate its messages.

  • SKEYID_d: The keying material that is used to derive keys for non-ISAKMP SAs.

  • SKEYID_em: The keying material that is used by AuthIP to authenticate extended mode negotiation messages.

  • Notify (additional notation): The ISAKMP Notify payload as specified in [RFC2408] section 3.14.

  • Authx (additional notation): The authentication proof for x, where x is either the first or second authentication and has a value of 1 to 4. It is embedded in a Hash payload.

  • Auth payload (auth): The payload that is constructed by looking up the peer authentication database (PAD) and the security policy database (SPD). The Auth payload contains the authentication methods that are valid for this negotiation.

  • VID (additional notation): The Vendor ID payload.

  • KeyDict (In): Key Dictation payload used for supplying dictator's inbound QM SA keys.

  • KeyDict (Out): Key Dictation payload used for supplying dictator's outbound QM SA keys.

  • SKWt : Key Dictation/Weight payload used for negotiating key dictation, that is, negotiating which end, if any, will supply the key.

  • A-KDF(Z, OtherInfo, keydatalen) (additional notation): Invoke the Key Derivation Function (KDF), as specified in [SP800-56A]. The Key Derivation Function uses the negotiated main mode hash function as its hash function.

  • Crypto-ID (additional notation): A 16-bit number that corresponds to the negotiated main mode encryption algorithm. The table that maps the algorithm identifiers to the corresponding numbers is defined in [RFC2409] Appendix A.

  • GSS-APIsecret, GSS-APIsecret_em (additional notation): The session key that is obtained from a successful GSS-API exchange in main mode (MM) and extended mode (EM), respectively, as specified in [GSS].

  • hashLength, cryptLength (additional notation): The length, in bytes, of the key for the negotiated MM SA authentication and encryption algorithms.<10>

  • ipsechashLength, ipseccryptLength (additional notation): The length, in bytes, of the key for the QM SA authentication and encryption algorithms.

  • #n (additional notation): Numbers the packet within a series of exchanges for reference. This information is not on the wire.

  • [ x ]: Indicates that x is optional.