Complete.Org: Mailing Lists: Archives: gopher: October 2002:
[gopher] Authentication
Home

[gopher] Authentication

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Authentication
From: Timm Murray <hardburn@xxxxxxxxxx>
Date: Thu, 10 Oct 2002 22:13:59 -0500
Reply-to: gopher@xxxxxxxxxxxx

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The document below is a generic means of authenticating using Gopher+ ASK 
fields.  I've built it to be the first half of an overall Gopher upload 
means, but it could be used for downloading, too. It breaks the "smart 
server, dumb client" tradition, but I think it is necessary in this case, 
unless you don't care about sending passwords in plaintext.


Gopher+ SRP Authentication

By Timm Murray

This document provides a secure means of authentication using 
the Secure Remote Password (SRP) scheme.  This scheme is documented 
in RFC 2945.  Implementors should be familer with that RFC.

In breaking with Gopher tradition, this document uses '\t' to denote a 
tab, '\r' to denote a cariage return, and '\n' to denote a newline.  
'C:' is a line of text sent by the client, and 'S: is a line sent by the 
server.  Calculations by one side or the other are contained in '[' ']' 
brackets, with a note specifiying who is doing the calculations.  Any 
numbers sent should be Base16 encoded [0-9A-Fa-f].

'|' indicates string cancatanation.  '^' is exponentation.  '%' is integer 
remainder. '==' checks for equivilence, while '!=' checks for unequivilence.  
SHA1() does an SHA-1 hash on the data.  SHA1_Interleave() is a special 
function that doubles the normal length of the SHA-1 hash, and is described 
in RFC 2945.

The means of storing username/password/salt values is also described in 
RFC 2945.  In short:

u = stored username
v = stored password verifier
s = salt value

At the beginning of the connection, the server sends a "HashType" field.  
This is a string specifying the type of cryptgraphic hash to use.  Where 
the protocol specifies "SHA1()" in calculations, the client and server MUST 
replace it with the proper hash type.  "SHA1_Interleave()" is also modified 
accordingly.  At a bare minimum, the clients and servers MUST implement the 
following:

Name        Referance
- ----        ---------
SHA-1      RFC 3174
MD5         RFC 1321

Authentication works as follows:

C: <sends selector string>\r\n
S: +ASK \r\n
[Server:
        selects values for g and N
]
S: Ask: Username? \t g \t N \t HashType\r\n
[Client: 
        if unrecoginized HashType, then send "Unknown Hash" and cut connection
        a = random()
        A = g^a % N
]
C: U \t A \r\n
[Server:
        if A % N == 0, then cut the connection.
        v = <stored password verifier>
        b = random()
        B = (u + g^b) % N
        s = salt stored for username
]
S: Ask: What is M? \t s \t B \r\n
[Client:
        if B % N == 0, then cut the connection. 
        p = <raw password>
        x = SHA(s | SHA(U | ':' | p))
        S = (B - g^x)^(a + u * x) % N
        K = SHA1_Interleave(S)
        M = SHA1(SHA1(N) XOR SHA1(g) | SHA1(U) | S | A | B | K)
]
[Server: 
        S = (A * v^u)^b % N
        K = SHA1_Interleave(S)
]
C: M \r\n
[Server: 
        J = SHA1(SHA1(N) XOR SHA1(g) | SHA1(U) | S | A | B | K)
        if J != M, then cut the connection.
        L = SHA1(A | M | K)
]
[Client: 
        I = SHA1(A | M | K)
]
S: Choose: L \t OK \t Wrong
[Client: 
        if L != I, then cut the connection
]
C: OK

The server now proceeds with normal operation on the selector 
string.


- -- 
Evidance exists that X is only the second worst windowing system in the world.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj2mQf4ACgkQqpueKcacfLQEewCgpAWo8CxaEPU7I0TWM+AbQCtz
09IAni/TV3eDY1m6Frx4Se0EbGCHdqvv
=I+hZ
-----END PGP SIGNATURE-----



[Prev in Thread] Current Thread [Next in Thread]