Network Working Group                                         Y. Sheffer
Internet-Draft                                               Check Point
Intended status: Informational                            March 24, 2010
Expires: September 25, 2010


     Password-Based Authentication in IKEv2: Selection Criteria and
                               Comparison
               draft-sheffer-ipsecme-pake-criteria-02.txt

Abstract

   The IPsecME working group has been chartered with specifying a new
   password-based authentication method for IKEv2.  This document
   presents a few solution alternatives, and lists potential criteria
   for choosing among them.  It is not the author's intention to publish
   this document as an RFC.  Moreover, it is more subjective than most
   IETF documents.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 25, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Sheffer                Expires September 25, 2010               [Page 1]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Selection Criteria . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Security Criteria  . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Intellectual Property  . . . . . . . . . . . . . . . . . .  5
     3.3.  Other Considerations and Engineering Criteria  . . . . . .  6
   4.  Some Possible Candidates . . . . . . . . . . . . . . . . . . .  7
   5.  Comparison Table . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
























Sheffer                Expires September 25, 2010               [Page 2]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


1.  Introduction

   The new IPsecME WG charter defines a new work item on password-based
   authentication for IKEv2.  This is a somewhat contentious issue, so
   the charter is very particular about the requirements.  Quoting in
   full:

      IKEv2 supports mutual authentication with a shared secret, but
      this mechanism is intended for "strong" shared secrets.  User-
      chosen passwords are typically of low entropy and subject to off-
      line dictionary attacks when used with this mechanism.  Thus, RFC
      4306 recommends using EAP with public-key based authentication of
      the responder instead.  This approach would be typically used in
      enterprise remote access VPN scenarios where the VPN gateway does
      not usually even have the actual passwords for all users, but
      instead typically communicates with a back-end RADIUS server.
      However, user-configured shared secrets are still useful for many
      other IPsec scenarios, such as authentication between two servers
      or routers.  These scenarios are usually symmetric: both peers
      know the shared secret, no back-end authentication servers are
      involved, and either peer can initiate an IKEv2 SA.  While it
      would be possible to use EAP in such situations (by having both
      peers implement both the EAP peer and the EAP server roles of an
      EAP method intended for "weak" shared secrets) with the mutual
      EAP-based authentication work item (above), a simpler solution may
      be desirable in many situations.
      The WG will develop a standards-track extension to IKEv2 to allow
      mutual authentication based on "weak" (low-entropy) shared
      secrets.  The goal is to avoid off-line dictionary attacks without
      requiring the use of certificates or EAP.  There are many already-
      developed algorithms that can be used, and the WG would need to
      pick one that both is believed to be secure and is believed to
      have acceptable intellectual property features.  The WG would also
      need to develop the protocol to use the chosen algorithm in IKEv2
      in a secure fashion.  It is noted up front that this work item
      poses a higher chance of failing to be completed than other WG
      work items; this is balanced by the very high expected value of
      the extension if it is standardized and deployed.

   The charter defines some properties that a good solution is required
   to have.  For example, despite the fact that EAP is an integral part
   of IKEv2, there are good reasons to avoid it in this case.  But the
   charter does not name a specific cryptographic protocol on which to
   base this solution, nor does it mention a specific IETF document as a
   starting point.  This document asserts that several such choices are
   possible, and attempts to provide the group with some selection
   criteria, in order to enable a reasoned discussion of these (and
   possibly other) alternatives.



Sheffer                Expires September 25, 2010               [Page 3]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


2.  Terminology

   This document is entirely non-normative.  None of the IETF-
   capitalized words SHOULD be used, and if perchance they are, they
   MUST be ignored.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Selection Criteria

   IKEv2 is targeted at applications that require a very high level of
   security.  Therefore, adding a new mode of operation to the protocol
   can only be done after careful consideration.  In this section, I
   describe some of the criteria we can use to choose between solution
   candidates.  Unfortunately, I am not aware of any potential solution
   that score a "perfect 10" under these criteria.  If this paper
   encourages the development of new solutions that better fit the
   criteria, so much the better.

3.1.  Security Criteria

   The primary requirement from a good solution is to have a high level
   of security.  Unfortunately, we all know this property is extremely
   hard to gauge.  But some data might enhance our confidence in a
   solution's security.

   SEC1:  The protocol has good security "best practices", such as
          crypto agility.
   SEC2:  The solution is based on a cryptographic protocol that has
          been (openly) published some time ago, giving the
          cryptographic community enough time to have reviewed it.
          Preferably, it was published in a location where it is more
          likely to be reviewed, e.g. a peer-reviewed crypto journal.
   SEC3:  The protocol has undergone thorough professional analysis.
          It's best if protocol analyses by prominent cryptographers
          have been published.  If issued were uncovered, we would
          prefer repeat analysis to have been undertaken on the fixed
          protocol.
   SEC4:  Some modern protocols have been mathematically proven secure
          under various models.  This is an attractive feature of such
          protocols.







