One document matched: draft-irtf-cfrg-pake-reqs-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
]>

<rfc category="std" ipr="trust200902" docName="draft-irtf-cfrg-pake-reqs-02">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
        <title>Requirements for PAKE schemes</title>
	<!--	<abbrev>Requirements for PAKE schemes</abbrev>-->
	<author initials="J.-M.S." fullname="Jörn-Marc Schmidt" surname="Schmidt">
      <organization>secunet Security Networks</organization>

      <address>
        <postal>
          <street>Mergenthaler Allee 77</street>

          <city>65760 Eschborn</city>

          <country>Germany</country>
        </postal>
        <email>joern-marc.schmidt@secunet.com</email>
      </address>
	  
    </author>
        <date/>
		<!--<workgroup>Internet Research Task Force</workgroup>-->
        <abstract><t>Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes and discusses their requirements.</t></abstract>
    </front>

    <middle>
        <section title="Requirements notation">
            <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="Introduction">	
	  <t>
	    Passwords are the predominant method of accessing the Internet today
	    due largely to their intuitiveness and ease of use. Since a user needs
	    to enter her password repeatedly over the course of many connections
	    to the Internet, these passwords tend to be easy to remember and able
	    to be entered, repeatedly, with a low probability of error. They
	    tend to be low-grade and not-so-random secrets that are susceptible
	    to brute-force guessing attacks. In other words, they are horrible
	    credentials to use for authentication. 
	  </t>
	  <t>
	    A Password-Authenticated Key Exchange (PAKE) attempts to address this
	    issue by constructing a cryptographic key exchange that does not
	    result in the password, or password-derived data, being transmitted
	    across an unsecured channel. Two parties to the exchange prove 
	    possession of the shared password without revealing it. Such 
	    exchanges are therefore resistant to an off-line, brute-force 
	    dictionary attack. PAKEs are especially interesting due to the fact
	    that they can achieve mutual authentication without requiring any
	    Public Key Infrastructure (PKI).
	  </t>
	  <t>
	    The problem was initially described by Bellovin and Merritt in 
	    <xref target="BM92"/> and has received considerable cryptographic
	    attention since then. 
	  </t>
</section>

