| HDR is an ISAKMP header whose exchange type is the mode. When written as
HDR* it indicates payload encryption. |
| SA is an SA negotiation payload with one or more proposals. An initiator
MAY provide multiple proposals for negotiation; a responder MUST reply with
only one. |
| <P>_b indicates the body of payload <P>-- the ISAKMP generic
vpayload is not included. |
| SAi_b is the entire body of the SA payload (minus the ISAKMP generic
header)-- i.e. the DOI, situation, all proposals and all transforms offered
by the Initiator. |
| CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie,
respectively, from the ISAKMP header. |
| g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the initiator
and responder respectively. |
| g^xy is the Diffie-Hellman shared secret. |
| KE is the key exchange payload which contains the public information
exchanged in a Diffie-Hellman exchange. There is no particular encoding (e.g.
a TLV) used for the data of a KE payload. |
| Nx is the nonce payload; x can be: i or r for the ISAKMP initiator and
responder respectively. |
| IDx is the identification payload for "x". x can be:
"ii" or "ir" for the ISAKMP initiator and responder
respectively during phase one negotiation; or "ui" or
"ur" for the user initiator and responder respectively during
phase two. The ID payload format for the Internet DOI is defined in [Pip97]. |
| SIG is the signature payload. The data to sign is exchange-specific. |
| CERT is the certificate payload. |
| HASH (and any derivitive such as HASH(2) or HASH_I) is the hash payload.
The contents of the hash are specific to the authentication method. |
| prf(key, msg) is the keyed pseudo-random function-- often a keyed hash
function-- used to generate a deterministic output that appears
pseudo-random. prf's are used both for key derivations and for
authentication (i.e. as a keyed MAC). (See [KBC96]). |
| SKEYID is a string derived from secret material known only to the active
players in the exchange. |
| SKEYID_e is the keying material used by the ISAKMP SA to protect the
confidentiality of its messages. |
| SKEYID_a is the keying material used by the ISAKMP SA to authenticate its
messages. |
| SKEYID_d is the keying material used to derive keys for non-ISAKMP
security associations. |
| <x>y indicates that "x" is encrypted with the key
"y". |
| è signifies "initiator to responder" communication (requests). |
| <-- signifies "responder to initiator" communication (replies). |
| | signifies concatenation of information-- e.g. X | Y is the
concatentation of X with Y. |
| [x] indicates that x is optional. |
Message encryption (when noted by a '*' after the ISAKMP header) MUST begin
immediately after the ISAKMP header. When communication is protected, all
payloads following the ISAKMP header MUST be encrypted. Encryption keys are
generated from SKEYID_e in a manner that is defined for each algorithm.
Perfect Forward Secrecy
When used in the memo Perfect Forward Secrecy (PFS) refers to the notion that
compromise of a single key will permit access to only data protected by a single
key. For PFS to exist the key used to protect transmission of data MUST NOT be
used to derive any additional keys, and if the key used to protect transmission
of data was derived from some other keying material, that material MUST NOT be
used to derive any more keys.
Perfect Forward Secrecy for both keys and identities is provided in this
protocol. (Sections 5.5 and 8).
Security Association
A security association (SA) is a set of policy and key(s) used to protect
information. The ISAKMP SA is the shared policy and key(s) used by the
negotiating peers in this protocol to protect their communication.