draft-sqrl.txt

Internet Engineering Task Force                                A. Comley
Internet-Draft
Intended status: Informational                                S. Killian
Expires: August 5, 2018                                    February 2018


   Secure Quick Reliable Login (SQRL), an Authentication and Identity
                          Management Framework
                           draft-sqrl-working

Abstract

   Secure Quick Reliable Login (SQRL) is an application-level protocol
   for user authentication and identity management.  It enables a user
   to create and manage a single pseudonymous lifetime identity.  That
   identity will allow the user to securely authenticate with any SQRL
   enabled server without relying on a third party or disclosing
   personally identifiable information.

   It provides:

   o  Unique pseudonymous identifiers for each site

   o  Separation of identity management from account management

   o  Strong anti-phishing protection

   o  No shared secrets that can be exploited by bad actors

   o  Out-of-band authentication for logging in on untrusted devices

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 August 5, 2018.




Comley & Killian         Expires August 5, 2018                 [Page 1]

Internet-Draft                    SQRL                     February 2018


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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Features  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     1.4.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.1.  Standard Algorithms . . . . . . . . . . . . . . . . . . .   8
     2.2.  base56check . . . . . . . . . . . . . . . . . . . . . . .   8
       2.2.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . .   9
       2.2.2.  Validation  . . . . . . . . . . . . . . . . . . . . .  10
       2.2.3.  Decoding  . . . . . . . . . . . . . . . . . . . . . .  10
     2.3.  EnHash  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     2.4.  EnScrypt  . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.  Cryptographic Keys, Secrets, and Passwords  . . . . . . . . .  12
     3.1.  Class A Secrets . . . . . . . . . . . . . . . . . . . . .  12
       3.1.1.  Identity Unlock Key (IUK) . . . . . . . . . . . . . .  13
       3.1.2.  Unlock Request Signing Key (URSK) . . . . . . . . . .  13
       3.1.3.  Rescue Code (RC)  . . . . . . . . . . . . . . . . . .  13
       3.1.4.  Password Derived Keys . . . . . . . . . . . . . . . .  13
     3.2.  Class B Secrets . . . . . . . . . . . . . . . . . . . . .  14
       3.2.1.  Previous Identity Unlock Key (PIUK) . . . . . . . . .  14
       3.2.2.  Identity Master Key (IMK) . . . . . . . . . . . . . .  14
       3.2.3.  Identity Lock Key (ILK) . . . . . . . . . . . . . . .  14
       3.2.4.  Site Specific Secret Key (SSSK) . . . . . . . . . . .  15
       3.2.5.  Random Lock Key (RLK) . . . . . . . . . . . . . . . .  15
     3.3.  Class C (Public) Keys . . . . . . . . . . . . . . . . . .  15
       3.3.1.  Site Specific Public Key (SSPK) . . . . . . . . . . .  15
       3.3.2.  Server Unlock Key (SUK) . . . . . . . . . . . . . . .  15
       3.3.3.  Verify Unlock Key (VUK) . . . . . . . . . . . . . . .  15
   4.  Identity Management . . . . . . . . . . . . . . . . . . . . .  15
     4.1.  Identity Lifecycle  . . . . . . . . . . . . . . . . . . .  15



Comley & Killian         Expires August 5, 2018                 [Page 2]

Internet-Draft                    SQRL                     February 2018


     4.2.  User Options  . . . . . . . . . . . . . . . . . . . . . .  16
     4.3.  Identity Storage  . . . . . . . . . . . . . . . . . . . .  17
       4.3.1.  Storage Blocks  . . . . . . . . . . . . . . . . . . .  18
       4.3.2.  Predefined Block Types  . . . . . . . . . . . . . . .  18
       4.3.3.  Encoding  . . . . . . . . . . . . . . . . . . . . . .  21
     4.4.  Identity Operations . . . . . . . . . . . . . . . . . . .  21
       4.4.1.  Identity Creation . . . . . . . . . . . . . . . . . .  22
       4.4.2.  Importing / Exporting an Identity . . . . . . . . . .  23
       4.4.3.  Changing the User's Password  . . . . . . . . . . . .  23
       4.4.4.  Identity Recovery . . . . . . . . . . . . . . . . . .  23
       4.4.5.  Rekeying an Identity  . . . . . . . . . . . . . . . .  24
   5.  Client-Server Protocol  . . . . . . . . . . . . . . . . . . .  25
     5.1.  Initiation of SQRL Authentication . . . . . . . . . . . .  25
       5.1.1.  The SQRL Scheme . . . . . . . . . . . . . . . . . . .  25
       5.1.2.  QR Codes (Out of Band)  . . . . . . . . . . . . . . .  25
     5.2.  The SQRL Realm (Domain) . . . . . . . . . . . . . . . . .  25
     5.3.  Client to Server Requests . . . . . . . . . . . . . . . .  25
       5.3.1.  Protocol Version  . . . . . . . . . . . . . . . . . .  25
       5.3.2.  Commands  . . . . . . . . . . . . . . . . . . . . . .  26
       5.3.3.  Options . . . . . . . . . . . . . . . . . . . . . . .  26
       5.3.4.  The Server Value  . . . . . . . . . . . . . . . . . .  26
       5.3.5.  The Client Value  . . . . . . . . . . . . . . . . . .  29
       5.3.6.  Client Keys . . . . . . . . . . . . . . . . . . . . .  32
       5.3.7.  Client Signatures . . . . . . . . . . . . . . . . . .  32
       5.3.8.  Composing the Request . . . . . . . . . . . . . . . .  32
     5.4.  Server to Client Replies  . . . . . . . . . . . . . . . .  32
       5.4.1.  Required Values . . . . . . . . . . . . . . . . . . .  33
       5.4.2.  Optional Values . . . . . . . . . . . . . . . . . . .  33
       5.4.3.  Additional Values . . . . . . . . . . . . . . . . . .  33
       5.4.4.  Composing the Reply . . . . . . . . . . . . . . . . .  33
   6.  Client-Server Interactions  . . . . . . . . . . . . . . . . .  33
     6.1.  Same Device Authentication  . . . . . . . . . . . . . . .  33
     6.2.  Cross Device Authentication . . . . . . . . . . . . . . .  33
     6.3.  Identity Association  . . . . . . . . . . . . . . . . . .  33
     6.4.  Updating Identity Association . . . . . . . . . . . . . .  33
     6.5.  Disabling Site Login  . . . . . . . . . . . . . . . . . .  33
     6.6.  Re-Enabling Site Login  . . . . . . . . . . . . . . . . .  33
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  34
     8.1.  Phishing  . . . . . . . . . . . . . . . . . . . . . . . .  34
     8.2.  Shoulder-Surfing  . . . . . . . . . . . . . . . . . . . .  36
     8.3.  Evil Router . . . . . . . . . . . . . . . . . . . . . . .  36
     8.4.  Server Compromise . . . . . . . . . . . . . . . . . . . .  37
     8.5.  CPU Flooding  . . . . . . . . . . . . . . . . . . . . . .  37
     8.6.  Evil Client . . . . . . . . . . . . . . . . . . . . . . .  38
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  39
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  39
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  40



Comley & Killian         Expires August 5, 2018                 [Page 3]

Internet-Draft                    SQRL                     February 2018


   Appendix A.  Recommendations and Best Practices . . . . . . . . .  40
     A.1.  Logo  . . . . . . . . . . . . . . . . . . . . . . . . . .  40
     A.2.  Font  . . . . . . . . . . . . . . . . . . . . . . . . . .  40
     A.3.  For Clients . . . . . . . . . . . . . . . . . . . . . . .  41
     A.4.  For Servers . . . . . . . . . . . . . . . . . . . . . . .  41
     A.5.  For Users . . . . . . . . . . . . . . . . . . . . . . . .  41
       A.5.1.  Master Password . . . . . . . . . . . . . . . . . . .  41
       A.5.2.  Identity Backup . . . . . . . . . . . . . . . . . . .  41
       A.5.3.  Disaster Recovery . . . . . . . . . . . . . . . . . .  42
   Appendix B.  The Optional ShortPass Feature . . . . . . . . . . .  42
   Appendix C.  Harvesting Entropy . . . . . . . . . . . . . . . . .  42
     C.1.  Entropy Sources . . . . . . . . . . . . . . . . . . . . .  43
       C.1.1.  Operating System  . . . . . . . . . . . . . . . . . .  43
       C.1.2.  Hardware  . . . . . . . . . . . . . . . . . . . . . .  43
       C.1.3.  User  . . . . . . . . . . . . . . . . . . . . . . . .  44
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  45

1.  Introduction

1.1.  Purpose

   Secure Quick Reliable Login (SQRL) is an authentication method and
   identity management framework which gives the user complete control
   over their online identity, including provisions for recovering from
   the loss of their identity file or password and recovering from
   potential security breaches.

1.2.  Features

   Secure
      Through a series of cryptographic signatures, the user can prove
      their identity without disclosing any information that would allow
      that identity to be compromised or their account hacked.  SQRL
      also provides strong anti-phishing features.

   Identity Management
      SQRL separates and delineates the concepts of account and
      identity.  SQRL provides a full identity lifecycle management
      framework which allows the user to maintain complete control of
      their identity, while leaving servers with complete control over
      account issues.  Even in the event of a compromise, the user
      retains the ability to retake control of their identity and lock
      the attacker out.  Automated rekeying means that the user can
      maintain a single SQRL identity indefinitely, even after a
      compromise.

   Global Password




Comley & Killian         Expires August 5, 2018                 [Page 4]

