[IPsec] PAKE selection: SPSK
"Dan Harkins" <dharkins@lounge.org> Mon, 24 May 2010 20:24 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77673A6841 for <ipsec@core3.amsl.com>; Mon, 24 May 2010 13:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Level:
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_80=2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inTEwYuEVfMx for <ipsec@core3.amsl.com>; Mon, 24 May 2010 13:24:34 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8EE433A67AC for <ipsec@ietf.org>; Mon, 24 May 2010 13:24:34 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B26A11022404C for <ipsec@ietf.org>; Mon, 24 May 2010 13:24:26 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 May 2010 13:24:26 -0700 (PDT)
Message-ID: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net>
Date: Mon, 24 May 2010 13:24:26 -0700
From: Dan Harkins <dharkins@lounge.org>
To: ipsec@ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [IPsec] PAKE selection: SPSK
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2010 20:24:35 -0000
Hi, To kick off the PAKE selection discussion I'd like to tout one of the candidate protocols. It is based on the dragonfly key exchange and is described in draft-harkins-ipsecme-spsk-auth. Variants of dragonfly have been proposed for IEEE 802.11 and as an EAP method. The aforementioned draft contains a complete description of how to add dragonfly to IKE(v2), including the additional payloads needed, their construction and processing, their format, and how they fit into IKE(v2). While complete it isn't rigid; things (like the way this exchange is indicated) can change without affecting security. I think the best way to start the discussion is to run through the enumerated selection criteria from draft-harkins-ipsecme-pake-criteria. SEC1: dragonfly is based on a zero knowledge proof. It is resistant to passive, active, and (off-line) dictionary attack. SEC2: the PFS characteristics of IKE and its resistance to the Denning-Sacco attack are unchanged by inclusion of this authentication method. Dragonfly generates a shared key that has the properties of PFS and it is resistant to the Denning-Sacco attack but the generated key is used only for authentication. SEC3: the dragonfly exchange happens after IKE(v2)'s Diffie-Hellman key exchange and the subsequent payloads, including the ID payloads, are protected by a derivative of the resulting key. ID protection is not affected. SEC4: the protocol does not effect the "crypto agility" of IKE(v2). It uses the same Diffie-Hellman group that IKE(v2) uses, uses the same prf+() construct, and can use the negotiated MAC in HMAC form. No additional primitives (special modes of encryption, for example) are needed. SEC5: dragonfly has received cryptographic review in its other instantiations (IEEE 802.11 and EAP) and is secure. A proof of security in the Random Oracle model is underway but has not been finished. SEC6: the way dragonfly has been added to IKE(v2) is for authentication of the exchange in which it resides only. Since dragonfly is key generating though, it is possible to use it to parlay the weak secret into a long-term credential. SEC7: a secret element, based on the password, in the selected group is used in the exchange. That element can be stored instead of the password to resist exposure of the password in the case of compromise. IPR1: dragonfly was first publicly disclosed in January of 2008. IPR2: dragonfly was invented by me but I did not patent it nor did my employer at the time of invention. It is believed to be patent-free. IPR3: no IPR disclosure to the IETF has been made because one is not needed. MISC1: dragonfly adds one roundtrip to IKEv2 and to IKEv1's Main Mode. It turns IKEv1's Aggressive Mode from a three message exchange to a four message exchange. MISC2: dragonfly requires three "scalar operations", point multiplication for ECC or modular exponentiation for MODP. Basically, a "Diffie- Hellman and a half". MISC3: the nature of the shared secret (password, passphrase, long random octet string) does not affect performance. MISC4: internationalization can be supported as evidenced by the EAP method employing the dragonfly exchange. MISC5: dragonfly can use any of the ECP and MODP groups defined in the IANA registry for IKE(v2). EC2N groups are disallowed because of patent concerns and a desire to make implementation of dragonfly be license free. There is no technical reason, though, why EC2N groups couldn't be used. MISC6: the protocol fits nicely into IKE(v2)'s request/response nature. One single request and response is added and additional information is piggy-backed on the final request and response in IKE(v2) already. MISC7: no additional negotiation is needed: no new groups, no new ciphers, no new cipher modes, no key wrapping. MISC8: dragonfly does not require trusted third parties nor does it require any clock synchronization. MISC9: dragonfly requires use of an HMAC instantiation of a hash algorithm. The current specification uses this as a "random function". Another instantiation of dragonfly uses an HMAC'd hash function in "extractor" and "expander" roles, effectively defining two roles for the single random function. This can easily be done for IKE(v2) too. MISC10: the protocol supports the use of elliptic curve cryptography. MISC11: dragonfly is easily implemented. A reference implementation of the IEEE 802.11 variant is a Source Forge project named "authsae". It requires APIs for ECC and MODP operations found in most modern crypto libraries (e.g. OpenSSL). Dragonfly is easy to implement, license/royalty/patent free, has modest overhead, and fits easily into IKE(v2). I believe the current manner in which it has been added to IKE(v2) is fine but it can be changed if implementation concerns require it. Dragonfly is secure and has received cryptographic review. It does not require any additional group definitions and, aside from an HMAC'd hash algorithm, does not require additional use of any other cryptographic primitives like ciphers. It does not require any specific cipher modes (e.g. CBC or ECB) nor does it prohibit any (e.g. a stream cipher or a block cipher being used as a stream cipher). It is completely "crypto agile". I believe it is the best candidate to meet the requirements laid out in the new charter. I solicit comments and questions on this proposal. regards, Dan.
- [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins