[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mccallum-kitten-krb-spake-preauth) 00 01 02 03 04 05 06 Draft is active
In: AD_Evaluation
Internet Engineering Task Force                              N. McCallum
Internet-Draft                                                  S. Sorce
Updates: 3961 (if approved)                                   R. Harwood
Intended status: Standards Track                           Red Hat, Inc.
Expires: June 3, 2018                                          G. Hudson
                                                                     MIT
                                                       November 30, 2017


                        SPAKE Pre-Authentication
                 draft-ietf-kitten-krb-spake-preauth-03

Abstract

   This document defines a new pre-authentication mechanism for the
   Kerberos protocol that uses a password authenticated key exchange.
   This document has three goals.  First, increase the security of
   Kerberos pre-authentication exchanges by making offline brute-force
   attacks infeasible.  Second, enable the use of second factor
   authentication without relying on FAST.  This is achieved using the
   existing trust relationship established by the shared first factor.
   Third, make Kerberos pre-authentication more resilient against time
   synchronization errors by removing the need to transfer an encrypted
   timestamp from the client.

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 June 3, 2018.

Copyright Notice

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





McCallum, et al.          Expires June 3, 2018                  [Page 1]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Properties of PAKE  . . . . . . . . . . . . . . . . . . .   3
     1.2.  PAKE Algorithm Selection  . . . . . . . . . . . . . . . .   3
     1.3.  PAKE and Two-Factor Authentication  . . . . . . . . . . .   4
     1.4.  SPAKE Overview  . . . . . . . . . . . . . . . . . . . . .   5
   2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   5
   3.  Prerequisites . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  PA-ETYPE-INFO2  . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Cookie Support  . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  More Pre-Authentication Data Required . . . . . . . . . .   6
   4.  Update to Checksum Specifications . . . . . . . . . . . . . .   6
   5.  SPAKE Pre-Authentication Message Protocol . . . . . . . . . .   7
     5.1.  First Pass  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Second Pass . . . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  Third Pass  . . . . . . . . . . . . . . . . . . . . . . .   9
     5.4.  Subsequent Passes . . . . . . . . . . . . . . . . . . . .  10
     5.5.  Reply Key Strengthening . . . . . . . . . . . . . . . . .  10
     5.6.  Optimizations . . . . . . . . . . . . . . . . . . . . . .  11
   6.  SPAKE Parameters and Conversions  . . . . . . . . . . . . . .  11
   7.  Transcript Checksum . . . . . . . . . . . . . . . . . . . . .  12
   8.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Second Factor Types . . . . . . . . . . . . . . . . . . . . .  14
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
     10.1.  Unauthenticated Plaintext  . . . . . . . . . . . . . . .  14
     10.2.  Side Channels  . . . . . . . . . . . . . . . . . . . . .  14
     10.3.  KDC State  . . . . . . . . . . . . . . . . . . . . . . .  15
     10.4.  Dictionary Attacks . . . . . . . . . . . . . . . . . . .  16
     10.5.  Brute Force Attacks  . . . . . . . . . . . . . . . . . .  16
     10.6.  Denial of Service Attacks  . . . . . . . . . . . . . . .  17
     10.7.  Reply-Key Encryption Type  . . . . . . . . . . . . . . .  17
     10.8.  KDC Authentication . . . . . . . . . . . . . . . . . . .  17
   11. Assigned Constants  . . . . . . . . . . . . . . . . . . . . .  17
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     12.1.  Kerberos Second Factor Types . . . . . . . . . . . . . .  18
       12.1.1.  Registration Template  . . . . . . . . . . . . . . .  18
       12.1.2.  Initial Registry Contents  . . . . . . . . . . . . .  18



McCallum, et al.          Expires June 3, 2018                  [Page 2]


Internet-Draft          SPAKE Pre-Authentication           November 2017


     12.2.  Kerberos SPAKE Groups  . . . . . . . . . . . . . . . . .  18
       12.2.1.  Registration Template  . . . . . . . . . . . . . . .  19
       12.2.2.  Initial Registry Contents  . . . . . . . . . . . . .  19
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     13.2.  Non-normative References . . . . . . . . . . . . . . . .  22
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  23
   Appendix B.  SPAKE M and N Value Selection  . . . . . . . . . . .  24
   Appendix C.  Test Vectors . . . . . . . . . . . . . . . . . . . .  24
   Appendix D.  Acknowledgements . . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

1.  Introduction

   When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC
   does not require preauthentication), a passive attacker that observes
   either the AS-REQ or AS-REP can perform an offline brute-force attack
   against the transferred ciphertext.  When the client principal's
   long-term key is based on a password, offline dictionary attacks can
   successfuly recover the key, with only modest effort needed if the
   password is weak.

1.1.  Properties of PAKE

   Password authenticated key exchange (PAKE) algorithms provide several
   properties which are useful to overcome this problem and make them
   ideal for use as a Kerberos pre-authentication mechanism.

   1.  Each side of the exchange contributes entropy.

   2.  Passive attackers cannot determine the shared key.

   3.  Active attackers cannot perform a man-in-the-middle attack.

   These properties of PAKE allow us to establish high-entropy
   encryption keys resistant to offline brute force attack, even when
   the passwords used are weak (low-entropy).

1.2.  PAKE Algorithm Selection

   The SPAKE algorithm works by encrypting the public keys of a Diffie-
   Hellman key exchange with a shared secret.  SPAKE was selected for
   this pre-authentication mechanism for the following properties:

   1.  Because SPAKE's encryption method ensures that the result is a
       member of the underlying group, it can be used with elliptic
       curve cryptography, which is believed to provide equivalent




McCallum, et al.          Expires June 3, 2018                  [Page 3]


Internet-Draft          SPAKE Pre-Authentication           November 2017


       security levels to finite-field DH key exchange at much smaller
       key sizes.

   2.  It can compute the shared key after just one message from each
       party.

   3.  It requires a small number of group operations, and can therefore
       be implemented simply and efficiently.

1.3.  PAKE and Two-Factor Authentication

   Using PAKE in a pre-authentication mechanism also has another benefit
   when used as a component of two-factor authentication (2FA).  2FA
   methods often require the secure transfer of plaintext material to
   the KDC for verification.  This includes one-time passwords,
   challenge/response signatures and biometric data.  Attempting to
   encrypt this data using the long-term secret results in packets that
   are vulnerable to offline brute-force attack if either authenticated
   encryption is used or if the plaintext is distinguishable from random
   data.  This is a problem that PAKE solves for first factor
   authentication.  So a similar technique can be used with PAKE to
   encrypt second-factor data.

   In the OTP pre-authentication [RFC6560] specification, this problem
   is mitigated by using FAST, which uses a secondary trust relationship
   to create a secure encryption channel within which pre-authentication
   data can be sent.  However, the requirement for a secondary trust
   relationship has proven to be cumbersome to deploy and often
   introduces third parties into the trust chain (such as certification
   authorities).  These requirements lead to a scenario where FAST
   cannot be enabled by default without sufficient configuration.  SPAKE
   pre-authentication, in contrast, can create a secure encryption
   channel implicitly, using the key exchange to negotiate a high-
   entropy encryption key.  This key can then be used to securely
   encrypt 2FA plaintext data without the need for a secondary trust
   relationship.  Further, if the second factor verifiers are sent at
   the same time as the first factor verifier, and the KDC is careful to
   prevent timing attacks, then an online brute-force attack cannot be
   used to attack the factors separately.

   For these reasons, this draft departs from the advice given in
   Section 1 of RFC 6113 [RFC6113] which states that "Mechanism
   designers should design FAST factors, instead of new pre-
   authentication mechanisms outside of FAST."  However, this pre-
   authentication mechanism does not intend to replace FAST, and may be
   used with it to further conceal the metadata of the Kerberos
   messages.




McCallum, et al.          Expires June 3, 2018                  [Page 4]


Internet-Draft          SPAKE Pre-Authentication           November 2017