Internet-Draft                    SQRL                     February 2018


      The user only has to remember a single password, which is used to
      locally decrypt their identity during SQRL authentication.  Since
      the user no longer has to remember a unique password for each
      site, this one global password can be very strong.  This strong
      password combined with strong encryption makes it infeasible for
      even a state level actor to compromise the user's identity.  (SQRL
      apps can alternately use other methods of protection such as
      biometrics when available on the host device.)

   Pseudononymous
      SQRL authentication is pseudonymous, in that it only provides a
      secure, site-specific token to the server.  This token cannot be
      directly linked to a user's account at any other server, and
      provides no personally identifiable information.

   No Shared Secrets
      Passwords, time-based authenticators, and other authentication
      methods work through shared secrets.  These secrets can
      conceivably be stolen by hackers or rogue employees and used to
      impersonate the user.  SQRL does not operate through shared
      secrets, and even if the server's account database is stolen the
      attacker is not given any means to impersonate the user.

   No Third Party
      The user's identity cannot be compromised by a security breach at
      a third party authentication provider, protecting it from both
      hackers and overreaching authorities.

   No Per-Site Settings
      Unlike password managers, SQRL does not require any information
      about specific websites to be saved, preventing potential privacy
      issues stemming from information leaks as well as keeping its
      database size small.

   Offline Identity Backup
      Since SQRL identities are intended to last a lifetime, and there
      is no third party that can help the user recover their identity if
      they forget their password, SQRL includes an offline backup
      mechanism.  The user can print out or write down their encrypted
      identity, along with a secure Rescue Code, that will allow the
      user to recover from a forgotten password.

   Out Of Band Authentication Option
      With SQRL, the user can safely authenticate a session on public or
      potentially compromised systems by scanning a QR code on a trusted
      mobile device containing their SQRL identity, without the need to
      expose that identity to the public system.




Comley & Killian         Expires August 5, 2018                 [Page 5]

Internet-Draft                    SQRL                     February 2018


1.3.  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.4.  Definitions

   Account
      Information on a user's services and permissions on a particular
      web site for purposes of facilitating access

   Authentication
      The process of verifying an identity and attaching it to an
      account

   Backup
      To externally save a user's Rescue Code-protected IUK via file, QR
      code, or text without saving the IMK

   Client
      The user component of SQRL

   Export
      To externally save a user's Rescue Code-protected IUK and
      password-protected IMK via file or QR code

   Identity
      A means of pseudonymously recognizing a user

   Identity Lock
      A method of locking a user's identity on various websites
      (generally out of fear the user's IMK may be compromised) for
      later unlocking with Rescue Code or rekeyed identity

   IDK
      IDentity Key: a secure, irreversible, and collision-resistant
      public key used to identify the user in a specific realm; unique
      to both the realm and the user's IMK

   ILK
      Identity Lock Key: public key counterpart to the IUK

   IMK
      Identity Master Key: A key derived from the IUK that is the basis
      of a user's identity for each realm

   Import



Comley & Killian         Expires August 5, 2018                 [Page 6]

Internet-Draft                    SQRL                     February 2018


      To load an exported or backed up identity into a client

   IUK
      Identity Unlock Key: the master key from which all aspects of a
      user's identity are derived

   Master Password
      A password created by the user that is used to derive the
      encryption key for the user's IMK

   Nut
      A unique, unpredictable, cryptographically-strong string
      identifying the current session

   Pseudonymous
      Of a consistent and reliable means of verifying a user without
      having to obtain personal information

   Realm
      The basis for generating a unique identity key; generally the
      domain name, but additional data can be included (ref)

   Rekey
      To replace a potentially-compromised IMK

   Rescue Code
      A cryptographically-strong 24 decimal digit random number that is
      used to derive the encryption key for the user's IUK

   RLK
      Random Lock Key: generated randomly by a user for a new website
      and used as the basis of the Identity Lock system

   Server
      The backend component of SQRL that verifies a user identity and
      attaches it to an account

   ShortPass
      The first few characters (4 by default) of a user's Master
      Password; used to verify the user after the Master Password has
      been used to start a session

   SUK
      Server Unlock Key: public key counterpart to the RLK; sent by the
      user to the server on account creation and used to unlock an
      identity

   VUK



Comley & Killian         Expires August 5, 2018                 [Page 7]

Internet-Draft                    SQRL                     February 2018


      Verify Unlock Key: public key counterpart to a Diffie-Hellman key
      generated by the RLK and the ILK; later used to verify an unlock
      request from the user made from the SUK and the user's IUK

2.  Algorithms

   TODO

2.1.  Standard Algorithms

   The following standard algorithms are used in this document:

   o  AES-GCM [NIST.800-38D]

   o  base64url: URL safe base64 encoding, as defined in Section 4 of
      [RFC3548], without padding.

   o  Curve25519 [RFC8031]

   o  Ed25519 [RFC8032]

   o  HMAC [RFC2104]

   o  HMAC-SHA256 [RFC4868]

   o  PBKDF2 [RFC2898]

   o  scrypt [RFC7914]

   o  SHA-256 [FIPS.180-4.2015]

   o  urlencode: Percent-Encoding as defined in Section 2.1 of
      [RFC3986].

2.2.  base56check

   base56check encoding allows the backup of SQRL identities to a
   textual form.  It:

   o  Accepts an arbitrarily sized payload.

   o  Uses a set of 56 alphanumeric symbols chosen to be easily
      distinguishable in any font.

   o  Ignores invalid characters and white space to allow readable
      formatting.





Comley & Killian         Expires August 5, 2018                 [Page 8]

Internet-Draft                    SQRL                     February 2018


   o  Designed to be printed 20 characters per line, in 5 space
      separated groups of 4 characters for readability.

   o  Includes a check character at the end of each line to catch errors
      while the user is typing with 98.2% accuracy.

   The chosen alphabet is:

   23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnpqrstuvwxyz

2.2.1.  Encoding

   To encode a series of bytes to base56check, treat the source bytes as
   a single, large, little-endian number and convert using the normal
   mathematical steps:

   1.  Calculate BASE_LENGTH: ceil( SOURCE_LENGTH * 8.0 / log2(56))

   2.  Divide SOURCE by 56 to yield SOURCE and REMAINDER.

   3.  Append the character in ALPHABET at position REMAINDER to the
       BASE string.

   4.  Repeat from step 1, until SOURCE is zero.

   5.  Append '2' (character in ALPHABET at position 0) to BASE until
       BASE is BASE_LENGTH bytes long.

   Now, with our converted BASE string, we can calculate the check
   digits and produce the final output.

   6.  Split BASE into 19 character CHUNKS (the final chunk may be
       smaller).

   7.  For each CHUNK:

       A.  Append a single byte zero-based CHUNK-NUMBER to the CHUNK.

       B.  Perform a SHA-256 hash on the CHUNK, yielding HASH.

       C.  Treating HASH as a single little-endian number, divide HASH
           by 56 to obtain REMAINDER.

       D.  Replace the last character in CHUNK with the character in
           ALPHABET at position REMAINDER.

       E.  Append the CHUNK to OUTPUT.




Comley & Killian         Expires August 5, 2018                 [Page 9]

Internet-Draft                    SQRL                     February 2018


   OUTPUT can then be formatted as desired.  The RECOMMENDED formatting
   is 20 characters per line in space-separated groups of 4 characters
   each.  This format is easy for humans to read and type, and allows
   error checking for each line of input.

2.2.2.  Validation

   base56check is designed to provide periodic error checking and
   feedback to the user as they are typing.  To perform this validation:

   1.  Remove any characters from INPUT that are invalid (not included
       in ALPHABET).

   2.  Split INPUT into 20 character CHUNKS (the final chunk may be
       smaller).

   3.  For each CHUNK:

       A.  Store the last character from CHUNK as CHECK.

       B.  Replace the last character in CHUNK with a single byte zero-
           based CHUNK-NUMBER.

       C.  Perform a SHA-256 hash on the CHUNK, yielding HASH.

       D.  Treating HASH as a single little-endian number, divide HASH
           by 56 to obtain REMAINDER.

       E.  Compare CHECK with the character from ALPHABET at position
           REMAINDER.

       F.  If comparison passes (is equal), continue.  Otherwise, there
           is an error in this CHUNK.

2.2.3.  Decoding

   Decoding base56check is similarly straight-forward:

   1.  Start with an empty BASE string and an zero OUTPUT buffer, to be
       treated as a single, large, little-endian number.

   2.  Perform the base56check validation as described above, appending
       all but the last character of each validated CHUNK to the BASE
       string.

   3.  If any chunk fails validation, abort.

   4.  For each CHARACTER in BASE, from right to left:



Comley & Killian         Expires August 5, 2018                [Page 10]

Internet-Draft                    SQRL                     February 2018


       A.  Multiply OUTPUT by 56.

       B.  Lookup the INDEX of CHARACTER in ALPHABET.

       C.  Add INDEX to OUTPUT.

2.3.  EnHash

   EnHash is an iterated hash used to derive a 256 bit key from another
   256 bit key.  It is performed by chaining 16 iterations of SHA-256,
   with each iteration's output XORed to produce the final output as
   follows:

   function EnHash ( input := 32 byte key )
   {
     output := 32 byte buffer;

     set output to all NULL (0) bytes;

     repeat {
       input = SHA256( input );
       output = output XOR input;
     } 16 times;

     return output;
   }

2.4.  EnScrypt

   EnScrypt is an implementation of PBKDF2 using scrypt as a PRF.  It
   hardens scrypt by allowing for extended processing time while keeping
   memory requirements low but still effective.

   The following parameters are used for the scrypt function:

                     +-------+------------+-----+---+
                     | dkLen | N          | r   | p |
                     +-------+------------+-----+---+
                     | 32    | 512 (1<<9) | 256 | 1 |
                     +-------+------------+-----+---+

                        Table 1: scrypt parameters

   In this document, we may refer to an additional parameter, "n-factor"
   or just "n".  This is simply a shorthand way of storing the N
   parameter.  N is derived from n as follows:

   N = (1 << n);



Comley & Killian         Expires August 5, 2018                [Page 11]

Internet-Draft                    SQRL                     February 2018


   Enscrypt is performed by calling scrypt via multiple rounds of
   PBKDF2.

   EnScrypt can operate in two different modes, the only difference
   being when the calculation is stopped.

   Counter Mode:
      Stops after a predefined number of iterations.

   Timer Mode:
      Stops after a desired amount of time has passed (5 seconds by
      default).

   Timer Mode is used when creating an encryption key from a password.
   Successive rounds of PBKDF2 are computed until the specified time
   elapses.  The result is used as the key to encrypt the identity, and
   the resulting number of iterations is saved with the identity file.
   Counter Mode is used to recreate this key and decrypt the identity.

3.  Cryptographic Keys, Secrets, and Passwords

   SQRL uses a wide variety of secrets in various operations.

3.1.  Class A Secrets

   Class A secrets are absolutely critical to protecting a user's
   identity.  A compromised Class A secret may result in the user's
   complete loss of control of the identity, with no recourse available.
   Due to their highly sensitive nature, the following precautions are
   REQUIRED when dealing with Class A secrets:

   o  The secret MUST be generated using the highest quality entropy
      source available to the client.  See Appendix C for
      recommendations.

   o  The client MUST prevent the secret from being written to non-
      volatile memory in plaintext form, including being swapped to
      disk, by any means possible.

   o  The plaintext secret MUST be securely wiped from RAM as soon as it
      is no longer needed.

   o  If the secret is to be stored, it MUST be stored in an offline
      format (printed), OR encrypted using a Class A key.

   o  The secret SHOULD NOT be transmitted over the network in any form,
      and MUST NOT be transmitted unencrypted.




Comley & Killian         Expires August 5, 2018                [Page 12]

Internet-Draft                    SQRL                     February 2018


3.1.1.  Identity Unlock Key (IUK)

   IUK = RandomBytes( 32 );

   The IUK is a Class A 256 bit high entropy random number that
   represents a user's identity.  All other identifying keys are derived
   from this one.  After identity creation, this key is only used in
   emergency situations, such as rekeying an identity in the event of a
   possible compromise.

3.1.2.  Unlock Request Signing Key (URSK)

   URSK = curve25519_key_agreement( SUK, curve25519_private_key( IUK ));

   Used by the client to update the identity association on a server,
   the URSK is derived from the SUK and IUK.

3.1.3.  Rescue Code (RC)

   The Rescue Code is a Class A, computer generated, high entropy
   passcode consisting of 24 numeric digits.  The client SHOULD
   encourage the user to store the Rescue Code in an offline format
   (printed or written).

3.1.4.  Password Derived Keys

   Several keys are generated from user input.  Both the user supplied
   passwords and the derived keys are to be treated as Class A secrets.
   Since these are expected to be low entropy, they must be processed
   through EnScrypt (Section 2.4).  When generating derived keys,
   EnScrypt MUST be used in timer mode with a minimum duration of 1
   second.  The table below lists RECOMMENDED durations for EnScrypt key
   generation:

       +----------------------------+--------------+---------------+
       | Key                        | Abbreviation | EnScrypt Time |
       +----------------------------+--------------+---------------+
       | Password Derived Key       | PWDK         | 5 seconds     |
       | Short Password Derived Key | SPDK         | 1 second      |
       | Rescue Code Derived Key    | RCDK         | 60 seconds    |
       +----------------------------+--------------+---------------+

       Table 2: Password Derived Keys and Recommended EnScrypt Times

   Clients MAY allow the user to specify the EnScrypt time for the PWDK,
   as long as that timer is at least 1 second.  The RCDK is used so
   rarely, and is so important to protect, that 60 seconds should not
   cause an undue burden on the user.



Comley & Killian         Expires August 5, 2018                [Page 13]

Internet-Draft                    SQRL                     February 2018


   When re-generating derived keys, EnScrypt is used in counter mode
   with the iteration count from the original generation operation.

3.2.  Class B Secrets

   Class B secrets are used often, and have less strict security
   requirements.  A compromised Class B secret may result in an attacker
   temporarily gaining the ability to impersonate the user to any
   server, but the user can regain control of their identity by rekeying
   followed by authenticating with each affected server.  The following
   precautions are REQUIRED when dealing with Class B secrets:

   o  The client MUST prevent the secret from being written to non-
      volatile memory in plaintext form, including being swapped to
      disk, by any means possible.

   o  The plaintext secret MUST be securely wiped from RAM as soon as it
      is no longer needed.

   o  If the secret is to be stored, it MUST be stored in an encrypted
      form.

   o  The secret SHOULD NOT be transmitted over the network in any form,
      and MUST NOT be transmitted unencrypted.

3.2.1.  Previous Identity Unlock Key (PIUK)

   A PIUK is an IUK that is no longer in active use.  It has been
   replaced by a newly generated IUK, and requires less strict
   protection.

3.2.2.  Identity Master Key (IMK)

   IMK = EnHash( IUK );

   This Class B key acts as a proxy for the IUK during normal SQRL
   operation.  It is used to generate the unique keys that each site
   associates with the user.  The IMK is derived from the IUK using the
   EnHash (Section 2.3) function.

3.2.3.  Identity Lock Key (ILK)

   ILK = curve25519_public_key( curve25519_private_key( IUK ));

   The (modified) IUK and ILK together form a Curve25519 key pair.






Comley & Killian         Expires August 5, 2018                [Page 14]

Internet-Draft                    SQRL                     February 2018


3.2.4.  Site Specific Secret Key (SSSK)

   SSSK = HMAC-SHA256( IMK, Realm );

   The Site Specific Secret Key is generated from the IMK and the Realm
   (Section 5.2).

3.2.5.  Random Lock Key (RLK)

   RLK = curve25519_private_key( RandomBytes( 32 ));

   The RLK is generated randomly when the client associates with a new
   server.

3.3.  Class C (Public) Keys

   Class C keys are not required to be kept secret.

3.3.1.  Site Specific Public Key (SSPK)

   SSPK = ed25519_public_key( SSSK );

   The Site Specific Public Key (SSPK) is the public counterpart to the
   SSSK.  It serves as the user's pseudonymous identity on the site.

3.3.2.  Server Unlock Key (SUK)

   SUK = curve25519_public_key( RLK );

   Created during identity association, the SUK is the public
   counterpart of the RLK.

3.3.3.  Verify Unlock Key (VUK)

   VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));

   Generated during identity association, and stored only on the server,
   the VUK is the public key used to verify the client's URSK.

