Internet Research Task Force D. Harkins
Internet-Draft HP Enterprise
Intended status: Informational August 6, 2018
Expires: February 7, 2019
Public Key Exchangedraft-harkins-pkex-06
Abstract
This memo describes a password-authenticated protocol to allow two
devices to exchange "raw" (uncertified) public keys and establish
trust that the keys belong to their respective identities.
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 February 7, 2019.
Copyright Notice
Copyright (c) 2018 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Harkins Expires February 7, 2019 [Page 1]

Internet-Draft PKEX August 2018
keys to each peer, and it enables the establishment of trust in
public keys that can subsequently be used to faccilitate
authentication in other authentication and key exchange protocols.
At the end of a successful run of PKEX the two peers will have trust
in each others exchanged public keys and also share an authenticated
symmetric key which may be discarded or used for another purpose.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
1.2. Notation
This memo describes a cryptographic exchange using sets of elements
called groups. Groups can be based on elliptic curves (hereafter,
ECC groups) or on the multiplicative group of the field of integers
modulo an odd prime (hereafter FFC groups). The public keys
exchanged by PKEX are elements in a group. Elements in groups are
denoted in upper-case and scalar values are denoted with lower-case.
There is a distinguised generator of the group, denoted G. The order
of the sub-group formed by G is q which itself must be a large prime.
When both the initator and responder use a similar, but unique, datum
it is denoted by appending an "i" for initiator or "r" for responder,
e.g. if each side needs an element C then the initiator's is Ci and
the responder's is Cr.
During the exchange, one side will generate data and the other side
will attempt to reconstruct it. The reconstructed data is "primed".
That is, if the initiator generates C then when responder tries to
reconstruct it, the responder will refer to it as C'. Data that is
directly sent and received is not primed.
The following notation is used in this memo:
C = A + B
The "group operation" on two elements, A and B, that produces a
third element, C. For finite field cryptography this is the
modular multiplication, for elliptic curve cryptography this is
point addition.
C = A - B
The "group operation" on element A and the inverse of element B
to produce a third element, C. Inversion is defined such that
the group operation on an element and its inverse results in the
Harkins Expires February 7, 2019 [Page 3]

Internet-Draft PKEX August 2018
identity element, the value one (1) for finite field cryptography
and the "point at infinity" for elliptic curve cryptography.
C = a * B
This denotes repeated application of the group operation to B--
i.e. B + B-- (a - 1) times.
a = H(b)
A cryptographic hash function that takes data b of indeterminate
length and returns a fixed sized digest a.
a = F(B)
A mapping function that takes an element and returns a scalar.
For elliptic curve cryptography, F() returns the x-coordinate of
the point B. For finite field cryptography, F() is the identity
function.
a = KDF-b(c, d)
A key derivation function that derives an output key a of length
b from an input key c and context d.
a = HMAC(b, c)
A keyed MAC function that produces a digest a using key b and
text c.
a | b
Concatentation of data a with data b.
{a}b[c]
Authenticated-encryption of data (a), with a key (b), and
associated data (c) that is authenticated but not encrypted. The
result of this is a ciphertext that includes authentication
information dependent on both a and c, whether c is actually
transmitted or is somehow reconstructed. The receipent can
decrypt a if it knows b and neither {a}b nor c have been altered
during transmission, otherwise an error will be flagged.
2. Properties
Subversion of PKEX involves an adversary being able to insert its own
public key into the exchange without the exchange failing, resulting
in one of the parties to the exchange believing the adversary's
public key actually belongs to the protocol peer.
PKEX has the following properties:
o An adversary is unable to subvert the exchange without knowing the
password.
Harkins Expires February 7, 2019 [Page 4]

