Hi Dennis, I have read the PACE submission. I believe claim 1 of the SPEKE patent, US 6,792,533, covers this protocol. If you do think otherwise, please explain why.
Also, in PACE you compute CIPH=E(Pwd, s) where E() is the encryption function of some block cipher and Pwd is the shared password. You don't mention the block cipher but some block ciphers have weak keys and most take a fixed-length key. For a general specification like this I suggest strengthening it by removing any kind of dependencies and also to bind the parties to the exchange. I suggest using an "extraction" function with the shared password and the identities of the two peers to distill the entropy from the password, bind the identities, and derive a key with which to do the encryption: k = Extractor(Pwd | max(ID-A, ID-B) | min(ID-A, ID-B)) CIPH = E(k, s) where max(x,y) and min(x,y) output an ordering their inputs in some deterministic fashion, ID-A and ID-B are the identities of the two parties to the exchange, and "|" is concatenation. regards, Dan. On Wed, May 26, 2010 4:37 am, Dennis Kügler wrote: > The evaluation of the PACE proposal according to the criteria draft is > already > contained in the draft itself > (http://www.ietf.org/id/draft-kuegler-ipsecme-pace-ikev2-00.txt) for > completeness and for convenience you'll find a copy below. > > PACE was designed to avoid existing patents (and is not patented) and to > allow > for implementations without any cryptographic restrictions other than that > the primitives have to be secure on their own. A proof of the security of > the > protocol is available. > > PACE is currently used and standardized in the context of contactless > smartcards, especially for electronic passports and ID-cards. The OpenPACE > project also provides a patch to implement PACE on top of OpenSSL. > > Best regards, > > Dennis > > > SEC1: PACE is a zero knowledge protocol. > SEC2: The protocol supports perfect forward secrecy and is > resistant to replay attacks. > SEC3: The identity protection provided by IKEv2 remains unchanged. > SEC4: Any cryptographically secure Diffie-Hellman group can be > used. > SEC5: The protocol is proven secure in the Bellare-Pointcheval- > Rogaway model. > SEC6: Strong session keys are generated. > SEC7: A transform of the password can be used instead of the > password itself. > > IPR1: The first draft of [TR03110] was published on May 21, 2007. > IPR2: BSI has developed PACE aiming to be free of patents. BSI has > not applied for a patent on PACE. > IPR3: The protocol itself is believed to be free of IPR. > > MISC1: One additional exchange is required. > MISC2: The protocol requires the following operations per entity: > o one key derivation from the password, > o one symmetric encryption or decryption, > o one multi-exponentiation for the mapping, > o one exponentiation for the key pair generation, > o one exponentiation for the shared secret calculation, and > o two symmetric authentications (generation & verification). > MISC3: The performance is independent of the type/size of password. > MISC4: Internationalization of character-based passwords is > supported. > MISC5: The protocol uses the same group as negotiated for IKEv2. > MISC6: The protocol fits into the request/response nature of IKE. > MISC7: The password-based symmetric encryption must be additionally > negotiated. > MISC8: Neither trusted third parties nor clock synchronization are > required. > MISC9: Only general cryptographic primitives are required. > MISC10: Any secure variant of Diffie Hellman (e.g. standard or > Elliptic Curve) can be used. > MISC11: The protocol can be implemented easily based on existing > cryptographic primitives. > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