4.  Identity Management

4.1.  Identity Lifecycle

   TODO







Comley & Killian         Expires August 5, 2018                [Page 15]

Internet-Draft                    SQRL                     February 2018


4.2.  User Options

   Several user options are available which will affect the operation of
   compatible SQRL clients:

   ShortPass Length:
      The number of characters from the user's password to use as the
      ShortPass (Appendix B).  Clients that implement ShortPass MUST
      honor the user's choice here.  Valid values are 0 to 255.  A value
      of 0 disables the ShortPass feature.

   EnScrypt Seconds:
      The number of seconds to run EnScrypt when deriving the PWDK.  The
      RECOMMENDED default is 5 seconds.  The REQUIRED minimum is 1
      second.

   Idle Timeout:
      If the client implements ShortPass or holds the user's password or
      keys in memory in any form, and the 0x0080 option flag is set, it
      MUST securely erase that memory after this many minutes of system
      idle time.  Valid values are 1-65535.

   Option Flags:
      The following binary flags turn on or off various user options:



























Comley & Killian         Expires August 5, 2018                [Page 16]

Internet-Draft                    SQRL                     February 2018


   +--------+----------------------------------------------------------+
   | Flag   | Description                                              |
   +--------+----------------------------------------------------------+
   | 0x0001 | Check for updates:  Gives the client permission to       |
   |        | periodically check for updates.                          |
   | 0x0002 | Update Automatically:  Requests that the client          |
   |        | automatically update itself when a new version is        |
   |        | available.                                               |
   | 0x0004 | Request SQRL only:  Requests that servers disable other  |
   |        | means of authentication and only allow SQRL.             |
   | 0x0008 | Request no bypass:  Requests that servers not allow non- |
   |        | SQRL account recovery options.                           |
   | 0x0010 | Warn of possible MITM attack: The client will warn the   |
   |        | user if their IP doesn't match the server's              |
   |        | expectations.                                            |
   | 0x0020 | Clear ShortPass when screen blanks: The client will      |
   |        | securely erase any ShortPass information when the screen |
   |        | saver is activated or the system is going to suspend /   |
   |        | sleep modes.                                             |
   | 0x0040 | Clear ShortPass when changing users: The client will     |
   |        | securely erase any ShortPass information when the        |
   |        | system's active user changes.                            |
   | 0x0080 | Clear ShortPass after idle timer: The client will        |
   |        | securely erase any ShortPass information after the       |
   |        | system has been idle for an amount of time specified in  |
   |        | the "Idle Timeout" option.                               |
   | 0x0100 | Warn of non-CPS authentication: The client will warn the |
   |        | user before a non-CPS authentication is attempted.  This |
   |        | flag MUST default to on.                                 |
   +--------+----------------------------------------------------------+

                             User Option Flags

