IPsec is a framework protocol that consists of the sub-protocols ESP and AH. IPsec, inately, doesn't include a Key Exchange mechanism, and is therefore dependent on manually setting Keys (archaic), or using IKEv1 or IKEv2 to securely establish mutual keys between two parties.

From reading the IKE and IKEv2 RFC's, I know that both of them at some point generate KEYMAT, which is meant to be passed to IPsec so that IPsec can generate its own symmetric keys.

IKEv1 generates KEYMAT using this formula:

PFS Disabled:
KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

PFS Enabled:
KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

IKEv2 generates KEYMAT using this formula:

For the first Child SA:
KEYMAT = prf+(SK_d, Ni | Nr)

For all subsequent Child SA's
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )

In both cases, KEYMAT is passed to IPSec to (presumably) create its own symmetric Encryption and Authentication keys. But I haven't been able to find anywhere the formulas IPsec uses to take the KEYMAT and/or derivative keys (SKEYID_d or SK_d) and create its own keys.

So my question is, What does IPsec do with KEYMAT in order to generate its own symmetric keys? And also related, What keys does IPsec generate after being given KEYMAT? Although I feel answering the first question will also answer the second.

  • PS. I wasn't sure whether to direct this question here, or to the Cryptography stack exchange. If Crypto is a better home for this question, please let me know and I will happily move it.
    – Eddie
    Dec 4, 2014 at 22:06

2 Answers 2


The IPsec stack does not create it's own keys, or request any keys for that matter, instead the IKE daemon generates as much key material as required for the negotiated encryption and authentication algorithms using the PRF+ (which can basically return an arbitrary amount of key material). How key material is taken from the expanded KEYMAT is described in detail in RFC 7296 (IKEv2), section 2.17. The resulting keys are then passed with the rest of the information about an IPsec SA to the stack. With the standardized PF_KEY interface, for instance, this is done with two Key extensions if encryption and authentication is used.

  • So you're saying IPsec requests from ISAKMP the appropriate amount of bits needed to create all of its keys, and ISAKMP's PRF is what generates all the necessary keying material? AKA, KEYMAT is all the IPsec keys? If so, could you point out where the RFC (or elsewhere) identify how many keys IPsec needs created?
    – Eddie
    Dec 5, 2014 at 21:51
  • Yes, KEYMAT comprises all the keys required for the negotiated IPsec SAs. I've update my answer.
    – ecdsa
    Dec 6, 2014 at 11:03
  • I'm sorry, I'm having a hard time finding the answer in the link you provided. I just want to know where in the RFC it identifies explicitly which keys IPsec needs. An example of what I am looking for is in Page9 of RFC 2409, starting with the paragraph that states "The result of either Main Mode or Aggressive mode...". But this states the Keys created by IKEv1/ISAKMP, I want to know what keys are created by IPsec.
    – Eddie
    Dec 6, 2014 at 22:29
  • Key are not created "by IPsec", they are created by IKE. And as mentioned, section 2.17 in RFC 7296 clearly describes how this is done (beginning with "In any case, keying material for each Child SA MUST be taken..." until the end of that section).
    – ecdsa
    Dec 8, 2014 at 9:31
  • So to make sure I understand. From RFC 7296: "For ESP and AH, defines the order, namely: the encryption key (if any) MUST be taken from the first bits and the integrity key (if any) MUST be taken from the remaining bits.". IPsec requires two keys from ISAKMP (per IPsec SA): One symmetric encryption key, sized based upon encryption algorithim chosen (DES=56, AES=128, etc); and One HMAC key, sized based upon hash algorithim (MD5=128, SHA1=160, etc). Does that about sum it up? Does IPsec make use of any OTHER secret keys, not listed here?
    – Eddie
    Dec 8, 2014 at 16:33

For ESP and AH the encryption key must be taken from the first bits and the integrity key must be taken from the remaining bits. rfc7296. If the KEYMAT key length is not enough then, KEYMAT is expanded by feeding the results of the prf or HMAC back into itself and concatenating results until the required keying material has been reached: KEYMAT = K1 | K2 | K3 | ...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .