Secure PreShared Key Authentication for IKE draftharkinsspskauth00 txt

Secure Pre-Shared Key Authentication for IKE draft-harkins-spsk-auth-00. txt Dan Harkins Aruba Networks

Use of PSKs Today • 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 errorprone to provision: – 128 bits of unpredictability is going to be a user-generated string whose length is over 100 characters from a 94 character alphabet! (see NIST SP 800 -63) – Humans have a hard time entering a string of more than 12 characters repeatedly 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 because they are easy to provision. • The easiest and most appealing use of PSKs with IKE is insecure.

Why is the Existing Scheme Insecure? • The problem is both IKEv 1 and IKEv 2 are not resistant to dictionary attack. – The exchange leaks information about the secret. – An attacker need see only one exchange to have enough information to run through all possible preshared keys until it she finds the right one. – Making the pre-shared key a uniformly random 128 -bit blob only makes the dictionary attack unlikely to succeed, it does not make the protocol resistant to a dictionary attack. – Moore’s law implies these attacks will take less and less time and the years go on. • Security is based on assumptions about the expertise of administrators (not good practice). • IKEv 1 doesn’t really do PSK authentication well.

The Solution: Zero Knowledge Proof • An active attack leaks a single bit of information: whether the guess of the PSK was right or wrong. A passive attack leaks nothing. • Advantage is achieved through interaction and not computation– resistant to dictionary attack! – The attacker gets one and only one guess at the preshared key per active attack. – Failed active attacks are trivially noticed and countermeasures can be taken. – Moore’s law does not affect this. • Security can be achieved even in the presence of weak PSKs, such as user-generated passwords.

What are the Practical Effects? • Imagine a randomly-chosen 4 character PSK using only lower-case English letters: 264 -- or 456, 976 -- different possible PSKs. – Existing PSK authentication: one attack and a couple minutes of number crunching to find PSK – Secure PSK authentication: tens of thousands of active attacks necessary before a significant chance of finding the PSK. Countermeasures can make this take months, or even make it highly improbable, to succeed. • Robust and misuse-resistant cryptography! – The security is no longer based on unrealistic assumptions about the expertise of administrators. – Security can be achieved even when deployed “incorrectly”. – PSKs can be used practically and realistically. – Provisioning UI can be simple.

Secure PSK Authentication in IKEv 2 HDR, SAi 1, KEi, Ni HDR, SAr 1, KEr, Nr HDR, SK {IDi, Commit [, IDr], SAi 2, TSi, TSr } HDR, SK {IDr, Commit, Confirm} HDR, SK {Confirm, AUTH} HDR, SK {AUTH, SAr 2, TSi, TSr}

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. Need to implement both client-side and server-side EAP. – There is no “User” as shown in draft-eronen-ipsec-ikev 2 -eap-auth. – Each side must possess the shared secret– no AAA server for scaling benefit. AAA servers don’t operate as EAP clients. • Security is based on “I know the secret” not “I know someone who knows the secret. ” • EAP would just be a pointless encapsulation – Implementations would be forced to implement both EAP client and EAP server state machines. – More, unnecessary, messages (12 vs. 6). 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”.

OK, But Why? • This should be done… – The existing PSK mode of IKE(v 2) is (becoming more) insecure. – With this proposal security becomes an integral part of IKE(v 2) and not a contingency that is dependent on how the protocol is deployed. – This is a secure alternative that uses PSKs in the natural manner in which we all know they are, and will continue to be, used. – Even if large random numbers are used as the PSK, this is still a better, more secure, exchange. • …in this working group – There are choices to make that would benefit from the cryptographic and implementer expertise in this group – 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 it’s done right.

Thank You!