2

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.

Community
  • 1
Eddie
  • 751
  • 1
  • 6
  • 21
  • 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 04 '14 at 22:06

1 Answers1

1

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.

Community
  • 1
ecdsa
  • 1,354
  • 7
  • 10
  • 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 05 '14 at 21:51
  • Yes, KEYMAT comprises all the keys required for the negotiated IPsec SAs. I've update my answer. – ecdsa Dec 06 '14 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 06 '14 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 08 '14 at 09: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 08 '14 at 16:33
  • Yes, that's about it. It depends on the algorithms, of course. For instance, [AEAD algorithms](http://en.wikipedia.org/wiki/AEAD_block_cipher_modes_of_operation) like [AES-GCM](https://tools.ietf.org/html/rfc4106) provide confidentiality and authentication but require only a single key. What other keys are you referring to? Maybe you should read up on IPsec in general, try [RFC 4301](http://tools.ietf.org/html/rfc4301), or perhaps something a bit easier to digest like [the Illustrated Guide to IPsec](http://www.unixwiz.net/techtips/iguide-ipsec.html). – ecdsa Dec 09 '14 at 09:52