Secure Shared Key Authentication for IKE

1
Secure Shared Key Authentication for IKE

• Dan Harkins
• Aruba Networks

2
Insecure Shared Key Authentication Today

• Use of a shared key based on a password is
  insecure.
• The exchange is susceptible to dictionary attack.
• The shared key needs to contain as much
  unpredictability as the strongest key being
  negotiated ( 2.15). In other words long, hard
  to remember and error-prone to provision
• 128 bits of unpredictability is going to be a
  password whose length is around 300 bytes!
• Humans have a hard time entering a string of more
  than 12 bytes without error.
• Where shared key authentication is used with IKE
  today it is (with high probability) insecure
  because no one does long, hard to remember, and
  error prone very well.
• Simple shared keys are very popular and will
  continue to be used. They should be supported
  securely and realistically.

3
Secure Shared Key Authentication

• Uses an exchange based on a zero-knowledge proof
  is resistant to dictionary attack.
• The only way to attack an exchange based on a
  zero-knowledge proof is repeated active attack.
• This can be detected and countermeasures can be
  deployed.
• This allows much weaker shared keys (like
  passwords) to be used while still being secure.
• This has nice benefits
• Shared keys can be used in the practical and
  realistic way they are today but it will be
  secure.
• Management interface for shared key provisioning
  can be simple.

4
Proposal

• Use a secure password-authenticated key exchange
  inside IKE
• Same underlying exchange as is in IEEE802.11s
  draft and in EAP-pwd.
• The Diffie-Hellman group used is the same one
  negotiated in the SA payload.
• Each side sends a Commit and a Confirm.
• Secure under Computational Diffie-Hellman (CDH)
  assumptions.
• Resistant to passive attack, active attack,
  dictionary attack.
• Resistant to Denning-Sacco attack.
• Note there is no Internet-Draft for this right
  now!

5
Secure IKE Authentication with a Shared Secret
HDR, SAi1, KEi, Ni
HDR, SAr1, KEr, Nr
HDR, SK IDi, Commit , IDr,
SAi2, TSi, TSr
HDR, SK IDr, Commit, Confirm
HDR, SK Confirm, AUTH
HDR, SK AUTH, SAr2, TSi, TSr
6
Why Not Just Use EAP?

• For use cases in 1.1.1 and 1.1.2
• EAP is a client-server protocol. If both sides
  can initiate there are no strict client and
  server roles.
• There is no User as shown in draft-eronen-ipsec-
  ikev2-eap-auth.
• Each side must possess the shared secret no AAA
  server for scaling benefit. AAA servers dont
  operate as EAP clients.
• Security is based on I know the secret not I
  know someone who knows someone who knows the
  secret.
• EAP would just be a pointless encapsulation
• Implementations would be forced to implement both
  client-side EAP and server-side EAP.
• More, unnecessary, messages (12 vs. 5). EAP
  fragmentation?
• EAP is still an option for other use cases
• For any asymmetric authentication or
  authentication using a credential other than a
  secret shared by both IKE peers.
• Where there are client and server roles and/or a
  AAA server is probable.
• Where there is a User.

7
Why This Should Be a WG Item

• There are choices to make that would benefit from
  the cryptographic and implementer expertise in
  this group
• How to fit Commit and Confirm into the data to
  MIC?
• How to best detect that this exchange is used?
  New Notify? Presence of a critical Commit payload
  in message 2?
• How to use the key derived from this exchange
• Is it only used as Shared Secret for AUTH
  signing purposes?
• How to use it with SKEYSEED and its derivatives
  (like SK_d)?
• New authentication method for AUTH payload?
• What about the existing (insecure) shared key
  authentication?
• It needs vetting by the group to ensure that it
  solves the problem in the best possible way.
• The devil is in the details and there are
  important details that this WG should work on to
  ensure its done right.

8
Thank You!