1.4.  SPAKE Overview

   The SPAKE algorithm can be broadly described in a series of four
   steps:

   1.  Calculation and exchange of the public key

   2.  Calculation of the shared secret (K)

   3.  Derivation of an encryption key (K')

   4.  Verification of the derived encryption key (K')

   Higher level protocols must define their own verification step.  In
   the case of this mechanism, verification happens implicitly by a
   successful decryption of the 2FA data.

   This mechanism provides its own method of deriving encryption keys
   from the calculated shared secret K, for several reasons: to fit
   within the framework of [RFC3961], to ensure negotiation integrity
   using a transcript checksum, to derive different keys for each use,
   and to bind the KDC-REQ-BODY to the pre-authentication exchange.

2.  Document Conventions

   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].

   This document refers to numerous terms and protocol messages defined
   in [RFC4120].

   The terms "encryption type", "required checksum mechanism", and
   "get_mic" are defined in [RFC3961].

   The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED",
   "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED", "pre-
   authentication facility", and "authentication set" are defined in
   [RFC6113].

   The [SPAKE] paper defines SPAKE as a family of two key exchange
   algorithms differing only in derivation of the final key.  This
   mechanism uses a derivation similar to the second algorithm (SPAKE2)
   with differences in detail.  For simplicity, this document refers to
   the algorithm as "SPAKE".  The normative reference for this algorithm
   is [I-D.irtf-cfrg-spake2].





McCallum, et al.          Expires June 3, 2018                  [Page 5]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   The terms "ASN.1" and "DER" are defined in [CCITT.X680.2002] and
   [CCITT.X690.2002] respectively.

3.  Prerequisites

3.1.  PA-ETYPE-INFO2

   This mechanism requires the initial KDC pre-authentication state to
   contain a singular reply key.  Therefore, a KDC which offers SPAKE
   pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE-
   INFO2 value containing a single ETYPE-INFO2-ENTRY, as described in
   [RFC6113] section 2.1.  PA-ETYPE-INFO2 is specified in [RFC4120]
   section 5.2.7.5.

3.2.  Cookie Support

   KDCs which implement SPAKE pre-authentication MUST have some secure
   mechanism for retaining state between AS-REQs.  For stateless KDC
   implementations, this method will most commonly be an encrypted PA-
   FX-COOKIE.  Clients which implement SPAKE pre-authentication MUST
   support PA-FX-COOKIE, as described in [RFC6113] section 5.2.

3.3.  More Pre-Authentication Data Required

   Both KDCs and clients which implement SPAKE pre-authentication MUST
   support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described
   in [RFC6113] section 5.2.

4.  Update to Checksum Specifications

   [RFC3961] section 4 specifies the Kerberos checksum algorithm
   profile.  It does not require checksums to be deterministic.  In
   practice, DES-based checksum types (deprecated by [RFC6649]) use a
   random confounder; all other current checksum types are
   deterministic.

   Future checksum types required by an encryption type MUST be
   deterministic.  All future checksum types SHOULD be deterministic.

   This mechanism requires a deterministic checksum type for the
   transcript checksum.  Therefore, a KDC MUST NOT offer this mechanism
   if the initial reply key is of type des-cbc-crc, des-cbc-md4, or des-
   cbc-md5.








McCallum, et al.          Expires June 3, 2018                  [Page 6]


Internet-Draft          SPAKE Pre-Authentication           November 2017


5.  SPAKE Pre-Authentication Message Protocol

   This mechanism uses the reply key and provides the Client
   Authentication and Strengthening Reply Key pre-authentication
   facilities ([RFC6113] section 3).  When the mechanism completes
   successfully, the client will have proved knowledge of the original
   reply key and possibly a second factor, and the reply key will be
   strengthened to a more uniform distribution based on the PAKE
   exchange.  This mechanism also ensures the integrity of the KDC-REQ-
   BODY contents.  This mechanism can be used in an authentication set;
   no pa-hint value is required or defined.

   This mechanism negotiates a choice of group for the SPAKE algorithm.
   Groups are defined in the IANA "Kerberos SPAKE Groups" registry
   created by this document.  Clients and KDCs MUST implement the
   edwards25519 group, but MAY choose not to offer or accept it by
   default.

   This section will describe the flow of messages when performing SPAKE
   pre-authentication.  We will begin by explaining the most verbose
   version of the protocol which all implementations MUST support.  Then
   we will describe several optional optimizations to reduce round-
   trips.

   Mechanism messages are communicated using PA-DATA elements within the
   padata field of KDC-REQ messages or within the METHOD-DATA in the
   e-data field of KRB-ERROR messages.  All PA-DATA elements for this
   mechanism MUST use the following padata-type:

   PA-SPAKE  TBD

   The padata-value for all PA-SPAKE PA-DATA values MUST be empty or
   contain a DER encoding for the ASN.1 type PA-SPAKE.

   PA-SPAKE ::= CHOICE {
       support     [0] SPAKESupport,
       challenge   [1] SPAKEChallenge,
       response    [2] SPAKEResponse,
       encdata     [3] EncryptedData,
       ...
   }

5.1.  First Pass

   The SPAKE pre-authentication exchange begins when the client sends an
   initial authentication service request (AS-REQ) without pre-
   authentication data.  Upon receipt of this AS-REQ, a KDC which
   requires pre-authentication and supports SPAKE SHOULD reply with a



McCallum, et al.          Expires June 3, 2018                  [Page 7]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty
   PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA
   elements).  This message indicates to the client that the KDC
   supports SPAKE pre-authentication.

