0k                                                             J. Miller
                                                  The Jabber.org Project
                                                           July 25, 2000


                 zero-knowledge auth system for Jabber


Abstract

   This is a proposal to accelerate a new authentication option to
   strengthen the security on the wire and remove the liability of
   storing passwords on the server. It is based on a typical
   zero-knowledge auth process. 

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Description  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.1 Server Reqts . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.2 Client Reqts . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.4 Reset  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3




























Miller                                                          [Page 1]

zeroknowledge    zero-knowledge auth system for Jabber         July 2000


1. Introduction

   zero-knowledge implies an authentication system where the
   credentials are never stored on the server or transferred over the
   wire, but the server is still able to validate the credentials of
   the client.

2. Description

2.1 Server Reqts

   The server must store three peices of data: token, hash, sequence#

2.2 Client Reqts

   The client needs the original user password

2.3 Authentication

   For the figurative server data: "garbagerandom",
   21e89932a96ec55d96aecf9975, 462

   Client performs a digest(password) resulting in hashA, and retrieves
   the token and sequence# from the server. The client then performs
   another digest(hashA + token) resulting in hash0, and then performs
   461 recursive digest calls resulting in hash461. The client then
   sends hash461 to the server. 

   The server receives hash461 from the client, and performs an
   additional hash to result in hash462, and compares it to the stored
   hash for that sequence#. If they match, store the hash461 from the
   client as the new hash and reduce the sequence#. 

2.4 Reset

   If the sequence# reaches 0, authentication can no longer occur and a
   reset is required. A Reset is when the server is given the base hash
   (hash0 above) and a new unique token, so that it can perform X
   recursive digests and store the result as the hash and the number of
   times as the sequence.

   The authentication is secure, but the reset is not, if the reset
   happens over an insecure transport layer then the authentication can
   be falsified based on the data snooped from the reset.

   The server could perform a very large number of digests, to reduce
   the time between the required resets.

   If the user already utilizes an existing system, such as https for


Miller                                                          [Page 2]

zeroknowledge    zero-knowledge auth system for Jabber         July 2000


   account maintainence or ssh for system access, the reset could
   happen on the server side when those methods are used, so that
   resets securely happen transparently to the user.

3. Protocol

   <iq type="get" id="100001">
      <query xmlns="jabber:iq:auth">
        <username>hamlet</username>
      </query>
    </iq>
   <iq type="result" id="100001">
      <query xmlns="jabber:iq:auth">
        <password/>
        <digest>526090b1ce912c88bd8</digest>
        <token>garbagerandom</token>
        <sequence>461</sequence>
      </query>
    </iq>

   This example shows a server that supports plaintext, simple sha1
   digest, or zero-knowledge authentication methods. Typically a server
   is only going to support one of the three. The username is sent in
   the get to identify to the server which account it should return the
   auth requirements from. The client then returns the hash for the
   zero-knowledge method. 

   <iq type="set" id="100002">
      <query xmlns="jabber:iq:auth">
        <username>hamlet</username>
        <hash>hash461</hash>
        <resource>Castle</resource>
      </query>
    </iq>
   <iq type="result" id="100002"/>
















Miller                                                          [Page 3]