-$Id: iauth.txt,v 1.1 2001-05-01 11:38:34 isomer Exp $
-
-Patrick Alken <wnder@underworld.net>
-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 <name>
-
- <name> - 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 <number> <maxlinks>
-
- <number> - Class number
- <maxlinks> - 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 <id> <nickname> <username> <hostname> <IP> [password]
-
- <id> - A unique ID used to identify each client
- <nickname> - Client's nickname
- <username> - Client's username
- <hostname> - Client's hostname
- <IP> - 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 <id> <username> <hostname> <class>
-
- <id> - Client's unique ID
- <username> - Client's username
- <hostname> - Client's hostname (may be different from original
- if they are allowed a spoof)
- <class> - 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 <id> :<reason>
-
- <id> - Client's unique ID
- <reason> - Reason client failed authorization
-
- The Ircd server will then send an error back to the client
-containing <reason> 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:<spoofhost>:[password]:[flags][user@]<host>::<class>
-
- <spoofhost> - 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 "*")
- <host> - Client's hostname
- <class> - 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:<username>@<hostname>:<reason>
-
- <username> - Client's username
- <hostname> - Client's hostname
- <reason> - 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:<nickname>:<reason>:[[username@]hostname]]
-
- <nickname> - Quarantined nickname
- <reason> - 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:<portnum>
-
- <portnum> - Port number