Sheffer                Expires September 25, 2010               [Page 4]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


   SEC5:  When integrated with IKEv2, the solution should preserve IKE's
          existing security properties.  These include forward secrecy
          (disclosure of long term credentials, in this case the
          password, does not expose past sessions), and identity
          protection in the presence of passive attackers
          (eavesdroppers).
   SEC6:  The solution should be able of generating of a cryptographic-
          strength credential (either a long key or a certificate) so
          that the weak credential needs to be used rarely or even only
          once.

   It is noted that some features (such as support for password expiry)
   and some security criteria (such as resistance to server compromise)
   are very important for the "teleworker" use case.  This document is
   limited to the use of password-based authentication to achieve trust
   between gateways, and for this use case, these features and criteria
   are of questionable value.

   The author considers security assurance to be by far the most
   important criterion.  The impact of a security vulnerability
   discovered late in the process would be extremely severe to the
   protocol and to deployed implementations.

3.2.  Intellectual Property

   "Intellectual property", a common euphemism for patents, is a complex
   issue.  The existence of patents covering a specific technology is
   often an important consideration for vendors, and critical for open
   source implementers.  Despite this fact, the IETF does not provide
   its constituency with any legal guidance or assistance in this
   matter.

   Unfortunately, the specific area of password-based authentication is
   riddled with patents.  This has hampered the IETF adoption of this
   technology for years, and caused at least one working group to fail.
   As a result, we (as individual implementers and as a working group)
   need to understand as best we can the IPR status of each proposal.

      Disclaimer: I am not a lawyer, and this document should not be
      construed as legal advice.

   IETF rules require that any participant who's aware of a patent
   relevant to an IETF work item should disclose the patent's existence.
   In practice, such disclosures are often submitted very late in the
   process, resulting in a long period when a document's IPR status
   remains unclear.  Even more worryingly, filing an IPR statement
   against another person's technology carries no cost: in at least one
   case I am aware of, a company filed an IPR statement for a



Sheffer                Expires September 25, 2010               [Page 5]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


   competitive technology asserting their own patent, even though the
   technology is in fact covered by another patent, making it very
   likely that the company's patent does not apply to the technology.
   Given this background, I propose the following as selection criteria:

   IPR1:  Ideally, the proposal should be unencumbered.  This property
          is very difficult to prove, and each WG participant should
          attempt to review the applicable patents and determine whether
          in fact they do not apply to the proposal.  Remember that
          independently invented technology might still infringe a
          patent.
   IPR2:  In some cases the IPR situation is clear: if the protocol
          relies on a specific patent, and believed to not require the
          use of any other.  This is mostly useful if the patent's
          licensing terms (whether free or not) are known, and/or the
          patent's expiration date is near.
   IPR3:  Many IETF participants, and the IETF as an organization, quite
          naturally prefer freely licensed technology to non-free
          licensing terms.

   Given the number and quality of encumbered protocols in this space,
   IPR is one area where the group might have to compromise.

3.3.  Other Considerations and Engineering Criteria

   Several additional criteria may be just as important:

   MISC1:  Protocols that have been specified within standards documents
           should be preferred over protocols that are only described in
           scientific papers.  Such description is typically
           insufficient to provide interoperability, and may not be
           sufficient for a thorough security analysis.
   MISC2:  Likewise, cryptographic protocols that have been integrated
           into the IKE framework have an advantage over those described
           only within other security protocols.
   MISC3:  The protocol should make a good fit into the minimal IPsec/
           IKE architecture, e.g. it should not assume a trusted third
           party or tight clock synchronization.
   MISC4:  It is advantageous if the same algorithms and where
           applicable, the same Diffie-Hellman groups can be used for
           IKE itself and for the authentication protocol.  This can
           simplify the implementation and eliminate spurious
           negotiation.
   MISC5:  Performance, measured primarily by the number of round trips
           and number of exponentiations.  Performance should remain
           reasonable even if the "password" is a long octet string.





Sheffer                Expires September 25, 2010               [Page 6]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


   MISC6:  The solution should accommodate algorithm agility relative to
           IKE cryptographic algorithms, e.g., transition to elliptic
           curve key agreement.
   MISC7:  The solution must support localization of identities and
           passwords.  In general, the scheme must support arbitrary
           octet strings as the input, so that any current and future
           character encoding can be supported.
   MISC8:  Similarly, the scheme must support arbitrary octet strings as
           input, so that it can be used to "boost" shared secrets that
           have been generated using weak methods, e.g. not-quite-random
           RNGs.
   MISC9:  The always valid, but always vague "ease of implementation".


