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
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
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.
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.
+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:
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
.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].
+
+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
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
network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify
type to the router's primary route.
-After joining the client to the channel server or router must send
-command reply packet for SILC_COMMAND_USERS command. This way the
-client gets the list of users on the channel. If the router joined
-the client to the channel then the router sends this command reply
-to the server which must send it further to the original client.
-
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
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
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
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).
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: 4
+ 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
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: 9
- Arguments: (1) <Status Payload> (2) <channel>
- (3) <Channel ID> (4) <channel mode mask>
- (5) <created> (6) <Channel Key Payload>
- (7) [<ban mask>] (8) [<invite list>]
- (9) [<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 mask>]
+ (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.
+ The <list count>, <Client ID list> and <client mode list> are
+ the clients curerntly on the channel and their modes on the
+ channel.
+
Client receives the channel key in the reply message as well
inside <Channel Key Payload>.
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: 7
+ Max Arguments: 8
Arguments: (1) <Channel ID> (2) <channel mode mask>
(3) [<user limit>] (4) [<passphrase>]
(5) [<ban mask>] (6) [<invite list>]
- (7) [<cipher>[:<key len>]]
+ (7) [<cipher>] (8) [<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 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
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. <ban mask> is comma (`,') separated
- list of banned clients in following format:
+ added to the ban list. <ban mask> is an comma (`,')
+ separated list of banned clients in the following format:
- [<nickname>!][<username>]@[<hostname>]
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
Wildcards maybe used when banning clients.
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. The <invite list>
- is command (`,') separated list of invited clients in following
- format:
+ is command (`,') separated list of invited clients in the
+ following format:
- [<nickname>!][<username>]@[<hostname>]
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
Wildcards maybe used when setting the invite 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. If <key len> argument is specified with
- <cipher> argument the new key is generated of <key len>
- length in bits. Only channel founder may set the cipher of
+ 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.
to set/unset this mode.
+ 0x0400 SILC_CMODE_HMAC
+
+ 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 [+|-]h on user interface
+ to set/unset this mode.
+
+
To make the mode system work, client must keep the channel 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:
client on the channel. Channel founder and channel operator
may set/unset (promote/demote) this mode.
-
Reply messages to the command:
Max Arguments: 3
21 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
- 22 SILC_COMMAND_DIE
+ 22 SILC_COMMAND_SHUTDOWN
Max Arguments: 0
Arguments: None
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
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
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.
32 SILC_STATUS_ERR_BANNED_FROM_SERVER
"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
projects / runtime.git / blobdiff