4.3.  Identity Storage

   Because SQRL identities are intended to last the user's lifetime, the
   user needs to be able to move his identity between clients.  Every
   SQRL client MUST be able to read and write identities in this
   standard format.  The format described here is RECOMMENDED for both
   non-volatile and in-memory storage.

   Because identities should be backed up offline (to printed paper),
   the storage format must be compact enough to reliably fit in a
   printed QR code, and short enough to not cause undue burden if the
   user has to type it in by hand.

   Values stored in standard SQRL storage format MUST follow these
   rules:



Comley & Killian         Expires August 5, 2018                [Page 17]

Internet-Draft                    SQRL                     February 2018


   o  All numeric values are unsigned.

   o  Multibyte numeric values are stored in little endian byte order,
      with the least significant byte first.

   o  String values are stored in natural order, first byte first.

4.3.1.  Storage Blocks

   A stored SQRL identity is composed of any number of blocks.  Each
   block begins with a four byte header identifying the total length of
   the block and the type of data stored in the block.

              +-----------------------------+--------------+
              | Field                       | Size (bytes) |
              +-----------------------------+--------------+
              | block length in bytes (n+4) | 2            |
              | block type                  | 2            |
              | block data                  | n            |
              +-----------------------------+--------------+

                       Table 3: Storage Block Format

   Standard block types are defined in the next section.  Clients MAY
   add their own block types to store additional information, but SHOULD
   consider types 0-255 as reserved for future official block types.
   Any client reading an identity that encouters a block type unknown to
   that client MUST simply ignore that block.

4.3.2.  Predefined Block Types

4.3.2.1.  Block Type 1: Working Identity

   The type 1 block contains the user's encrypted IMK and ILK, as well
   as user defined options.  The user options are in plain text, but
   MUST be regarded as untrusted until authenticated through AES-GCM.
   Type 1 blocks are encrypted with AES-GCM using the PWDK.  The type 1
   block is formatted as follows:













Comley & Killian         Expires August 5, 2018                [Page 18]

Internet-Draft                    SQRL                     February 2018


              +--------------------------+---------+-------+
              | Field                    | Default | Bytes |
              +--------------------------+---------+-------+
              | Block Length             | 125     |     2 |
              | Block Type               | 1       |     2 |
              | AAD Length               | 45      |     2 |
              | AES-GCM IV               |         |    12 |
              | EnScrypt Salt            |         |    16 |
              | EnScrypt n-factor        | 9       |     1 |
              | EnScrypt Iteration Count |         |     4 |
              | User Option Flags        | 0x01F3  |     2 |
              | ShortPass Length         | 4       |     1 |
              | EnScrypt Seconds         | 5       |     1 |
              | Idle Timeout (minutes)   | 15      |     2 |
              | Encrypted IMK            |         |    32 |
              | Encrypted ILK            |         |    32 |
              | AES-GCM Verification Tag |         |    16 |
              +--------------------------+---------+-------+

                               Type 1 Block

   Constructing a type 1 block is relatively straight-forward:

   1.  Allocate a 125 byte buffer.

   2.  Populate the default values (or user chosen options).

   3.  Generate a random 12 byte initialization vector (IV) and store it
       in the buffer.

   4.  Generate a random 16 byte salt and store it in the buffer.

   5.  Use the generated salt, the user's password, and the user's
       chosen EnScrypt Seconds value to generate the PWDK and Iteration
       Count.

   6.  Populate the Iteration Count in the buffer.

   7.  AES-GCM encrypt the IMK and ILK (64 bytes total) using the first
       "AAD Length" bytes of the buffer as AAD, the IV, the PWDK.

   8.  Populate the ciphertext result and verification tag from AES-GCM.

   9.  Securely wipe the plaintext keys, encryption key, and password
       from memory if they are no longer needed.






Comley & Killian         Expires August 5, 2018                [Page 19]

Internet-Draft                    SQRL                     February 2018


   If the client is updating a type 1 block, and the user's password
   hasn't changed, clients SHOULD use the original salt and iteration
   count to re-encrypt the block.

4.3.2.2.  Block Type 2: Rescue Identity

   The type 2 block contains a single key, the IUK, along with it's
   encryption parameters.  It is encrypted with AES-GCM using the RCDK.

              +--------------------------+---------+-------+
              | Field                    | Default | Bytes |
              +--------------------------+---------+-------+
              | Block Length             | 73      | 2     |
              | Block Type               | 2       | 2     |
              | EnScrypt Salt            |         | 16    |
              | EnScrypt n-factor        | 9       | 1     |
              | EnScrypt Iteration Count |         | 4     |
              | Encrypted IUK            |         | 32    |
              | AES-GCM Verification Tag |         | 16    |
              +--------------------------+---------+-------+

                               Type 2 Block

   The type 2 block is constructed the same way as the type 1, with the
   following exceptions:

   o  To save space in textual exports, we implicitly use a 12 byte, all
      zero Initialization Vector for AES-GCM.  This means that the type
      2 block MUST NOT be re-encrypted with different parameters.  This
      block MUST NOT be changed after identity creation.  It can only be
      replaced by rekeying.

   o  The RCDK is used in place of the PWDK.

4.3.2.3.  Block Type 3: Previous Identities

   The type 3 block contains from one to four of the most recent PIUKs,
   IUKs which have been replaced by rekeying.  It also includes the
   total number of times the identity has been rekeyed, the "Edition".
   If the identity has never been rekeyed, this block will be absent.
   Encrypted using the IMK as the AES-GCM encryption key, the content of
   this block is accessible to the client if either the user's password
   or the Rescue Code is known.








Comley & Killian         Expires August 5, 2018                [Page 20]

Internet-Draft                    SQRL                     February 2018


   +------------------------+---------------------+--------------------+
   | Field                  | Default             | Bytes              |
   +------------------------+---------------------+--------------------+
   | Block Length           | 54, 86, 118, or 150 | 2                  |
   | Block Type             | 3                   | 2                  |
   | Edition                |                     | 2                  |
   | Previous IUKs          |                     | 32, 64, 96, or 128 |
   | AES-GCM Verification   |                     | 16                 |
   | Tag                    |                     |                    |
   +------------------------+---------------------+--------------------+

                               Type 3 Block

   The type 3 block is encrypted with AES-GCM, using the first 6 bytes
   of the block as AAD, the IMK as the encryption key, and a 12 byte all
   zero initialization vector (IV).  Due to the nature of the block's
   content, the same encryption key will never be used to encrypt a
   different set of data and AAD, so a random IV is not necessary.

4.3.3.  Encoding

   Identities may be stored to file or optical (QR) code in binary
   format, or in base64url or base56check (Section 2.2) encoded text.
   Compatible clients MUST support at least one of these standard
   encodings.

   Identities stored in this standard format MUST include an 8 byte
   header identifying the encoding used for the remainder of the file,
   with a single exception: Identities exported to text using
   base56check encoding do not include a header.  Instead, they are
   validated by the encoded check characters.  The header itself is not
   encoded, but indicates that everything following it will be.

                     +-------------+----------------+
                     | Encoding    | Header (ASCII) |
                     +-------------+----------------+
                     | binary      | sqrldata       |
                     | base64url   | SQRLDATA       |
                     | base56check |                |
                     +-------------+----------------+

                  Table 4: Storage Encodings and Headers

4.4.  Identity Operations

   Identity creation, recovery, and rekeying are particularly vulnerable
   times for the SQRL identity, during which several Class A secrets may
   be exposed.  Special care is required to protect this sensitive key



Comley & Killian         Expires August 5, 2018                [Page 21]

Internet-Draft                    SQRL                     February 2018


   during these operations.  Clients SHOULD inform the user of the
   security implications and encourage the user not to perform these
   operations on a device that the user believes to be compromised.

4.4.1.  Identity Creation

   The SQRL identity is, in essence, just a long random number (the
   IUK).  In order to protect the new identity, both during creation and
   against future exploits, the client MUST use the highest quality
   entropy available to it while creating a new identity.  See
   Appendix C for recommendations on harvesting entropy.

   Creating an identity involves generating a random IUK and Rescue
   Code, deriving the IMK and ILK, and encrypting these keys.  In
   addition, the client MUST allow and encourage the user to store both
   the new identity and the Rescue Code in an offline format.  The
   following process is RECOMMENDED:

   1.  Begin harvesting entropy if the client does not do this
       continuously.

   2.  Prompt the user to name their new identity so that they can
       recognize it later.

   3.  Generate a random Rescue Code, and have the user store the Rescue
       Code offline.  Written or printed form is RECOMMENDED.  Encourage
       the user to securely store the Rescue Code in an offline format.
       The client MAY require the user to retype the Rescue Code to
       ensure that they have stored a copy.

   4.  Prompt the user for a password to protect the new identity.
       Clients SHOULD encourage the user to choose a strong password.

   5.  Generate a random IUK and store it in a newly constructed Type 2
       block (Section 4.3.2.2), encrypted with the newly generated
       Rescue Code.

   6.  Derive the IMK and ILK and store them in a newly constructed Type
       1 block (Section 4.3.2.1), encrypted with the user's new
       password.

   7.  Securely wipe any memory containing unencrypted keys or
       passwords.

   8.  Save the newly created blocks to local storage with the user
       chosen name.





Comley & Killian         Expires August 5, 2018                [Page 22]

Internet-Draft                    SQRL                     February 2018


   9.  Provide options for, and encourage the user to backup the new
       identity to an offline format.

