[Top] [Prev] [Next]

login, getauthinfo - get an Authinfo adt from a certificate authority

include "keyring.m";

include "security.m";
lg:= load Login Login->PATH;
login:       fn(id, password, dest: string):
                   (string, ref Keyring->Authinfo);
getauthinfo: fn(ctxt: ref Draw->Context, keyname, path:
                    string): ref Keyring->Authinfo;



 Description


The login module provides routines to communicate with a Certifying Authority (CA) in order to create a Keyring->Authinfo adt. It does this assuming a password has already been established between the user and the CA. 


The password is used by the encrypted key exchange protocol described in this section to establish a secure channel between the user and CA. The description uses the following notation:  





ivec



an 8 - byte random number chosen for this conversation




sha



the 20 - byte secure hash (SHA-1) of the password




key



an 8 - byte secret formed as follows:





key[0] = ivec[0]^sha[0]^sha[8]^sha[16]   


key[1] = ivec[1]^sha[1]^sha[9]^sha[17] 


...   


key[5] = ivec[5]^sha[5]^sha[13];   


key[6] = ivec[6]^sha[6]^sha[14];   


key[7] = ivec[7]^sha[7]^sha[15]; 




alpha



a Diffie-Hellman base used system wide




p



a Diffie-Hellman modulus used system wide 




key (m)



m encrypted using the RC4 algorithm with key




Rx



a random number of the same order as p.




secret



the Diffie-Hellman secret alpha**(r0*r1) mod p


















In the following protocol, the notation user --> CA xxx means that a user sends the message xxx to the certifying authority (CA). At any point in the exchange, either party can send an error instead of a message to terminate the protocol.


user --> CA  name   
CA --> user  ACK
     
user --> CA  ivec   
CA --> user  key(alpha**r0 mod p), alpha, p

user --> CA  alpha**r1 mod p
CA --> user  CA's public key, SHA(CA's public key + secret)

user --> CA  user's public key, SHA(user's public key + secret)
CA --> user  user's public key certificate



The complexity of this protocol is intended to shield the password. To start a clear text attack against the password, one needs to first attack the Diffie-Hellman exponential to determine alpha**r0 mod p. 


The values alpha and p are sent unprotected, though the user code does a few sanity checks on the values it receives. 


The role of ivec is to foil any replay attacks by someone spoofing the CA. 



 login (id, password, dest) 


The login function is used to get a signed certificate from the certifying authority, CA, using the protocol described in login, getauthinfo - get an Authinfo adt from a certificate authority in Chapter  9. The dest parameter is the network address of the CA. The user, id, must have previously received the password from the CA for this to work.


If login fails, the string returned will be an error message. If it succeeds, the string will be the nil value and an Authinfo abstract data type is returned. This adt can be used with the auth function (see auth, readauthinfo, writeauthinfo - authenticate a connection) to authenticate future connections.



 getauthinfo (ctxt, keyname, path)


The getauthinfo function is a Tk user interface to login. It will first try to read the file, path, for the Authinfo adt (see the description of the readauthfinfo function on auth, readauthinfo, writeauthinfo - authenticate a connection). If path is nil, it is set to /usr/$user/keyring/keyname. If the read succeeds, then that adt is returned.   If it fails, a Tk window will be opened to allow the user to enter an id, password, and the network address of the certificate authority to use. The default CA is the $SIGNER listed in the file /services/cs/db.


If requested by the checkbox in the interface, getauthinfo will save the adt in the file, path. This allows the Authinfo to be kept across re-boots. If the box is not checked, getauthinfo will use the system file2chan function (see file2chan - create file connected to Limbo channel in Chapter  8) to create a temporary file, path, that will disappear if unmounted, or when the system is re-booted.


The login protocol uses TCP port 6673 with the symbolic name inflogin.



 See Also 





auth, readauthinfo, writeauthinfo - authenticate a connection 




file2chan - create file connected to Limbo channel in Chapter  8


















 
[Top] [Prev] [Next] 








infernosupport@lucent.com



Copyright © 1996,Lucent Technologies, Inc.   All rights
reserved.