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
