$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