4.4.2.  Importing / Exporting an Identity

   For compatibility, clients MUST support importing and exporting
   identities in at least one of these standard formats.  It is
   RECOMMENDED that clients support all of them.  Clients MAY offer
   additional formats as well.

   Binary File
      An identity in the standard format (Section 4.3), saved as a
      binary file with the "sqrldata" header.  The RECOMMENDED file
      extension is ".sqrl".

   QR Code


      *  TODO: Reference QR Code specification?

      *  TODO: Recommend Mode, Encoding, Error Correction, etc.

   Text
      An identity in the standard format (Section 4.3), encoded with
      base56check (Section 2.2), intended to be printed to paper for
      offline storage and manually entered by the user during import.

4.4.3.  Changing the User's Password

   Clients SHOULD allow the user to change their password at any time.
   The process is simple:

   1.  Using the user's current password, decrypt the Type 1 Block.
       Other block types are not affected by this operation.

   2.  Using the user's new password, re-encrypt the Type 1 Block.
       During encryption, EnScrypt MUST be called in Timer Mode, using
       the user's chosen "EnScrypt Seconds" option (Section 4.2).

   3.  Save the changes to non-volatile storage.

4.4.4.  Identity Recovery

   If the user has forgotten their password, or lost their identity
   file, identity recovery is required to reconstruct a usable identity.
   Depending on the situation, the client may be recovering from an
   existing identity file, or from an offline backup.  In either case,
   the procedure is the same:



Comley & Killian         Expires August 5, 2018                [Page 23]

Internet-Draft                    SQRL                     February 2018


   1.  Because the user's options are lost in this process, the client
       SHOULD give the user an opportunity to review the default options
       and make changes.

   2.  Prompt the user to enter their Rescue Code and new password.

   3.  Validate the Rescue Code by decrypting the Type 2 block and
       obtain the IUK.

   4.  Derive the IMK and ILK, and construct a new Type 1 block
       protected by the user's newly chosen password.

   5.  Securely wipe any memory containing unencrypted keys or
       passwords.

   6.  Save the recovered identity.

4.4.5.  Rekeying an Identity

   Rekeying an identity completely replaces the IUK with a new one.  It
   is only required when the user believes that their identity may have
   been compromised.  After rekeying, the client SHOULD encourage the
   user to visit and authenticate with any important sites to ensure
   that those sites update their identity association.  Until this is
   done, an attacker may still have full access to those sites.  To
   rekey an identity:

   1.  Prompt the user for their Rescue Code.

   2.  Using the Rescue Code, decrypt the Type 2 block to obtain the IUK
       (now a PIUK).

   3.  Follow the steps in Section 4.4.1 to create a new identity.

   4.  Before saving or exporting the new identity, a Type 3 block
       (Section 4.3.2.3) must be constructed:

       A.  If a Type 3 block already exists (rekeying has been performed
           in the past), the existing block must be decrypted and
           modified.  The "Edition" field is incremented, and the new
           PIUK is prepended to the existing PIUKs.  If the list now
           contains more than four PIUKs, the last (oldest) one is
           removed.

       B.  If a Type 3 block does not already exist, a new one is
           created.  Fill the "Edition" field with the number 1.  The
           encrypted section will contain only the new PIUK.




Comley & Killian         Expires August 5, 2018                [Page 24]

Internet-Draft                    SQRL                     February 2018


       C.  Encrypt the Type 3 block using the new IMK and ensure that it
           is saved / exported with the new identity.

5.  Client-Server Protocol

   TODO

5.1.  Initiation of SQRL Authentication

   TODO

5.1.1.  The SQRL Scheme

   TODO

5.1.2.  QR Codes (Out of Band)

   TODO

5.2.  The SQRL Realm (Domain)

   TODO

5.3.  Client to Server Requests

   TODO

5.3.1.  Protocol Version

   SQRL protocol versions are specified by integers starting at 1.

   Both client and server MUST declare the set of SQRL protocol versions
   it understands, supports, and is willing to use.  This protocol
   version declaration MUST be the first name=value pair appearing in
   the argument list and MUST be one of the following formats:

   o  A single supported version (e.g., "ver=1", signifying that only
      version 1 of the SQRL protocol is supported)

   o  Multiple supported versions via a comma-separated list (e.g.,
      "ver=1,3", signifying that versions 1 and 3 of the SQRL protocol
      are supported, but not 2)

   o  A range of versions via hyphenation (e.g., "ver=1-3", signifying
      that versions 1, 2, and 3 of the SQRL protocol are supported)






Comley & Killian         Expires August 5, 2018                [Page 25]

Internet-Draft                    SQRL                     February 2018


   o  A combination of these techniques (e.g., "ver=1-3,5", signifying
      that versions 1, 2, 3, and 5 of the SQRL protocol are supported,
      but not 4)

   Once both client and server have declared their supported version
   sets, the version used MUST be the highest version number in the
   intersection of these sets.

5.3.2.  Commands

   TODO

5.3.3.  Options

   TODO

5.3.4.  The Server Value

   The server gives data to the client in two ways: encoded into the
   SQRL URL, where it provides the "nut=" session identifier and the
   optional "x=" domain extension, and the HTTP response bodies where
   any of the following parameters may be used.

   When appearing in a URL, name=value pairs MUST be URL-safe and
   ampersand separated as per standard HTTP GET syntax.  When returned
   as a response to a client's query, the name=value pairs occupy the
   body, one per line with each (including the last one) terminated by
   CRLF.

   There MUST NOT be any space between either the name or value and the
   equal sign.

   ver
      The server MUST declare the set of supported protocol versions,
      and this declaration MUST be first in the client's argument list.
      See Section 5.3.1.

   nut
      Base64url-encoded opaque token that is a never-repeating
      cryptographically-strong nonce.  The nut MAY contain reversibly
      encrypted data to help the server associate and maintain state.
      It MUST be included with every response to prevent reuse/replay
      and hijacking attacks.  As with all of SQRL's base64 values, any
      trailing equals signs must be stripped. [add xref here once
      section on nut is complete]

   tif




Comley & Killian         Expires August 5, 2018                [Page 26]

Internet-Draft                    SQRL                     February 2018


      Transaction Information Flags.  A single hexadecimal-encoded
      integer that MUST be included in every server response.  The "0x"
      prefix is included here for clarity, but they are not needed or
      used in the TIF's value.

   +-------+-----------------------------------------------------------+
   |  Flag | Description                                               |
   +-------+-----------------------------------------------------------+
   |  0x01 | (Current) ID Match. Indicates that the server has found   |
   |       | an identity association for the user based on the current |
   |       | IDK and IDS supplied by the client.                       |
   +-------+-----------------------------------------------------------+
   |  0x02 | Previous ID Match. Indicates that the server has found an |
   |       | identity association for the user based on the PIDK and   |
   |       | PIDS. When neither of the ID bits are set, none of the    |
   |       | credentials supplied are known to the web server.         |
   +-------+-----------------------------------------------------------+
   |  0x04 | IP Match. Indicates that the IP address of the client     |
   |       | matches the IP address of the initial logon page          |
   |       | containing the SQRL URL.                                  |
   +-------+-----------------------------------------------------------+
   |  0x08 | SQRL Disabled. Indicates that the SQRL authentication for |
   |       | this identity has previously been disabled. While this    |
   |       | bit is set, any attempt at authentication MUST fail. This |
   |       | bit can ONLY be reset, and the identity re-enabled, by    |
   |       | the "enable=" parameter from the client signed by the URS |
   |       | for the identity known to the server.                     |
   +-------+-----------------------------------------------------------+
   |  0x10 | Function(s) Not Supported. The client requested one or    |
   |       | more SQRL functions that the server does not currently    |
   |       | support. The server MUST also fail the query by setting   |
   |       | 0x40 Command Failed.                                      |
   +-------+-----------------------------------------------------------+
   |  0x20 | Transient Error. Indicates that the client signature(s)   |
   |       | are correct, but something about the query prevented the  |
   |       | command from completing. MUST be accompanied by a fresh   |
   |       | "nut=" and a new "qry=" parameter. The server is          |
   |       | requesting that the client retry and reissue the command  |
   |       | with the new nut and query values. The server MUST also   |
   |       | fail the query by setting 0x40 Command Failed.            |
   +-------+-----------------------------------------------------------+
   |  0x40 | Command Failed. Indicates that the server has had a       |
   |       | problem processing the client's query. No change is made  |
   |       | to the user's account or login status. With SQRL, either  |
   |       | everything succeeds, or nothing happens. When set without |
   |       | 0x80 Client Failure, the trouble was not with the         |
   |       | client's data, protocol, etc. but with some other aspect  |
   |       | of the request failing. The server MAY use the "ask="     |



Comley & Killian         Expires August 5, 2018                [Page 27]

