2.3 Communication in the Network .............................. 6
2.4 Channel Communication ..................................... 7
2.5 Router Connections ........................................ 7
+ 2.6 Backup Routers ............................................ XX
3 SILC Specification ............................................ 8
3.1 Client .................................................... 8
3.1.1 Client ID ........................................... 9
3.10 Algorithms ............................................... 20
3.10.1 Ciphers ............................................ 20
3.10.2 Public Key Algorithms .............................. 21
- 3.10.3 MAC Algorithms ..................................... 21
- 3.10.4 Compression Algorithms ............................. 22
+ 3.10.3 Hash Functions ..................................... XXX
+ 3.10.4 MAC Algorithms ..................................... XXX
+ 3.10.5 Compression Algorithms ............................. XXX
3.11 SILC Public Key .......................................... 22
3.12 SILC Version Detection ................................... 24
4 SILC Procedures ............................................... 25
This, on the other hand, leads to cellular like network, where routers
are in the center of the cell and servers are connected to the router.
-Following diagram represents SILC network topology.
+The following diagram represents SILC network topology.
its local server first to the router of the cell, and from the router
to the other server in the cell.
-Following diagram represents this scenario:
+The following diagram represents this scenario:
.in 25
the message is routed to the router server to which the destination
server belongs, if the local router is connected to destination router.
If there is no direct connection to the destination router, the local
-router routes the message to its primary route. Following diagram
+router routes the message to its primary route. The following diagram
represents message sending between cells.
distributed by SILC broadcast packets.
+.ti 0
+2.6 Backup Routers
+
+Backup routers may exist in the cell in addition of the primary router.
+However, they must not be active routers and act as routers in the cell.
+Only one router may be acting as primary router in the cell. In the case
+of failure of the primary router may one of the backup routers become
+active. The purpose of backup routers are in case of failure of the
+primary router to maintain working connections inside the cell and outside
+the cell and to avoid netsplits.
+
+Backup routers are normal servers in the cell that are prepared to take
+over the tasks of primary router if needed. They need to have at least
+one direct and active connection to the primary router of the cell.
+This communication channel is used to send the router information to
+the backup router. Backup router must know everything that the primary
+router knows to be able to take over the tasks of the primary router.
+It is the primary router's responsibility to feed the data to the backup
+router. If the backup router does not know all the data in the case of
+failure some connections may be lost. The primary router of the cell
+must consider the backup router being normal router server and feed the
+data accordingly.
+
+In addition of having direct connection to the primary router of the
+cell the backup router must also have connection to the same router
+the primary router of the cell has connected. However, it must not be
+active router connection meaning that the backup router must not use
+that channel as its primary route and it must not notify the router
+about having connected servers, channels and clients behind it. It
+merely connects to the router. This sort of connection is later
+referred as being passive connection. Some keepalive actions may be
+needed by the router to keep the connection alive.
+
+The primary router notifies its primary router about having backup
+routers in the cell by sending SILC_PACKET_CELL_ROUTERS packet. If
+and when the primary router of the cell becomes unresponsive, its
+primary router knows that there exists backup routers in the cell.
+After that it will start using the first backup router sent in the
+packet as router of that cell. In this case the backup router must
+notify its new primary router about the servers, channels and clients
+it has connected to it. The primary router knows that this server
+has become a router of the cell because of failure of the primary
+router in the cell. It must also cope with the fact that the servers,
+channels and clients that the new backup router announces are not
+really new, since they used to exist in the primary router of the
+cell.
+
+It is required that other normal servers has passive connections to
+the backup router(s) in the cell. Some keepalive actions may be needed
+by the server to keep the connection alive. After they notice the
+failure of the primary router they must start using the connection to
+the first backup router as their primary route.
+
+It is recommended that there would be at least one backup router in
+the cell. It is not recommended to have all servers in the cell acting
+as backup routers as it requires establishing several connections to
+several servers in the cell. Large cells can easily have several
+backup routers in the cell. The order of the backup routers are decided
+at the primary router of the cell and servers and backup servers in the
+cell must be configured accordingly. It is not required that the backup
+server is actually active server in the cell. Backup router may be spare
+server in the cell that does not accept normal client connections at all.
+It maybe reserved purely for the backup purposes. These, however, are
+cell management issues.
+
+If the first backup router is down as well and there is another backup
+router in the cell then it will start acting as the primary router as
+described above.
+
+
.ti 0
3. SILC Specification
the requirements of keeping this information.
The nickname selected by the user is not unique in the SILC network.
-There can be 2^8 same nicknames for one IP address. As for comparison to
-IRC [IRC] where nicknames are unique this is a fundamental difference
+There can be 2^8 same nicknames for one IP address. As for comparison
+to IRC [IRC] where nicknames are unique this is a fundamental difference
between SILC and IRC. This causes the server names to be used along
with the nicknames to identify specific users when sending messages.
This feature of SILC makes IRC style nickname-wars obsolete as no one
owns their nickname; there can always be someone else with the same
-nickname. Another difference is that there are no limit of the length
-of the nickname in the SILC.
+nickname. The maximum length of nickname is 128 characters.
.ti 0
3.1.1 Client ID
Client ID is used to identify users in the SILC network. The Client ID
-is unique to the extent that there can be 2^128 different Client ID's.
-Collisions are not expected to happen. The Client ID is defined as
-follows.
+is unique to the extent that there can be 2^128 different Client ID's,
+and ID's based on IPv6 addresses extends this to 2^224 different Client
+ID's. Collisions are not expected to happen. The Client ID is defined
+as follows.
.in 6
128 bit Client ID based on IPv4 addresses:
-32 bit ServerID IP address (bits 1-32)
- 8 bit Random number
+32 bit Server ID IP address (bits 1-32)
+ 8 bit Random number or counter
88 bit Truncated MD5 hash value of the nickname
+224 bit Client ID based on IPv6 addresses:
+
+128 bit Server ID IP address (bits 1-128)
+ 8 bit Random number or counter
+ 88 bit Truncated MD5 hash value of the nickname
+
o Server ID IP address - Indicates the server where this
client is coming from. The IP address hence equals the
server IP address where to the client has connected.
-o Random number - Random number to further randomize the
- Client ID. This makes it possible to have 2^8 same
- nicknames from the same server IP address.
+o Random number or counter - Random number to further
+ randomize the Client ID. Another choice is to use
+ a counter starting from the zero (0). This makes it
+ possible to have 2^8 same nicknames from the same
+ server IP address.
o MD5 hash - MD5 hash value of the nickname is truncated
taking 88 bits from the start of the hash value. This
.ti 0
3.2.2 Server ID
-Servers are distinguished from other servers by unique 64 bit Server ID.
-The Server ID is used in the SILC to route messages to correct servers.
-Server ID's also provide information for Client ID's, see section 3.1.1
-Client ID. Server ID is defined as follows.
+Servers are distinguished from other servers by unique 64 bit Server ID
+(for IPv4) or 160 bit Server ID (for IPv6). The Server ID is used in
+the SILC to route messages to correct servers. Server ID's also provide
+information for Client ID's, see section 3.1.1 Client ID. Server ID is
+defined as follows.
.in 6
64 bit Server ID based on IPv4 addresses:
16 bit Port
16 bit Random number
+160 bit Server ID based on IPv6 addresses:
+
+128 bit IP address of the server
+ 16 bit Port
+ 16 bit Random number
+
o IP address of the server - This is the real IP address of
the server.
.ti 0
3.2.3 SILC Server Ports
-Following ports has been assigned by IANA for the SILC protocol:
+The following ports has been assigned by IANA for the SILC protocol:
.in 10
silc 706/tcp SILC
Channel names are unique although the real uniqueness comes from 64 bit
Channel ID that unifies each channel. However, channel names are still
-unique and no two global channels with same name may exist. Channel name
-is a string which begins with `#' character. There is no limit on the
-length of the channel name. Channel names may not contain any spaces
-(` '), any non-printable ASCII characters, commas (`,') and wildcard
-characters.
+unique and no two global channels with same name may exist. The Channel
+name is a string of maximum length of 256 characters. Channel names may
+not contain any spaces (` '), any non-printable ASCII characters,
+commas (`,') and wildcard characters.
Channels can have operators that can administrate the channel and
-operate all of its modes. Following operators on channel exist on SILC
+operate all of its modes. The following operators on channel exist on SILC
network.
.in 6
3.4.1 Channel ID
Channels are distinguished from other channels by unique Channel ID.
-The Channel ID is a 64 bit ID and collisions are not expected to happen
-in any conditions. Channel names are just for logical use of channels.
-The Channel ID is created by the server where the channel is created.
-The Channel ID is defined as follows.
+The Channel ID is a 64 bit ID (for IPv4) or 160 bit ID (for IPv6), and
+collisions are not expected to happen in any conditions. Channel names
+are just for logical use of channels. The Channel ID is created by the
+server where the channel is created. The Channel ID is defined as
+follows.
.in 6
64 bit Channel ID based on IPv4 addresses:
16 bit Router's Server ID port (bits 33-48)
16 bit Random number
+160 bit Channel ID based on IPv6 addresses:
+
+128 bit Router's Server ID IP address (bits 1-128)
+ 16 bit Router's Server ID port (bits 129-144)
+ 16 bit Random number
+
o Router's Server ID IP address - Indicates the IP address of
the router of the cell where this channel is created. This is
taken from the router's Server ID. This way SILC router knows
Client usually sends the commands and server replies by sending a reply
packet to the command. Server may also send commands usually to serve
the original client's request. However, server may not send command
-to client and there are some commands that server must not send. Server
-is also able to send the forwarded command packets. For example,
-SILC_COMMAND_JOIN is always forwarded packet. See [SILC2] for more
-about packet forwarding.
+to client and there are some commands that server must not send.
Note that the command reply is usually sent only after client has sent
the command request but server is allowed to send command reply packet
to client even if client has not requested the command. Client may,
-however, choose not to accept the command reply, but there are some
-command replies that the client should accept. Example of a such
-command reply is reply to SILC_COMMAND_CMODE command that the server
-uses to distribute the channel mode on all clients on the channel
-when the mode has changed.
+however, choose ignore the command reply, but should not.
It is expected that some of the commands may be miss-used by clients
resulting various problems on the server side. Every implementation
should assure that commands may not be executed more than once, say,
-in two (2) seconds. This should be sufficient to prevent the miss-use
-of commands.
+in two (2) seconds. However, to keep response rate up, allowing for
+example five (5) commands before limiting is allowed. It is recommended
+that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN and
+SILC_COMMAND_LEAVE should be limited in all cases as they require
+heavy operations. This should be sufficient to prevent the miss-use of
+commands.
SILC commands are described in section 5 SILC Commands.
connection authentication protocol is described in detail in [SILC3].
+.ti 0
+3.9.1 Authentication Payload
+
+Authentication payload is used separately from the SKE and the Connection
+authentication protocol. It is used during the session to authenticate
+with the remote. For example, the client can authenticate itself to the
+server to be server operator. In this case, Authentication Payload is
+used.
+
+The format of the Authentication Payload is as follows:
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Payload Length | Authentication Method |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Public Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Authentication Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Authentication Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
+.in 3
+
+.ce
+Figure 5: Authentication Payload
+
+
+.in 6
+o Payload Length (2 bytes) - Length of the entire payload.
+
+o Authentication Type (2) - The method of the authentication.
+ The authentication methods are defined in [SILC2] in the
+ Connection Auth Request Payload. The NONE authentication
+ method is not recommended.
+
+o Public Data Length (2 bytes) - Indicates the length of
+ the Public Data field.
+
+o Public Data (variable length) - This is defined only if
+ the authentication method is public key. If it is any other
+ this field does not exist and the Public Data Length field
+ is set to zero (0).
+
+ When the authentication method is public key this includes
+ 128 to 4096 bytes of non-zero random data that is used in
+ the signature process, described subsequently.
+
+o Authentication Data Length (2 bytes) - Indicates the
+ length of the Authentication Data field.
+
+o Authentication Data (variable length) - Authentication
+ method dependent authentication data.
+.in 3
+
+
+If the authentication method is password based, the Authentication
+Data field includes the plaintext password. It is safe to send
+plaintext password since the entire payload is encrypted. In this
+case the Public Data Lenght is set to zero (0).
+
+If the authentication method is public key based (or certificate)
+the Authentication Data is computed as follows:
+
+ HASH = hash(random bytes | ID | public key (or certificate));
+ Authentication Data = sign(HASH);
+
+The hash() and the sign() are the hash funtion and the public key
+cryptography function selected in the SKE protocol. The public key
+is SILC style public key unless certificates are used. The ID is the
+entity's ID (Client or Server ID) who is authenticating itself. The ID
+is raw ID data. The random bytes are non-zero random bytes of length
+between 128 and 4096 bytes, and will be included into the Public Data
+field as is.
+
+The receiver will compute the signature using the random data received
+in the payload, the ID associated to the connection and the public key
+(or certificate) received in the SKE protocol. After computing the
+receiver must verify the signature. In this case also, the entire
+payload is encrypted.
+
+
.ti 0
3.10 Algorithms
definition of how it must be done. SILC has a mandatory algorithm that
must be supported in order to be compliant with this protocol.
-Following ciphers are defined in SILC protocol:
+The following ciphers are defined in SILC protocol:
.in 6
-aes-cbc AES in CBC mode (mandatory)
-twofish-cbc Twofish in CBC mode (optional)
-blowfish-cbc Blowfish in CBC mode (optional)
-rc6-cbc RC6 in CBC mode (optional)
-rc5-cbc RC5 in CBC mode (optional)
-mars-cbc Mars in CBC mode (optional)
-none No encryption (optional)
+aes-256-cbc AES in CBC mode, 256 bit key (mandatory)
+aes-192-cbc AES in CBC mode, 192 bit key (optional)
+aes-128-cbc AES in CBC mode, 128 bit key (optional)
+twofish-256-cbc Twofish in CBC mode, 256 bit key (optional)
+twofish-192-cbc Twofish in CBC mode, 192 bit key (optional)
+twofish-128-cbc Twofish in CBC mode, 128 bit key (optional)
+blowfish-128-cbc Blowfish in CBC mode, 128 bit key (optional)
+cast-256-cbc CAST-256 in CBC mode, 256 bit key (optional)
+cast-192-cbc CAST-256 in CBC mode, 192 bit key (optional)
+cast-128-cbc CAST-256 in CBC mode, 128 bit key (optional)
+rc6-256-cbc RC6 in CBC mode, 256 bit key (optional)
+rc6-192-cbc RC6 in CBC mode, 192 bit key (optional)
+rc6-128-cbc RC6 in CBC mode, 128 bit key (optional)
+mars-256-cbc Mars in CBC mode, 256 bit key (optional)
+mars-192-cbc Mars in CBC mode, 192 bit key (optional)
+mars-128-cbc Mars in CBC mode, 128 bit key (optional)
+none No encryption (optional)
.in 3
-All algorithms must use minimum of 128 bit key, by default. Several
-algorithms, however, supports longer keys and it is recommended to use
-longer keys if they are available.
-
Algorithm none does not perform any encryption process at all and
thus is not recommended to be used. It is recommended that no client
or server implementation would accept none algorithms except in special
and to perform other tasks related to public key cryptography. The
public keys are also used in the SILC Key Exchange protocol [SILC3].
-Following public key algorithms are defined in SILC protocol:
+The following public key algorithms are defined in SILC protocol:
.in 6
rsa RSA (mandatory)
dss DSS (optional)
.in 3
-Both of the algorithms are described in [Scheneir] and [Menezes].
+DSS is described in [Menezes]. The RSA must be implemented according
+PKCS #1 [PKCS1]. The mandatory PKCS #1 implementation in SILC must be
+compliant to either PKCS #1 version 1.5 or newer with the the following
+notes: The signature encoding is always in same format as the encryption
+encoding regardles of the PKCS #1 version. The signature with appendix
+(with hash algorithm OID in the data) must not be used in the SILC. The
+rationale for this is that there is no binding between the PKCS #1 OIDs
+and the hash algorithms used in the SILC protocol. Hence, the encoding
+is always in PKCS #1 version 1.5 format.
Additional public key algorithms may be defined to be used in SILC.
.ti 0
-3.10.3 MAC Algorithms
+3.10.3 Hash Functions
+
+Hash functions are used as part of MAC algorithms defined in the next
+section. They are also used in the SILC Key Exchange protocol defined
+in the [SILC3].
+
+The following Hash algorithm are defined in SILC protocol:
+
+sha1 SHA-1, length = 20 (mandatory)
+md5 MD5, length = 16 (optional)
+
+
+.ti 0
+3.10.4 MAC Algorithms
Data integrity is protected by computing a message authentication code
(MAC) of the packet data. See [SILC2] for details how to compute the
MAC.
-Following MAC algorithms are defined in SILC protocol:
+The following MAC algorithms are defined in SILC protocol:
.in 6
-hmac-sha1 HMAC-SHA1, length = 20 (mandatory)
+hmac-sha1-96 HMAC-SHA1, length = 12 (mandatory)
+hmac-md5-96 HMAC-MD5, length = 12 (optional)
+hmac-sha1 HMAC-SHA1, length = 20 (optional)
hmac-md5 HMAC-MD5, length = 16 (optional)
none No MAC (optional)
.in 3
.ti 0
-3.10.4 Compression Algorithms
+3.10.5 Compression Algorithms
SILC protocol supports compression that may be applied to unencrypted
data. It is recommended to use compression on slow links as it may
use compression which is the mode that must be supported by all SILC
implementations.
-Following compression algorithms are defined:
+The following compression algorithms are defined:
.in 6
none No compression (mandatory)
-zlib GBU ZLIB (LZ77) compression (optional)
+zlib GNU ZLIB (LZ77) compression (optional)
.in 3
Additional compression algorithms may be defined to be used in SILC.
o Identifier (variable length) - Indicates the identifier
of the public key. This data can be used to identify
- the owner of the key. The identifier is of following
+ the owner of the key. The identifier is of the following
format:
UN User name
The version detection of both client and server is performed at the
connection phase while executing the SILC Key Exchange protocol. The
version identifier is exchanged between initiator and responder. The
-version identifier is of following format:
+version identifier is of the following format:
.in 6
SILC-<protocol version>-<software version>
.in 3
-The version strings are of following format:
+The version strings are of the following format:
.in 6
protocol version = <major>.<minor>
who it claims to be. Client, host, connecting to server must have
both valid IP address and fully qualified domain name (FQDN).
-After that client and server performs SILC Key Exchange protocol which
-will provide the key material used later in the communication. The
-key exchange protocol must be completed successfully before the connection
-registration may continue. The SILC Key Exchange protocol is described
-in [SILC3].
+After that the client and server performs SILC Key Exchange protocol
+which will provide the key material used later in the communication.
+The key exchange protocol must be completed successfully before the
+connection registration may continue. The SILC Key Exchange protocol
+is described in [SILC3].
Typical server implementation would keep a list of connections that it
allows to connect to the server. The implementation would check, for
locally. This would indicate that some client connected to the server
has already joined to the channel. If this is case the client is
joined to the client, new channel key is created and information about
-newly joined channel is sent to the router. The new channel key is
-also distributed to the router and to all clients on the channel.
+newly joined channel is sent to the router. The router is informed
+by sending SILC_NOTIFY_TYPE_JOIN notify type. The notify type must
+also be sent to the local clients on the channel. The new channel key
+is also sent to the router and to local clients on the channel.
-If the channel does not exist in the local list the command must be
-forwarded to the router which will then perform the actual joining
+If the channel does not exist in the local list the client's command
+must be sent to the router which will then perform the actual joining
procedure. When server receives the reply to the command from the
-router it must be distributed to the client who sent the command
-originally. Server will also receive the channel key from the server
-that it must distribute to the client who originally requested the
-join command. The server must also save the channel key.
+router it must be sent to the client who sent the command originally.
+Server will also receive the channel key from the server that it must
+send to the client who originally requested the join command. The server
+must also save the channel key.
If the receiver of the join command is router it must first check its
local list whether anyone in the cell has already joined to the channel.
sent to the client. If the command was sent by server the command reply
is sent to the server who sent it. Then the router must also create
new channel key and distribute it to all clients on the channel and
-all servers that has clients on the channel.
+all servers that has clients on the channel. Router must also send
+the SILC_NOTIFY_TYPE_JOIN notify type to local clients on the channel
+and to local servers that has clients on the channel.
If the channel does not exist on the router's local list it must
check the global list whether the channel exists at all. If it does
channel is made automatically channel founder and both channel founder
and channel operator privileges is set for the client.
-When the router joins the client to the channel it must send
-information about newly joined client to all routers in the SILC
-network. Also, if the channel was created in the process, information
-about newly created channel must also be distributed to all routers.
-The distribution of newly created channel is done by sending packet
-SILC_PACKET_NEW_CHANNEL.
+If the router created the channel in the process, information about the
+new channel must be broadcasted to all routers. This is done by
+broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary
+route. When the router joins the client to the channel it must also
+send information about newly joined client to all routers in the SILC
+network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify
+type to the router's primary route.
It is important to note that new channel key is created always when
new client joins to channel, whether the channel has existed previously
or not. This way the new client on the channel is not able to decrypt
any of the old traffic on the channel. Client who receives the reply to
the join command must start using the received Channel ID in the channel
-message communication thereafter. However, client must not start
-communicating on the channel before it has received the packet
-SILC_PACKET_CHANNEL_KEY.
-
-If client wants to know the other clients currently on the channel
-the client must send SILC_COMMAND_NAMES command to receive a list of
-channel users. Server implementation, however, may send command reply
-packet to SILC_COMMAND_NAMES command after client has joined to the
-channel even if the client has not sent the command. Server should also
-send SILC_NOTIFY_TYPE_JOIN to all clients on the channel about a new
-client on the channel.
+message communication thereafter. Client also receives the key for the
+channel in the command reply.
.ti 0
how channel messages must be encrypted and decrypted when router is
processing them.
+When client receives the SILC_PACKET_CHANNEL_KEY packet with the
+Channel Key Payload it must process the key data to create encryption
+and decryption key, and to create the HMAC key that is used to compute
+the MACs of the channel messages. The processing is as follows:
+
+ channel_key = raw key data
+ HMAC key = hash(raw key data)
+
+The raw key data is the key data received in the Channel Key Payload.
+The hash() function is the hash function used in the HMAC of the channel.
+
.ti 0
4.5 Private Message Sending and Reception
SILC_PACKET_PRIVATE_MESSAGE_KEY which travels through the network
and is secured by session keys. After that the private message key
is used in the private message communication between those clients.
-See more information about how this works technically in [SILC2].
Other choice is to entirely use keys that are not sent through
the SILC network at all. This significantly adds security. This key
would be pre-shared-key that is known by both of the clients. Both
agree about using the key and starts sending packets that indicate
-that the private message is secured using private message key. This
-is the technical aspect mentioned previously that is described
-in [SILC2].
-
-If the private message keys are not set to be used, which is the
-case by default in SILC, the private messages are secured by using
-normal session keys established by SILC Key Exchange protocol.
-
+that the private message is secured using private message key.
+The key material used as private message key is implementation issue.
+However, SILC_PACKET_KEY_AGREEMENT packet may be used to negotiate
+the key material. If the key is normal pre-shared-key or randomly
+generated key, and the SILC_PACKET_KEY_AGREEMENT was not used, then
+the key material should be processed as defined in the [SILC3]. In
+the processing, however, the HASH, as defined in [SILC3] must be
+ignored. After processing the key material it is employed as defined
+in [SILC3], however, the HMAC key material must be discarded.
+If the key is pre-shared-key or randomly generated the implementations
+should use the SILC protocol's mandatory cipher as the cipher. If the
+SKE was used to negotiate key material the cipher was negotiated as well.
.ti 0
4.7 Channel Message Sending and Reception
hashing the old key with hash function selected earlier in the SKE
protocol. If the digest length of the hash function is too short for the
key, then the key is distributed as described in section Processing the
-Key Material in [SILC3]. After both parties has regenerated the session
-key, both send SILC_PACKET_REKEY_DONE packet to each other. These packets
-are still secured with the old key. After these packets, following
-packets must be protected with the new key.
+Key Material in [SILC3].
+
+After both parties has regenerated the session key, both send
+SILC_PACKET_REKEY_DONE packet to each other. These packets are still
+secured with the old key. After these packets, the following packets
+must be protected with the new key. After sending the REKEY_DONE packet
+all subsequent sent packets must be encrypted with the new key. After
+receiving the REKEY_DONE packet all subsequent packets must be
+decrypted with the new key.
.ti 0
the client simply sends the command packet to server and the server
processes it and replies with command reply packet.
-However, if the server is not able to process the command, it is usually
-sent to the server's router. This is case for example with commands such
+However, if the server is not able to process the command, it is sent
+to the server's router. This is case for example with commands such
as, SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there
are other commands as well. For example, if client sends the WHOIS
command requesting specific information about some client the server must
send the WHOIS command to router so that all clients in SILC network
are searched. The router, on the other hand, sends the WHOIS command
-to further to receive the exact information about the requested client.
+further to receive the exact information about the requested client.
The WHOIS command travels all the way to the server who owns the client
and it replies with command reply packet. Finally, the server who
sent the command receives the command reply and it must be able to
may return inside the <Status Payload>. All status messages
are defined in the section 5.3 SILC Command Status Types.
+.in 3
Every command that has some kind of ID as argument (for example
<Client ID>) are actually ID Payloads, defined in [SILC2] that includes
the type of the ID, length of the ID and the actual ID data. This
way variable length ID's can be sent as arguments.
-.in 3
.ti 0
1 SILC_COMMAND_WHOIS
- Max Arguments: 3
- Arguments: (1) <nickname>[@<server>] (2) [<Client ID>]
- (3) [<count>]
+ Max Arguments: 3328
+ Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
+ (3) [<Client ID>] (n) [...]
Whois command is used to query various information about specific
user. The user maybe requested by their nickname and server name.
It is also possible to search the user by Client ID. If <Client ID>
is provided server must use it as the search value instead of
- the <nickname>.
+ the <nickname>. One of the arguments must be given. It is also
+ possible to define multiple Client ID's to search multiple users
+ sending only one WHOIS command. In this case the Client ID's are
+ appended as normal arguments. The server replies in this case
+ with only one reply message for all requested users.
To prevent miss-use of this service wildcards in the nickname
or in the servername are not permitted. It is not allowed
to request all users on some server. The WHOIS requests must
be based on specific nickname request.
- The WHOIS request must be always forwarded to router by server
+ The WHOIS request must be always sent to the router by server
so that all users are searched. However, the server still must
- search its locally connected clients. The server must send
+ search its locally connected clients. The router must send
this command to the server who owns the requested client. That
- server must reply to the command.
+ server must reply to the command. Server must not send whois
+ replies to the client until it has received the reply from its
+ router.
Reply messages to the command:
- Max Arguments: 7
+ Max Arguments: 8
Arguments: (1) <Status Payload> (2) <Client ID>
(3) <nickname>[@<server>] (4) <username@host>
- (5) <real name> (6) [<channel list>]
- (7) [<idle time>]
+ (5) <real name> (6) [<Channel Payload
+ list>]
+ (7) [<user mode>] (8) [<idle time>]
+
This command may reply with several command reply messages to
form a list of results. In this case the status payload will
<count> option were defined in the query there will be only
<count> many replies from the server.
+ The server may return the list of channel the client has joined.
+ In this case the list is list of Channel Payloads. The Mode Mask
+ in the Channel Payload (see [SILC2] and section 2.3.2.3 for the
+ Channel Payload) is the client's mode on the channel. The list
+ is encoded by adding the Channel Payloads one after the other.
+
Status messages:
SILC_STATUS_OK
SILC_STATUS_LIST_START
SILC_STATUS_LIST_END
SILC_STATUS_ERR_NO_SUCH_NICK
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_WILDCARDS
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
-
-
2 SILC_COMMAND_WHOWAS
Max Arguments: 2
or in the servername are not permitted. The WHOWAS requests must
be based on specific nickname request.
- The WHOWAS request must be always forwarded to router by server
+ The WHOWAS request must be always sent to the router by server
so that all users are searched. However, the server still must
search its locally connected clients.
Reply messages to the command:
- Max Arguments: 3
- Arguments: (1) <Status Payload> (2) <nickname>[@<server>]
- (3) <username@host>
+ Max Arguments: 5
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) <nickname>[@<server>] (4) <username@host>
+ (5) [<real name>]
This command may reply with several command reply messages to form
a list of results. In this case the status payload will include
3 SILC_COMMAND_IDENTIFY
- Max Arguments: 2
- Arguments: (1) <nickname>[@<server>] (2) [<count>]
+ Max Arguments: 3328
+ Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
+ (3) [<Client ID>] (n) [...]
Identify. Identify command is almost analogous to WHOIS command,
except that it does not return as much information. Only relevant
are no limit of accepted results. The query may also be narrowed
down by defining the server name of the nickname.
+ It is also possible to search the user by Client ID. If <Client ID>
+ is provided server must use it as the search value instead of
+ the <nickname>. One of the arguments must be given. It is also
+ possible to define multiple Client ID's to search multiple users
+ sending only one IDENTIFY command. In this case the Client ID's are
+ appended as normal arguments. The server replies in this case
+ with only one reply message for all requested users.
+
To prevent miss-use of this service wildcards in the nickname
or in the servername are not permitted. It is not allowed
to request all users on some server. The IDENTIFY requests must
be based on specific nickname request.
Implementations may not want to give interface access to this
- command as it is hardly a command that would be used a end user.
+ command as it is hardly a command that would be used by an end user.
However, it must be implemented as it is used with private message
sending.
- The IDENTIFY must be always forwarded to router by server so that
+ The IDENTIFY must be always sent to the router by server so that
all users are searched. However, server must still search its
locally connected clients.
SILC_STATUS_LIST_START
SILC_STATUS_LIST_END
SILC_STATUS_ERR_NO_SUCH_NICK
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_WILDCARDS
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
nicknames in SILC are case-sensitive which must be taken into
account when searching clients by nickname.
+ When nickname is changed new Client ID is generated. Server must
+ distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
+ channels (if any) the client is joined on. Then it must send
+ SILC_PACKET_REPLACE_ID to its primary route to replace the old
+ Client ID with the new one.
+
Reply messages to the command:
Max Arguments: 2
SILC_STATUS_ERR_TOO_MANY_PARAMS
-
-
-
-
5 SILC_COMMAND_LIST
- Max Arguments: 2
- Arguments: (1) [<Channel ID>] [<server>]
+ Max Arguments: 1
+ Arguments: (1) [<Channel ID>]
- The list command is used to list channels and their topics on
+ The list command is used to list channels and their topics on the
current server. If the <Channel ID> parameter is used, only the
status of that channel is displayed. Secret channels are not
listed at all. Private channels are listed with status indicating
- that the channel is private.
-
- If the <server> argument is specified the specified server's
- channels are listed. In this case the command must be sent to
- the server who owns the channel that was requested.
+ that the channel is private. Router may reply with all channels
+ it knows about.
Reply messages to the command:
- Max Arguments: 4
+ Max Arguments: 5
Arguments: (1) <Status Payload> (2) <Channel ID>
- (3) <channel> (4) <topic>
+ (3) <channel> (4) [<topic>]
+ (5) [<user count>]
This command may reply with several command reply messages to form
a list of results. In this case the status payload will include
SILC_STATUS_ERR_WILDCARDS
SILC_STATUS_ERR_NOT_REGISTERED
SILC_STATUS_ERR_TOO_MANY_PARAMS
- SILC_STATUS_ERR_NO_SUCH_CHANNEL
SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
SILC_STATUS_ERR_NO_SUCH_SERVER
for that channel will be changed, if the channel modes permit
this action.
+ After setting the topic the server must send the notify type
+ SILC_NOTIFY_TYPE_TOPIC_SET to its primary router and then to
+ the channel which topic was changed.
+
Reply messages to the command:
Max Arguments: 2
- Arguments: (1) <Status Payload> (2) [<topic>]
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<topic>]
The command may reply with the topic of the channel if it is
set.
7 SILC_COMMAND_INVITE
- Max Arguments: 2
- Arguments: (1) <Client ID> (2) <Channel ID>
+ Max Arguments: 4
+ Arguments: (1) <Channel ID> (2) [<Client ID>]
+ (3) [<adding client>] (4) [<removing client>]
This command is used to invite other clients to join to the
channel. The <Client ID> argument is the target client's ID that
is being invited. The <Channel ID> is the Channel ID of the
requested channel. The sender of this command must be on the
- channel. This command must fail if the requested channel does
- not exist, the requested client is already on the channel or if
- the channel is invite only channel and the caller of this command
- does not have at least channel operator privileges.
+ channel. The server must also send the notify type
+ SILC_NOTIFY_TYPE_INVITE to its primary router and then to the
+ client indicated by the <Client ID>.
+
+ The <adding client> and <removing client> can be used to add to
+ and remove from the invite list. The format of the <adding client>
+ and <removing client> is as follows:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
+
+ When adding to or removing from the invite list the server must
+ send the notify type SILC_NOTIFY_TYPE_INVITE to its primary router
+ and must not send it to the client which was added to the list.
+ The client which executes this command must have at least channel
+ operator privileges to be able to add to or remove from the invite
+ list. The wildcards may be used with this command. If adding or
+ removing from than one clients then the lists are an comma (`,')
+ separated list.
+
+ Note that the <Client ID> provided must be resolved into correct
+ nickname and hostname and add to the invite list before sending
+ the notify packet.
+
+ When this command is given with only <Channel ID> argument then
+ the command merely returns the invite list of the channel. This
+ command must fail if the requested channel does not exist, the
+ requested <Client ID> is already on the channel or if the channel
+ is invite only channel and the caller of this command does not
+ have at least channel operator privileges.
Reply messages to the command:
- Max Arguments: 2
- Arguments: (1) <Status Payload>
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<invite list>]
- This command replies only with Status Payload.
+ This command replies with the invite list of the channel if it
+ exists.
Status messages:
SILC_STATUS_ERR_NO_CHANNEL_ID
SILC_STATUS_ERR_NOT_ON_CHANNEL
SILC_STATUS_ERR_USER_ON_CHANNEL
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
8 SILC_COMMAND_QUIT
give to the removed client some information why it was removed
from the network.
+ When killing a client the router must first send notify type
+ SILC_NOTIFY_TYPE_KILLED to all channels the client has joined.
+ The packet must not be sent to the killed client on the channel.
+ Then, the router must send the same notify type to its primary
+ router. Finally, the router must send the same notify type to
+ the client who was killed.
+
Reply messages to the command:
Max Arguments: 1
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_NO_CLIENT_ID
-
+ SILC_STATUS_ERR_NO_ROUTER_PRIV
10 SILC_COMMAND_INFO
- Max Arguments: 1
- Arguments: (1) [<server>]
+ Max Arguments: 2
+ Arguments: (1) [<server>] (2) [<Server ID>]
This command is used to fetch various information about a server.
If <server> argument is specified the command must be sent to
the requested server.
+ If the <Server ID> is specified the server information if fetched
+ by the provided Server ID.
+
Reply messages to the command:
- Max Arguments: 3
+ Max Arguments: 4
Arguments: (1) <Status Payload> (2) <Server ID>
- (3) <string>
+ (3) <server name> (4) <string>
This command replies with the Server ID of the server and a
string which tells the information about the server.
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NO_SUCH_SERVER
+ SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+ SILC_STATUS_ERR_NO_SERVER_ID
11 SILC_COMMAND_CONNECT
Max Arguments: 2
- Arguments: (1) <Server ID>
- (2) [<remote server/router>[ <port>]]
+ Arguments: (1) <remote server/router> (2) [<port>]
This command is used by operators to force a server to try to
- establish a new connection to another router (if the connecting
- server is normal server) or server (if the connecting server is
- router server). Operator may specify the server/router to be
- connected by setting <remote server> argument. The separator
- between <remote server address> and <port> is whitespace (` ').
+ establish a new connection to remote server or router. The
+ Operator must specify the server/router to be connected by
+ setting <remote server> argument. The port is 32 bit MSB value.
Reply messages to the command:
SILC_STATUS_ERR_NOT_REGISTERED
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
- SILC_STATUS_ERR_NO_SUCH_SERVER_ID
SILC_STATUS_ERR_NO_SERVER_PRIV
SILC_STATUS_ERR_NO_ROUTER_PRIV
13 SILC_COMMAND_OPER
Max Arguments: 2
- Arguments: (1) <username> (2) <authentication data>
+ Arguments: (1) <username> (2) <authentication payload>
This command is used by normal client to obtain server operator
privileges on some server or router. Note that router operator
must use SILCOPER command to obtain router level privileges.
The <username> is the username set in the server configurations
- as operator. The <authentication data> is the data that the
+ as operator. The <authentication payload> is the data that the
client is authenticated against. It may be passphrase prompted
- for user on client's screen or it may be public key
- authentication data (data signed with private key), or
- certificate.
+ for user on client's screen or it may be public key or certificate
+ authentication data (data signed with private key).
+
+ After changing the mode server must send the notify type
+ SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
Reply messages to the command:
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NOT_REGISTERED
- SILC_STATUS_ERR_BAD_PASSWORD
SILC_STATUS_ERR_AUTH_FAILED
-
-
-
14 SILC_COMMAND_JOIN
- Max Arguments: 3
- Arguments: (1) <channel> (2) [<passphrase>]
- (3) [<cipher>]
+ Max Arguments: 5
+ Arguments: (1) <channel> (2) <Client ID>
+ (3) [<passphrase>] (4) [<cipher>]
+ (5) [<hmac>]
Join to channel/create new channel. This command is used to
join to a channel. If the channel does not exist the channel is
- created. If server is normal server this command must be forwarded
- to router who will create the channel. The channel may be protected
- with passphrase. If this is the case the passphrase must be sent
- along the join command.
+ created. If server is normal server this command must be sent
+ to router who will create the channel. The channel may be
+ protected with passphrase. If this is the case the passphrase
+ must be sent along the join command.
The name of the <channel> must not include any spaces (` '),
non-printable characters, commas (`,') or any wildcard characters.
+ The second argument <Client ID> is the Client ID of the client who
+ is joining to the client. When client sends this command to the
+ server the <Client ID> must be the client's own ID.
+
Cipher to be used to secure the traffic on the channel may be
requested by sending the name of the requested <cipher>. This
is used only if the channel does not exist and is created. If
the channel already exists the cipher set previously for the
- channel will be used to secure the traffic.
+ channel will be used to secure the traffic. The computed MACs
+ of the channel message are produced by the default HMAC or by
+ the <hmac> provided for the command.
The server must check whether the user is allowed to join to
the requested channel. Various modes set to the channel affect
Reply messages to the command:
- Max Arguments: 5
- Arguments: (1) <Status Payload> (2) <channel>
- (3) <Channel ID> (4) <channel mode mask>
- (5) [<ban mask>] (6) [<invite list>]
- (6) [<topic>]
+ Max Arguments: 14
+ Arguments: (1) <Status Payload> (2) <channel>
+ (3) <Channel ID> (4) <Client ID>
+ (5) <channel mode mask> (6) <created>
+ (7) [<Channel Key Payload>] (8) [<ban list>]
+ (9) [<invite list>] (10) [<topic>]
+ (11) [<hmac>] (12) <list count>
+ (13) <Client ID list> (14) <client mode list>
This command replies with the channel name requested by the
client, channel ID of the channel and topic of the channel
- if it exists. It also replies with the channel mode mask
+ if it exists. The <Client ID> is the Client ID which was joined
+ to the channel. It also replies with the channel mode mask
which tells all the modes set on the channel. If the
channel is created the mode mask is zero (0). If ban mask
and/or invite list is set they are sent as well.
- Client must not start transmitting to the channel even after
- server has replied to this command. Client is permitted to
- start transmitting on channel after server has sent packet
- SILC_PACKET_CHANNEL_KEY to the client.
+ The <list count>, <Client ID list> and <client mode list> are
+ the clients currently on the channel and their modes on the
+ channel. The <Client ID list> is formed by adding the ID Payloads
+ one after the other. The <client mode list> is formed by adding
+ 32 bit MSB first order values one after the other.
+
+ Client receives the channel key in the reply message as well
+ inside <Channel Key Payload>.
Status messages:
Max Arguments: 1
Arguments: (1) <server>
- This command is used to query the Message of the Day of a server.
+ This command is used to query the Message of the Day of the server.
Reply messages to the command:
- Max Arguments: 2
- Arguments: (1) <Status Payload> (2) [<motd>]
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Server ID>
+ (3) [<motd>]
This command replies with the motd message if it exists.
locally so that the mode setting/unsetting would work without
problems. Client may change only its own modes.
- Following client modes are defined:
+ After changing the mode server must send the notify type
+ SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
+ The following client modes are defined:
0x0000 SILC_UMODE_NONE
privileges by SILC_COMMAND_SILCOPER command. Client
may unset the mode itself.
+
Reply messages to the command:
Max Arguments: 2
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_BAD_CLIENT_ID
SILC_STATUS_ERR_NOT_YOU
+ SILC_STATUS_ERR_PERM_DENIED
SILC_STATUS_ERR_UNKNOWN_MODE
- SILC_STATUS_ERR_NO_RECIPIENT
SILC_STATUS_ERR_NO_CLIENT_ID
17 SILC_COMMAND_CMODE
- Max Arguments: 8
+ Max Arguments: 6
Arguments: (1) <Channel ID> (2) <channel mode mask>
(3) [<user limit>] (4) [<passphrase>]
- (5) [<ban mask>] (6) [<invite list>]
- (7) [<Client ID>] (8) [<cipher>[:<key len>]]
+ (5) [<cipher>] (6) [<hmac>]
This command is used by client to set or change channel flags on
a channel. Channel has several modes that set various properties
the same channel and poses sufficient privileges to be able to
change the mode.
- Following channel modes are defined:
+ When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
+ type is distributed to the channel.
+
+ The following channel modes are defined:
0x0000 SILC_CMODE_NONE
the key before hand (it is considered to be pre-shared-
key). This specification does not define how the private
channel key is set as it is entirely local setting on
- client end.
+ the client end.
As it is local setting it is possible to have several
private channel keys on one channel. In this case several
to set/unset this mode.
- 0x0080 SILC_CMODE_BAN
+ 0x0080 SILC_CMODE_CIPHER
- Ban mask has been set to the channel. The ban mask
- may be used to ban specific clients to join the channel.
- The <ban mask> argument is the set ban mask. When
- unsetting a ban mask the mask must be provided as
- argument. Channel founder and channel operator may
- set/unset this mode. Channel founder may not be
- added to the ban list.
+ Sets specific cipher to be used to protect channel
+ traffic. The <cipher> argument is the requested cipher.
+ When set or unset the server must re-generate new
+ channel key. Only channel founder may set the cipher of
+ the channel. When unset the new key is generated using
+ default cipher for the channel.
- Typical implementation would use [+|-]b on user interface
+ Typical implementation would use [+|-]c on user interface
to set/unset this mode.
- 0x0100 SILC_CMODE_INVITE
+ 0x0100 SILC_CMODE_HMAC
- Invite list has been set to the channel. The invite list
- can be used to mark the clients that is able to join
- channel without being invited when the channel is set to
- be invite-only channel. The <invite list> argument is the
- set invite mask. When unsetting entry from the invite list
- the entry must be provided as argument. Channel founder and
- channel operator may set/unset this mode.
-
- Typical implementation would use [+|-]I on user interface
- to set/unset this mode.
-
-
- 0x0200 SILC_CMODE_OPERATOR
-
- Sets channel operator privileges on the channel for a
- client on the channel. The <Client ID> argument is the
- target client on the channel. Channel founder and
- channel operator may set/unset (promote/demote) this
- mode.
+ Sets specific hmac to be used to compute the MACs of the
+ channel message. The <hmac> argument is the requested hmac.
+ Only channel founder may set the hmac of the channel.
- Typical implementation would use [+|-]o on user interface
- to set/unset this mode.
-
-
- 0x0400 SILC_CMODE_CIPHER
-
- Sets specific cipher to be used to protect channel
- traffic. The <cipher> argument is the requested cipher.
- When set or unset the server must re-generate new
- channel key. If <key len> argument is specified with
- <cipher> argument the new key is generated of <key len>
- length.
-
- Typical implementation would use [+|-]c on user interface
+ Typical implementation would use [+|-]h on user interface
to set/unset this mode.
mask locally so that the mode setting and unsetting would work
without problems. The client receives the initial channel mode
mask when it joins to the channel. When the mode changes on
- channel the server distributes the changed channel mode mask to
- all clients on the channel by sending SILC_COMMAND_CMODE command
- reply packet.
-
+ channel the servers distributes the changed channel mode mask to
+ all clients on the channel by sending SILC_NOTIFY_TYPE_CMODE_CHANGE
+ notify type.
Reply messages to the command:
Arguments: (1) <Status Payload> (2) <channel mode mask>
This command replies with the changed channel mode mask that
- client is required to keep locally. The same mask is also
- sent to all clients on channel by sending additional command
- reply to them.
+ client is required to keep locally.
Status messages:
SILC_STATUS_ERR_NO_CHANNEL_ID
SILC_STATUS_ERR_NO_CHANNEL_PRIV
SILC_STATUS_ERR_UNKNOWN_MODE
- SILC_STATUS_ERR_NO_CLIENT_ID
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+
+
+ 18 SILC_COMMAND_CUMODE
+
+ Max Arguments: 3
+ Arguments: (1) <Channel ID> (2) <mode mask>
+ (3) <Client ID>
+
+ This command is used by client to change channel user modes on
+ channel. Users on channel may have some special modes and this
+ command is used by channel operators to set or change these modes.
+ The <Channel ID> is the ID of the target channel. The <mode mask>
+ is OR'ed mask of modes. The <Client ID> is the target client.
+ The client changing channel user modes must be on the same channel
+ as the target client and poses sufficient privileges to be able to
+ change the mode.
+
+ When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
+ type is distributed to the channel.
+
+ The following channel modes are defined:
+
+ 0x0000 SILC_CUMODE_NONE
+
+ No specific mode. This is the normal situation for client.
+ Also, this is the mode set when removing all modes from client.
+
+ 0x0001 SILC_CUMODE_FOUNDER
+ The client is channel founder of the channel. This mode
+ cannot be set by other client, it is set by the server when
+ the channel was founded (created). The mode is provided
+ because client may remove the founder rights from itself.
+
+
+ 0x0002 SILC_CUMODE_OPERATOR
+
+ Sets channel operator privileges on the channel for a
+ client on the channel. Channel founder and channel operator
+ may set/unset (promote/demote) this mode.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <channel user mode mask>
+ (3) <Client ID>
+
+ This command replies with the changed channel user mode mask that
+ client is required to keep locally. The <Client ID> is the target
+ client.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_BAD_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ SILC_STATUS_ERR_UNKNOWN_MODE
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
- 18 SILC_COMMAND_KICK
+ 19 SILC_COMMAND_KICK
Max Arguments: 3
- Arguments: (1) <channel> (2) <Client ID>
+ Arguments: (1) <Channel ID> (2) <Client ID>
(3) [<comment>]
This command is used by channel operators to remove a client from
channel. If <comment> is provided it will be sent to the removed
client.
+ After kicking the client the server must send the notify type
+ SILC_NOTIFY_TYPE_KICKED to the channel and to its primary router.
+ The channel key must also be re-generated after kicking.
+
Reply messages to the command:
Max Arguments: 1
SILC_STATUS_ERR_NO_CLIENT_ID
- 19 SILC_COMMAND_RESTART
+ 20 SILC_COMMAND_RESTART
Max Arguments: 0
Arguments: None
SILC_STATUS_ERR_NO_SERVER_PRIV
+ 21 SILC_COMMAND_CLOSE
-
-
- 20 SILC_COMMAND_CLOSE
-
- Max Arguments: 1
- Arguments: (1) <Server ID>
+ Max Arguments: 2
+ Arguments: (1) <remote server/router> (2) [<port>]
This command is used only by operator to close connection to a
- remote site. The <Server ID> argument is the ID of the remote
- site and must be valid.
+ remote site.
Reply messages to the command:
SILC_STATUS_ERR_NO_SUCH_SERVER_ID
- 21 SILC_COMMAND_DIE
+ 22 SILC_COMMAND_SHUTDOWN
Max Arguments: 0
Arguments: None
SILC_STATUS_ERR_NO_SERVER_PRIV
- 22 SILC_COMMAND_SILCOPER
+ 23 SILC_COMMAND_SILCOPER
Max Arguments: 2
- Arguments: (1) <username> (2) <authentication data>
+ Arguments: (1) <username> (2) <authentication payload>
This command is used by normal client to obtain router operator
privileges (also known as SILC operator) on some router. Note
server operator privileges.
The <username> is the username set in the server configurations
- as operator. The <authentication data> is the data that the
+ as operator. The <authentication payload> is the data that the
client is authenticated against. It may be passphrase prompted
for user on client's screen or it may be public key
authentication data (data signed with private key), or
local properties, such as, local connections and normal server
administration.
+ After changing the mode server must send the notify type
+ SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
Reply messages to the command:
Max Arguments: 1
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NOT_REGISTERED
- SILC_STATUS_ERR_BAD_PASSWORD
SILC_STATUS_ERR_AUTH_FAILED
- 23 SILC_COMMAND_LEAVE
+ 24 SILC_COMMAND_LEAVE
Max Arguments: 1
Arguments: (1) <Channel ID>
This command is used by client to leave a channel the client is
- joined to. After a client has leaved the channel the server
- must create new key for the channel and distribute to all clients
- still currently on the channel.
+ joined to.
+
+ When leaving the channel the server must send the notify type
+ SILC_NOTIFY_TYPE_LEAVE to its primary router and to the channel.
+ The channel key must also be re-generated when leaving the channel
+ and distribute it to all clients still currently on the channel.
Reply messages to the command:
SILC_STATUS_ERR_NO_CHANNEL_ID
- 24 SILC_COMMAND_NAMES
+ 25 SILC_COMMAND_USERS
Max Arguments: 1
Arguments: (1) <Channel ID>
command must not send the list of users, as private and secret
channels cannot be seen by outside. In this case the returned
name list may include a indication that the server could not
- resolve the names of the users on the channel.
+ resolve the names of the users on the channel. Also, in this case
+ Client ID's or client modes are not sent either.
Reply messages to the command:
- Max Arguments: 3
+ Max Arguments: 5
Arguments: (1) <Status Payload> (2) <Channel ID>
- (3) <name list> (4) <Client ID list>
-
- This command replies with the Channel ID of the requested channel,
- comma separated list of users on the channel and Client ID list
- of the users on the list. The Client ID list has Client ID's
- of all users in the list. First Client ID in the list must be
- the Client ID of the first user in <name list>. The Client ID
- List is formed by adding Client ID's each after each. Note that
- the Client ID list is binary data.
+ (3) <list count> (4) <Client ID list>
+ (5) <client mode list>
+
+ This command replies with the Channel ID of the requested channel
+ Client ID list of the users on the channel and list of their modes.
+ The Client ID list has Client ID's of all users in the list. The
+ <Client ID list> is formed by adding Client ID's one after another.
+ The <client mode list> is formed by adding client's user modes on
+ the channel one after another (4 bytes (32 bits) each). The <list
+ count> of length of 4 bytes (32 bits), tells the number of entries
+ in the lists. Both lists must have equal number of entries.
Status messages:
SILC_STATUS_ERR_NOT_ON_CHANNEL
- 25 - 199
+ 26 SILC_COMMAND_BAN
+
+ Max Arguments: 3
+ Arguments: (1) <Channel ID> (2) [<adding client>]
+ (3) [<removing client>]
+
+ This command is used to manage the ban list of the channel
+ indicated by the <Channel ID>. A client that is banned from
+ channel is no longer able to join the channel. The client which
+ is executing this command must have at least channel operator
+ privileges on the channel.
+
+ The <adding client> and <removing client> are used to add to and
+ remove from the ban list. The format of the <adding client> and
+ the <removing client> is of following format:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
+
+ The server must send the notify type SILC_NOTIFY_TYPE_BAN to its
+ primary router after adding to or removing from the ban list.
+ The wildcards may be used with this command. If adding or removing
+ from than one clients then the lists are an comma (`,') separated
+ list.
+
+ If this command is executed without the ban arguments the command
+ merely replies with the current ban list.
+
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<ban list>]
+
+ This command replies with the <Channel ID> of the channel and
+ the current <ban list> of the channel if it exists.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+
+
+ 27 - 199
Currently undefined commands.
Command Status Payload is sent in command reply messages to indicate
the status of the command. The payload is one of argument in the
command thus this is the data area in Command Argument Payload described
-in [SILC2]. The payload is only 2 bytes of length. Following diagram
+in [SILC2]. The payload is only 2 bytes of length. The following diagram
represents the Command Status Payload (field is always in MSB order).
Start of the list. There will be several command replies and
this reply is the start of the list.
- 2 SILC_STATUS_LIST_END
+ 2 SILC_STATUS_LIST_ITEM
+
+ Item in the list. This is one of the item in the list but not the
+ first or last one.
+
+ 3 SILC_STATUS_LIST_END
End of the list. There were several command replies and this
reply is the last of the list. There won't be other replies
belonging to this list after this one.
- 3 - 9
+ 4 - 9
Currently undefined and has been reserved for the future.
25 SILC_STATUS_ERR_NOT_ON_CHANNEL
"You are not on that channel". The command were specified for
- client user is not currently on.
+ channel user is not currently on.
- 26 SILC_STATUS_ERR_USER_ON_CHANNEL
+ 26 SILC_STATUS_ERR_USER_NOT_ON_CHANNEL
+
+ "They are not on channel". The requested target client is not
+ on requested channel.
+
+ 27 SILC_STATUS_ERR_USER_ON_CHANNEL
"User already on channel". User were invited on channel they
already are on.
- 27 SILC_STATUS_ERR_NOT_REGISTERED
+ 28 SILC_STATUS_ERR_NOT_REGISTERED
"You have not registered". User executed command that requires
the client to be registered on the server before it may be
executed.
- 28 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ 29 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
"Not enough parameters". Command requires more parameters
than provided.
- 29 SILC_STATUS_ERR_TOO_MANY_PARAMS
+ 30 SILC_STATUS_ERR_TOO_MANY_PARAMS
"Too many parameters". Too many parameters were provided
for the command.
- 30 SILC_STATUS_ERR_PERM_DENIED
+ 31 SILC_STATUS_ERR_PERM_DENIED
- "Your host is not among the privileged". The client tried to
- register on server that does not allow this host to connect.
+ "Permission denied". Generic permission denied error status
+ to indicate disallowed access.
- 31 SILC_STATUS_ERR_BANNED_FROM_SERVER
+ 32 SILC_STATUS_ERR_BANNED_FROM_SERVER
"You are banned from this server". The client tried to register
on server that has explicitly denied this host to connect.
- 32 SILC_STATUS_ERR_BAD_PASSWORD
+ 33 SILC_STATUS_ERR_BAD_PASSWORD
"Cannot join channel. Incorrect password". Password provided for
channel were not accepted.
- 33 SILC_STATUS_ERR_CHANNEL_IS_FULL
+ 34 SILC_STATUS_ERR_CHANNEL_IS_FULL
"Cannot join channel. Channel is full". The channel is full
and client cannot be joined to it.
- 34 SILC_STATUS_ERR_NOT_INVITED
+ 35 SILC_STATUS_ERR_NOT_INVITED
"Cannot join channel. You have not been invited". The channel
is invite only channel and client has not been invited.
- 35 SILC_STATUS_ERR_BANNED_FROM_CHANNEL
+ 36 SILC_STATUS_ERR_BANNED_FROM_CHANNEL
"Cannot join channel. You have been banned". The client has
been banned from the channel.
- 36 SILC_STATUS_ERR_UNKNOWN_MODE
+ 37 SILC_STATUS_ERR_UNKNOWN_MODE
"Unknown mode". Mode provided by the client were unknown to
the server.
- 37 SILC_STATUS_ERR_NOT_YOU
+ 38 SILC_STATUS_ERR_NOT_YOU
"Cannot change mode for other users". User tried to change
someone else's mode.
- 38 SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ 39 SILC_STATUS_ERR_NO_CHANNEL_PRIV
"Permission denied. You are not channel operator". Command may
be executed only by channel operator.
- 39 SILC_STATUS_ERR_NO_SERVER_PRIV
+ 40 SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+
+ "Permission denied. You are not channel founder". Command may
+ be executed only by channel operator.
+
+ 41 SILC_STATUS_ERR_NO_SERVER_PRIV
"Permission denied. You are not server operator". Command may
be executed only by server operator.
- 40 SILC_STATUS_ERR_NO_ROUTER_PRIV
+ 42 SILC_STATUS_ERR_NO_ROUTER_PRIV
"Permission denied. You are not SILC operator". Command may be
executed only by router (SILC) operator.
- 41 SILC_STATUS_ERR_BAD_NICKNAME
+ 43 SILC_STATUS_ERR_BAD_NICKNAME
"Bad nickname". Nickname requested contained illegal characters
or were malformed.
- 42 SILC_STATUS_ERR_BAD_CHANNEL
+ 44 SILC_STATUS_ERR_BAD_CHANNEL
"Bad channel name". Channel requested contained illegal characters
or were malformed.
- 43 SILC_STATUS_ERR_AUTH_FAILED
+ 45 SILC_STATUS_ERR_AUTH_FAILED
"Authentication failed". The authentication data sent as
argument were wrong and thus authentication failed.
+
+ 46 SILC_STATUS_ERR_UNKOWN_ALGORITHM
+
+ "The algorithm was not supported." The server does not support the
+ requested algorithm.
.in 3
6 Security Considerations
Security is central to the design of this protocol, and these security
-considerations permeate the specification.
+considerations permeate the specification. Common security considerations
+such as keeping private keys truly private and using adequate lengths for
+symmetric and asymmetric keys must be followed in order to maintain the
+security of this protocol.
.ti 0
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
Internet Draft.
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
.ti 0
projects / crypto.git / blobdiff