$Id: iauth.txt,v 1.1.1.1 2002/08/14 05:57:37 strtok Exp $ Patrick Alken 01/09/2000 Ircd Authentication ==== ============== 1. Introduction This document describes the protocol used for the IAuth server. IAuth performs authorization checks for all clients that connect to the ircd server. 2. Protocol Ircd and IAuth communicate through a TCP/IP connection. The Ircd server will always initiate the connection to the IAuth server. 2.1 Server When an Ircd server first connects to an IAuth server, it will send IAuth a string of the form: Server - Ircd server name This is used for identification purposes in case more than one Ircd server is using an IAuth server. 2.2 Class 2.2.1 Class Add When an Ircd server first connects to an IAuth server, it will send IAuth it's class list in the form: Class Add - Class number - Maximum number of clients in this class This is needed for the I-line check, in case the number of clients allowed to use a certain I-line is limited. 2.2.2 Class Clear Upon a rehash, the Ircd server will send I-line a string of the form: Class Clear [number] [number] - optional number In case the Ircd server's Y: lines were changed prior to the rehash, IAuth will clear it's old class list to make room for the new one Ircd will send after the rehash (via Class Add). 2.3 DoAuth When a client connects to the Ircd server, Ircd will send a string of the form: DoAuth [password] - A unique ID used to identify each client - Client's nickname - Client's username - Client's hostname - Client's IP Address in unsigned int format [password] - *Optional* Client password The DoAuth directive will initiate an authorization check on the client. The following checks are performed. 2.3.1 I-line Check This check will ensure that the client matches a valid I-line (as given in iauth.conf). If the client fails this check, he/she will not be allowed to remain connected to the Ircd server. The actual reason they failed authorization will be told to them. (See the BadAuth directive). See the section on iauth.conf for more information on I-lines. 2.3.2 Server Ban Check K-lines are server-wide bans for individual (or groups of) clients. If a client matches a K-line, they will be disconnected from the Ircd server with the reason they are banned. The only exception to this is if they have an exemption flag in their I-line. See the iauth.conf section for more details on this. 2.3.3 Quarantine Check Q-lines specify nicknames which are not allowed to be used on the Ircd server. If a client's nickname matches that of a Q-lined nickname, they will be informed they have selected a quarantined nickname and be disconnected from the server. 2.4 DoneAuth If a client passes all of the above checks, they will pass authorization and be allowed to continue their connection to the Ircd server. IAuth will send a string back to the Ircd server of the form: DoneAuth - Client's unique ID - Client's username - Client's hostname (may be different from original if they are allowed a spoof) - Client's I-line class This will inform the Ircd server that the specified client is authorized to connect. 2.5 BadAuth If a client fails any of the above checks, IAuth will send a string to the Ircd server of the form: BadAuth : - Client's unique ID - Reason client failed authorization The Ircd server will then send an error back to the client containing and disconnect them. 3. Configuration file (iauth.conf) IAuth reads a configuration file upon startup. The name of the file is located in setup.h, under #define CONFFILE. The format of this file is identical to that of ircd.conf, except it supports less directives. 3.1 I-lines (Server Access) I-lines allow clients access to the Ircd server and are of the form: I::[password]:[flags][user@]:: - Hostname to give client if SPOOF_FREEFORM is defined. [password] - *Optional* password that clients will be required to supply to gain access. [flags] - *Optional* flags (see below) [user] - *Optional* username (if not given, defaults to "*") - Client's hostname - I-line class (see section Class Add) Possible values to go in the [flags] section are: = - Spoof their IP Address (requires #define SPOOF_FREEFORM) ! - Limit 1 client per IP Address - - Do not give them a tilde (~) character if they are not running identd + - Do not allow them to connect if they are not running identd ^ - Client is exempt from K/G lines > - Client is also exempt from connection limits 3.2 K-lines (Server Bans) K-lines specify clients who are banned from the Ircd server and are of the form: K:@: - Client's username - Client's hostname - Reason client is banned 3.3 Q-lines (Quarantined Nicknames) Q-lines specify illegal nicknames. A client that attempts to use a quarantined nickname will be exited from the Ircd server. Q-lines are of the form: Q:::[[username@]hostname]] - Quarantined nickname - Reason nickname is quarantined [username] - *Optional* exempted username [hostname] - *Optional* exempted hostname Examples: Q:dcc*:Dcc bots not allowed Q:GoodOper:GoodOper may use this nick:goodoper@oper.irc.server.com 3.4 P-lines (Ports) P-lines specify ports on which the IAuth server will listen for incoming Ircd server connections. They are of the form: P: - Port number