Internet-Draft                    SQRL                     February 2018


   |       | parameter to explain the problem to the client's user.    |
   |       | When this flag is activated, the client MUST consider all |
   |       | other TIFs other than 0x80 to be invalid.                 |
   +-------+-----------------------------------------------------------+
   |  0x80 | Client Failure. Some aspect of the client's submitted     |
   |       | query (other than expired but otherwise valid state       |
   |       | information) was incorrect and prevented the server from  |
   |       | understanding and/or completing the requested action.     |
   |       | Moreover, this is not an issue the server expects could   |
   |       | be fixed by having the client reissue the command with a  |
   |       | fresh nut. The server MUST also set 0x40 Command Failed.  |
   +-------+-----------------------------------------------------------+
   | 0x100 | Bad ID Association. The server may request reverification |
   |       | of the user's SQRL identity after a successful            |
   |       | authentication. If it then receives a SQRL query using    |
   |       | that nut but with a different SQRL identity, the server   |
   |       | MUST reply with 0x100 Bad ID Association along with 0x40  |
   |       | Command Failed and 0x80 Client Failure.                   |
   +-------+-----------------------------------------------------------+

                   Transaction Information Flags (TIFs)

   Note that the number of characters in the "tif=" value may vary
   depending on the number of characters required to represent the most
   significant bit set within the value.  Later versions of the SQRL
   protocol may expand this list as needed.  Therefore, there MUST NOT
   be any restrictions on or assumptions about the length of the "tif="
   value.

   SQRL clients MUST immediately terminate any connection and abort any
   authentication operation with any SQRL server that includes TIF bits
   not defined.

   qry
      The query path.  Instructs the client to query the provided server
      object in its next query (if any).  MUST be included in every
      reply.  MUST contain the full path from the root ("/"), and MUST
      NOT contain the scheme, domain name, or port.

   url
      Redirection URL.  MUST be provided in response to any command
      other than "query" when the SQRL client's query includes the
      "opt=cps" parameter.  The server MUST NOT authenticate the current
      web browser sessio, but instead uset his parameter to provide the
      client with a URL taking the user to a page showing the result of
      the authentication.

   sin



Comley & Killian         Expires August 5, 2018                [Page 28]

Internet-Draft                    SQRL                     February 2018


      The Secret INdex.  The server MAY include this parameter to
      request an identity-based, high-entropy, 256-bit indexed secret
      from the client.  The client will hash this value via a secondary
      identity-keyed HMAC256.  Servers MAY request any number of indexed
      secret values.  SHOULD contain a cryptographically-secure degree
      of entropy.

   suk
      Server Unlock Key. When the server receives a successful
      authentication on a PIDK, or when the existing SQRL account is
      disabled, the server MUST provide the SUK to the client so that
      the client may either re-enable the user's account, update the
      user's identity, or remove the user's account entirely.

   ask
      A simple but flexible means for a remote server to gain a response
      from the SQRL client's user.  The value MUST contain the
      base64url-encoded text to display to the user, and MAY contain one
      or two button parameters separated by tildes.  If no buttons are
      specified, a simple "OK" button will be displayed to the user.  A
      button parameter consists of base64url-encoded text to display in
      the button, and MAY be followed by a semicolon delimiting a URL.
      If the user selects a button where a URL is provided, the SQRL
      client will submit the link to its host operating system for
      handling.  All text MUST be UTF-8 encoded to support international
      characters.

   can
      OPTIONAL CANcellation redirection URL.  If "opt=cps" is set but
      the authentication is aborted by the user and this value is
      present, the SQRL client will redirect the pending browser page to
      the URL specified in this parameter.

   The server MAY include additional name=value pairs not defined to
   support extensions to the SQRL protocol.  Any undefined "name="
   parameter SHOULD simply be ignored.

5.3.5.  The Client Value

   The "client=" parameter contains a base64url encoded list of
   name=value pairs, one per line, with each line terminated by a CRLF
   character pair.  The client assembles a list of the name=value pairs
   to return data to the web server, to specify one or more command
   actions it is requesting from the server, and to provide any
   cryptographic keying material required to authorize the requested
   actions and/or authenticate its user's identity.

   ver



Comley & Killian         Expires August 5, 2018                [Page 29]

Internet-Draft                    SQRL                     February 2018


      The client MUST declare the set of supported protocol versions,
      and this declaration MUST be first in the client's argument list.
      See Section 5.3.1.

   cmd
      Specifies the action the client is requesting from the server.
      See Command Tokens.

   opt
      An unordered list of transaction options, separated by tildes.
      See Options.

   btn
      When receiving an "ask" query from the server, the client displays
      the query to the user.  Once the user responds, the client MUST
      include the "btn" parameter with the character "1" or "2"
      depending on which button the user selected.  If the prompt was
      acknowledged without selecting either button, "btn=3" is returned.

   idk
      The IDentity Key. This is the user's SSPK which uniquely
      identifies them to the realm.  See .

   pidk
      The Previous IDentity Key. When a user has rekeyed their identity,
      it must be updated on any server the user has not visited since
      the rekeying.  During one or more queries, the client will present
      the server with the user's current IDK and the previous PIDK along
      with its matching signature.  This process MUST be repeated for
      each PIDK until either the authentication is successful and the
      IDK updated, or until the client runs out of PIDKs, causing the
      authentication to fail.

   suk
      The Server Unlock Key (Paragraph 22).  Included in every query
      where the immediately previous server reply did not have the 0x01
      bit of its TIF flags set.  See Transaction Information Flags
      (TIFs) (Paragraph 3).

   vuk  The Verify Unlock Key (Paragraph 23).  Generated along with and
      always accompanies the SUK.  [Add reference to TIF once that
      section is written]

   ins
      The INdex Secret.  When the immediately previous server reply
      contains a "sin" parameter, the user's SSSK (Section 3.2.4) is
      passed through EnHash (Section 2.3) and used to key a secondary




Comley & Killian         Expires August 5, 2018                [Page 30]

Internet-Draft                    SQRL                     February 2018


      HMAC256 to hash the server's "sin" value.  The output is base64url
      encoded and sent as the value for the "ins" parameter.

   pins
      The Previous INdex Secret.  When the authentication was made using
      a PIDK, the client MUST include the corresponding PINS, calculated
      the same way as the INS, in its query.

   ids
      The IDentity Signature.  Authenticates the contents of the query
      block to the server.  The SSSK is used to sign the concatenated
      values of the client and server prarameters.

   pids
      The Previous IDentity Signature.  Used when authentication was
      made using a PIDK.

   URS
      Unlock Request Signature.  When an account is locked, the server
      sends the SUK to the client, the client's IUK is used to generate
      the unlock request.  The URS is the result of DHKA ( SUK, IUK ).

   The client MAY include additional name=value pairs not defined to
   support extensions to the SQRL protocol.  Any undefined "name="
   parameter SHOULD simply be ignored.

5.3.5.1.  Command Tokens

   query
      Queries are generally initiated after the user verifies the domain
      name and decrypts his identity with his Master Password.  The
      client uses the query to provide the user's IDK and optionally one
      or more PIDKs.  The server response with TIF codes indicating the
      status of the request.

   ident
      A query is usually followed by an ident.  The query allows the
      client to obtain requested information from the server; the ident
      requests that the web server accept the user's identity assertion.

   disable
      Activates the SQRL Identity Lock feature for this server.

   enable
      Re-enables the user's SQRL identity after it has been locked.  The
      client will receive the SUK in a server response so that it can
      generate the Unlock Request Signature necessary to unlock the
      identity.



Comley & Killian         Expires August 5, 2018                [Page 31]

Internet-Draft                    SQRL                     February 2018


   remove
      Instructs the server to immediately remove all trace of this SQRL
      identity from the server.  Different from disable in that it
      allows a change to an unassociated identity.

5.3.5.2.  Options

   noiptest
      Instructs the server to disable same-IP verification.  Results in
      the 0x04 "IPs matched" TIF to be activated even if the IP
      addresses did not match.  Used when the client knows the link was
      received from a remote device (e.g., when a QR code was scanned).

   sqrlonly
      Requests that the server disable any alternative non-SQRL
      autentication methods such as username/password authentication.

   hardlock
      Disables "out of band" changes to the user's SQRL identity such as
      security questions and email resets.

   cps
      Client Provided Session.  Informs the server that the client has a
      secure and private means of returning a server-supplied URL to the
      web browser after successful authentication.

   suk
      Requests that the server return the user's Server Unlock Key so
      that the identity can be unlocked or rekeyed.

5.3.6.  Client Keys

   TODO

5.3.7.  Client Signatures

   TODO

5.3.8.  Composing the Request

   TODO

5.4.  Server to Client Replies

   TODO






Comley & Killian         Expires August 5, 2018                [Page 32]

Internet-Draft                    SQRL                     February 2018


5.4.1.  Required Values

   TODO

5.4.2.  Optional Values

   TODO

5.4.3.  Additional Values

   TODO

5.4.4.  Composing the Reply

   TODO

6.  Client-Server Interactions

   TODO

6.1.  Same Device Authentication

   TODO

6.2.  Cross Device Authentication

   TODO

6.3.  Identity Association

   TODO

6.4.  Updating Identity Association

   TODO

6.5.  Disabling Site Login

   TODO

6.6.  Re-Enabling Site Login

   TODO








Comley & Killian         Expires August 5, 2018                [Page 33]

Internet-Draft                    SQRL                     February 2018


7.  IANA Considerations

   TODO

8.  Security Considerations

   As SQRL aims to protect a single identity that is ultimately used to
   authenticate a user everywhere, the security of this identity is
   paramount.  Further, users must face many of the same security issues
   as with traditional methods of authentication.

   It is important to consider the following attack goals:

   1.  Session hijacking

   2.  Site credential theft

   3.  Association of SQRL identity to site account

   4.  Master key theft

   5.  Breaking of pseudonymous nature of SQRL authentication
       (association of SQRL identities on various sites)

8.1.  Phishing

   One well-known attack mode is where the user is invited to click on a
   link appearing to go to a legitimate site, but is in reality directed
   to an attacker's server.

   One common method of this is a look-alike link.  For example, a user
   believing he is going to example.com is in reality going to
   examp1e.com (the lowercase "l" is replaced with a numeral "1").  A
   historical example is "tvvitter.com" (the letter "v" twice instead of
   a "w").

   Another method is to use a malformed URL to misdirect a user.  For
   example, this link:

   https://www.amazon.com@%67%72%63.%63%6f%6d/

   at first glance appears to be a link to Amazon, but in reality takes
   the user to grc.com.  In a real-world attack, the attacker would
   substitute the name of his phishing site and most users might be
   fooled entirely.

   Another technique known as "Punycode" exploits the display of UTF-8
   characters to hide the true ASCII text of the domain name.  For



