One document matched: draft-sheffer-ipsecme-pake-criteria-01.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" ipr="trust200902"
docName="draft-sheffer-ipsecme-pake-criteria-01.txt">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <front>
    <title abbrev="Password Based Authentication in IKEv2">
    Password-Based Authentication in IKEv2: Selection Criteria and Comparison</title>
    <author initials="Y." surname="Sheffer"
    fullname="Yaron Sheffer">
      <organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
      <address>
        <postal>
          <street>5 Hasolelim St.</street>
          <city>Tel Aviv</city>
          <code>67897</code>
          <country>Israel</country>
        </postal>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2010" />
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <!-- ************************************************************************************ -->
    <section title="Introduction">
    <t>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:</t>
    <t>
    <list style="empty">
	<t>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.</t>

  <t>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.</t>

  <t>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.</t>
  </list>
  </t>

  <t>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.</t>

    </section>
    <!-- ************************************************************************************ -->
    <section title="Terminology">
    <t>This document is entirely non-normative. None of the IETF-capitalized words SHOULD
    be used, and if perchance they are, they MUST be ignored.</t>
      <t>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
      <xref target="RFC2119" />.</t>

    </section>
    <!-- ************************************************************************************ -->
    <section title="Selection Criteria">
    <t>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.
    </t>
    <section title="Security Criteria">
	<t>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.</t>
	<t>
	<list style="symbols">
	<t>The protocol has good security "best practices", such as crypto agility.</t>
	<t>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.</t>
	<t>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.</t>
	<t>Some modern protocols have been mathematically proven secure under various models.
	This is an attractive feature of such protocols.</t>
	</list>
	</t>
	<t>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.</t>
	<t>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 all deployed implementations.</t>
    </section>
    <section title="Intellectual Property">
    <t>"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.</t>
    <t>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.</t>
    <t>
    <list style="empty">
    <t>Disclaimer: I am not a lawyer, and this document should not be
    construed as legal advice.</t>
    </list>
    </t>
    <t>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 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:
    </t>
    <t>
    <list style="symbols">
    <t>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.</t>
    <t>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.</t>
    <t>Many IETF participants, and the IETF as an organization, quite naturally prefer freely
    licensed technology to non-free licensing terms.</t>
    </list>
    </t>
    <t>Given the number and quality of encumbered protocols in this space, IPR is one area
    where the group might have to compromise.</t>
    </section>
    <section title="Other Considerations and Engineering Criteria">
    <t>A few additional criteria may be just as important:</t>
    <t>
    <list style="symbols">
    <t>Protocols that have been specified within standards document 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 serious security
    analysis.</t>
    <t>Likewise, cryptographic protocols that have been integrated
    into the IKE framework have an
    advantage over those described only within other security protocols.</t>
    <t>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.</t>
    <t>Performance, measured primarily by the number of round trips and
    number of exponentiations.</t>
    <t>The ability to scale as security criteria become more stringent. Specifically,
    the ability to replace modular by elliptic curve arithmetic.</t>
    <t>The always valid, but always vague "ease of implementation".</t>
    </list>
    </t>
    </section>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Some Possible Candidates">
    <t>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.</t>
    <t>
    <list style="numbers">
    <t>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.</t>
    <t>SPSK (a.k.a. EAP-PWD) is a relatively new mechanism. It has been standardized within
    IEEE 802.11s.</t>
    <t>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).</t>
    <t>SRP has been deployed in multiple products. It is described by
    several IETF documents, including a TLS-SRP variant. SRP
    can be used under a royalty-free license.</t>
    </list>
    </t>
    <t>In addition, applicable standards to be consulted
    for these and additional protocols include:</t>
    <t>
    <list style="symbols">
    <t>IEEE P1363.2, Specifications for Password based Public Key Cryptographic Techniques.</t>
    <t>ISO/IEC 11770-4:2006 Information technology - Security techniques - Key management - Part 4:
    Mechanisms based on weak secrets.</t>
    </list>
    </t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Comparison Table">
    <t>This is a very rough attempt at a comparative analysis. Many of the details are
    incomplete, and/or controversial.</t>
    <texttable>
    <ttcol>Name</ttcol>
    <ttcol>Security Standards</ttcol>
    <ttcol>Security Analysis</ttcol>
    <ttcol>IPR</ttcol>
    <c>EKE</c><c><xref target="I-D.sheffer-emu-eap-eke"/></c><c>Well analyzed security,
    since 1992, several analysis papers published.</c><c>Patent from 1992 (Lucent?),
    due to expire Oct. 2011.</c>
    <c>SRP</c><c>SRP published as <xref target="RFC2945"/>, TLS-SRP is
    <xref target="RFC5054"/>. IEEE 1363.2.</c>
    <c>Published and unpublished analysis by Bleichenbacher.</c>
    <c>Patent held by Stanford University, with a free license.
    Phoenix posted an IPR statement, but no request for reexamination.</c>
    <c>SPSK</c><c><xref target="I-D.harkins-emu-eap-pwd"/>,
    <xref target="I-D.harkins-ipsecme-spsk-auth"/>.</c>
    <c>Security analysis by NIST cryptographers.</c>
    <c>Explicitly not patented. May or may not infringe on existing patents.</c>
    <c>SPEKE</c><c>IEEE 1363.2.</c><c>[To be completed]</c><c>Patents held by Phoenix.</c>
	<c>PAK</c><c>Published as <xref target="RFC5683"/>. IEEE 1363.2.</c>
	<c>[To be completed]</c>
	<c>Patents held by Lucent.</c>
    </texttable>

    </section>
    <!-- ************************************************************************************ -->
    <section title="IANA Considerations">
      <t>This document does not require any action by IANA.</t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Security Considerations" anchor="security">
    <t>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.</t>
    </section>
    <!-- ************************************************************************************ -->
<!--
    <section title="Acknowledgments">
    </section>
    -->
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml"?>
    </references>
    <references title="Informative References">
    <?rfc include="reference.I-D.sheffer-emu-eap-eke"?>
    <?rfc include="reference.I-D.harkins-emu-eap-pwd"?>
    <?rfc include="reference.I-D.harkins-ipsecme-spsk-auth"?>
    <?rfc include="reference.RFC.2945.xml"?>
    <?rfc include="reference.RFC.5054.xml"?>
    <?rfc include="reference.RFC.5683.xml"?>
    </references>
    <section title="Change Log">
      <section title="-01">
        <t>Added some criteria after mailing list review.</t>
      </section>
      <section title="draft-sheffer-ipsecme-pake-criteria-00">
        <t>Initial version.</t>
      </section>
    </section>
  </back>
</rfc>