0

I can't seem to find a sufficiently detailed resource that describes the IKE phase 1 PSK identity authentication process. They seem to focus on differences between aggressive and main mode while oversimplifying them.

I'm trying to understand the identity vetting of IKE phase 1 using a pre-shared key.

I read one source describing that the pre-shared key is hashed and those hashes are shared to prove that each party knows the hash (and therefore vet the identity of each party), however wouldn't capturing of those hashes present an opportunity for a replay attack? Or for example couldn't one side wait for the hash and send it back to "prove" it knows the PSK? Which leads to my next question, apparently main-mode encrypts the hash, so what is used to encrypt that hash, the same PSK?

I would love to read up on this more in order to attempt to answer my own questions, but again I can't seem to find anything thorough.

Thanks in advance.

Daveba123
  • 43
  • 5

1 Answers1

0

All this is basically answered in RFC 2409, section 5, which describes how SKEYID and HASH_I/R are calculated plus how the different keys are derived.

however wouldn't capturing of those hashes present an opportunity for a replay attack?

No, random nonces that are exchanged between the peers are used as input when calculating SKEYID (besides the PSK).

Or for example couldn't one side wait for the hash and send it back to "prove" it knows the PSK?

No, HASH_I (sent by the initiator) and HASH_R (sent by the responder) are calculated differently.

Which leads to my next question, apparently main-mode encrypts the hash, so what is used to encrypt that hash, the same PSK?

SKEYID_e is largely based on the shared secret from an ephemeral Diffie-Hellman exchange. But SKEYID is also incorporated and, as mentioned above, that is based on the PSK. So yes, without the PSK the message containing the HASH_I payload can't be decrypted. But depending on the strength of the PSK that might not help much (see my answer here).

Community
  • 1
ecdsa
  • 1,354
  • 7
  • 10
  • Interesting, thank you. I've read your other answers on IPSec and they were helpful as well. I'm still a bit confused about the nonce/PSK authentication portion but I guess I will have to read up on the rfc for further clarification. – Daveba123 Jan 30 '19 at 14:11
  • What exactly confuses you? – ecdsa Jan 31 '19 at 08:42
  • So random nonces are shared and then added to SKEYID along with the PSK to further protect the hash of the PSK. How then are these nonces shared in a way that protects them from eavesdroppers so each party knows what nonce was used in the hash in order to reverse the SKEY hash? – Daveba123 Jan 31 '19 at 12:49
  • The nonces are not private, they are publicly shared in the third and fourth Main Mode messages (`Ni/Nr` payloads). And what do you mean with "reverse the SKEY hash"? It's not possible to reverse a hash. – ecdsa Jan 31 '19 at 13:02
  • You're right, that's the part that messed me up. This makes sense now. Thanks for sticking with me! – Daveba123 Jan 31 '19 at 18:51