Comley & Killian         Expires August 5, 2018                [Page 34]

Internet-Draft                    SQRL                     February 2018


   example, it might substitute Cyrillic characters (e.g., U+430 which
   looks similar or identical to the ASCII "a", U+0061), or it may use
   the ASCII equivalent of the bytes making up the unicode string (e.g.,
   a domain appearing as "apple.com" is really "xn-80ak6aa92e.com").
   Browsers may even show the bogus domain in the address bar, giving
   the user no opportunity to realize they are being fooled.  For more
   information, see Xudong Zheng, "Phishing with Unicode Domains."
   [Zheng]

   The phishing site is generally set up to look and work exactly the
   way the real site works, at least up until the point where the
   attacker has stolen the desired data.

   Phishing attacks where the goal is to obtain authentication
   credentials are entirely foiled by SQRL.  Since SQRL uses the domain
   name as the basis for authentication, it will create completely
   different identity keys.  The IDK the attacker gets will be a public
   key specifically for his attack site, useless to him for obtaining
   access to the real site.

   However, the attacker may have other goals.  If the attacker can
   successfully mimic a banking or e-commerce site, the user could be
   tricked into entering account data such as a credit card number.
   SQRL clients MUST display the real domain name to the user in a font
   with unambiguous glyphs before any authentication occurs, giving them
   the opportunity to realize they are being fooled.

   Many phishing attacks are pass-through attacks, where the phishing
   site acts as an active Man-In-The-Middle.  It obtains the genuine
   page from the real site and passes it along to the user, receiving
   the user's responses and passing them back to the site.  In the case
   of same-device authentication (Section 6.1), the client will be
   warned of an IP mismatch, and CPS will redirect the browser to a safe
   page on the real site.  No such protections exist for cross-device
   authentication (Section 6.2), but this is generally used in the case
   of untrusted devices where the user will probably be typing in the
   domain name manually.

   The attacker can get around SQRL's protections with DNS spoofing,
   where the device's DNS addresses are altered, entries are added to
   the hosts file, or otherwise made to redirect a host name to an
   incorrect address, generally the phishing site controlled by the
   attacker.  In such a case, SQRL would be fooled (as would anything
   else on the compromised device).

   However, cross-device authentication would foil this, as the user
   would be using a smartphone or other trusted device that would be
   doing its own DNS lookup.  Local authentication should take place



Comley & Killian         Expires August 5, 2018                [Page 35]

Internet-Draft                    SQRL                     February 2018


   only on trusted devices.  DNS could only be spoofed on these devices
   using malware, but malware can compromise any security feature.

   A SQRL client MAY employ an additional protection from such an attack
   in the form of an internal DNS resolver, bypassing the attacker's
   spoofing.  However, such a feature may not be desired on enterprise
   networks running their own internal DNS systems, so the SQRL client
   MUST give the user a configuration option to disable the internal
   resolver and use the OS resolver as per normal.

8.2.  Shoulder-Surfing

   In the context of SQRL, the danger is of an attacker scanning the QR
   code of a SQRL-enabled website.  With good timing, the attacker could
   fool the user into thinking he's logged in as himself when in reality
   he's authenticated to an account controlled by the attacker.  The
   attacker could then get anything the user enters into that web site,
   including credit card numbers and other sensitive information.

   Shoulder-surfing is when an attacker reads or scans the display,
   keyboard, and other components of the target's device directly,
   allowing the attacker to see sensitive information, including
   information entered into forms.

   However, in such a case the user's authentication would fail as the
   nut is no longer valid.  The SQRL client MUST deliver an error
   message to the user saying that the authentication has failed, and
   SHOULD advise the user of the dangers of continuing to use the web
   site, especially if the authentication has the appearance of having
   worked.

   Care should be taken when authenticating to a website in a public
   area, or any other place where others could see the QR code or watch
   the user type the Master Password on the keyboard.  Keep in mind that
   these can be picked up using binoculars or seen on a CCTV camera.

   It is absolutely crucial that a new SQRL identity NOT be created, and
   an existing one NOT be rekeyed, in such an area.  Anyone who can
   resolve the screen and keyboard can get the Master Password, the full
   identity backup, AND the Rescue Code.

8.3.  Evil Router

   In this context, the router in consideration is the one connecting
   the user's LAN segment to the rest of the Internet.  Home routers
   have been shown to be lacking in security, and even a well-supported
   router must be updated when new firmware versions are released,
   something most users aren't aware of.



Comley & Killian         Expires August 5, 2018                [Page 36]

Internet-Draft                    SQRL                     February 2018


   It is also increasingly the case that users connect to Wi-Fi hotspots
   when travelling, relying on routers whose security they could not
   evaluate even if they knew to.  Moreover, an attacker on the LAN
   segment could engage in ARP spoofing to make the attacker's own
   device the default gateway for the segment, forwarding the packets on
   to the true router but establishing himself as a Man-In-The-Middle.

   Once an attacker gains control of the default gateway, he could
   engage in phishing and DNS spoofing attacks as described above.  More
   significantly, he could insert himself into the TLS handshake and
   commit any number of attacks designed to compromise the security of
   TLS.

   SQRL provides no means of defending the user against such an attack,
   however, at most the attacker will gain access to the specific login
   sessions the user makes while at that location.

8.4.  Server Compromise

   A server compromise can result in sensitive user data being obtained
   by the attacker without the user even logging in.

   In the case of SQRL there is less critical data for the attacker to
   get.  There are no passwords or other secrets sent to the server that
   have to be hashed and protected.  The attacker can only get the IDK,
   SUK, and VUK, which are useless to him.

   If the attacker obtained write access, he could conceivably generate
   a new SUK and VUK based on his own IUK and take control of the
   account via the Identity Lock protocol.  However, if the attacker
   already has write access there would be little more to gain by doing
   so in most situations.

   If the attacker has gained access to more than one site, the IDK
   would be different, meaning that the attacker could not correlate
   user data between websites (unless, of course, there was other
   identifying information in common such as an email address).

   All the same, once authenticated the user is subject to all of the
   harms that can occur regardless of the form of authentication.

8.5.  CPU Flooding

   CPU flooding is where the attacker is able to cause one or more
   processes to run that take up significant CPU time.  It also can
   happen absent a malicious attack, when a normal CPU-intensive process
   starts running in the background.




Comley & Killian         Expires August 5, 2018                [Page 37]

Internet-Draft                    SQRL                     February 2018


   With SQRL, this can be a vulnerability when running EnScrypt
   (Section 2.4) in Timer Mode.  After 5 seconds (by default), the timer
   runs out, and the resulting key is used to encrypt the identity and
   the number of iterations recorded.  If another process utilizes
   significant CPU clocks during this process, the total number of
   iterations will be lower than it would have, meaning that the Master
   Password has weaker protection against cracking.

8.6.  Evil Client

   An evil client is a maliciously-developed SQRL client.  It may take
   the form of its own client, or it may mimic an existing and trusted
   SQRL client.  It may enter the user's computer in the form of
   malware, hijacking the sqrl:// protocol as a new handler and
   attaching itself to the localhost:25519 port.  If artfully done, the
   user would have no clue that a substitution has been made.

   The consequences cannot be overstated.  The evil client would be able
   to gain the unencrypted IMK on its very first use, allowing the
   attacker to be able to hijack ANY account on ANY website where the
   user has authenticated using SQRL.

   Moreover, it could keep track of everywhere the user logs in and send
   to the attacker all of the user's accounts on banking, e-commerce,
   and other important websites.  And although a user can rekey his
   identity, he would first have to understand that his identity has
   been compromised.

   The absolute worst case scenario would be when a user uses an evil
   client to create or rekey his identity, which would give the attacker
   access to even the Rescue Code.  All other possible security concerns
   pale to this.

   SQRL mitigates this possibility by requiring (and advising) only that
   the user place his SQRL identity on trusted devices, using cross-
   device authentication on all other devices.  However, this only
   limits the attack surface.  In the past, fake versions of Firefox and
   other web browsers, fake Bitcoin wallets, and numerous others have
   been downloaded by users and even placed inside the trusted app
   stores for Android and iOS.  A malicious SQRL app, sadly, is not out
   of the question.

   This issue can be somewhat mitigated by requiring that SQRL apps be
   certified by trusted authorities.  The reference implementation from
   GRC not only checks the certificate on every update, but checks the
   fingerprint on the DigiCert root certificate as well to help ensure
   that there was no improper substitution.  However, the ultimate
   protection can only come from complete SQRL integration into web



Comley & Killian         Expires August 5, 2018                [Page 38]

Internet-Draft                    SQRL                     February 2018


   browsers and operating systems, which will refuse to let any other
   software hijack the sqrl:// protocol and eliminate the need for a
   localhost connection on port 25519.

9.  References

9.1.  Normative References

   [FIPS.180-4.2015]
              National Institute of Standards and Technology, "Secure
              Hash Standard", August 2015.

   [NIST.800-38D]
              Dworkin, M., "NIST Special Publication 800-38D:
              Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC.", November 2007.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
              editor.org/info/rfc2104>.

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

   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
              Specification Version 2.0", RFC 2898,
              DOI 10.17487/RFC2898, September 2000, <https://www.rfc-
              editor.org/info/rfc2898>.

   [RFC3548]  Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003,
              <https://www.rfc-editor.org/info/rfc3548>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC7914]  Percival, C. and S. Josefsson, "The scrypt Password-Based
              Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
              August 2016, <https://www.rfc-editor.org/info/rfc7914>.