Internet-Draft PKEX August 2018
o An adversary is unable to discover the password through passive
attack.
o The only information exposed by an active attack is whether a
single guess of the password is correct or not.
o Proof-of-possession of the private key is provided.
o At the end of the protocol, either trust is established in the
peer's public key and the public key is bound to the peer's
identity, or the exchange fails.
3. Assumptions
Due to the nature of the exchange, only DSA ([DSS]) and ECDSA
([X9.62]) keys can be exchanged with PKEX.
PKEX requires fixed elements that are unique to the particular role
in the protocol, an initiator-specific element and a responder-
specific element. They need not be secret. It is assumed that both
parties know the role-specific elements for the particular group in
which their key pairs were derived. Techniques to generate role-
specific elements, and generated elements for popular groups, are
listed in Appendix A.1 and Appendix A.2.
The generator used in PKEX SHALL be obtained from the domain
parameter set defining the group, for example [DSS] for the NIST
elliptic curves and [RFC5639] for brainpool curves.
The authenticated-encryption algorithm provides deterministic "key
wrapping". To achieve this the AE scheme used in PKEX is AES-SIV as
defined in [RFC5297].
The KDF provides for the generation of a cryptographically strong
secret key from an "imperfect" source of randomness. To achieve this
the KDF used in PKEX is the unsalted version of [RFC5869].
The keyed MAC function is HMAC per [RFC2104].
The following assumptions are made on PKEX:
o Only the peers involved in the exchange know the password.
o The peers' public keys are from the same group.
o The discrete logarithms of the public role-specific elements are
unknown, and determining them is computationally infeasible.
Harkins Expires February 7, 2019 [Page 5]

Internet-Draft PKEX August 20184. Cryptographic Primitives
HKDF and HMAC require an underlying hash function and AES-SIV
requires a key length. To provide for consistent security the hash
algorithm and key length depend on the group chosen to use with PKEX.
For ECC, the hash algorithm and key length depends on the size of the
prime defining the curve, p:
o SHA-256 and 256 bits: when len(p) <= 256
o SHA-384 and 384 bits: when 256 < len(p) <= 384
o SHA-512 and 512 bits: when 384 < len(p)
For FFC, the hash algorithm depends on the prime, p, defining the
finite field:
o SHA-256 and 256 bits: when len(p) <= 2048
o SHA-384 and 384 bits: when 2048 < len(p) <= 3072
o SHA-512 and 512 bits: when 3072 < len(p)
5. Protocol Definition
PKEX is a balanced PAKE. The identical version of the password is
used by both parties.
PKEX consists of two phases: authentication and reveal. It is
described using the popular protocol participants, Alice (an
initiator of PKEX), and Bob (a responder of PKEX).
We denote Alice's role-specific element a Pi and Bob's as Pr. The
password is pw. For simplicity, Alice's identity is "Alice" and
Bob's identity is "Bob". Alice's public key she wants to share with
Bob is A and her private key is a, while Bob's public key he wants to
share with Alice is B and his private key is b.
While both Alice and Bob expose their identities to passive
eavesdroppers, the public keys they exchange (and ultimately gain
trust in) are not. Once PKEX has finished, Alice and Bob can
identifiy each other using their trusted public keys and thereby
provide a level of anonymity to subsequent communications.
Implementations SHALL maintain a counter of unsuccessful exchanges
for each password in order to defend against repeated active attacks
to determine the password. This counter SHALL be set to zero when a
Harkins Expires February 7, 2019 [Page 6]

Internet-Draft PKEX August 2018
password is provisioned and incremented each time PKEX finishes
unsuccessfully for that password. When the counter reaches a value
of five (5) the password SHALL be irretrievably removed from the
implementation.
5.1. Authentication Phase
The Authenticaiton phase is essentially the SPAKE2 key exchange. The
peers derive ephemeral public keys, encrypt, and exchange them. Each
party hashes the password and operates on the role-specific element
to obtain a secret encrypting element. The group operation is then
performed with the ephemeral key and the secret encrypting element to
produce an encrypted ephmeral key. The ephemeral private keys MUST
be generated with high quality (pseudo-)randomness and SHALL never be
re-used.
Alice: Bob:
------ ----
x, X = x*G y, Y = y*G
Qa = H(pw)*Pi Qb = H(pw)*Pr
M = X + Qa
Alice, M ------>
Qa = H(pw)*Pi
X' = M - Qa
N = Y + Qb
z = KDF-n(F(y*X'),
Alice | Bob |
F(M) | F(N) | pw)
<------ Bob, N
Qb = H(pw)*Pr
Y' = N - Qb
z = KDF-n(F(x*Y'),
Alice | Bob |
F(M) | F(N) | pw)
where n is the key length and KDF uses the hash algorithm from
Section 4.
Both M and N MUST be verified to be valid elements in the selected
group. For ECC groups this means they MUST be valid points on the
curve, for FFC groups they MUST be between one and the prime minus
one, and the group operation on the element and the order of the sub-
group, q, MUST equal one. If either element is not valid the
protocol fails.
At this point the peers have exchanged ephemeral elements that will
be unknown except by someone with knowledge of the password. Given
Harkins Expires February 7, 2019 [Page 7]

Internet-Draft PKEX August 2018
our assumptions that means only Alice and Bob can know the elements X
and Y, and the secret key, z.
The secret encrypting elements Qa and Qb SHALL be irretrievably
deleted at this point. The password MAY be irretrievably deleted at
this time.
5.2. Reveal Phase
In the Reveal phase the peers commit to the particular public key
they wish to exchange and reveal it to the peer. Proof-of-possession
of the private key is accomplished by "signing" the public key, the
identity to which the public key is bound, the receipient's ephemeral
public key, and the sender's ephemeral public key.
The messages exchanged in the Reveal phase are encrypted and
authenticated with AES-SIV using a key derived from the SPAKE2 key
exchange in Section 5.1. Successful construction and validation of
these messages authenticates the SPAKE2 exchange by proving
possession of the SPAKE2 shared secret and therefore knowledge of the
password. A single octet of the value zero (0) is used as associated
data when encrypting Alice's message to Bob and a single octet of the
value one (1) is used as associated data when constructing Bob's
response. The associated data is not transferred as part of the
either message.
The received public keys MUST be verified to be valid elements in the
selected group using the same technique as above: for ECC groups they
MUST be valid points on the curve, for FFC groups they MUST be
between one and the prime minus one, and the group operation on the
element and the order of the group, q, MUST equal one. If a received
public key is not valid the protocol fails.
Harkins Expires February 7, 2019 [Page 8]

Internet-Draft PKEX August 2018
Alice: Bob:
------ ----
u = HMAC(F(a*Y'), Alice | F(A) |
F(Y') | F(X))
{A, u}z[0] ------>
if (SIV-decrypt returns fail) fail
if (A not valid element) fail
u' = HMAC(F(y*A), Alice | F(A) |
F(Y) | F(X'))
if (u' != u) fail
v = HMAC(F(b*X'), Bob | F(B) |
F(X') | F(Y))
<------ {B, v}z[1]
if (SIV-decrypt returns fail) fail
if (B not valid element) fail
v' = HMAC(F(x*B), Bob | F(B) |
F(X) | F(Y))
if (v'!= v) fail
where 0 and 1 are single octets of the value zero and one,
respectively, and HMAC uses the hash algorithm from Section 4.
If the parties didn't fail they have each other's public key,
knowledge that the peer possesses the corresponding private key, and
trust that the public key belongs to the peer's identity that was
authenticated in the Authentication Phase.
If the parties fail, the counter that protects against active attack
(see Section 5) SHALL be incremented. If the value of the counter is
five (5) the password SHALL be irretrievably deleted.
All ephemeral state created during the PKEX exchange SHALL be
irretrievably deleted at this point. Once PKEX successfully
completes the password MAY be deleted (or even exposed, with no loss
of security). The authenticated and secret symmetric key, z, MAY be
used for further key derivation with a different context but if not
it SHOULD be irretrievably deleted.
6. IANA Considerations
This memo could create a registry of the fixed public elements for a
nice cross section of popular groups. Or not. Once published this
document will be a stable reference and a registry might not be
needed.
Harkins Expires February 7, 2019 [Page 9]

Internet-Draft PKEX August 20187. Security Considerations
The encrypted shares exchanged in the Authentication phase MUST be
ephemeral. Reuse of these keys, even with a different password,
voids the security of the exchange.
If fixed elements other than those in Appendix A.1 and Appendix A.2
are used, their discrete logarithm MUST not be known. Knowledge of
of the discrete logarithm of either of the fixed elements voids the
security of the exchange.
The public keys exchanged in PKEX are never disclosed to an attacker,
either passive or active. While they are, as the name implies,
public, PKEX provides for secrecy of the exchanged keys for any
protocol that might need such a capability.
PKEX has forward secrecy in the sense that exposure of the password
used in a previous run of the protocol will not affect the security
of that run. This also means that once PKEX has finished, the
password can be exposed to a third party with out loss of security--
the public keys exchanged are still trusted and still bound to the
entities that performed the exchange originally.
The Authentication Phase of PKEX is SPAKE2. The SPAKE2 security
proof guarantees that if both sides bind the same password to each
other's identity they will derive the same secret. This means that
the public key sent in the Reveal phase is guaranteed to be sent by
the identified peer-- it is sent in a message that is integrity
protected and encrypted by a key, z, derived from the SPAKE2 shared
secret. This binds the peer's public key to its authenticated
identity. Proof-of-possession of the private key is provided by also
sending a digest keyed by the result of a function of the private key
and the peer's ephemeral share from the Authentication Phase. Since
the sender is not able to predict what random ephemeral share will be
received in the Authentication Phase, it is unable to generate a
keyed digest without knowing the private analog to the public key it
is sending.
There is no proof of security of PKEX at this time.
8. Acknowledgements
The author wishes to thank Liliya Ruslanovna Ahmetzyanova, Stanislav
Smyshlyaev, and Greg Rose for their detailed reviews, helpful
comments, and patience in answering questions.
Harkins Expires February 7, 2019 [Page 10]

Internet-Draft PKEX August 20189. Changes/Author Notes
[ RFC Editor: Please remove this section before publication ]
00-04
Initial version recorded is -04
04-05
Accepted comments from Liliya Ruslanovna Ahmetzyanova and
Stanislav Smyshlyaev.
Accepted comments from Greg Rose
Indicated G is from group definitions, added normative reference
to brainpool curves.
Added a counter to deal with repeated active attack.
Mention in introduction that the result of PKEX is trust in the
public key and an authenticated symmetric key
Make group description more formal and accurate.
Add some assumptions to the notational definition for
authenticated encryption.
Send identities during auth phase instead of asssuming identities
are somehow learned a priori. Add mention that public key is not
exposed to passive attackers.
Note that ephemeral private keys must be generated with high
quality randomness and never be reused.
Define what it means to verify M and N for both FFC and ECC.
Fix the technique used to generate the fixed elements for both FFC
and ECC.
10. References10.1. Normative References
[DSS] U.S. Department of Commerce/National Institute of
Standards and Technology, "Digital Signature Standard
(DSS)", Federal Information Processing Standards FIPS PUB
186-4, July 2013.
Harkins Expires February 7, 2019 [Page 11]

Internet-Draft PKEX August 2018Appendix A. Role-specific Elements
Role-specific elements for six popular elliptic curves and four
popular modp groups from [RFC3526] have been generated using the
following technique which guarantees that their discrete logarithm
will be unknown.
A loop is performed to generate role-specific elements by generating
a candidate, testing the candidate, and exiting the loop once the
test succeeds. A single octet counter is incremented each time
through the loop (first time through the loop, the counter is one).
To find a candidate, a hash of an identifier (the concatenation of
the ASN.1 of the OID of the curve or the name of the FFC group), a
constant string, and the counter is produced. If the length of the
hash's digest is less than the desired bits, the digest is pre-pended
to the inputs and the result is fed back into the hash (this time it
is a hash of a concatentation of the old digest, identifier, constant
string, counter) to produce the next length-of-digest bits. This is
repeated until the number of bits has been produced. Excess octets
are stripped off. The resulting string is interpreted as an integer
with the first octet of the (first) hash being the high-order octet
of the integer. If the prime defining the group (the modulo of all
operations in an FFC group or the prime defining the curve for ECC
groups) is not an integral number of octets, the bitstring is right-
shifted, pre-pending with zero bits, in order to make a big-endian
bitstring of the appropriate length. If that resulting big-endian
number is larger than the prime defining group, the counter is
incremented and the loop continues. Otherwise, the integer is
checked to see whether it is in the correct sub-group. This process
is different for ECC and FFC.
For ECC, the integer is treated as an x-coordinate and checked
whether it produces a valid point on the curve. If a solution to the
equation of the curve does not exist for that x-coordinate, the
counter is incremented and a new candidate integer is calculated. If
a solution to the equation of the curve exists for that x-coordinate,
the polarity of the counter is used to select a y-coordinate-- if the
counter is odd then use y-p, if the counter is even use y. This
point is in the correct sub-group and looping terminates.
For FFC, the co-factor is calculated as (p-1)/q, where p is the prime
modulus and q is the order of the sub-group. The integer is taken to
the power of the co-factor modulo p. If the result is equal to one,
the counter is increased and a new candidate integer is calculated.
If the result is not equal to one then the result is in the correct
sub-group and it becomes the element; looping terminates.
Harkins Expires February 7, 2019 [Page 13]