Requirements for PAKE schemes
draft-irtf-cfrg-pake-reqs-07
Network Working Group J. Schmidt
Internet-Draft secunet Security Networks
Intended status: Informational September 5, 2016
Expires: March 9, 2017
Requirements for PAKE schemes
draft-irtf-cfrg-pake-reqs-07
Abstract
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. Furthermore,
it presents requirements and gives recommendations to designers of
new schemes. It is a product of the Crypto Forum Research Group
(CFRG).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 9, 2017.
Copyright Notice
Copyright (c) 2016 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
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
Schmidt Expires March 9, 2017 [Page 1]
Internet-Draft Requirements for PAKE schemes September 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. PAKE Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Storage of the Password . . . . . . . . . . . . . . . . . 3
3.2. Transmission of Public Keys . . . . . . . . . . . . . . . 4
3.3. Two Party versus Multiparty . . . . . . . . . . . . . . . 4
4. Security of PAKEs . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Implementation Aspects . . . . . . . . . . . . . . . . . 6
4.2. Special case: Elliptic Curves . . . . . . . . . . . . . . 6
5. Protocol Considerations and Applications . . . . . . . . . . 6
6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements notation
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].
2. Introduction
Passwords are the predominant method of accessing the Internet today
due, in large part, to their intuitiveness and ease of use. Since a
user needs to enter passwords repeatedly in many connections and
applications, these passwords tend to be easy to remember and be 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.
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 in the exchange prove
possession of the shared password without revealing it. Such
exchanges are therefore resistant to off-line, brute-force dictionary
attacks. The idea was initially described by Bellovin and Merritt in
Schmidt Expires March 9, 2017 [Page 2]
Show full document text