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 error-prone 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 IKEv1 and IKEv2 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 pre-shared 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). IKEv1 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 pre-shared 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 IKEv2 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}

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-ikev2-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 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… …in this working group The existing PSK mode of IKE(v2) is (becoming more) insecure. With this proposal security becomes an integral part of IKE(v2) 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!