4.  Some Possible Candidates

   This section provides background regarding some of the candidate
   protocols.  Some pertinent properties are mentioned, but this is by
   no means an analysis against the criteria defined above.

   1.  EKE is the oldest password-authenticated key exchange (PAKE)
       protocol still considered secure, although some of its variants
       have been broken.  It is covered by a patent, due to expire in
       late 2011.
   2.  SPSK (a.k.a.  EAP-PWD) is a relatively new mechanism.  It has
       been standardized within IEEE 802.11s.
   3.  PAK is the earliest provably-secure mechanism.  A protocol
       description has been standardized within the IETF, but no other
       IETF PAK-based protocol exists.  PAK is patented (IPR statement
       #1179).
   4.  SRP has been deployed in multiple products.  It is described by
       several IETF documents, including a TLS-SRP variant.  SRP is
       patented, and can be used under a royalty-free license (IPR
       statement #31, as well as additional IPR statements filed by
       other parties).

   In addition, applicable standards to be consulted for these and
   additional protocols include:

   o  IEEE P1363.2, Specifications for Password based Public Key
      Cryptographic Techniques.
   o  ISO/IEC 11770-4:2006 Information technology - Security techniques
      - Key management - Part 4: Mechanisms based on weak secrets.


5.  Comparison Table

   This is a very rough attempt at a comparative analysis.  Many of the



Sheffer                Expires September 25, 2010               [Page 7]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


   details are incomplete, and/or controversial.

   +------+-----------------------------+---------------+--------------+
   | Name | Security Standards          | Security      | IPR          |
   |      |                             | Analysis      |              |
   +------+-----------------------------+---------------+--------------+
   | EKE  | [I-D.sheffer-emu-eap-eke],  | Well analyzed | Patent filed |
   |      | [I-D.sheffer-ipsecme-hush]  | security,     | 1992 (now    |
   |      |                             | since 1992,   | owned by     |
   |      |                             | several       | Lucent), due |
   |      |                             | analysis      | to expire    |
   |      |                             | papers        | Oct. 2011.   |
   |      |                             | published.    |              |
   | SRP  | SRP published as [RFC2945], | Published and | Patent held  |
   |      | TLS-SRP is [RFC5054].  IEEE | unpublished   | by Stanford  |
   |      | 1363.2, ISO IEC 11770-4.    | analysis by   | University,  |
   |      |                             | Bleichenbache | with a free  |
   |      |                             | r.            | license.     |
   |      |                             |               | Phoenix      |
   |      |                             |               | posted an    |
   |      |                             |               | IPR          |
   |      |                             |               | statement,   |
   |      |                             |               | but no       |
   |      |                             |               | request for  |
   |      |                             |               | reexaminatio |
   |      |                             |               | n.           |
   | SPSK | [I-D.harkins-emu-eap-pwd],  | Security      | Explicitly   |
   |      | [I-D.harkins-ipsecme-spsk-a | analysis by   | not          |
   |      | uth].                       | NIST          | patented.    |
   |      |                             | cryptographer |              |
   |      |                             | s.            |              |
   | SPEK | IEEE 1363.2 and ISO IEC     | [To be        | Patents held |
   | E    | 11770-4.                    | completed]    | by Phoenix.  |
   | PAK  | Published as [RFC5683].     | See [RFC5683] | Patents held |
   |      | IEEE 1363.2.                |               | by Lucent.   |
   +------+-----------------------------+---------------+--------------+


6.  IANA Considerations

   This document does not require any action by IANA.


7.  Security Considerations

   This document does not define any new protocol, and has no inherent
   security considerations.  It does discuss criteria for the selection
   of a security protocol, chief among them being security.



Sheffer                Expires September 25, 2010               [Page 8]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [I-D.harkins-emu-eap-pwd]
              Harkins, D. and G. Zorn, "EAP Authentication Using Only A
              Password", draft-harkins-emu-eap-pwd-13 (work in
              progress), February 2010.

   [I-D.harkins-ipsecme-spsk-auth]
              Harkins, D., "Secure PSK Authentication for IKE",
              draft-harkins-ipsecme-spsk-auth-01 (work in progress),
              March 2010.

   [I-D.sheffer-emu-eap-eke]
              Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An
              EAP Authentication Method Based on the EKE Protocol",
              draft-sheffer-emu-eap-eke-05 (work in progress),
              March 2010.

   [I-D.sheffer-ipsecme-hush]
              Sheffer, Y. and S. Fluhrer, "HUSH: Using HUmanly memorable
              SHared secrets with IKEv2", draft-sheffer-ipsecme-hush-00
              (work in progress), March 2010.

   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
              RFC 2945, September 2000.

   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
              "Using the Secure Remote Password (SRP) Protocol for TLS
              Authentication", RFC 5054, November 2007.

   [RFC5683]  Brusilovsky, A., Faynberg, I., Zeltsan, Z., and S. Patel,
              "Password-Authenticated Key (PAK) Diffie-Hellman
              Exchange", RFC 5683, February 2010.


Appendix A.  Change Log

A.1.  -02

   Yet more criteria after the discussion in Anaheim and on the list.




Sheffer                Expires September 25, 2010               [Page 9]


Internet-Draft   Password Based Authentication in IKEv2       March 2010


A.2.  -01

   Added some criteria after mailing list review.

A.3.  draft-sheffer-ipsecme-pake-criteria-00

   Initial version.


Author's Address

   Yaron Sheffer
   Check Point Software Technologies Ltd.
   5 Hasolelim St.
   Tel Aviv  67897
   Israel

   Email: yaronf.ietf@gmail.com

































Sheffer                Expires September 25, 2010              [Page 10]