5.2.  Second Pass

   Once the client knows that the KDC supports SPAKE pre-authentication
   and the client desires to use it, the client will generate a new AS-
   REQ message containing a PA-SPAKE PA-DATA element using the support
   choice.  This message indicates to the KDC which groups the client
   prefers for the SPAKE operation.  The group numbers are defined in
   the IANA "Kerberos SPAKE Groups" registry created by this document.
   The groups sequence is ordered from the most preferred group to the
   least preferred group.

   SPAKESupport ::= SEQUENCE {
       groups      [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
       ...
   }

   The client and KDC initialize a transcript checksum (Section 7) and
   update it with the DER-encoded PA-SPAKE message.

   Upon receipt of the support message, the KDC will select a group.
   The KDC SHOULD choose a group from the groups provided by the support
   message.  However, if the support message does not contain any group
   that is supported by the KDC, the KDC MAY select another group in
   hopes that the client might support it.  Otherwise, the KDC MUST
   respond with a KDC_ERR_PREAUTH_FAILED error.

   Once the KDC has selected a group, the KDC will reply to the client
   with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE
   PA-DATA element using the challenge choice.  The client and KDC
   update the transcript checksum with the DER-encoded PA-SPAKE message.

   SPAKEChallenge ::= SEQUENCE {
       group       [0] Int32,
       pubkey      [1] OCTET STRING,
       factors     [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor,
       ...
   }

   The group field indicates the KDC-selected group used for all SPAKE
   calculations as defined in the IANA "Kerberos SPAKE Groups" registry
   created by this document.





McCallum, et al.          Expires June 3, 2018                  [Page 8]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   The pubkey field indicates the KDC's public key generated using the M
   constant in the SPAKE algorithm, with inputs and conversions as
   specified in Section 6.

   The factors field contains an unordered list of second factors which
   can be used to complete the authentication.  Each second factor is
   represented by a SPAKESecondFactor.

   SPAKESecondFactor ::= SEQUENCE {
       type        [0] Int32,
       data        [1] OCTET STRING OPTIONAL
   }

   The type field is a unique integer which identifies the second factor
   type.  The factors field of SPAKEChallenge MUST NOT contain more than
   one SPAKESecondFactor with the same type value.

   The data field contains optional challenge data.  The contents in
   this field will depend upon the second factor type chosen.

5.3.  Third Pass

   Upon receipt of the challenge message, the client will complete its
   part of of the SPAKE algorithm, generating a public key and computing
   the shared secret K.  The client will then choose one of the second
   factor types listed in the factors field of the challenge message and
   gather whatever data is required for the chosen second factor type,
   possibly using the associated challenge data.  Finally, the client
   will send an AS-REQ containing a PA-SPAKE PA-DATA element using the
   response choice.

   SPAKEResponse ::= SEQUENCE {
       pubkey      [0] OCTET STRING,
       factor      [1] EncryptedData, -- SPAKESecondFactor
       ...
   }

   The client and KDC will update the transcript checksum with the
   pubkey value, and use the resulting checksum for all encryption key
   derivations.

   The pubkey field indicates the client's public key generated using
   the N constant in the SPAKE algorithm, with inputs and conversions as
   specified in Section 6.

   The factor field indicates the client's chosen second factor data.
   The key for this field is K'[1] as specified in Section 8.  The key
   usage number for the encryption is KEY_USAGE_SPAKE_FACTOR.  The plain



McCallum, et al.          Expires June 3, 2018                  [Page 9]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   text inside the EncryptedData is an encoding of SPAKESecondFactor.
   Once decoded, the SPAKESecondFactor contains the type of the second
   factor and any optional data used.  The contents of the data field
   will depend on the second factor type chosen.  The client MUST NOT
   send a response containing a second factor type which was not listed
   in the factors field of the challenge message.

   When the KDC receives the response message from the client, it will
   use the pubkey to compute the SPAKE result, derive K'[1], and decrypt
   the factors field.  If decryption is successful, the first factor is
   successfully validated.  The KDC then validates the second factor.
   If either factor fails to validate, the KDC SHOULD respond with a
   KDC_ERR_PREAUTH_FAILED error.

   If validation of the second factor requires further round-trips, the
   KDC MUST reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
   containing a PA-SPAKE PA-DATA element using the encdata choice.  The
   key for the EncryptedData value is K'[2] as specified in Section 8,
   and the key usage number is KEY_USAGE_SPAKE_FACTOR.  The plain text
   of this message contains a DER-encoded SPAKESecondFactor message.  As
   before, the type field of this message will contain the second factor
   type, and the data field will optionally contain second factor type
   specific data.

   KEY_USAGE_SPAKE_FACTOR                  65

5.4.  Subsequent Passes

   Any number of additional round trips may occur using the encdata
   choice.  The contents of the plaintexts are specific to the second
   factor type.  If a client receives a PA-SPAKE PA-DATA element using
   the encdata choice from the KDC, it MUST reply with a subsequent AS-
   REQ with a PA-SPAKE PA-DATA using the encdata choice, or abort the AS
   exchange.

   The key for client-originated encdata messages in subsequent passes
   is K'[3] as specified in Section 8 for the first subsequent pass,
   K'[5] for the second, and so on.  The key for KDC-originated encdata
   messages is K'[4] for the first subsequent pass, K'[6] for the
   second, and so on.

5.5.  Reply Key Strengthening

   When the KDC has successfully validated both factors, the reply key
   is strengthened and the mechanism is complete.  To strengthen the
   reply key, the client and KDC replace it with K'[0] as specified in
   Section 8.  The KDC then replies with a KDC-REP message, or continues




McCallum, et al.          Expires June 3, 2018                 [Page 10]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   on to the next mechanism in the authentication set.  There is no
   final PA-SPAKE PA-DATA message from the KDC to the client.

   Reply key strengthening occurs only once at the end of the exchange.
   The client and KDC MUST use the initial reply key as the base key for
   all K'[n] derivations.

5.6.  Optimizations

   The full protocol has two possible optimizations.

   First, the KDC MAY reply to the initial AS-REQ (containing no pre-
   authentication data) with a PA-SPAKE PA-DATA element using the
   challenge choice, instead of an empty padata-value.  In this case,
   the KDC optimistically selects a group which the client may not
   support.  If the group chosen by the challenge message is supported
   by the client, the client MUST skip to the third pass by issuing an
   AS-REQ with a PA-SPAKE message using the response choice.  If the
   KDC's chosen group is not supported by the client, the client MUST
   initialize and update the transcript checksum with the KDC's
   challenge message, and then continue to the second pass.  Clients
   MUST support this optimization.

   Second, clients MAY skip the first pass and send an AS-REQ with a PA-
   SPAKE PA-DATA element using the support choice.  If the KDC accepts
   the support message and generates a challenge, it MUST include a PA-
   ETYPE-INFO2 value within the METHOD-DATA of the
   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may
   not otherwise be able to compute the initial reply key.  If the KDC
   cannot continue with SPAKE (either because initial reply key type is
   incompatible with SPAKE or because it does not support any of the
   client's groups) but can offer other pre-authentication mechanisms,
   it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing
   METHOD-DATA.  A client supporting this optimization MUST continue
   after a KDC_ERR_PREAUTH_FAILED error as described in [RFC6113]
   section 2.  KDCs MUST support this optimization.

6.  SPAKE Parameters and Conversions

   Group elements are converted to octet strings using the serialization
   method defined in the IANA "Kerberos SPAKE Groups" registry created
   by this document.

   The SPAKE algorithm requires constants M and N for each group.  These
   constants are defined in the IANA "Kerberos SPAKE Groups" registry
   created by this document.





McCallum, et al.          Expires June 3, 2018                 [Page 11]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   The SPAKE algorithm requires a shared secret input w to be used as a
   scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2).  This value
   MUST be produced from the initial reply key as follows:

   1.  Determine the length of the multiplier octet string as defined in
       the IANA "Kerberos SPAKE Groups" registry created by this
       document.

   2.  Compose a pepper string by concatenating the string "SPAKEsecret"
       and the group number as a big-endian four-byte unsigned binary
       number.

   3.  Produce an octet string of the required length using PRF+(K,
       pepper), where K is the initial reply key and PRF+ is defined in
       [RFC6113] section 5.1.

   4.  Convert the octet string to a multiplier scalar using the
       multiplier conversion method defined in the IANA "Kerberos SPAKE
       Groups" registry created by this document.

   The KDC chooses a secret scalar value x and the client chooses a
   secret scalar value y.  As required by the SPAKE algorithm, these
   values are chosen randomly and uniformly.  The KDC and client MUST
   NOT reuse x or y values for authentications involving different
   initial reply keys (see Section 10.3).

7.  Transcript Checksum

   The transcript checksum is an octet string of length equal to the
   output length of the required checksum type of the encryption type of
   the initial reply key.  The initial value consists of all bits set to
   zero.

   When the transcript checksum is updated with an octet string input,
   the new value is the get_mic result computed over the concatenation
   of the old value and the input, for the required checksum type of the
   initial reply key's encryption type, using the initial reply key and
   the key usage number KEY_USAGE_SPAKE_TRANSCRIPT.

   In the normal message flow or with the second optimization described
   in Section 5.6, the transcript checksum is first updated with the
   client's support message, then the KDC's challenge message, and
   finally with the client's pubkey value.  It therefore incorporates
   the client's supported groups, the KDC's chosen group, the KDC's
   initial second-factor messages, and the client and KDC public values.
   Once the transcript checksum is finalized, it is used without change
   for all key derivations (Section 8).




McCallum, et al.          Expires June 3, 2018                 [Page 12]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   If the first optimization described in Section 5.6 is used
   successfully, the transcript checksum is updated only with the KDC's
   challenge message and the client's pubkey value.

   If first optimization is used unsuccessfully (i.e. the client does
   not accept the KDC's selected group), the transcript checksum is
   updated with the KDC's optimistic challenge message, then with the
   client's support message, then the KDC's second challenge message,
   and finally with the client's pubkey value.

   KEY_USAGE_SPAKE_TRANSCRIPT              66

8.  Key Derivation

   Implementations MUST NOT use the SPAKE result (denoted by K in
   Section 2 of SPAKE [I-D.irtf-cfrg-spake2]) directly for any
   cryptographic operation.  Instead, the SPAKE result is used to derive
   keys K'[n] as defined in this section.  This method differs slightly
   from the method used to generate K' in Section 3 of SPAKE
   [I-D.irtf-cfrg-spake2].

   An input string is assembled by concatenating the following values:

   o  The fixed string "SPAKEkey".

   o  The group number as a big-endian four-byte unsigned binary number.

   o  The encryption type of the initial reply key as a big-endian four-
      byte unsigned binary number.

   o  The SPAKE result K, converted to an octet string as specified in
      Section 6.

   o  The transcript checksum.

   o  The KDC-REQ-BODY encoding for the request being sent or responded
      to.  Within a FAST channel, the inner KDC-REQ-BODY encoding MUST
      be used.

   o  The value n as a big-endian four-byte unsigned binary number.

   The derived key K'[n] has the same encryption type as the initial
   reply key, and has the value random-to-key(PRF+(initial-reply-key,
   input-string)).  PRF+ is defined in [RFC6113] section 5.1.







McCallum, et al.          Expires June 3, 2018                 [Page 13]


Internet-Draft          SPAKE Pre-Authentication           November 2017


9.  Second Factor Types

   This document defines one second factor type:

   SF-NONE  1

   This second factor type indicates that no second factor is used.
   Whenever a SPAKESecondFactor is used with SF-NONE, the data field
   MUST be omitted.  The SF-NONE second factor always successfully
   validates.

10.  Security Considerations

   All of the security considerations from SPAKE [I-D.irtf-cfrg-spake2]
   apply here as well.

10.1.  Unauthenticated Plaintext

   This mechanism includes unauthenticated plaintext in the support and
   challenge messages.  Beginning with the third pass, the integrity of
   this plaintext is ensured by incorporating the transcript checksum
   into the derivation of the final reply key and second factor
   encryption keys.  Downgrade attacks on support and challenge messages
   will result in the client and KDC deriving different reply keys and
   EncryptedData keys.  The KDC-REQ-BODY contents are also incorporated
   into key derivation, ensuring their integrity.  The unauthenticated
   plaintext in the KDC-REP message is not protected by this mechanism.

   Unless FAST is used, the factors field of a challenge message is not
   integrity-protected until the response is verified.  Second factor
   types MUST account for this when specifying the semantics of the data
   field.  Second factor data in the challenge should not be included in
   user prompts, as it could be modified by an attacker to contain
   misleading or offensive information.

   Subsequent factor data, including the data in the response, are
   encrypted in a derivative of the shared secret K.  Therefore, it is
   not possible to exploit the untrustworthiness of the challenge to
   turn the client into an encryption or signing oracle, unless the
   attacker knows the client's long-term key.

10.2.  Side Channels

   An implementation of this pre-authentication mechanism can have the
   property of indistinguishability, meaning that an attacker who
   guesses a long-term key and a second factor value cannot determine
   whether one of the factors was correct unless both are correct.
   Indistinguishability is only maintained if the second factor can be



McCallum, et al.          Expires June 3, 2018                 [Page 14]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   validated solely based on the data in the response; the use of
   additional round trips will reveal to the attacker whether the long-
   term key is correct.  Indistinguishability also requires that there
   are no side channels.  When processing a response message, whether or
   not the KDC successfully decrypts the factor field, it must reply
   with the same error fields, take the same amount of time, and make
   the same observable communications to other servers.

   Both the size of the EncryptedData and the number of EncryptedData
   messages used for second-factor data (including the factor field of
   the SPAKEResponse message and messages using the encdata PA-SPAKE
   choice) may reveal information about the second factor used in an
   authentication.  Care should be taken to keep second factor messages
   as small and as few as possible.

   Any side channels in the creation of the shared secret input w, or in
   the multiplications wM and wN, could allow an attacker to recover the
   client long-term key.  Implementations MUST take care to avoid side
   channels, particularly timing channels.  Generation of the secret
   scalar values x and y need not take constant time, but the amount of
   time taken MUST NOT provide information about the resulting value.

   The conversion of the scalar multiplier for the SPAKE w parameter may
   produce a multiplier that is larger than the order of the group.
   Some group implementations may be unable to handle such a multiplier.
   Others may silently accept such a multiplier, but proceed to perform
   multiplication that is not constant time.  This is a minor risk in
   all known groups, but is a major risk for P-521 due to the extra
   seven high bits in the input octet string.  A common solution to this
   problem is achieved by reducing the multiplier modulo the group
   order, taking care to ensure constant time operation.

10.3.  KDC State

   A stateless KDC implementation generally must use a PA-FX-COOKIE
   value to remember its private scalar value x and the transcript
   checksum.  The KDC MUST maintain confidentiality and integrity of the
   cookie value, perhaps by encrypting it in a key known only to the
   realm's KDCs.  Cookie values may be replayed by attackers.  The KDC
   SHOULD limit the time window of replays using a timestamp, and SHOULD
   prevent cookie values from being applied to other pre-authentication
   mechanisms or other client principals.  Within the validity period of
   a cookie, an attacker can replay the final message of a pre-
   authentication exchange to any of the realm's KDCs and make it appear
   that the client has authenticated.

   If an x or y value is reused for pre-authentications involving two
   different client long-term keys, an attacker who observes both



McCallum, et al.          Expires June 3, 2018                 [Page 15]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   authentications and knows one of the long-term keys can conduct an
   offline dictionary attack to recover the other one.

   This pre-authentication mechanism is not designed to provide forward
   secrecy.  Nevertheless, some measure of forward secrecy may result
   depending on implementation choices.  A passive attacker who
   determines the client long-term key after the exchange generally will
   not be able to recover the ticket session key; however, an attacker
   who also determines the PA-FX-COOKIE encryption key (if the KDC uses
   an encrypted cookie) will be able to recover the ticket session key.
   The KDC can mitigate this risk by periodically rotating the cookie
   encryption key.  If the KDC or client retains the x or y value for
   reuse with the same client long-term key, an attacker who recovers
   the x or y value and the long-term key will be able to recover the
   ticket session key.

10.4.  Dictionary Attacks

   Although this pre-authentication mechanism is designed to prevent an
   offline dictionary attack by an active attacker posing as the KDC,
   such an attacker can attempt to downgrade the client to encrypted
   timestamp.  Client implementations SHOULD provide a configuration
   option to disable encrypted timestamp on a per-realm basis to
   mitigate this attack.

   If the user enters the wrong password, the client might fall back to
   encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error
   from the KDC, if encrypted timestamp is offered by the KDC and not
   disabled by client configuration.  This fallback will enable a
   passive attacker to mount an offline dictionary attack against the
   incorrect password, which may be similar to the correct password.
   Client implementations SHOULD assume that encrypted timestamp and
   encrypted challenge are unlikely to succeed if SPAKE pre-
   authentication fails in the second pass and no second factor was
   used.

   Like any other pre-authentication mechanism using the client long-
   term key, this pre-authentication mechanism does not prevent online
   password guessing attacks.  The KDC is made aware of unsuccessful
   guesses, and can apply facilities such as password lockout to
   mitigate the risk of online attacks.

10.5.  Brute Force Attacks

   The selected group's resistance to offline brute-force attacks may
   not correspond to the size of the reply key.  For performance
   reasons, a KDC MAY select a group whose brute-force work factor is
   less than the reply key length.  A passive attacker who solves the



McCallum, et al.          Expires June 3, 2018                 [Page 16]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   group discrete logarithm problem after the exchange will be able to
   conduct an offline attack against the client long-term key.  Although
   the use of password policies and costly, salted string-to-key
   functions may increase the cost of such an attack, the resulting cost
   will likely not be higher than the cost of solving the group discrete
   logarithm.

10.6.  Denial of Service Attacks

   Elliptic curve group operations are more computationally expensive
   than secret-key operations.  As a result, the use of this mechanism
   may affect the KDC's performance under normal load and its resistance
   to denial of service attacks.

10.7.  Reply-Key Encryption Type

   This mechanism does not upgrade the encryption type of the initial
   reply key, and relies on that encryption type for confidentiality,
   integrity, and pseudo-random functions.  If the client long-term key
   uses a weak encryption type, an attacker might be able to subvert the
   exchange, and the replaced reply key will also be of the same weak
   encryption type.

10.8.  KDC Authentication

   This mechanism does not directly provide the KDC Authentication pre-
   authentication facility, because it does not send a key confirmation
   from the KDC to the client.  When used as a stand-alone mechanism,
   the traditional KDC authentication provided by the KDC-REP enc-part
   still applies.

11.  Assigned Constants

   The following key usage values are assigned for this mechanism:

   KEY_USAGE_SPAKE_TRANSCRIPT              65
   KEY_USAGE_SPAKE_FACTOR                  66

12.  IANA Considerations

   The notes for the "Kerberos Checksum Type Numbers" registry should be
   updated with the following addition: "If the checksum algorithm is
   non-deterministic, see [this document] Section 4."

   This document establishes two registries with the following
   procedure, in accordance with [RFC5226]:





McCallum, et al.          Expires June 3, 2018                 [Page 17]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   Registry entries are to be evaluated using the Specification Required
   method.  All specifications must be be published prior to entry
   inclusion in the registry.  There will be a three-week review period
   by Designated Experts on the krb5-spake-review@ietf.org mailing list.
   Prior to the end of the review period, the Designated Experts must
   approve or deny the request.  This decision is to be conveyed to both
   the IANA and the list, and should include reasonably detailed
   explanation in the case of a denial as well as whether the request
   can be resubmitted.

12.1.  Kerberos Second Factor Types

   This section species the IANA "Kerberos Second Factor Types"
   registry.  This registry records the number, name, and reference for
   each second factor protocol.

12.1.1.  Registration Template

   ID Number:  This is a value that uniquely identifies this entry.  It
      is a signed integer in range -2147483648 to 2147483647, inclusive.
      Positive values must be assigned only for algorithms specified in
      accordance with these rules for use with Kerberos and related
      protocols.  Negative values should be used for private and
      experimental algorithms only.  Zero is reserved and must not be
      assigned.

   Name:  Brief, unique, human-readable name for this algorithm.

   Reference:  URI or otherwise unique identifier for where the details
      of this algorithm can be found.  It should be as specific as
      reasonably possible.

12.1.2.  Initial Registry Contents

   o ID Number: 1
   o Name: NONE
   o Reference: this draft.

12.2.  Kerberos SPAKE Groups

   This section specifies the IANA "Kerberos SPAKE Groups" registry.
   This registry records the number, name, specification, serialization,
   multiplier length, multiplier conversion, SPAKE M constant and SPAKE
   N constant.







McCallum, et al.          Expires June 3, 2018                 [Page 18]


Internet-Draft          SPAKE Pre-Authentication           November 2017


12.2.1.  Registration Template

   ID Number:  This is a value that uniquely identifies this entry.  It
      is a signed integer in range -2147483648 to 2147483647, inclusive.
      Positive values must be assigned only for algorithms specified in
      accordance with these rules for use with Kerberos and related
      protocols.  Negative values should be used for private and
      experimental use only.  Zero is reserved and must not be assigned.
      Values should be assigned in increasing order.

   Name:  Brief, unique, human readable name for this entry.

   Specification:  Reference to the definition of the group parameters
      and operations.

   Serialization:  Reference to the definition of the method used to
      serialize group elements.

   Multiplier Length:  The length of the input octet string to
      multiplication operations.

   Multiplier Conversion:  Reference to the definition of the method
      used to convert an octet string to a multiplier scalar.

   SPAKE M Constant:  The serialized value of the SPAKE M constant in
      hexadecimal notation.

   SPAKE N Constant:  The serialized value of the SPAKE N constant in
      hexadecimal notation.

12.2.2.  Initial Registry Contents

   o ID Number: 1
   o Name: edwards25519
   o Specification: [RFC7748] section 4.1 (edwards25519)
   o Serialization: [RFC8032] section 3.1
   o Multiplier Length: 32
   o Multiplier Conversion: [RFC8032] section 3.1
   o SPAKE M Constant:
     d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
   o SPAKE N Constant:
     d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab









McCallum, et al.          Expires June 3, 2018                 [Page 19]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   o ID Number: 2
   o Name: P-256
   o Specification: [SEC2] section 2.4.2
   o Serialization: [SEC1] section 2.3.3 (compressed).
   o Multiplier Length: 32
   o Multiplier Conversion: [SEC1] section 2.3.8.
   o SPAKE M Constant:
     02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
   o SPAKE N Constant:
     03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49

   o ID Number: 3
   o Name: P-384
   o Specification: [SEC2] section 2.5.1
   o Serialization: [SEC1] section 2.3.3 (compressed).
   o Multiplier Length: 48
   o Multiplier Conversion: [SEC1] section 2.3.8.
   o SPAKE M Constant:
     030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664
     34b363d3dc36f15314739074d2eb8613fceec2853
   o SPAKE N Constant:
     02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215
     18f9c543bb252c5490214cf9aa3f0baab4b665c10

   o ID Number: 4
   o Name: P-521
   o Specification: [SEC2] section 2.6.1
   o Serialization: [SEC1] section 2.3.3 (compressed).
   o Multiplier Length: 66
   o Multiplier Conversion: [SEC1] section 2.3.8.
   o SPAKE M Constant:
     02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1
     8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5
     6979962d7aa
   o SPAKE N Constant:
     0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b
     c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34
     9d95575cd25

13.  References

13.1.  Normative References

   [CCITT.X680.2002]
              International Telephone and Telegraph Consultative
              Committee, "Abstract Syntax Notation One (ASN.1):
              Specification of basic notation", CCITT Recommendation
              X.680, July 2002.



McCallum, et al.          Expires June 3, 2018                 [Page 20]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   [CCITT.X690.2002]
              International Telephone and Telegraph Consultative
              Committee, "ASN.1 encoding rules: Specification of basic
              encoding Rules (BER), Canonical encoding rules (CER) and
              Distinguished encoding rules (DER)", CCITT Recommendation
              X.690, July 2002.

   [I-D.irtf-cfrg-spake2]
              Ladd, W., "SPAKE2, a PAKE", draft-irtf-cfrg-spake2-01
              (work in progress), February 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997, <https://www.rfc-editor.org/info/
              rfc2119>.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
              2005, <https://www.rfc-editor.org/info/rfc3961>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005, <https://www.rfc-
              editor.org/info/rfc4120>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226, DOI
              10.17487/RFC5226, May 2008, <https://www.rfc-
              editor.org/info/rfc5226>.

   [RFC6113]  Hartman, S. and L. Zhu, "A Generalized Framework for
              Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/
              RFC6113, April 2011, <https://www.rfc-editor.org/info/
              rfc6113>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/
              RFC8032, January 2017, <https://www.rfc-editor.org/info/
              rfc8032>.

   [SEC1]     Standards for Efficient Cryptography Group, "SEC 1:
              Elliptic Curve Cryptography", May 2009.





McCallum, et al.          Expires June 3, 2018                 [Page 21]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   [SEC2]     Standards for Efficient Cryptography Group, "SEC 2:
              Recommended Elliptic Curve Domain Parameters", January
              2010.

13.2.  Non-normative References

   [RFC6560]  Richards, G., "One-Time Password (OTP) Pre-
              Authentication", RFC 6560, DOI 10.17487/RFC6560, April
              2012, <https://www.rfc-editor.org/info/rfc6560>.

   [RFC6649]  Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-
              EXP, and Other Weak Cryptographic Algorithms in Kerberos",
              BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012,
              <https://www.rfc-editor.org/info/rfc6649>.

   [SPAKE]    Abdalla, M. and D. Pointcheval, "Simple Password-Based
              Encrypted Key Exchange Protocols", February 2005.


































McCallum, et al.          Expires June 3, 2018                 [Page 22]


Internet-Draft          SPAKE Pre-Authentication           November 2017


Appendix A.  ASN.1 Module

   KerberosV5SPAKE {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosV5(2) modules(4) spake(8)
   } DEFINITIONS EXPLICIT TAGS ::= BEGIN

   IMPORTS
       EncryptedData, Int32
         FROM KerberosV5Spec2 { iso(1) identified-organization(3)
           dod(6) internet(1) security(5) kerberosV5(2) modules(4)
           krb5spec2(2) };
           -- as defined in RFC 4120.

   SPAKESupport ::= SEQUENCE {
       groups      [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
       ...
   }

   SPAKEChallenge ::= SEQUENCE {
       group       [0] Int32,
       pubkey      [1] OCTET STRING,
       factors     [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor,
       ...
   }

   SPAKESecondFactor ::= SEQUENCE {
       type        [0] Int32,
       data        [1] OCTET STRING OPTIONAL
   }

   SPAKEResponse ::= SEQUENCE {
       pubkey      [0] OCTET STRING,
       factor      [1] EncryptedData, -- SPAKESecondFactor
       ...
   }

   PA-SPAKE ::= CHOICE {
       support     [0] SPAKESupport,
       challenge   [1] SPAKEChallenge,
       response    [2] SPAKEResponse,
       encdata     [3] EncryptedData,
       ...
   }

   END





McCallum, et al.          Expires June 3, 2018                 [Page 23]


Internet-Draft          SPAKE Pre-Authentication           November 2017


Appendix B.  SPAKE M and N Value Selection

   The M and N constants for the NIST groups are from
   [I-D.irtf-cfrg-spake2] section 3.

   The M and N constants for the edwards25519 group were generated using
   the algorithm from [I-D.irtf-cfrg-spake2] section 3 and the seed
   strings "edwards25519 point generation seed (M)" and "edwards25519
   point generation seed (N)".

Appendix C.  Test Vectors

   For the following text vectors:

   o  The key is the string-to-key of "password" with the salt
      "ATHENA.MIT.EDUraeburn" for the designated initial reply key
      encryption type.

   o  x and y were chosen randomly within the order of the designated
      group, then multiplied by the cofactor..

   o  The SPAKESupport message contains only the designated group's
      number.

   o  The SPAKEChallenge message offers only the SF-NONE second factor
      type.

   o  The KDC-REQ-BODY message contains no KDC options, the client
      principal name "raeburn@ATHENA.MIT.EDU", the server principal name
      "krbtgt/ATHENA.MIT.EDU", the realm "ATHENA.MIT.EDU", the till
      field "19700101000000Z", the nonce zero, and an etype list
      containing only the designated encryption type.

   DES3 edwards25519
   key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
   w: a1f1a25cbd8e3092667e2fddba8ecd24f2c9cef124f7a3371ae81e11cad42a07
   x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723
   y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25
   X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e
   Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028
   T: 18f511e750c97b592acd30db7d9e5fca660389102e6bf610c1bfbed4616c8362
   S: 5d10705e0d1e43d5dbf30240ccfbde4a0230c70d4c79147ab0b317edad2f8ae7
   K: 25bde0d875f0feb5755f45ba5e857889d916ecf7476f116aa31dc3e037ec4292
   SPAKESupport: a0093007a0053003020101
   Checksum after SPAKESupport: 9037756a58a060f80c13354b1a743a66837f1d4d
   SPAKEChallenge: a1363034a003020101a122042018f511e750c97b592acd30
                   db7d9e5fca660389102e6bf610c1bfbed4616c8362a20930
                   073005a003020101



McCallum, et al.          Expires June 3, 2018                 [Page 24]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   Checksum after SPAKEChallenge: 145fbe58e8bd6bf84627
                                  df10ee9954b7849fdc8c
   Final checksum after pubkey: f08091064aa5cc32c5660d9a04efb84a1948381b
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020110
   K'[0]: 8fcdad5da81f0b4962e91a67d598a2d9c84fc83b0104c868
   K'[1]: abf286ce894523013ba89e3413f7c4ef43c1eca8efa7dadf
   K'[2]: 6897524c86b5dc5ec7ecc1944cbc1aae7cbcc1643dcd989e
   K'[3]: b0a22c32e37902e023192cefada1869b08e69429e9fe0243

   RC4 edwards25519
   key: 8846f7eaee8fb117ad06bdd830b7586c
   w: 2713c1583c53861520b849bfef0525cd4fe82215b3ea6fcd896561d48048f40c
   x: c8a62e7b626f44cad807b2d695450697e020d230a738c5cd5691cc781dce8754
   y: 18fe7c1512708c7fd06db270361f04593775bc634ceaf45347e5c11c38aae017
   X: b0bcbbdd25aa031f4608d0442dd4924be7731d49c089a8301859d77343ffb567
   Y: 7d1ab8aeda1a2b1f9eab8d11c0fda60b616005d0f37d1224c5f12b8649f579a5
   T: 7db465f1c08c64983a19f560bce966fe5306c4b447f70a5bca14612a92da1d63
   S: 38f8d4568090148ebc9fd17c241b4cc2769505a7ca6f3f7104417b72b5b5cf54
   K: 03e75edd2cd7e7677642dd68736e91700953ac55dc650e3c2a1b3b4acdb800f8
   SPAKESupport: a0093007a0053003020101
   Checksum after SPAKESupport: c8bb7fb72f6b142557fd5de9b1b8bb4c
   SPAKEChallenge: a1363034a003020101a12204207db465f1c08c64983a19f5
                   60bce966fe5306c4b447f70a5bca14612a92da1d63a20930
                   073005a003020101
   Checksum after SPAKEChallenge: 318afd9874400fffa744bc602615cde8
   Final checksum after pubkey: 0853678dff8b9e5eb855c5e05420790c
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020117
   K'[0]: 87a50a15f0dbd7c958e5bf1bbffee4f2
   K'[1]: 1b4a484d4ac7dd18acf5ebc42d8e1b14
   K'[2]: 8d6b89f491be1b532be6c6e8482328fe
   K'[3]: 425c47073edd4a6f0067f08166d44c7a

   AES128 edwards25519
   key: fca822951813fb252154c883f5ee1cf4
   w: 17c2a9030afb7c37839bd4ae7fdfeb179e99e710e464e62f1fb7c9b67936f30b
   x: 50be049a5a570fa1459fb9f666e6fd80602e4e87790a0e567f12438a2c96c138
   y: b877afe8612b406d96be85bd9f19d423e95be96c0e1e0b5824127195c3ed5917
   X: e73a443c678913eb4a0cad5cbd3086cf82f65a5a91b611e01e949f5c52efd6dd
   Y: 473c5b44ed2be9cb50afe1762b535b3930530489816ea6bd962622cccf39f6e8
   T: 9e9311d985c1355e022d7c3c694ad8d6f7ad6d647b68a90b0fe46992818002da



McCallum, et al.          Expires June 3, 2018                 [Page 25]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   S: fbe08f7f96cd5d4139e7c9eccb95e79b8ace41e270a60198c007df18525b628e
   K: c2f7f99997c585e6b686ceb62db42f17cc70932def3bb4cf009e36f22ea5473d
   SPAKESupport: a0093007a0053003020101
   Checksum after SPAKESupport: ce5052873534f00424e38897
   SPAKEChallenge: a1363034a003020101a12204209e9311d985c1355e022d7c
                   3c694ad8d6f7ad6d647b68a90b0fe46992818002daa20930
                   073005a003020101
   Checksum after SPAKEChallenge: 9c46dbbaa67fe262585e68f4
   Final checksum after pubkey: 9eb1f4db71208adad0d6d9f1
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020111
   K'[0]: 50de22f3b9cd6cd283b23396870ca246
   K'[1]: b8e433cef3a84fff59f683b5206d3c86
   K'[2]: 3c96a2da9575a297c4e831fe2ae625d8
   K'[3]: 54ef2f63b25f66aed65f3d6c77030c6a

   AES256 edwards25519
   key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
   w: 35b35ca126156b5bf4ec8b90e9545060f2108f1b6aa97b381012b9400c9e3f0e
   x: 88c6c0a4f0241ef217c9788f02c32d00b72e4310748cd8fb5f94717607e6417d
   y: 88b859df58ef5c69bacdfe681c582754eaab09a74dc29cff50b328613c232f55
   X: 23c48eaff2721051946313840723b38f563c59b92043d6ffd752f95781af0327
   Y: 3d51486ec1d9be69bc45386bb675c013db87fd0488f6a9cacf6b43e8c81a0641
   T: 6f301aacae1220e91be42868c163c5009aeea1e9d9e28afcfc339cda5e7105b5
   S: 9e2cc32908fc46273279ec75354b4aeafa70c3d99a4d507175ed70d80b255dda
   K: cf57f58f6e60169d2ecc8f20bb923a8e4c16e5bc95b9e64b5dc870da7026321b
   SPAKESupport: a0093007a0053003020101
   Checksum after SPAKESupport: 14b16e16da078fab9830a66c
   SPAKEChallenge: a1363034a003020101a12204206f301aacae1220e91be428
                   68c163c5009aeea1e9d9e28afcfc339cda5e7105b5a20930
                   073005a003020101
   Checksum after SPAKEChallenge: 667e82727168d0fef248c926
   Final checksum after pubkey: 32bf15d0606762b6411a0f68
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020112
   K'[0]: 9463038f091c0aed6f8186224b7da5cf
          24557bf5c7fd6fe35526ce34a9eb5b05
   K'[1]: 1900e226176d6730e9e4c1bf342fd954
          df3fc65790f8c267c89b4a3026d0d164
   K'[2]: b025fb4103dc29f233640540627331e1
          b567c1a7f5a3a00d800c70f0ef213804
   K'[3]: 840e2280e4d4c61c44c057e2c7c92207



McCallum, et al.          Expires June 3, 2018                 [Page 26]


Internet-Draft          SPAKE Pre-Authentication           November 2017


          041dd205bd76b6dc50c9add16cc76c7b

   AES256 P-256
   key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
   w: eb2984af18703f94dd5288b8596cd36988d0d4e83bfb2b44de14d0e95e2090bd
   x: 935ddd725129fb7c6288e1a5cc45782198a6416d1775336d71eacd0549a3e80e
   y: e07405eb215663abc1f254b8adc0da7a16febaa011af923d79fdef7c42930b33
   X: 03bc802165aea7dbd98cc155056249fe0a37a9c203a7c0f7e872d5bf687bd105e2
   Y: 0340b8d91ce3852d0a12ae1f3e82c791fc86df6b346006431e968a1b869af7c735
   T: 024f62078ceb53840d02612195494d0d0d88de21feeb81187c71cbf3d01e71788d
   S: 021d07dc31266fc7cfd904ce2632111a169b7ec730e5f74a7e79700f86638e13c8
   K: 0268489d7a9983f2fde69c6e6a1307e9d252259264f5f2dfc32f58cca19671e79b
   SPAKESupport: a0093007a0053003020102
   Checksum after SPAKESupport: 61f93e7f998dec5f54cac55c
   SPAKEChallenge: a1373035a003020102a1230421024f62078ceb53840d0261
                   2195494d0d0d88de21feeb81187c71cbf3d01e71788da209
                   30073005a003020101
   Checksum after SPAKEChallenge: 949916036d3c524608533206
   Final checksum after pubkey: 1024bfe60a1e22b5bf2838c3
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020112
   K'[0]: b3a882eccd2f31df46880f6235522a4d
          87523a34442547778c46780f5b35800a
   K'[1]: 6e18ebfd20a9a05af11b320eaab15870
          93f3e21a5efcb261307786661330344d
   K'[2]: 11e1a36e87c729a89bbda12cfa15652f
          a1848c0ba9b72cb3e69562648744fb09
   K'[3]: 9875d491c6d0bb7cbe6d374c368e1242
          97e506becbf8ec6aa539a0d70b9e430a

   AES256 P-384
   key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
   w: 0304cfc55151c6bbe889653db96dbfe0ba4acafc024c1e8840cb3a486f6d80c1
      6e1b8974016aa4b7fa43042a9b3825b1
   x: f323ca74d344749096fd35d0adf20806e521460637176e84d977e9933c49d76f
      cfc6e62585940927468ff53d864a7a50
   y: 5b7c709acb175a5afb82860deabca8d0b341facdff0ac0f1a425799aa905d750
      7e1ea9c573581a81467437419466e472
   X: 0211e3334f117b76635dd802d4022f601680a1fd066a56606b7f246493a10351
      7797b81789b225bd5bb1d9ae1da2962250
   Y: 0383dfa413496e5e7599fc8c6430f8d6910d37cf326d81421bc92c0939b555c4
      ca2ef6a993f6d3db8cb7407655ef60866e
   T: 02a1524603ef14f184696f854229d3397507a66c63f841ba748451056be07879
      ac298912387b1c5cdff6381c264701be57
   S: 020d5adfdb92bc377041cf5837412574c5d13e0f4739208a4f0c859a0a302bc6



McCallum, et al.          Expires June 3, 2018                 [Page 27]


Internet-Draft          SPAKE Pre-Authentication           November 2017


      a533440a245b9d97a0d34af5016a20053d
   K: 0264aa8c61da9600dfb0beb5e46550d63740e4ef29e73f1a30d543eb43c25499
      037ad16538586552761b093cf0e37c703a
   SPAKESupport: a0093007a0053003020103
   Checksum after SPAKESupport: a0024c7b5ff667ae074a9988
   SPAKEChallenge: a1473045a003020103a133043102a1524603ef14f184696f
                   854229d3397507a66c63f841ba748451056be07879ac2989
                   12387b1c5cdff6381c264701be57a20930073005a003020101
   Checksum after SPAKEChallenge: ecd0f64ed7c0d4e18fa4c5b4
   Final checksum after pubkey: a238108c88afd856f04d3aa5
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020112
   K'[0]: ff59fb5fb83c7bafe197b62c853eb7c3
          a2902301dfe8326851626a0e9c714c47
   K'[1]: e3c741ac7041feed0f0b5c36cb74c179
          cb565e509b6d65594d0badafe318c4dc
   K'[2]: 9c7a73087f22b52db38a14eb8292df61
          54516eaadb7149b14d35864bdb85aa22
   K'[3]: 75ea14f0f53ee8dbabd78f446462cfda
          590d4ace0fa93708a00f26f26c565e56

   AES256 P-521
   key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
   w: 003a095a2b2386eff3eb15b735398da1caf95bc8425665d82370aff58b0471f3
      4cce63791cfed967f0c94c16054b3e1703133681bece1e05219f5426bc944b0f
      bfb3
   x: 017c38701a14b490b6081dfc83524562be7fbb42e0b20426465e3e37952d30bc
      ab0ed857010255d44936a1515607964a870c7c879b741d878f9f9cdf5a865306
      f3f5
   y: 003e2e2950656fa231e959acdd984d125e7fa59cec98126cbc8f3888447911eb
      cd49428a1c22d5fdb76a19fbeb1d9edfa3da6cf55b158b53031d05d51433ade9
      b2b4
   X: 03003e95272223b210b48cfd908b956a36add04a7ff443511432f94ddd87e064
      1d680ba3b3d532c21fa6046192f6bfae7af81c4b803aa154e12459d1428f8f2f
      56e9f2
   Y: 030064916687960df496557ecab08298bf075429eca268c6dabbae24e258d568
      c62841664dc8ecf545369f573ea84548faa22f118128c0a87e1d47315afabb77
      3bb082
   T: 02017d3de19a3ec53d0174905665ef37947d142535102cd9809c0dfbd0dfe007
      353d54cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc275adbd9675
      6696ec
   S: 02004d142d87477841f6ba053c8f651f3395ad264b7405ca5911fb9a55abd454
      fef658a5f9ed97d1efac68764e9092fa15b9e0050880d78e95fd03abf5931791
      6822b5
   K: 03007c303f62f09282cc849490805bd4457a6793a832cbeb55df427db6a31e99



McCallum, et al.          Expires June 3, 2018                 [Page 28]


Internet-Draft          SPAKE Pre-Authentication           November 2017


      b055d5dc99756d24d47b70ad8b6015b0fb8742a718462ed423b90fa3fe631ac1
      3fa916
   SPAKESupport: a0093007a0053003020104
   Checksum after SPAKESupport: 1b69d116036e141e45d4f7d7
   SPAKEChallenge: a1593057a003020104a145044302017d3de19a3ec53d0174
                   905665ef37947d142535102cd9809c0dfbd0dfe007353d54
                   cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc2
                   75adbd96756696eca20930073005a003020101
   Checksum after SPAKEChallenge: cac3da1e9ab1261723ece823
   Final checksum after pubkey: 654493ca7e47f3c5200f4b84
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020112
   K'[0]: c91635dfd1de3884b635b58b30d3cfd5
          26fe78f8dade6f19e4eb2fb23ef594ca
   K'[1]: 03d38e139bb3f66cc76c5da720f3bf11
          4280f64ed708e69e96094bb62aa28f32
   K'[2]: 515eaa3c45b08bc9d77468059e64a8e1
          96cfcd15db92ad431cae5edbe721d07e
   K'[3]: 898ae786e58391d8a00eb7a7cbddd005
          3aff9147b42a3076d934608e70a6f0ff

   AES256 edwards25519 with accepted optimistic challenge
   key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
   w: 35b35ca126156b5bf4ec8b90e9545060f2108f1b6aa97b381012b9400c9e3f0e
   x: 70937207344cafbc53c8a55070e399c584cbafce00b836980dd4e7e74fad2a64
   y: 785d6801a2490df028903ac6449b105f2ff0db895b252953cdc2076649526103
   X: 13841224ea50438c1d9457159d05f2b7cd9d05daf154888eeed223e79008b47c
   Y: d01fc81d5ce20d6ea0939a6bb3e40ccd049f821baaf95e323a3657309ef75d61
   T: 83523b35f1565006cbfc4f159885467c2fb9bc6fe23d36cb1da43d199f1a3118
   S: 2a8f70f46cee9030700037b77f22cec7970dcc238e3e066d9d726baf183992c6
   K: d3c5e4266aa6d1b2873a97ce8af91c7e4d7a7ac456acced7908d34c561ad8fa6
   SPAKEChallenge: a1363034a003020101a122042083523b35f1565006cbfc4f
                   159885467c2fb9bc6fe23d36cb1da43d199f1a3118a20930
                   073005a003020101
   Checksum after SPAKEChallenge: 0b1dc2059f7411b639295982
   Final checksum after pubkey: 3990d78eb0abc055d1f69fcb
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730
                 303130313030303030305aa703020100a8053003020112
   K'[0]: 1e9b04bdbdaaffb340aa09c6cdf560fa
          dcaadb7cb8762b22cd6e7c96753090b7
   K'[1]: 7b959d40bd6c517a89278b008cf314e5
          d947b181a3251d2832ab61a21c40d484



McCallum, et al.          Expires June 3, 2018                 [Page 29]


Internet-Draft          SPAKE Pre-Authentication           November 2017


   K'[2]: 3e484bb86ab7f4ffc4b80a6f6d79692c
          55daf2b78654b38c7f1d37b1d688d1f3
   K'[3]: 23a331ddf33211859b82502295b0be4b
          23a56057b77356d62a13985ca573dae1

   AES256 P-521 with rejected optimistic edwards25519 challenge
   key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
   w: 003a095a2b2386eff3eb15b735398da1caf95bc8425665d82370aff58b0471f3
      4cce63791cfed967f0c94c16054b3e1703133681bece1e05219f5426bc944b0f
      bfb3
   x: 01687b59051bf40048d7c31d5a973d792fa12284b7a447e7f5938b5885ca0bb2
      c3f0bd30291a55fea08e143e2e04bdd7d19b753c7c99032f06cab0d9c2aa8f83
      7ef7
   y: 01ded675ebf74fe30c9a53710f577e9cf84f09f6048fe245a4600004884cc167
      733f9a9e43108fb83babe8754cd37cbd7025e28bc9ff870f084c7244f536285e
      25b4
   X: 03001bed88af987101ef52db5b8876f6287eb49a72163876c2cf99deb94f4c74
      9bfd118f0f400833cc8daad81971fe40498e6075d8ba0a2acfac35eb9ec8530e
      e0edd5
   Y: 02007bd3bf214200795ea449852976f241c9f50f445f78ff2714fffe42983f25
      cd9c9094ba3f9d7adadd6c251e9dc0991fc8210547e7769336a0ac406878fb94
      be2f1f
   T: 02014cb2e5b592ece5990f0ef30d308c061de1598bc4272b4a6599bed466fd15
      21693642abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03fb96ef5f1e
      d3e645
   S: 02016c64995e804416f748fd5fa3aa678cbc7cbb596a4f523132dc8af7ce84e5
      41f484a2c74808c6b21dcf7775baefa6753398425becc7b838b210ac5daa0cb0
      b710e2
   K: 0200997f4848ae2e7a98c23d14ac662030743ab37fccc2a45f1c721114f40bcc
      80fe6ec6aba49868f8aea1aa994d50e81b86d3e4d3c1130c8695b68907c673d9
      e5886a
   Optimistic SPAKEChallenge: a1363034a003020102a122042047ca8c
                              24c3a4a70b6eca228322529dadcfa85c
                              f58faceecf5d5c02907b9e2deba20930
                              073005a003020101
   Checksum after optimist SPAKEChallenge: 57eff4df899bc520010deb48
   SPAKESupport: a0093007a0053003020104
   Checksum after SPAKESupport: c2fe6c3c142c207d0bdbdd9c
   SPAKEChallenge: a1593057a003020104a145044302014cb2e5b592ece5990f
                   0ef30d308c061de1598bc4272b4a6599bed466fd15216936
                   42abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03
                   fb96ef5f1ed3e645a20930073005a003020101
   Checksum after SPAKEChallenge: c78a00b2d896b73dbed4969b
   Final checksum after pubkey: 80a1da254a44641e0223a944
   KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
                 1b077261656275726ea2101b0e415448454e412e4d49542e
                 454455a3233021a003020102a11a30181b066b7262746774
                 1b0e415448454e412e4d49542e454455a511180f31393730



McCallum, et al.          Expires June 3, 2018                 [Page 30]


Internet-Draft          SPAKE Pre-Authentication           November 2017


                 303130313030303030305aa703020100a8053003020112
   K'[0]: 567cb2ee046cc10cd29cd5bbe5998e5c
          d4fca318075981087400c32c55299697
   K'[1]: 57535deb12a3bcaac8389957d9065ee5
          51a869148de1f457b232e12055ee9efa
   K'[2]: 6d18f714b69242f1e556b2819f895926
          9ee0da5b014785b4f1fabb3b7318b70c
   K'[3]: a1d86d7d091800f191884e501974fa32
          ca513a520197866d7c57e5c1296319e6

Appendix D.  Acknowledgements

     Nico Williams (Cryptonector)
     Taylor Yu (MIT)

Authors' Addresses

   Nathaniel McCallum
   Red Hat, Inc.

   EMail: npmccallum@redhat.com


   Simo Sorce
   Red Hat, Inc.

   EMail: ssorce@redhat.com


   Robbie Harwood
   Red Hat, Inc.

   EMail: rharwood@redhat.com


   Greg Hudson
   MIT

   EMail: ghudson@mit.edu












McCallum, et al.          Expires June 3, 2018                 [Page 31]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/