Comley & Killian         Expires August 5, 2018                [Page 39]

Internet-Draft                    SQRL                     February 2018


   [RFC8031]  Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
              Internet Key Exchange Protocol Version 2 (IKEv2) Key
              Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
              <https://www.rfc-editor.org/info/rfc8031>.

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

9.2.  Informative References

   [Klyubin]  Klyubin, A., "Some SecureRandom Thoughts", August 2013,
              <https://android-developers.googleblog.com/2013/08/some-
              securerandom-thoughts.html>.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868,
              DOI 10.17487/RFC4868, May 2007, <https://www.rfc-
              editor.org/info/rfc4868>.

   [Shamir]   Shamir, A., "How to share a secret",
              DOI 10.1145/359168.359176, November 1979.

   [Zheng]    Zheng, X., "Phishing with Unicode Domains", April 2017,
              <https://www.xudongz.com/blog/2017/idn-phishing/>.

Appendix A.  Recommendations and Best Practices

A.1.  Logo

   For ease of user understanding and recognition, a SQRL logo has been
   designed and released into the public domain.  Clients SHOULD use
   this as the program logo, and servers SHOULD use this for the
   clickable link.  The standard colors are a white SQRL figure against
   a background color of #007CC3 (CMYK: 100/20/0/0).  Clients and
   servers MAY recolor the logo to suit the look of themes and skins.
   <https://www.grc.com/sqrl/logo.htm>

A.2.  Font

   Museo Slab MAY be used by client and server developers desiring a
   consistent look across disparate SQRL implementations.
   <https://www.exljbris.com/museoslab.html>







Comley & Killian         Expires August 5, 2018                [Page 40]

Internet-Draft                    SQRL                     February 2018


A.3.  For Clients

   TODO

A.4.  For Servers

   TODO

A.5.  For Users

   Disclaimer: None of this is intended to be any sort of legal advice,
   or indeed any guarantee that problems involving SQRL clients and
   identities will be minimized.  They are designed to apply to most
   SQRL users in most situations most of the time.  It should be up to
   each individual's discretion to determine whether or not particular
   recommendations make sense to their situation.

A.5.1.  Master Password

   Traditionally, security experts have advised having unique passwords
   for every resource.  The reason why is so that one resource being
   compromised will not threaten others.  However, in the case of a
   single SQRL identity copied to multiple devices, a compromise of any
   of these identities would give an attacker full access to all SQRL-
   enabled logins, so the user gains nothing from protecting their SQRL
   identity on different devices with different passwords.  But when
   users are asked to create different passwords, they generally pick
   weaker, formulaic passwords that are easier to remember.

   For this reason, it makes sense to have a single strong password
   protecting all copies of the user's SQRL identity.

A.5.2.  Identity Backup

   It is crucial that the user not lose his or her identity, as that
   would lock them out of any and all needed resources.  Keeping a
   secure backup is essential.

   SQRL clients generally do not distinguish between exporting and
   backing up an identity, whether done by file, QR code, or text.  But
   conceptually, exporting an identity is done with the intent to import
   it into another client in a timely manner.  Therefore, exporting
   generally includes the identity encrypted with the Master Password.

   Backups, on the other hand, are intended for longer-term storage.
   The encryption on them therefore needs to be more secure than perhaps
   will be the case with the user's Master Password, which may be
   forgotten in the interim anyway.  Therefore, when making a backup of



Comley & Killian         Expires August 5, 2018                [Page 41]

Internet-Draft                    SQRL                     February 2018


   an identity, it should be made without the Master Password,
   containing only a copy of the encrypted IUK from which the identity
   can be regenerated.  The user would therefore need the Rescue Code to
   restore the backup.

   Note that text backup MUST NOT be exported with the Master Password.

A.5.3.  Disaster Recovery

   A user putting together his or her Last Will and Testament will want
   the executor(s) of their estate to be able to easily access all
   important assets.  Since probate attorneys consider the security of
   all of this information to be paramount, it is recommended that they
   be given a hard copy of the SQRL client, exported without password,
   using the "data entry" method.  The Rescue Code must also be
   included.  The information must be updated whenever the user creates
   a new SQRL identity or rekeys an existing one.

   If the use of a probate attorney isn't desirable (e.g., the user
   lives in a country with no recognition of attorney-client privilege),
   SQRL's "data entry" export and the associated Rescue Code could be
   distributed through the person's heirs via Shamir's Secret Sharing.
   [Shamir]

Appendix B.  The Optional ShortPass Feature

   TODO

Appendix C.  Harvesting Entropy

   Secure cryptographic systems depend on the ability to create quality
   random numbers, and SQRL is no different in this regard.  SQRL's
   needs are meager compared to many other functions and protocols, but
   critical.

   The use of a pseudo-random function to generate random numbers is
   only as good as the entropy it is seeded with.  As RFC4086 points
   out, a hacker may find it easier to reproduce the environment a PRF
   was running in when it produced the secret quantities than to make
   blind guesses through the search space.  [RFC4086]

   Optimally, the numbers used for seeding cryptographic functions such
   as Curve25519 should be truly random, but what constitutes "truly
   random" is regarded as much philosophy as computer science.  However,
   a good working definition of "truly random" is one where the amount
   of entropy in a number is equal to its length; e.g., a 256-bit number
   that contains 256 bits of entropy.




Comley & Killian         Expires August 5, 2018                [Page 42]

Internet-Draft                    SQRL                     February 2018


   Unfortunately, determining the amount of entropy in an information
   stream is tricky at best.  But entropy is never reduced as more
   information is added; even weak sources of entropy, when added
   together, can produce sufficient entropy.  For that reason, none of
   the data collected during entropy harvesting should be discarded.

   The method recommended by SQRL is to harvest as much entropy as
   possible from as many uncorrelated sources as possible in the time
   available, and run the data stream through SHA-256 or SHA-512,
   depending on how much randomness is needed.  The Secure Hashing
   Algorithm should change half the bits of the output when just a
   single bit of the input is changed, so the entropy should be
   preserved up to the length of the resulting hash.  The technique,
   then, is to hash an amount of data where the entropy content almost
   certainly far exceeds 256 or 512 bits.  These amounts are fairly
   trivial.

   For more about entropy harvesting, see RFC4086.

C.1.  Entropy Sources

   Sources of entropy vary greatly depending on the hardware, operating
   system, and other aspects of the client device.

C.1.1.  Operating System

   All operating systems have a source of randomness available (e.g.,
   /dev/random on UNIX-like systems), but developers should think twice
   before relying solely on these.  Flaws and backdoors could result in
   a false sense of security.  For example, in 2013 a flaw in Android's
   SecureRandom function made Bitcoin wallets generated on those devices
   vulnerable to remote hacking and the theft of funds, even without
   access to the device.[Klyubin]

   Developers should also be advised that many of these use some of the
   same techniques described below, meaning that utilizing the same
   technique might not result in as much entropy as estimated.

C.1.2.  Hardware

   Hardware sources can be very effective at harvesting entropy, but
   care must be taken to make sure that they exist on a particular
   implementation, and that the hardware hasn't failed in some way.

   The system clock has traditionally been used as a source of
   randomness, although it must be considered that users are more likely
   to generate the random numbers at some times of the day than others.
   Subseconds provide the greatest entropy here.



Comley & Killian         Expires August 5, 2018                [Page 43]

Internet-Draft                    SQRL                     February 2018


   Some systems come with embedded hardware that produce noise
   specifically for the purpose of seeding PRFs.

   Wireless networking devices can be polled for signal strength and
   other data.

   Processor statistics can be a significant source, such as cache hits/
   misses and other low-level system counters, voltage, fan speed, and
   thermal data.

   Sound from a microphone could be a source of high-quality entropy in
   a typical room with air conditioning, fans, and other source of
   noise, as well as interference on the sound channel.  In such a case,
   a fraction of a second--less than two hundredths--would be
   sufficient, but as there is no guarantee longer periods should be
   considered.

   One or two frames from a camera can likewise be a source of high-
   entropy noise because of the sensor, which is especially the case if
   the SQRL client can set the camera's ISO to a high number.  Most cell
   phones in particular have cameras that generate sufficient noise in
   the low-order bits.  A single 640x480 frame would likely be
   sufficient for SQRL's purposes, although higher resolutions tend to
   be noisier.  Care must be taken to ensure the client is getting the
   raw camera data, not compressed data which may have much of the noise
   removed.

   Free bytes of memory and storage space can vary quite a bit, adding a
   not insignificant amount of entropy.

   Network statistics, such as packet arrival time, can be effective,
   but only if it can be ensured that these are not subject to
   manipulation.

C.1.3.  User

   The user can provide a good measure of entropy, either directly by
   the client engaging the user, or indirectly.

   Examining mouse movements or keyboard strokes can be a source of
   entropy, although how much is a matter of some debate.

   Accelerometer data on cell phones and other such devices can pick up
   minute movements of the user's hand, even if the user is trying to
   hold it steady.






Comley & Killian         Expires August 5, 2018                [Page 44]

Internet-Draft                    SQRL                     February 2018


Authors' Addresses

   Adam Comley

   Email: adam@novators.net


   Shane D. Killian

   Email: shane@shanekillian.org









































Comley & Killian         Expires August 5, 2018                [Page 45]