<section title="PAKE Taxonomy">
  <t>
    Broadly speaking, different PAKEs satisfy their goals in a number of common ways. This leads to various design choices -
    how public keys are transmitted (encrypted or not), whether both parties possess the same representation of the password (balanced versus augmented), and the number of parties (two party versus
    multiparty). 
  </t>
  <section title="Storage of the Password">
    <t>
      When both sides of a PAKE store the same representation of the password, 
	  the PAKE is said to be "balanced". In a balanced PAKE the
      password can be stored directly, in a salted state by hashing it
      with a random salt, or by representing the credential as an element in
      a finite field (by, for instance, multiplying a generator from a
      finite field the password represented as a number to produce a "password
      element"). The benefits of such PAKE are that it is applicable to
      situations where either party can initiate the exchange or both parties
      can initiate simultaneously (where they both believe themselves to be
      the "initiator"). This sort of PAKE can be useful for mesh networking
      (e.g. <xref target="DOT11"/>) or Internet-of-Things applications.
    </t>
    <t>
      When one side maintains are uninvertable transform of the password and
      the other maintains the raw password, the PAKE is said to be "augmented".
      Typically, a client will maintain the raw password and a server will
      maintain a transformed element generated with a one-way function. 
      The benefit of an augmented PAKE is that
      the server's password database is protected in a way that is not possible
      with a balanced PAKE. Augmented PAKEs are resistant to Key Compromise
      Impersonation (KCI) where an adversary who has successfully attacked Bob can
      impersonate Bob to everyone, but it is not possible to impersonate everyone
      back to Bob. An adversary that has successfully obtained the server's PAKE
      credentials is still required to perform a dictionary attack in order to
      learn an individual password. This sort of PAKE is useful for strict
      client-server protocols, such as <xref target="RFC5246"/>. 
    </t>
  </section>
  <section title="Transmission of Public Keys">
    <t>
      All known PAKEs use public key cryptography. A fundamental difference in
      PAKEs is how the public key is communicated in the exchange. 
    </t>
    <t>
      One class of PAKEs uses symmetric key cryptography, with a key derived
      from the password, to encrypt an ephemeral public key. The ability of the
      peer to demonstrate it has successfully decrypted the public key proves
      knowledge of the shared password. Examples of this exchange include the
      first PAKE presented by <xref target="BM92"/>, the Encrypted Key Exchange
      (EKE). A variant of this method, as it is e.g. used in international travel 
	  documents by PACE <xref target="BFK09"/>, is to encrypt a nonce instead 
	  of a key, which is later used for the derivation of the shared key.
    </t>
    <t>
      The other class of PAKEs transmit unencrypted public keys. These public keys
      may be blinded by some function of the shared password, but the public key that
      is transmitted across the unsecured medium is an element in a finite field,
      not a random blob. The ability of the peer to successfully use that public key
      (for example, possibly unblinding it) proves knowledge of the shared password.
      Examples of this exchange include <xref target="SPEKE"/>.
    </t>
  </section>
  <section title="Two Party versus Multiparty">
    <t>
      The majority of PAKE protocols allow two parties to agree on a shared key based on a shared password. Nevertheless, there exist proposals that allow key agreement for more than two parties. Those protocols allow key establishment for a group of parties, hence are called Group PAKEs or GPAKEs. Examples of such protocols include <xref target="ABCP06"/>, while <xref target="ACGP11"/> and <xref target="HYCS15"/> propose a generic construction that allows transferring any two-party PAKE into a GPAKE protocol. Another possibility to define a multi-party PAKE protocol is to assume the existence of a trusted server each party shares a password with. This server enables different parties to agree on a common secret key without the need to share a password among each other. Each party has only a shared secret with the trusted server. For example Abdalla et al. designed such a protocol <xref target="AFP05"/>.
    </t>
  </section>
</section>

<section title="Security of PAKEs">
  <t>
    PAKE schemes are modelled on the scenario of two parties, typically Alice and Bob,
    who share a password (or perhaps Bob shares a function of the password) and would
    like to use it to establish a secure session key over an untrusted link. There is
    a powerful adversary, typically Eve, who would like to subvert the exchange. Eve
    has access to a dictionary that is likely to contain Alice and Bob's password and
    Eve is capable of enumerating through the dictionary in a brute-force manner to
    try and discover Alice and Bob's password.
  </t>
  <t>
    All PAKEs have a flaw: if Eve guesses the password she can subvert the exchange.
    Therefore to consider security of a PAKE it is necessary to model the difficulty
    of that happening. If the probability of discovering the password is a function
    of interaction with the protocol participants, and not a function of computation,
    then the PAKE is secure. That is, if Eve is unable to take information from a
    passive attack or a single active attack and enumerate through her dictionary
    then the only attack left is repeated guessing attacks. Eve learns one thing
    from a single active attack: whether her single guess is correct or not.
  </t>
<t>In other words, the security of a PAKE scheme is based on the idea that Eve, who is trying to impersonate Alice cannot efficiently verify a password guess without interacting with Bob (or Alice) and hence is detected. Hence, it is essential to keep a balance of allowed tries to reduce the probability of Eve to succeed on the one hand and to limit the risk of a denial of service vulnerability on the other hand. In order to judge and compare the security of PAKE schemes, security proofs in commonly accepted models should be used. However, each proof and model is based on assumptions: Often, a security proof shows that in case an adversary is able to break the scheme, she is also able to solve a problem that is assumed to be hard, like computing a discrete logarithm. By conversion, breaking the  scheme is considered as a hard problem, too. In addition, proofs sometimes rely on idealized versions of hash functions and/or block ciphers, called random oracles and ideal ciphers.</t>
<t>A PAKE scheme should come with a security proof and also clearly state its assumptions and used models. In addition, the authors may specify which underlying primitives to be used with their scheme.</t>

<section title="Implementation Aspects" anchor="implementation_aspects">
<t>Besides the theoretical security of a scheme, pitfalls when implementing it in practice have to be considered as well. Even a scheme that is secure in a well-defined mathematical model can leak information via side-channels, 
if it is not carefully implemented. The design of the scheme may allow or prevent an easy protection against information leakage. In a network scenario, an adversary may measure the time the computation of an answer takes and 
derive information about secret parameters of the scheme. If a device operates in a potential hostile environment, e.g. in case it is implemented on a smart card, other side-channels like power consumption and 
electromagnetic emanations, or even active implementation attacks have to be taken into account as well.</t>
<t>The developers of a scheme should keep the implementation aspects in mind and show how to implement the protocol in constant time. Furthermore, adding a discussion how to protect implementations of their scheme in potential 
hostile environments is encouraged. </t>
</section>

<section title="Special case: Elliptic Curves" >
<t>Since Elliptic Curve Cryptography (ECC) allows for a smaller key-length compared to traditional schemes based on the discrete logarithm problem in finite fields at similar security levels, using ECC for PAKE schemes is also 
of interest. In contrast to schemes that can use the finite field element directly, an additional challenge has to be considered for some schemes based on ECC: The mapping of a random string to an element that can be computed 
with, i.e. a point on the curve. In some cases, also the opposite is required, i.e. the mapping of a curve point to a string that is not distinguishable from a random one. When choosing a mapping, it is crucial to consider the 
implementation aspects as well. </t>
<t>In case the PAKE scheme is intended to be used with ECC, the authors should state whether there is a mapping function required and if so, discuss its requirements. Alternatively, the authors may define a mapping to be used with their scheme.</t>
</section>
</section>

<section title="Protocol Considerations and Applications">
<t>In most cases, the PAKE scheme is a building block in a more complex protocol like IPSEC or TLS. This can influence the choice of a suited PAKE scheme. For example, an augmented scheme can be 
beneficial for protocols that have a strict server-client relationship. In case both parties may initiate a connection of a protocol, a balanced PAKE may be more appropriate.</t>

  <t>
    A special variation of the network password problem, called Password Authenticated Key Distribution, is defined in <xref target="P1363"/> as
    password authenticated key retrieval: "The retrieval of a key from a secure
    key repository or escrow requiring authentication derived in part from a password."
  </t>
  <t>
    In addition to retrieval of a key from escrow, there is the variant of two parties
    exchanging public keys using a PAKE in lieu of certificates-- public keys can be
    encrypted using a password and the ability of each side to both know the private
    key associated with its unencrypted public key and also decrypt the peer's public
    key performs authenticated key distribution. This technique can be used to parlay
    a short one-time code, into a long-lived public key.
  </t>
  <t>
	Another possible variant of a PAKE scheme allows combining authentication with certificates and the use of passwords. In this variant, the private key of the certificate is used to blind the password key agreement. For verification, the message is unblinded with the public key. A correct key establishment therefore implies the possession of the private key belonging to the certificate. This method enables authentication of one side as well as mutual authentication in addition to the authentication using the password. 
  </t>
  <t>
	The authors of a PAKE scheme MAY discuss variations of their scheme and explain application scenarios, where these variations are beneficial. In particular, techniques that allow agreeing on a long-term (public) key are encouraged. 
  </t>
  </section>	

<section title="Privacy">
<t>In order to establish a connection, each party of the PAKE protocol needs to know the identity of its communication partner to use the right password for the agreement. In cases where a user wants to establish a secure channel with a server, the user first has to let the server know which password to use, i.e. send some kind of identifier to the server. If this identifier is not protected, everyone who is able to eavesdrop on the connection can identify the user. In order to prevent this, i.e. to protect the privacy of the user, the scheme might come with a way to protect the transmission of the user's identity. A simple way to achieve privacy of a user that communicates with a server is to use a public key provided by the server to encrypt the user's identity. 
</t><t>
The PAKE scheme MAY discuss special ideas and solutions how to protect the privacy of the users of the scheme.

</t>
</section>
<section title="Performance">
<t>The performance of a scheme can be judged along different lines, depending on what is the scarcest resource in the application field. Potential metrics include latency, code-size/area, power consumption, or exchanged messages. 
In addition, there might be application scenarios, in which a constrained client communicates with a powerful server, i.e., a scheme that requires minimal efforts on client side is most suited. Note that for some clients the 
computations might even be carried out in a hardware implementation, asking for different optimizations compared to software. </t>
<t>Furthermore, the design of the scheme may also influence the cost of protecting its implementation from adversaries exploiting its physical properties (see <xref target="implementation_aspects"/>). </t>
<t>The authors of a PAKE scheme may discuss their design choices and the influence of these choice on the performance. In particular, the optimization goals could be stated.</t>
</section>

<section title="Requirements">
<t>This section formulates the requirements for PAKE schemes based on the previous discussed properties. 
</t>
<t>
<list>
<t>R1: A PAKE scheme MUST clearly state its features regarding balanced/augmented versions.</t>
<t>R2: A PAKE scheme SHOULD come with a security proof and clearly state its assumptions and models.</t>
<t>R3: It SHOULD be possible to implement the PAKE scheme in constant time.</t>
<t>R4: The authors MAY show how to protect an implementation of their PAKE scheme in hostile environments. </t>
<t>R5: In case the PAKE scheme is intended to be used with ECC, the authors SHOULD discuss their requirements for a potential mapping or define a mapping to be used with the scheme.</t>
<t>R6: A PAKE scheme MAY discuss its design choice with regard to performance, i.e., its optimization goals.</t>
<t>R7: The authors of a scheme MAY discuss variations of their scheme that allows the use in special application scenarios. In particular, techniques that allow agreeing on a long-term (public) key are encouraged.</t>
<t>R8: A scheme MAY discuss special ideas and solutions on privacy protection of its users. </t>
<t>R9: The authors MUST declare the status of their scheme with respect to patents.</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>

<section title="Security Considerations">
<t> This document analyses requirements for a cryptographic scheme. Security considerations are discussed throughout the document.</t>
</section>
</middle>
	
<back>
  <references title='Normative References'>
    &RFC2119;
  </references>
  <references title='Informative References'>
    &RFC5246;

    <!--<reference anchor="BPR2000"> 
      <front>
	<title>Authenticated Key Exchange Secure against Dictionary Attacks</title>
	<author initials ="M.B." fullname='Mihir Bellare' surname="Bellare"/>
	<author initials ="D.P." fullname='David Pointcheval' surname="Pointcheval"/>
	<author initials ="P.R." fullname='Phillip Rogaway' surname="Rogaway"/>
	<date year="2000"/>
      </front>
      <seriesInfo name="Euorcrypt" value="2000"/>
      <seriesInfo name="LNCS" value="1807"/>
    </reference> -->

    <reference anchor="BM92">
      <front>
	<title>Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks</title>
	<author initials="S" surname="Bellovin">
	  <organization>Bell Laboratories</organization>
	</author>
	<author initials="M" surname="Merritt">
	  <organization>Bell Laboratories</organization>
	</author>
	<date year="1992"/>
      </front>
      <seriesInfo name="Proc. of the Symposium on Security and Privacy" value="Oakland"/>
    </reference>

    <reference anchor="SPEKE">
      <front>
	<title>Strong Password-Only Authenticated Key Exchange</title>
	<author initials="D.J" fullname="David Jablon" surname="Jablon"/>
	<date year="1996"/>
      </front>
      <seriesInfo name="ACM Computer Communications Review" value="October 1996"/>
    </reference>

    <reference anchor="DOT11">
      <front>
	<title>Telecommunications and information exchange between systems
		Local and metropolitan area networks</title>
	<author>
	  <organization>IEEE Computer Society</organization>
	</author>
	<date year="2012"/>
      </front>
	<seriesInfo name="
	    Part 11: Wireless LAN Medium Access Control (MAC) and Physical 
	    Layer (PHY) Specifications" value="IEEE Std 802.11-2012"/>
    </reference>
      
    <reference anchor="P1363">
      <front>
	<title>Draft Standard for Specifications for Password-based Public Key 
		Cryptograpic Techniques
	</title>
	<author>
	  <organization>IEEE Microprocessor Standards Committee</organization>
	</author>
	<date year="2006"/>
      </front>
      <seriesInfo name="IEEE" value="P1363.2"/>
    </reference>
	
	  <reference anchor="AFP05">
      <front>
	<title>Password-based authenticated key exchange in the three-party setting
	</title>
	<author initials ="M.A." fullname='Michel Abdalla' surname="Abdalla"/>
	<author initials ="P.-A. F." fullname='Pierre-Alain Fouque' surname="Fouque"/>
	<author initials ="D.P." fullname='David Pointcheval' surname="Pointcheval"/>
		<date year="2005"/>
		 </front>
	  <seriesInfo name="PKC" value="2005"/>
      <seriesInfo name="LNCS" value="3386"/>
	 
	    </reference>  
	 
	  <reference anchor="ACGP11">
      <front>
	<title>Contributory Password-Authenticated Group Key Exchange with Join Capability	</title>
	<author initials ="M.A." fullname='Michel Abdalla' surname="Abdalla"/>
	<author initials ="C. C." fullname='Celine Chevalier' surname="Chevalier"/>
	<author initials ="L. G." fullname='Louis Granboulan' surname="Granboulan"/>
	<author initials ="D.P." fullname='David Pointcheval' surname="Pointcheval"/>
		<date year="2011"/>
		 </front>
	  <seriesInfo name="CT-RSA" value="2011"/>
      <seriesInfo name="LNCS" value="6558"/>
	 
	    </reference>  
	  
	  
	 
  	  <reference anchor="ABCP06">
      <front>
	<title>Password-Based Group Key Exchange in a Constant Number of Rounds
	</title>
	<author initials ="M.A." fullname='Michel Abdalla' surname="Abdalla"/>
	<author initials ="E.B." fullname='Emmanuel Bresson' surname="Bresson"/>
		<author initials ="O.C." fullname='Olivier Chevassut' surname="Chevassut"/>
	<author initials ="D.P." fullname='David Pointcheval' surname="Pointcheval"/>
	<date year="2006"/>
	</front>
	  <seriesInfo name="PKC" value="2006"/>
      <seriesInfo name="LNCS" value="3958"/>
	  
	    </reference>  
    
	
	  	  <reference anchor="HYCS15">
      <front>
	<title>The Fairy-Ring Dance: Password Authenticated Key Exchange in a Group
	</title>
	<author initials ="F.H." fullname='Feng Hao' surname="Hao"/>
	<author initials ="X.Y." fullname='Xun Yi' surname="Yi"/>
		<author initials ="L.C." fullname=' Liqun Chen' surname="Chen"/>
	<author initials ="S.F.S." fullname='Siamak F. Shahandashti' surname="Shahandashti"/>
	<date year="2015"/>
	</front>
	  <seriesInfo name="IoTPTS" value="2015"/>
      <seriesInfo name="ACM" value=""/>
	  
	    </reference>  
		
	
	  <reference anchor="BFK09">
      <front>
	<title>Security Analysis of the PACE Key-Agreement Protocol</title>
		<author initials ="J.B." fullname='Jens Bender' surname="Bender"/>
		<author initials ="M.F." fullname='Marc Fischlin' surname="Fischlin"/>
		<author initials ="D.K." fullname='Dennis Kuegler' surname="Kuegler"/>
	<date year="2009"/>
	  </front>
	   <seriesInfo name="ISC" value="2009"/>
      <seriesInfo name="LNCS" value="5735"/>
	    </reference>  
  </references>	
</back>

</rfc>