From db09edb9bcabe0b9e74c8a061770df6ad1379f34 Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Wed, 29 Aug 2001 15:00:40 +0000 Subject: [PATCH] updates. --- CHANGES | 8 + doc/Makefile.am.pre | 40 +- doc/draft-riikonen-silc-commands-02.nroff | 1935 +++++++++++++++ doc/draft-riikonen-silc-ke-auth-04.nroff | 4 +- doc/draft-riikonen-silc-pp-04.nroff | 2700 +++++++++++++++++++++ doc/draft-riikonen-silc-spec-04.nroff | 2046 ++++++++++++++++ 6 files changed, 6711 insertions(+), 22 deletions(-) create mode 100644 doc/draft-riikonen-silc-commands-02.nroff create mode 100644 doc/draft-riikonen-silc-pp-04.nroff create mode 100644 doc/draft-riikonen-silc-spec-04.nroff diff --git a/CHANGES b/CHANGES index 1e24bc44..346ca5ac 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,11 @@ +Wed Aug 29 17:55:01 EEST 2001 Pekka Riikonen + + * Statement about ignoring the Mutual Authentication flag when + performing rekey with PFS was a bit misleading. It is ignored + if it was set in the initial negotiation, it cannot be even + set in the rekey. Fixed in the ke-auth draft. Started the + new versions of the protocol drafts in the doc/. + Sun Aug 26 14:59:15 EEST 2001 Pekka Riikonen * Fixed a bug in silc_client_command_identify_save when saving diff --git a/doc/Makefile.am.pre b/doc/Makefile.am.pre index 7d906cbe..a04d8c35 100644 --- a/doc/Makefile.am.pre +++ b/doc/Makefile.am.pre @@ -24,33 +24,33 @@ DIST_SUBDIRS = SILC_DISTRIBUTION_SUBDIRS makerfc = ../scripts/makerfc all: - touch draft-riikonen-silc-spec-03.txt - touch draft-riikonen-silc-pp-03.txt - touch draft-riikonen-silc-ke-auth-03.txt - touch draft-riikonen-silc-commands-01.txt + touch draft-riikonen-silc-spec-04.txt + touch draft-riikonen-silc-pp-04.txt + touch draft-riikonen-silc-ke-auth-04.txt + touch draft-riikonen-silc-commands-02.txt -cd .. if SILC_DIST_CLIENT dist-hook: rm draft-riikonen*.txt - touch draft-riikonen-silc-spec-03.txt - touch draft-riikonen-silc-pp-03.txt - touch draft-riikonen-silc-ke-auth-03.txt - touch draft-riikonen-silc-commands-01.txt + touch draft-riikonen-silc-spec-04.txt + touch draft-riikonen-silc-pp-04.txt + touch draft-riikonen-silc-ke-auth-04.txt + touch draft-riikonen-silc-commands-02.txt else dist-hook: - touch draft-riikonen-silc-spec-03.txt - touch draft-riikonen-silc-pp-03.txt - touch draft-riikonen-silc-ke-auth-03.txt - touch draft-riikonen-silc-commands-01.txt - $(makerfc) draft-riikonen-silc-spec-03.nroff \ - draft-riikonen-silc-spec-03.txt - $(makerfc) draft-riikonen-silc-pp-03.nroff \ - draft-riikonen-silc-pp-03.txt - $(makerfc) draft-riikonen-silc-ke-auth-03.nroff \ - draft-riikonen-silc-ke-auth-03.txt - $(makerfc) draft-riikonen-silc-commands-01.nroff \ - draft-riikonen-silc-commands-01.txt + touch draft-riikonen-silc-spec-04.txt + touch draft-riikonen-silc-pp-04.txt + touch draft-riikonen-silc-ke-auth-04.txt + touch draft-riikonen-silc-commands-02.txt + $(makerfc) draft-riikonen-silc-spec-04.nroff \ + draft-riikonen-silc-spec-04.txt + $(makerfc) draft-riikonen-silc-pp-04.nroff \ + draft-riikonen-silc-pp-04.txt + $(makerfc) draft-riikonen-silc-ke-auth-04.nroff \ + draft-riikonen-silc-ke-auth-04.txt + $(makerfc) draft-riikonen-silc-commands-02.nroff \ + draft-riikonen-silc-commands-02.txt endif EXTRA_DIST = \ diff --git a/doc/draft-riikonen-silc-commands-02.nroff b/doc/draft-riikonen-silc-commands-02.nroff new file mode 100644 index 00000000..0094ece8 --- /dev/null +++ b/doc/draft-riikonen-silc-commands-02.nroff @@ -0,0 +1,1935 @@ +.pl 10.0i +.po 0 +.ll 7.2i +.lt 7.2i +.nr LL 7.2i +.nr LT 7.2i +.ds LF Riikonen +.ds RF FORMFEED[Page %] +.ds CF +.ds LH Internet Draft +.ds RH XXX +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-commands-02.txt XXX +Expires: XXX + +.in 3 + +.ce 2 +SILC Commands + + +.ti 0 +Status of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. + + +.ti 0 +Abstract + +This memo describes the commands used in the Secure Internet Live +Conferencing (SILC) protocol, specified in the Secure Internet Live +Conferencing, Protocol Specification Internet Draft [SILC1]. The +SILC Commands are very important part of the SILC protocol. Usually +the commands are used by SILC clients to manage the SILC session, but +also SILC servers may use the commands. This memo specifies detailed +command messages and command reply messages. + + + + + + + + +.ti 0 +Table of Contents + +.nf +1 Introduction .................................................. 2 + 1.1 Requirements Terminology .................................. 2 +2 SILC Commands ................................................. 2 + 2.1 SILC Commands Syntax ...................................... 2 + 2.2 SILC Commands List ........................................ 4 + 2.3 SILC Command Status Types ................................. 32 + 2.3.1 SILC Command Status Payload ......................... 32 + 2.3.2 SILC Command Status List ............................ 32 +3 Security Considerations ....................................... 37 +4 References .................................................... 38 +5 Author's Address .............................................. 39 + + +.ti 0 +1. Introduction + +This document describes the commands used in the Secure Internet Live +Conferencing (SILC) protocol, specified in the Secure Internet Live +Conferencing, Protocol Specification Internet Draft [SILC1]. This +document specifies detailed command messages and command reply messages. + +Commands are very important part on SILC network especially for client +which uses commands to operate on the SILC network. Commands are used +to set nickname, join to channel, change modes and many other things. + +See the [SILC1] for the requirements and the restrictions for the usage +of the SILC commands. The [SILC2] defines the command packet type and +the Command Payload which is actually used to deliver the commands and +command reply messages. + + +.ti 0 +1.1 Requirements Terminology + +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +MAY, and OPTIONAL, when they appear in this document, are to be +interpreted as described in [RFC2119]. + + +.ti 0 +2 SILC Commands + +.ti 0 +2.1 SILC Commands Syntax + +This section briefly describes the syntax of the command notions +in this document. Every field in command is separated from each +other by whitespaces (` ') indicating that each field is independent +argument and each argument MUST have own Command Argument Payload. +The number of maximum arguments are defined with each command +separately. The Command Argument Payload is described in [SILC2]. + +Every command defines specific number for each argument. Currently, +they are defined in ascending order; first argument has number one +(1), second has number two (2) and so on. This number is set into the +Argument Type field in the Command Argument Payload. This makes it +possible to send the arguments in free order as the number MUST be +used to identify the type of the argument. This makes is it also +possible to have multiple optional arguments in commands and in +command replies. The number of argument is marked in parentheses +before the actual argument. + + + +.in 6 +Example: Arguments: (1) (2) +.in 3 + + +Every command replies with Status Payload. This payload tells the +sender of the command whether the command was completed successfully or +whether there was an error. If error occurred the payload includes the +error type. In the next section the Status Payload is not described +as it is common to all commands and has been described here. Commands +MAY reply with other arguments as well. These arguments are command +specific and are described in the next section. + +Example command: +.in 6 + +EXAMPLE_COMMAND + +.in 8 +Max Arguments: 3 + Arguments: (1) [@] (2) + (3) [] + +The command has maximum of 3 arguments. However, only first +and second arguments are mandatory. + +First argument is mandatory but may have optional + format as well. Second argument is mandatory + argument. Third argument is optional argument. + +The numbers in parentheses are the argument specific numbers +that specify the type of the argument in Command Argument Payload. +The receiver always knows that, say, argument number two (2) is + argument, regardless of the ordering of the arguments in +the Command Payload. + +Reply messages to the command: + +Max Arguments: 4 + Arguments: (1) (2) [] + (3) (4) [] + +This command may reply with maximum of 4 arguments. However, +only the first and third arguments are mandatory. The numbers +in the parentheses have the same meaning as in the upper +command sending specification. + +Every command reply with , it is mandatory +argument for all command replies and for this reason it is not +described in the command reply descriptions. + + + +Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_TOO_MANY_TARGETS + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_NO_SUCH_NICK + +Every command reply also defines set of status message that it +may return inside the . All status messages +are defined in the section 2.3 SILC Command Status Types. + +.in 3 +Every command that has some kind of ID as argument (for example +) 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. + + +.ti 0 +2.2 SILC Commands List + +This section lists all SILC commands, however, it is expected that a +implementation and especially client implementation has many more +commands that has only local affect. These commands are official +SILC commands that has both client and server sides and cannot be +characterized as local commands. + +List of all defined commands in SILC follows. + +.in 0 + 0 SILC_COMMAND_NONE + + None. This is reserved command and MUST NOT be sent. + + + 1 SILC_COMMAND_WHOIS + + Max Arguments: 3328 + Arguments: (1) [[@]] (2) [] + (3) [] (n) [...] + + Whois command is used to query various information about specific + user. The user may be requested by their nickname and server name. + The query may find multiple matching users as there are no unique + nicknames in the SILC. The option may be given to narrow + down the number of accepted results. If this is not defined there + are no limit of accepted results. The query may also be narrowed + down by defining the server name of the nickname. The is + int string format. + + It is also possible to search the user by Client ID. If the + is provided server MUST use it as the search value + instead of the . 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. + + To prevent miss-use of this command wildcards in the nickname + or in the server name 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 sent to the router by server + so that all users are searched. However, the server still MUST + search its locally connected clients. The router MUST send + this command to the server which owns the requested client. That + 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: 8 + Arguments: (1) (2) + (3) [@] (4) + (5) (6) [] + (7) [] (8) [] + + + This command may reply with several command reply messages to + form a list of results. In this case the status payload will + include STATUS_LIST_START status in the first reply and + STATUS_LIST_END in the last reply to indicate the end of the + list. If there are only one reply the status is set to normal + STATUS_OK. + + The command replies include the Client ID of the nickname, + nickname and server name, user name and host name and user's real + name. Client SHOULD process these replies only after the last + reply has been received with the STATUS_LIST_END status. If the + option were defined in the query there will be only + 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 + Arguments: (1) [@] (2) [] + + Whowas. This command is used to query history information about + specific user. The user may be requested by their nickname and + server name. The query may find multiple matching users as there + are no unique nicknames in the SILC. The option may be + given to narrow down the number of accepted results. If this + is not defined there are no limit of accepted results. The query + may also be narrowed down by defining the server name of the + nickname. The is in string format. + + To prevent miss-use of this command wildcards in the nickname + or in the server name are not permitted. The WHOWAS requests MUST + be based on specific nickname request. + + 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: 5 + Arguments: (1) (2) + (3) [@] (4) + (5) [] + + This command may reply with several command reply messages to form + a list of results. In this case the status payload will include + STATUS_LIST_START status in the first reply and STATUS_LIST_END in + the last reply to indicate the end of the list. If there are only + one reply the status is set to normal STATUS_OK. + + The command replies with nickname and user name and host name. + Every server MUST keep history for some period of time of its + locally connected clients. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_LIST_START + SILC_STATUS_LIST_END + SILC_STATUS_ERR_NO_SUCH_NICK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + + + 3 SILC_COMMAND_IDENTIFY + + Max Arguments: 3328 + Arguments: (1) [[@]] (2) [] + (3) [] (4) [] + (5) [] (n) [...] + + Identify command is used to query information about an entity by + the entity's name or ID. This command can be used to query + information about clients, server and channels. + + The query may find multiple matching entities. The option + may be given to narrow down the number of accepted results. If + this is not defined there are no limit of accepted results. The + is in string format. + + It is also possible to search the entity by its ID. If the + is provided server must use it as the search value + instead of the entity's name. One of the arguments must be given. + It is also possible to define multiple ID Payloads to search + multiple entities sending only one IDENTIFY command. In this case + the ID Payloads are appended as normal arguments. The type of the + entity is defined by the type of the ID Payload. + + To prevent miss-use of this command wildcards in the names are + not permitted. It is not allowed to request for example all users + on server. + + Implementations may not want to give interface access to this + 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 command MUST be always sent to the router by server + so that all users are searched. However, server MUST still search + its locally connected clients. + + Reply messages to the command: + + Max Arguments: 4 + Arguments: (1) (2) + (3) [] (4) [] + + This command may reply with several command reply messages to form + a list of results. In this case the status payload will include + STATUS_LIST_START status in the first reply and STATUS_LIST_END in + the last reply to indicate the end of the list. If there are only + one reply the status is set to normal STATUS_OK. + + When querying clients the must include the client's + nickname in the following format: nickname>[@server]. The + must include the client's username and host in the following + format: username@host. + + When querying servers the must include the server's + full name. The may be omitted. + + When querying channels the must include the + channel's name. The may be omitted. + + If the option were defined in the query there will be only + many replies from the server. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_LIST_START + SILC_STATUS_LIST_END + SILC_STATUS_ERR_NO_SUCH_NICK + SILC_STATUS_ERR_NO_SUCH_SERVER + SILC_STATUS_ERR_NO_SUCH_CHANNEL + SILC_STATUS_ERR_NO_SUCH_CLIENT_ID + SILC_STATUS_ERR_NO_SUCH_SERVER_ID + SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + + + 4 SILC_COMMAND_NICK + + Max Arguments: 1 + Arguments: (1) + + Set/change nickname. This command is used to set nickname for + user. Nickname MUST NOT include any spaces (` '), non-printable + characters, commas (`,') and any wildcard characters. Note that + 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 + Arguments: (1) (2) + + This command is replied always with New ID Payload that is + generated by the server every time user changes their nickname. + Client receiving this payload MUST start using the received + Client ID as its current valid Client ID. The New ID Payload + is described in [SILC2]. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NICKNAME_IN_USE + SILC_STATUS_ERR_BAD_NICKNAME + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + + + 5 SILC_COMMAND_LIST + + Max Arguments: 1 + Arguments: (1) [] + + The list command is used to list channels and their topics on the + current server. If the 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. Router MAY reply with all channels + it knows about. + + Reply messages to the command: + + Max Arguments: 5 + Arguments: (1) (2) + (3) (4) [] + (5) [] + + This command may reply with several command reply messages to form + a list of results. In this case the status payload will include + STATUS_LIST_START status in the first reply and STATUS_LIST_END in + the last reply to indicate the end of the list. If there are only + one reply the status is set to normal STATUS_OK. + + This command replies with Channel ID, name and the topic of the + channel. If the channel is private channel the SHOULD + include the "*private*" string. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_LIST_START + SILC_STATUS_LIST_END + SILC_STATUS_ERR_WILDCARDS + 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_NO_SUCH_SERVER + + + 6 SILC_COMMAND_TOPIC + + Max Arguments: 2 + Arguments: (1) (2) [] + + This command is used to change or view the topic of a channel. + The topic for channel is returned if there is no + given. If the parameter is present, the topic + 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) (2) + (3) [] + + The command may reply with the topic of the channel if it is + set. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_ON_CHANNEL + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_NO_SUCH_CHANNEL + SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + SILC_STATUS_ERR_NO_CHANNEL_ID + SILC_STATUS_ERR_BAD_CHANNEL_ID + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_CHANNEL_PRIV + + + 7 SILC_COMMAND_INVITE + + Max Arguments: 4 + Arguments: (1) (2) [] + (3) [] (4) [] + + This command is used to invite other clients to join to the + channel. The argument is the target client's ID that + is being invited. The is the Channel ID of the + requested channel. The sender of this command MUST be on the + 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 . + + The and can be used to add to + and remove from the invite list. The format of the + and is as follows: + + [[@]!][]@[] + + 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 more than one client then the lists are an comma (`,') + separated. + + Note that the provided MUST be resolved into correct + nickname and host name and add to the invite list before sending + the notify packet. + + When this command is given with only 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 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: 3 + Arguments: (1) (2) + (3) [] + + This command replies with the invite list of the channel if it + exists. The may be omitted if the list was not + altered. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_CLIENT_ID + SILC_STATUS_ERR_NO_CLIENT_ID + SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + 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 + + Max Arguments: 1 + Arguments: (1) [] + + This command is used by client to end SILC session. The server + must close the connection to a client which sends this command. + if is given it will be sent to other clients on + channel if the client is on channel when quitting. + + Reply messages to the command: + + This command does not reply anything. + + + 9 SILC_COMMAND_KILL + + Max Arguments: 2 + Arguments: (1) (2) [] + + This command is used by SILC operators to remove a client from + SILC network. The removing has temporary effects and client may + reconnect to SILC network. The is the client to be + removed from SILC. The argument may be provided to + 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 channels. + Then, the router MUST send the same notify type to its primary + router. Finally, the router MUST send the same notify type + directly to the client which was killed. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + 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: 2 + Arguments: (1) [] (2) [] + + This command is used to fetch various information about a server. + If argument is specified the command MUST be sent to + the requested server. + + If the is specified the server information if fetched + by the provided Server ID. One of the arguments must always be + present. + + Reply messages to the command: + + Max Arguments: 4 + Arguments: (1) (2) + (3) (4) + + This command replies with the Server ID of the server and a + string which tells the information about the server. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_REGISTERED + 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) (2) [] + + This command is used by operators to force a server to try to + establish a new connection to remote server or router. The + Operator MUST specify the server/router to be connected by + setting argument. The port is 32 bit MSB value. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SERVER_PRIV + SILC_STATUS_ERR_NO_ROUTER_PRIV + + + 12 SILC_COMMAND_PING + + Max Arguments: 1 + Arguments: (1) + + This command is used by client and server to test the communication + channel to its server if one suspects that the communication is not + working correctly. The is the ID of the server the + sender is connected to. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. Server returns + SILC_STATUS_OK in Status Payload if pinging was successful. + + + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SERVER_ID + SILC_STATUS_ERR_NO_SUCH_SERVER + SILC_STATUS_ERR_NOT_REGISTERED + + + 13 SILC_COMMAND_OPER + + Max Arguments: 2 + Arguments: (1) (2) + + This command is used by normal client to obtain server operator + privileges on some server or router. Note that router operator + has router privileges that supersedes the server operator + privileges and this does not obtain those privileges. Client + MUST use SILCOPER command to obtain router level privileges. + + The is the username set in the server configurations + as operator. The 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 or certificate + authentication data (data signed with private key). The public + key that server will use to verify the signature found in the + payload should be verified. It is recommended that the public + key is saved locally in the server and server would not use + any public keys received during the SKE. + + After changing the mode the server MUST send the notify type + SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + 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_AUTH_FAILED + + + 14 SILC_COMMAND_JOIN + + Max Arguments: 5 + Arguments: (1) (2) + (3) [] (4) [] + (5) [] + + 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 sent + to router which 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 MUST NOT include any spaces (` '), + non-printable characters, commas (`,') or any wildcard characters. + + The second argument is the Client ID of the client + which is joining to the client. When client sends this command + to the server the 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 . 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. The computed MACs + of the channel message are produced by the default HMAC or by + the 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 + the ability of the user to join the channel. These conditions + are: + + o The user MUST be invited to the channel if the channel + is invite-only channel. + + o The Client ID/nickname/username/host name MUST NOT match + any active bans. + + o The correct passphrase MUST be provided if passphrase + is set to the channel. + + o The user count limit, if set, MUST NOT be reached. + + Reply messages to the command: + + Max Arguments: 14 + Arguments: (1) (2) + (3) (4) + (5) (6) + (7) [] (8) [] + (9) [] (10) [] + (11) [] (12) + (13) (14) + + This command replies with the channel name requested by the + client, channel ID of the channel and topic of the channel + if it exists. The 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 , and are + the clients currently on the channel and their modes on the + channel. The is formed by adding the ID Payloads + one after the other. The 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 . + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_BAD_PASSWORD + SILC_STATUS_ERR_CHANNEL_IS_FULL + SILC_STATUS_ERR_NOT_INVITED + SILC_STATUS_ERR_BANNED_FROM_CHANNEL + SILC_STATUS_ERR_BAD_CHANNEL + SILC_STATUS_ERR_USER_ON_CHANNEL + + + 15 SILC_COMMAND_MOTD + + Max Arguments: 1 + Arguments: (1) + + This command is used to query the Message of the Day of the server. + + Reply messages to the command: + + Max Arguments: 3 + Arguments: (1) (2) + (3) [] + + This command replies with the motd message if it exists. + + 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_NO_SUCH_SERVER + + + 16 SILC_COMMAND_UMODE + + Max Arguments: 2 + Arguments: (1) (2) + + This command is used by client to set/unset modes for itself. + However, there are some modes that the client MUST NOT set itself, + but they will be set by server. However, client MAY unset any + mode. Modes may be masked together ORing them thus having + several modes set. Client MUST keep its client mode mask + locally so that the mode setting/unsetting would work without + problems. Client may change only its own modes. + + 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 + + No specific mode for client. This is the initial + setting when new client is created. The client is + normal client now. + + + 0x0001 SILC_UMODE_SERVER_OPERATOR + + Marks the user as server operator. Client MUST NOT + set this mode itself. Server sets this mode to the + client when client attains the server operator + privileges by SILC_COMMAND_OPER command. Client + MAY unset the mode itself. + + + 0x0002 SILC_UMODE_ROUTER_OPERATOR + + Marks the user as router (SILC) operator. Client + MUST NOT this mode itself. Router sets this mode to + the client when client attains the router operator + privileges by SILC_COMMAND_SILCOPER command. Client + MAY unset the mode itself. + + + 0x0004 SILC_UMODE_GONE + + Marks that the user is not currently present in the + SILC Network. Client MAY set and unset this mode. + + Reply messages to the command: + + Max Arguments: 2 + Arguments: (1) (2) + + This command replies with the changed client mode mask that + the client MUST to keep locally. + + + 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_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_CLIENT_ID + + + 17 SILC_COMMAND_CMODE + + Max Arguments: 7 + Arguments: (1) (2) + (3) [] (4) [] + (5) [] (6) [] + (7) [] + + This command is used by client to set or change channel flags on + a channel. Channel has several modes that set various properties + of a channel. Modes may be masked together by ORing them thus + having several modes set. The is the ID of the + target channel. The client changing channel mode MUST be on + the same channel and poses sufficient privileges to be able to + change the mode. + + When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify + type MUST be distributed to the channel. + + The following channel modes are defined: + + 0x0000 SILC_CMODE_NONE + + No specific mode on channel. This is the default when + channel is created. This means that channel is just plain + normal channel. + + + 0x0001 SILC_CMODE_PRIVATE + + Channel is private channel. Private channels are shown + in the channel list listed with SILC_COMMAND_LIST command + with indication that the channel is private. Also, + client on private channel will no be detected to be on + the channel as the channel is not shown in the client's + currently joined channel list. Channel founder and + channel operator MAY set/unset this mode. + + Typical implementation would use [+|-]p on user interface + to set/unset this mode. + + + 0x0002 SILC_CMODE_SECRET + + Channel is secret channel. Secret channels are not shown + in the list listed with SILC_COMMAND_LIST command. Secret + channels can be considered to be invisible channels. + Channel founder and channel operator MAY set/unset this + mode. + + Typical implementation would use [+|-]s on user interface + to set/unset this mode. + + + 0x0004 SILC_CMODE_PRIVKEY + + Channel uses private channel key to protect the traffic + on the channel. When this mode is set the client will be + responsible to set the key it wants to use to encrypt and + decrypt the traffic on channel. Server generated channel + keys are not used at all. This mode provides additional + security as clients on channel may agree to use private + channel key that even servers do not know. Naturally, + this requires that every client on the channel knows + the key before hand (it is considered to be pre-shared- + key). The key material is RECOMMENDED to be processed + as stated in the [SILC3] in the section Processing the + Key Material. + + As it is local setting it is possible to have several + private channel keys on one channel. In this case several + clients can talk on same channel but only those clients + that share the key with the message sender will be able + to hear the talking. Client SHOULD NOT display those + message for the end user that it is not able to decrypt + when this mode is set. + + Only channel founder MAY set/unset this mode. If this + mode is unset the server will distribute new channel + key to all clients on the channel which will be used + thereafter. + + Typical implementation would use [+|-]k on user interface + to set/unset this mode. + + + 0x0008 SILC_CMODE_INVITE + + Channel is invite only channel. Client may join to this + channel only if it is invited to the channel. Channel + founder and channel operator MAY set/unset this mode. + + Typical implementation would use [+|-]i on user interface + to set/unset this mode. + + + 0x0010 SILC_CMODE_TOPIC + + The topic of the channel may only be set by client that + is channel founder or channel operator. Normal clients + on channel will not be able to set topic when this mode + is set. Channel founder and channel operator MAY set/ + unset this mode. + + Typical implementation would use [+|-]t on user interface + to set/unset this mode. + + + 0x0020 SILC_CMODE_ULIMIT + + User limit has been set to the channel. New clients + may not join to the channel when the limit set is + reached. Channel founder and channel operator MAY set/ + unset the limit. The argument is the + number of limited users. + + Typical implementation would use [+|-]l on user interface + to set/unset this mode. + + + 0x0040 SILC_CMODE_PASSPHRASE + + Passphrase has been set to the channel. Client may + join to the channel only if it is able to provide the + correct passphrase. Setting passphrases to channel + is entirely safe as all commands are protected in the + SILC network. Only channel founder MAY set/unset + the passphrase. The argument is the + set passphrase. + + Typical implementation would use [+|-]a on user interface + to set/unset this mode. + + + 0x0080 SILC_CMODE_CIPHER + + Sets specific cipher to be used to protect channel + traffic. The 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 [+|-]c on user interface + to set/unset this mode. + + + 0x0100 SILC_CMODE_HMAC + + Sets specific hmac to be used to compute the MACs of the + channel message. The 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. + + + 0x0200 SILC_CMODE_FOUNDER_AUTH + + Channel founder may set this mode to be able to regain + channel founder rights even if the client leaves the + channel. The is the Authentication Payload + consisting of the authentication method and authentication + data to be used in the authentication. The server MUST + NOT accept NONE authentication method. Also, if the + method is public key authentication the server MUST NOT + save the authentication data from the payload as the + data is different on all authentications. In this case the + server only saves the authentication method. However, + server MUST verify the sent authentication payload and + set the mode only if the verification was successful. + + Note that this mode is effective only in the current server. + The client MUST connect to the same server later to be able + to regain the channel founder rights. The server MUST save + the public key of the channel founder and use that to identify + the client which is claiming the channel founder rights. + The rights may be claimed by the SILC_CUMODE_FOUNDER + channel user mode using SILC_COMMAND_CUMODE command. The + set authentication data remains valid as long as the channel + exists or until the founder unsets this mode. + + Typical implementation would use [+|-]f 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 MUST distribute the changed channel mode mask + to all clients on the channel by sending the notify type + SILC_NOTIFY_TYPE_CMODE_CHANGE. The notify type MUST also be sent + to the server's primary router. + + Reply messages to the command: + + Max Arguments: 3 + Arguments: (1) (2) + (3) + + This command replies with the changed channel mode mask that + client MUST keep locally. + + 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 + SILC_STATUS_ERR_AUTH_FAILED + + + 18 SILC_COMMAND_CUMODE + + Max Arguments: 4 + Arguments: (1) (2) + (3) (4) [] + + 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 is the ID of the target channel. The + is OR'ed mask of modes. The 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 + the target client. + + + 0x0001 SILC_CUMODE_FOUNDER + + The client is channel founder of the channel. Usually this + mode is set only by the server when the channel was created. + However, if the SILC_CMODE_FOUNDER_AUTH channel mode has + been set, the client can claim channel founder privileges + by providing the that the server will use + to authenticate the client. The public key that server will + use to verify the must the same public key + that was saved when the SILC_CMODE_FOUNDER_AUTH channel + mode was set. The client MAY remove this mode at any time. + + + 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 this mode. + + Reply messages to the command: + + Max Arguments: 4 + Arguments: (1) (2) + (3) (4) + + This command replies with the changed channel user mode mask that + client MUST keep locally. The is the specified + channel. The 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 + SILC_STATUS_ERR_AUTH_FAILED + + + 19 SILC_COMMAND_KICK + + Max Arguments: 3 + Arguments: (1) (2) + (3) [] + + This command is used by channel operators to remove a client from + channel. The argument is the channel the client to be + removed is on currently. Note that the "kicker" must be on the same + channel. If 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, unless + the SILC_CMODE_PRIVKEY mode is set. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + 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_NO_SUCH_CHANNEL + SILC_STATUS_ERR_NO_SUCH_CLIENT_ID + SILC_STATUS_ERR_NO_CHANNEL_PRIV + SILC_STATUS_ERR_NO_CLIENT_ID + + + 20 SILC_COMMAND_BAN + + Max Arguments: 3 + Arguments: (1) (2) [] + (3) [] + + This command is used to manage the ban list of the channel + indicated by the . 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 and are used to add to and + remove from the ban list. The format of the and + the is of following format: + + [[@]!][]@[] + + 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. + + 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) (2) + (3) [] + + This command replies with the of the channel and + the current 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 + + + 21 SILC_COMMAND_CLOSE + + Max Arguments: 2 + Arguments: (1) (2) [] + + This command is used only by operator to close connection to a + remote site. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + 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_NO_SUCH_SERVER + SILC_STATUS_ERR_NO_SERVER_PRIV + SILC_STATUS_ERR_NO_SUCH_SERVER_ID + + + 22 SILC_COMMAND_SHUTDOWN + + Max Arguments: 0 + Arguments: None + + This command is used only by operator to shutdown the server. + All connections to the server will be closed and the server is + shutdown. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NO_SERVER_PRIV + + + 23 SILC_COMMAND_SILCOPER + + Max Arguments: 2 + Arguments: (1) (2) + + This command is used by normal client to obtain router operator + privileges (also known as SILC operator) on the router. Note + that router operator has privileges that supersedes the server + operator privileges. + + The is the username set in the server configurations + as operator. The 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 or certificate + authentication data (data signed with private key). The public + key that router will use to verify the signature found in the + payload should be verified. It is recommended that the public + key is saved locally in the router and router would not use + any public keys received during the SKE. + + Difference between router operator and server operator is that + router operator is able to handle cell level properties while + server operator (even on router server) is able to handle only + local properties, such as, local connections and normal server + administration. The router operator is also able to use the + SILC_COMMAND_KILL command. + + 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 + Arguments: (1) + + This command replies only with Status Payload. + + 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_AUTH_FAILED + + + 24 SILC_COMMAND_LEAVE + + Max Arguments: 1 + Arguments: (1) + + This command is used by client to leave a channel the client is + joined to. + + When leaving 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. + The key MUST NOT be re-generated if the SILC_CMODE_PRIVKEY mode + is set. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + SILC_STATUS_ERR_BAD_CHANNEL_ID + SILC_STATUS_ERR_NO_CHANNEL_ID + + + 25 SILC_COMMAND_USERS + + Max Arguments: 2 + Arguments: (1) [] (2) [] + + This command is used to list user names currently on the requested + channel; either the argument or the . + One of these arguments must be present. The server MUST resolve + the user names and send a comma (`,') separated list of user names + on the channel. Server or router MAY resolve the names by sending + SILC_COMMAND_WHOIS or SILC_COMMAND_IDENTIFY commands. + + If the requested channel is a private or secret channel, this + 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. Also, in this case + Client ID's or client modes are not sent either. + + Reply messages to the command: + + Max Arguments: 5 + Arguments: (1) (2) + (3) (4) + (5) + + 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 + is formed by adding Client ID's one after another. + The is formed by adding client's user modes on + the channel one after another (4 bytes (32 bits) each). The 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_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + SILC_STATUS_ERR_BAD_CHANNEL_ID + SILC_STATUS_ERR_NO_CHANNEL_ID + SILC_STATUS_ERR_NOT_ON_CHANNEL + + + 26 SILC_COMMAND_GETKEY + + Max Arguments: 1 + Arguments: (1) + + This command is used to fetch the public key of the client or + server indicated by the . The public key is fetched + from the server where to the client is connected. + + Reply messages to the command: + + Max Arguments: 3 + Arguments: (1) (2) + (3) [] + + This command replies with the client's or server's ID and with + the . + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_CLIENT_ID + SILC_STATUS_ERR_NO_SUCH_SERVER_ID + + + 27 - 199 + + Currently undefined commands. + + + 200 - 254 + + These commands are reserved for private use and will not be defined + in this document. + + + 255 SILC_COMMAND_MAX + + Reserved command. This must not be sent. +.in 3 + + +.ti 0 +2.3 SILC Command Status Types + +.ti 0 +2.3.1 SILC Command Status Payload + +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. The following diagram +represents the Command Status Payload (field is always in MSB order). + + +.in 21 +.nf + 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Status Message | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 6: SILC Command Status Payload + + +.in 6 +o Status Message (2 bytes) - Indicates the status message. + All Status messages are described in the next section. +.in 3 + + +.ti 0 +2.3.2 SILC Command Status List + +Command Status messages are returned in the command reply messages +to indicate whether the command were executed without errors. If error +has occurred the status indicates which error occurred. Status payload +only sends numeric reply about the status. Receiver of the payload must +convert the numeric values into human readable error messages. The +list of status messages below has an example human readable error +messages that client may display for the user. + +List of all defined command status messages following. + +.in 0 + Generic status messages: + + 0 SILC_STATUS_OK + + Ok status. Everything went Ok. The status payload maybe + safely ignored in this case. + + 1 SILC_STATUS_LIST_START + + Start of the list. There will be several command replies and + this reply is the start of the list. + + 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. + + 4 - 9 + + Currently undefined and has been reserved for the future. + + + Error status message: + + + + 10 SILC_STATUS_ERR_NO_SUCH_NICK + + "No such nickname". Requested nickname does not exist. + + 11 SILC_STATUS_ERR_NO_SUCH_CHANNEL + + "No such channel". Requested channel name does not exist. + + 12 SILC_STATUS_ERR_NO_SUCH_SERVER + + "No such server". Requested server name does not exist. + + 13 SILC_STATUS_ERR_TOO_MANY_TARGETS + + "Duplicate recipients. No message delivered". Message were + tried to be sent to recipient which has several occurrences in + the recipient list. + + 14 SILC_STATUS_ERR_NO_RECIPIENT + + "No recipient given". Command required recipient which was + not provided. + + 15 SILC_STATUS_ERR_UNKNOWN_COMMAND + + "Unknown command". Command sent to server is unknown by the + server. + + 16 SILC_STATUS_ERR_WILDCARDS + + "Wildcards cannot be used". Wildcards were provided but they + weren't permitted. + + 17 SILC_STATUS_ERR_NO_CLIENT_ID + + "No Client ID given". Client ID were expected as command + parameter but were not found. + + 18 SILC_STATUS_ERR_NO_CHANNEL_ID + + "No Channel ID given". Channel ID were expected as command + parameter but were not found. + + 19 SILC_STATUS_ERR_NO_SERVER_ID + + "No Serve ID given". Server ID were expected as command + parameter but were not found. + + 20 SILC_STATUS_ERR_BAD_CLIENT_ID + + "Bad Client ID". Client ID provided were erroneous. + + 21 SILC_STATUS_ERR_BAD_CHANNEL_ID + + "Bad Channel ID". Channel ID provided were erroneous. + + 22 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID + + "No such Client ID". Client ID provided does not exist. + + 23 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + + "No such Channel ID". Channel ID provided does not exist. + + 24 SILC_STATUS_ERR_NICKNAME_IN_USE + + "Nickname already exists". Nickname created could not be + registered because number of same nicknames were already set to + maximum. This is not expected to happen in real life but is + possible to occur. + + 25 SILC_STATUS_ERR_NOT_ON_CHANNEL + + "You are not on that channel". The command were specified for + channel user is not currently on. + + 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. + + 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. + + 29 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + + "Not enough parameters". Command requires more parameters + than provided. + + 30 SILC_STATUS_ERR_TOO_MANY_PARAMS + + "Too many parameters". Too many parameters were provided + for the command. + + 31 SILC_STATUS_ERR_PERM_DENIED + + "Permission denied". Generic permission denied error status + to indicate disallowed access. + + 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. + + 33 SILC_STATUS_ERR_BAD_PASSWORD + + "Cannot join channel. Incorrect password". Password provided for + channel were not accepted. + + 34 SILC_STATUS_ERR_CHANNEL_IS_FULL + + "Cannot join channel. Channel is full". The channel is full + and client cannot be joined to it. + + 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. + + 36 SILC_STATUS_ERR_BANNED_FROM_CHANNEL + + "Cannot join channel. You have been banned". The client has + been banned from the channel. + + 37 SILC_STATUS_ERR_UNKNOWN_MODE + + "Unknown mode". Mode provided by the client were unknown to + the server. + + 38 SILC_STATUS_ERR_NOT_YOU + + "Cannot change mode for other users". User tried to change + someone else's mode. + + 39 SILC_STATUS_ERR_NO_CHANNEL_PRIV + + "Permission denied. You are not channel operator". Command may + be executed only by channel operator. + + 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. + + 42 SILC_STATUS_ERR_NO_ROUTER_PRIV + + "Permission denied. You are not SILC operator". Command may be + executed only by router (SILC) operator. + + 43 SILC_STATUS_ERR_BAD_NICKNAME + + "Bad nickname". Nickname requested contained illegal characters + or were malformed. + + 44 SILC_STATUS_ERR_BAD_CHANNEL + + "Bad channel name". Channel requested contained illegal characters + or were malformed. + + 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. + + 47 SILC_STATUS_ERR_NO_SUCH_SERVER_ID + + "No such Server ID". Server ID provided does not exist. + +.in 3 + + +.ti 0 +3 Security Considerations + +Security is central to the design of this protocol, and these security +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 +4 References + +[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, April 2001. + +[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + April 2001. + +[SILC3] Riikonen, P., "SILC Key Exchange and Authentication + Protocols", Internet Draft, April 2001. + +[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. + +[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, + November 1998. + +[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, + September 1999. + +[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key + Infrastructure, Certificate and CRL Profile", RFC 2459, + January 1999. + +[Schneier] Schneier, B., "Applied Cryptography Second Edition", + John Wiley & Sons, New York, NY, 1996. + +[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography", + CRC Press 1997. + +[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + +[ISAKMP] Maughan D., et al, "Internet Security Association and + Key Management Protocol (ISAKMP)", RFC 2408, November + 1998. + +[IKE] Harkins D., and Carrel D., "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + +[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. + +[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +.ti 0 +5 Author's Address + +.nf +Pekka Riikonen +Snellmanninkatu 34 A 15 +70100 Kuopio +Finland + +EMail: priikone@silcnet.org + +This Internet-Draft expires XXX + diff --git a/doc/draft-riikonen-silc-ke-auth-04.nroff b/doc/draft-riikonen-silc-ke-auth-04.nroff index 1ad085ea..1ad23bdb 100644 --- a/doc/draft-riikonen-silc-ke-auth-04.nroff +++ b/doc/draft-riikonen-silc-ke-auth-04.nroff @@ -220,8 +220,8 @@ payload before the key exchange procedure starts. The cookie MUST be returned to the original sender by the responder. Following diagram represents the Key Exchange Start Payload. The lists -mentioned below are always comma (`,') separated and the list MUST -not include spaces (` '). +mentioned below are always comma (`,') separated and the list MUST NOT +include spaces (` '). .in 5 diff --git a/doc/draft-riikonen-silc-pp-04.nroff b/doc/draft-riikonen-silc-pp-04.nroff new file mode 100644 index 00000000..f2fdc8c4 --- /dev/null +++ b/doc/draft-riikonen-silc-pp-04.nroff @@ -0,0 +1,2700 @@ +.pl 10.0i +.po 0 +.ll 7.2i +.lt 7.2i +.nr LL 7.2i +.nr LT 7.2i +.ds LF Riikonen +.ds RF FORMFEED[Page %] +.ds CF +.ds LH Internet Draft +.ds RH XXX +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-pp-04.txt XXX +Expires: XXX + +.in 3 + +.ce 2 +SILC Packet Protocol + + +.ti 0 +Status of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. + + +.ti 0 +Abstract + +This memo describes a Packet Protocol used in the Secure Internet Live +Conferencing (SILC) protocol, specified in the Secure Internet Live +Conferencing, Protocol Specification Internet Draft [SILC1]. This +protocol describes the packet types and packet payloads which defines +the contents of the packets. The protocol provides secure binary packet +protocol that assures that the contents of the packets are secured and +authenticated. + + + + + + + + + +.ti 0 +Table of Contents + +.nf +1 Introduction .................................................. 3 + 1.1 Requirements Terminology .................................. 4 +2 SILC Packet Protocol .......................................... 4 + 2.1 SILC Packet ............................................... 4 + 2.2 SILC Packet Header ........................................ 5 + 2.3 SILC Packet Types ......................................... 7 + 2.3.1 SILC Packet Payloads ................................ 16 + 2.3.2 Generic payloads .................................... 16 + 2.3.2.1 ID Payload .................................. 16 + 2.3.2.2 Argument Payload ............................ 17 + 2.3.2.3 Channel Payload ............................. 18 + 2.3.2.4 Public Key Payload .......................... 19 + 2.3.3 Disconnect Payload .................................. 19 + 2.3.4 Success Payload ..................................... 19 + 2.3.5 Failure Payload ..................................... 20 + 2.3.6 Reject Payload ...................................... 21 + 2.3.7 Notify Payload ...................................... 22 + 2.3.8 Error Payload ....................................... 21 + 2.3.9 Channel Message Payload ............................. 28 + 2.3.10 Channel Key Payload ................................ 31 + 2.3.11 Private Message Payload ............................ 33 + 2.3.12 Private Message Key Payload ........................ 34 + 2.3.13 Command Payload .................................... 36 + 2.3.14 Command Reply Payload .............................. 37 + 2.3.15 Connection Auth Request Payload .................... 37 + 2.3.16 New ID Payload ..................................... 38 + 2.3.17 New Client Payload ................................. 39 + 2.3.18 New Server Payload ................................. 40 + 2.3.19 New Channel Payload ................................ 41 + 2.3.20 Key Agreement Payload .............................. 42 + 2.3.21 Cell Routers Payload ............................... 43 + 2.4 SILC ID Types ............................................. 44 + 2.5 Packet Encryption And Decryption .......................... 44 + 2.5.1 Normal Packet Encryption And Decryption ............. 45 + 2.5.2 Channel Message Encryption And Decryption ........... 45 + 2.5.3 Private Message Encryption And Decryption ........... 46 + 2.6 Packet MAC Generation ..................................... 47 + 2.7 Packet Padding Generation ................................. 47 + 2.8 Packet Compression ........................................ 48 + 2.9 Packet Sending ............................................ 48 + 2.10 Packet Reception ......................................... 49 + 2.11 Packet Routing ........................................... 49 + 2.12 Packet Broadcasting ...................................... 50 +3 Security Considerations ....................................... 50 +4 References .................................................... 50 +5 Author's Address .............................................. 52 + +.ti 0 +List of Figures + +.nf +Figure 1: Typical SILC Packet +Figure 2: SILC Packet Header +Figure 3: ID Payload +Figure 4: Argument Payload +Figure 5: Channel Payload +Figure 6: Public Key Payload +Figure 7: Disconnect Payload +Figure 8: Success Payload +Figure 9: Failure Payload +Figure 10: Reject Payload +Figure 11: Notify Payload +Figure 12: Error Payload +Figure 13: Channel Message Payload +Figure 14: Channel Key Payload +Figure 15: Private Message Payload +Figure 16: Private Message Key Payload +Figure 17: Command Payload +Figure 18: Connection Auth Request Payload +Figure 19: New Client Payload +Figure 20: New Server Payload +Figure 21: Key Agreement Payload +Figure 22: Cell Routers Payload + + +.ti 0 +1. Introduction + +This document describes a Packet Protocol used in the Secure Internet +Live Conferencing (SILC) protocol specified in the Secure Internet Live +Conferencing, Protocol Specification Internet Draft [SILC1]. This +protocol describes the packet types and packet payloads which defines +the contents of the packets. The protocol provides secure binary packet +protocol that assures that the contents of the packets are secured and +authenticated. + +The basis of SILC protocol relies in the SILC packets and it is with +out a doubt the most important part of the protocol. It is also probably +the most complicated part of the protocol. Packets are used all the +time in the SILC network to send messages, commands and other information. +All packets in SILC network are always encrypted and their integrity +is assured by computed MACs. The protocol defines several packet types +and packet payloads. Each packet type usually has a specific packet +payload that actually defines the contents of the packet. Each packet +also includes a default SILC Packet Header that provides sufficient +information about the origin of the packet and destination of the +packet. + + +.ti 0 +1.1 Requirements Terminology + +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +MAY, and OPTIONAL, when they appear in this document, are to be +interpreted as described in [RFC2119]. + + +.ti 0 +2 SILC Packet Protocol + +.ti 0 +2.1 SILC Packet + +SILC packets deliver messages from sender to receiver securely by +encrypting important fields of the packet. The packet consists of +default SILC Packet Header, Padding, Packet Payload data, and, packet +MAC. + +The following diagram illustrates typical SILC packet. + + +.in 5 +.nf + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +| n bytes | 1 - n bytes | n bytes | n bytes +| SILC Header | Padding | Data Payload | MAC + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +.in 3 + +.ce +Figure 1: Typical SILC Packet + + +SILC Header is always the first part of the packet and its purpose +is to provide information about the packet. It provides for example +the packet type, origin of the packet and the destination of the packet. +The header is variable in length and first two (2) bytes of the +header (thus first two bytes of the packet) are not encrypted. The +first two (2) bytes are the length of the packet which is not encrypted. +See the following section for description of SILC Packet header. Packets +without SILC header or with malformed SILC header MUST be dropped. + +Padding follows the packet header. The purpose of the padding is to +make the packet multiple by eight (8) or by the block size of the +cipher used in the encryption, which ever is larger. The maximum +length of padding is currently 16 bytes. The padding is always +encrypted. + +Data payload area follows padding and it is the actual data of the +packet. The packet data is the packet payloads defined in this +protocol. The data payload area is always encrypted. + +The last part of SILC packet is the packet MAC that assures the +integrity of the packet. The MAC is always computed from the packet +before the encryption is applied to the packet. If compression is used +in the packet the MAC is computed after the compression has been +applied. The compression, on the other hand, is always applied before +encryption. + +All fields in all packet payloads are always in MSB (most significant +byte first) order. + + +.ti 0 +2.2 SILC Packet Header + +The SILC packet header is applied to all SILC packets and it is +variable in length. The purpose of SILC Packet header is to provide +detailed information about the packet. The receiver of the packet +uses the packet header to parse the packet and gain other relevant +parameters of the packet. + +The following diagram represents the SILC packet header. (*) indicates +that this field is never encrypted. Other fields are always encrypted. + +.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 * | Flags | Packet Type | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Source ID Length | Destination ID Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Src ID Type | | ++-+-+-+-+-+-+-+-+ + +| | +~ Source ID ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Dst ID Type | | ++-+-+-+-+-+-+-+-+ + +| | +~ Destination ID ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 2: SILC Packet Header + + +.in 6 +o Payload Length (2 bytes) - Is the length of the packet + not including the padding of the packet. This field must + not be encrypted but must always be authenticated. + +o Flags (1 byte) - Indicates flags to be used in packet + processing. Several flags may be set by ORing the flags + together. + + The following flags are reserved for this field: + + + No flags 0x00 + + In this case the field is ignored. + + + Private Message Key 0x01 + + Indicates that the packet must include private + message that is encrypted using private key set by + client. Servers does not know anything about this + key and this causes that the private message is + not handled by the server at all, it is just + passed along. See section 2.5.3 Private Message + Encryption And Decryption for more information. + + + List 0x02 + + Indicates that the packet consists of list of + packet payloads indicated by the Packet Type field. + The payloads are added one after the other. Note that + there are packet types that must not be used as + list. Parsing of list packet is done by calculating + the length of each payload and parsing them one by + one. + + + Broadcast 0x04 + + Marks the packet to be broadcasted. Client cannot + send broadcast packet and normal server cannot send + broadcast packet. Only router server may send broadcast + packet. The router receiving of packet with this flag + set MUST send (broadcast) the packet to its primary + route. If router has several router connections the + packet may be sent only to the primary route. See + section 2.12 Packet Broadcasting for description of + packet broadcasting. + +.in 3 + + + + +o Packet Type (1 byte) - Is the type of the packet. Receiver + uses this field to parse the packet. See section 2.3 + SILC Packets for list of defined packet types. + +o Source ID Length (2 bytes) - Indicates the length of the + Source ID field in the header, not including this or any + other fields. + +o Destination ID Length (2 bytes) - Indicates the length of the + Destination ID field in the header, not including this or + any other fields. + +o Src ID Type (1 byte) - Indicates the type of ID in the + Source ID field. See section 2.4 SILC ID Types for + defined ID types. + +o Source ID (variable length) - The actual source ID that + indicates which is the original sender of the packet. + +o Dst ID Type (1 byte) - Indicates the type of ID in the + Destination ID field. See section 2.4 SILC ID Types for + defined ID types. + +o Destination ID (variable length) - The actual destination + ID that indicates which is the end receiver of the packet. + + +.ti 0 +2.3 SILC Packet Types + +SILC packet types defines the contents of the packet and it is used by +the receiver to parse the packet. The packet type is 8 bits, as a one +byte, in length. The range for the packet types are from 0 - 255, +where 0 is never sent and 255 is currently reserved for future +extensions and MUST NOT be defined to any other purpose. Every SILC +specification compliant implementation SHOULD support all of these packet +types. + +The below list of the SILC Packet types includes reference to the packet +payload as well. Packet payloads are the actual packet, that is, the data +that the packet consists of. Each packet type defines packet payload +which usually may only be sent with the specific packet type. + +Most of the packets are packets that must be destined directly to entity +that is connected to the sender. It is not allowed, for example, for +router to send disconnect packet to client that is not directly connected +to the router. However, there are some special packet types that may +be destined to some entity that the sender has not direct connection +with. These packets are for example private message packets, channel +message packets, command packets and some other packets that may be +broadcasted in the SILC network. If the packet is allowed to be sent to +indirectly connected entity it is mentioned separately in the packet +description (unless it is obvious as in private and channel message +packets). Other packets MUST NOT be sent or accepted, if sent, to +indirectly connected entities. + +List of SILC Packet types are defined as follows. + +.in 1 + 0 SILC_PACKET_NONE + + This type is reserved and it is never sent. + + + 1 SILC_PACKET_DISCONNECT + + This packet is sent to disconnect the remote end. Reason of + the disconnection is sent inside the packet payload. Client + usually does not send this packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.3 Disconnect Payload + + + 2 SILC_PACKET_SUCCESS + + This packet is sent upon successful execution of some protocol. + The status of the success is sent in the packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.4 Success Payload + + + 3 SILC_PACKET_FAILURE + + This packet is sent upon failure of some protocol. The status + of the failure is sent in the packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.5 Failure Payload + + + 4 SILC_PACKET_REJECT + + This packet MAY be sent upon rejection of some protocol. + The status of the rejection is sent in the packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.6 Reject Payload + + + 5 SILC_PACKET_NOTIFY + + This packet is used to send notify message, usually from + server to client, although it MAY be sent from server to another + server as well. Client MUST NOT send this packet. Server MAY + send this packet to channel as well when the packet is + distributed to all clients on the channel. + + Payload of the packet: See section 2.3.7 Notify Payload. + + + 6 SILC_PACKET_ERROR + + This packet is sent when an error occurs. Server MAY + send this packet. Client MUST NOT send this packet. The + client MAY entirely ignore the packet, however, server is + most likely to take action anyway. This packet MAY be sent + to entity that is indirectly connected to the sender. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.8 Error Payload. + + + 7 SILC_PACKET_CHANNEL_MESSAGE + + This packet is used to send messages to channels. The packet + includes Channel ID of the channel and the actual message to + the channel. Messages sent to the channel are always protected + by channel specific keys. Channel Keys are distributed by + SILC_PACKET_CHANNEL_KEY packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.9 Channel Message + Payload + + + 8 SILC_PACKET_CHANNEL_KEY + + This packet is used to distribute new key for particular + channel. Each channel has their own independent keys that + is used to protect the traffic on the channel. Only server + may send this packet. This packet MAY be sent to entity + that is indirectly connected to the sender. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.10 Channel Key Payload + + + 9 SILC_PACKET_PRIVATE_MESSAGE + + This packet is used to send private messages from client + to another client. By default, private messages are protected + by session keys established by normal key exchange protocol. + However, it is possible to use specific key to protect private + messages. SILC_PACKET_PRIVATE_MESSAGE_KEY packet is used to + agree the key with the remote client. Pre-shared key MAY be + used as well if both of the client knows it, however, it needs + to be agreed outside SILC. See more of this in [SILC1]. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.11 Private Message + Payload + + + 10 SILC_PACKET_PRIVATE_MESSAGE_KEY + + This packet is used to agree about a key to be used to protect + the private messages between two clients. If this is not sent + the normal session key is used to protect the private messages + inside SILC network. Agreeing to use specific key to protect + private messages adds security, as no server between the two + clients will be able to decrypt the private message. However, + servers inside SILC network are considered to be trusted, thus + using normal session key to protect private messages does not + degrade security. Whether to agree to use specific keys by + default or to use normal session keys by default, is + implementation specific issue. See more of this in [SILC1]. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.12 Private Message + Key Payload + + + 11 SILC_PACKET_COMMAND + + This packet is used to send commands from client to server. + Server MAY send this packet to other servers as well. All + commands are listed in their own section SILC Command Types + in [SILC4]. The contents of this packet is command specific. + This packet MAY be sent to entity that is indirectly connected + to the sender. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.13 Command Payload + + + 12 SILC_PACKET_COMMAND_REPLY + + This packet is sent as reply to the SILC_PACKET_COMMAND packet. + The contents of this packet is command specific. This packet + MAY be sent to entity that is indirectly connected to the + sender. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.14 Command Reply + Payload and section 2.3.13 Command + Payload + + + 13 SILC_PACKET_KEY_EXCHANGE + + This packet is used to start SILC Key Exchange Protocol, + described in detail in [SILC3]. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: Payload of this packet is described + in the section SILC Key Exchange + Protocol and its sub sections in + [SILC3]. + + + 14 SILC_PACKET_KEY_EXCHANGE_1 + + This packet is used as part of the SILC Key Exchange Protocol. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: Payload of this packet is described + in the section SILC Key Exchange + Protocol and its sub sections in + [SILC3]. + + + 15 SILC_PACKET_KEY_EXCHANGE_2 + + This packet is used as part of the SILC Key Exchange Protocol. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: Payload of this packet is described + in the section SILC Key Exchange + Protocol and its sub sections in + [SILC3]. + + + 16 SILC_PACKET_CONNECTION_AUTH_REQUEST + + This packet is used to request the authentication method to + be used in the SILC Connection Authentication Protocol. If + initiator of the protocol does not know the mandatory + authentication method this packet MAY be used to determine it. + + The party receiving this payload MUST respond with the same + packet including the mandatory authentication method. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.15 Connection Auth + Request Payload + + + + + 17 SILC_PACKET_CONNECTION_AUTH + + This packet is used to start and perform the SILC Connection + Authentication Protocol. This protocol is used to authenticate + the connecting party. The protocol is described in detail in + [SILC3]. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: Payload of this packet is described + in the section SILC Authentication + Protocol and it sub sections in [SILC]. + + + 18 SILC_PACKET_NEW_ID + + This packet is used to distribute new ID's from server to + router and from router to all routers in the SILC network. + This is used when for example new client is registered to + SILC network. The newly created ID's of these operations are + distributed by this packet. Only server may send this packet, + however, client MUST be able to receive this packet. This + packet MAY be sent to entity that is indirectly connected + to the sender. + + Payload of the packet: See section 2.3.16 New ID Payload + + + 19 SILC_PACKET_NEW_CLIENT + + This packet is used by client to register itself to the + SILC network. This is sent after key exchange and + authentication protocols has been completed. Client sends + various information about itself in this packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.17 New Client Payload + + + 20 SILC_PACKET_NEW_SERVER + + This packet is used by server to register itself to the + SILC network. This is sent after key exchange and + authentication protocols has been completed. Server sends + this to the router it connected to, or, if router was + connecting, to the connected router. Server sends its + Server ID and other information in this packet. The client + MUST NOT send or receive this packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.18 New Server Payload + + + 21 SILC_PACKET_NEW_CHANNEL + + This packet is used to notify routers about newly created + channel. Channels are always created by the router and it MUST + notify other routers about the created channel. Router sends + this packet to its primary route. Client MUST NOT send this + packet. This packet MAY be sent to entity that is indirectly + connected to the sender. + + Payload of the packet: See section 2.3.19 New Channel Payload + + + 22 SILC_PACKET_REKEY + + This packet is used to indicate that re-key must be performed + for session keys. See section Session Key Regeneration in + [SILC1] for more information. This packet does not have + a payload. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + + 23 SILC_PACKET_REKEY_DONE + + This packet is used to indicate that re-key is performed and + new keys must be used hereafter. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + + 24 SILC_PACKET_HEARTBEAT + + This packet is used by clients, servers and routers to keep the + connection alive. It is recommended that all servers implement + keepalive actions and perform it to both direction in a link. + This packet does not have a payload. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + + 25 SILC_PACKET_KEY_AGREEMENT + + This packet is used by clients to request key negotiation + between another client in the SILC network. If the negotiation + is started it is performed using the SKE protocol. The result of + the negotiation, the secret key material, can be used for + example as private message key. The server and router MUST NOT + send this packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.20 Key Agreement Payload + + + 26 SILC_PACKET_CELL_ROUTERS + + This packet is used by primary router in the cell to notify its + primary router what other routers (backup routers) exist in the + cell. In case of failure of the primary router in the cell the + first router in the list will act as primary router of the cell. + This packet MAY be sent at anytime after connection has been + registered to the primary router. The client MUST NOT send this + packet. + + This packet MUST NOT be sent as list and the List flag MUST + NOT be set. + + Payload of the packet: See section 2.3.21 Cell Routers Payload + + + 27 - 199 + + Currently undefined commands. + + + 200 - 254 + + These packet types are reserved for private use and they will + not be defined by this document. + + + + + 255 SILC_PACKET_MAX + + This type is reserved for future extensions and currently it + MUST NOT be sent. +.in 3 + + +.ti 0 +2.3.1 SILC Packet Payloads + +All payloads resides in the main data area of the SILC packet. However +all payloads MUST be at the start of the data area after the SILC +packet header and padding. All fields in the packet payload are always +encrypted, as they reside in the data area of the packet which is +always encrypted. + +Payloads described in this section are common payloads that MUST be +accepted anytime during SILC session. Most of the payloads may only +be sent with specific packet type which is defined in the description +of the payload. + +There are a lot of other payloads in the SILC as well. However, they +are not common in the sense that they could be sent at any time. +These payloads are not described in this section. These are payloads +such as SILC Key Exchange payloads and so on. These are described +in [SILC1], [SILC3] and [SILC4]. + + +.ti 0 +2.3.2 Generic payloads + +This section describes generic payloads that are not associated to any +specific packet type. They can be used for example inside some other +packet payloads. + + +.ti 0 +2.3.2.1 ID Payload + +This payload can be used to send an ID. ID's are variable in length +thus this payload provides a way to send variable length ID's. + + + + + + + + + + + + +The following diagram represents the ID Payload. + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| ID Type | ID Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ ID Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 3: ID Payload + + +.in 6 +o ID Type (2 bytes) - Indicates the type of the ID. See + section 2.4 SILC ID Types for list of defined ID types. + +o ID Length (2 bytes) - Length of the ID Data area not + including the length of any other fields in the payload. + +o ID Data (variable length) - The actual ID data. +.in 3 + + +.ti 0 +2.3.2.2 Argument Payload + +Argument Payload is used to set arguments for any packet payload that +needs and supports arguments, such as commands. Number of arguments +associated with a packet MUST be indicated by the packet payload which +needs the arguments. Argument Payloads MUST always reside right after +the packet payload needing the arguments. Incorrect amount of argument +payloads MUST cause rejection of the packet. The following diagram +represents the Argument Payload. + +The following diagram represents the Argument Payload. + +.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 | Argument Type | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Argument Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 4: Argument Payload + + +.in 6 +o Payload Length (2 bytes) - Length of the argument payload data + area not including the length of any other fields in the + payload. + +o Argument Type (1 byte) - Indicates the type of the argument. + Every argument may have a specific type that MUST be defined + by the packet payload needing the argument. For example + every command specify a number for each argument that maybe + associated with the command. By using this number the receiver + of the packet knows what type of argument this is. If there is + no specific argument type this field is set to zero (0). + +o Argument Data (variable length) - Argument data. +.in 3 + + +.ti 0 +2.3.2.3 Channel Payload + +Generic Channel Payload may be used to send information about channel, +its name, the Channel ID and a mode. + +The following diagram represents the Channel Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Channel Name Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Channel Name ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Channel ID Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Channel ID ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Mode Mask | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 5: New Channel Payload + + +.in 6 +o Channel Name Length (2 bytes) - Length of the channel name + field. + +o Channel Name (variable length) - The name of the channel. + +o Channel ID Length (2 bytes) - Length of the Channel ID field. + +o Channel ID (variable length) - The Channel ID. + +o Mode Mask (4 bytes) - A mode. This can be the mode of the + channel but it can also be the mode of the client on the + channel. The contents of this field is dependent of the + usage of this payload. The usage is defined separately + when this payload is used. This is a 32 bit MSB first value. +.in 3 + + +.ti 0 +2.3.2.4 Public Key Payload + +Generic Public Key Payload may be used to send different types of +public keys and certificates. + +The following diagram represents the Public Key Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Public Key Length | Public Key Type | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Public Key of the party (or certificate) ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 6: Public Key Payload + + +.in 6 +o Public Key Length (2 bytes) - The length of the Public Key + (or certificate) field, not including any other field. + +o Public Key Type (2 bytes) - The public key (or certificate) + type. This field indicates the type of the public key in + the packet. See the [SILC3] for defined public key types. + +o Public Key (or certificate) (variable length) - The + public key or certificate. +.in 3 + + +.ti 0 +2.3.3 Disconnect Payload + +Disconnect payload is sent upon disconnection. The payload is simple; +reason of disconnection is sent to the disconnected party. + +The payload may only be sent with SILC_PACKET_DISCONNECT packet. It +MUST NOT be sent in any other packet type. The following diagram +represents the Disconnect Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Disconnect Message ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 7: Disconnect Payload + + + + +.in 6 +o Disconnect Message (variable length) - Human readable + reason of the disconnection. +.in 3 + + +.ti 0 +2.3.4 Success Payload + +Success payload is sent when some protocol execution is successfully +completed. The payload is simple; indication of the success is sent. +This may be any data, including binary or human readable data. + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Success Indication ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 8: Success Payload + + +.in 6 +o Success Indication (variable length) - Indication of + the success. This may be for example some flag that + indicates the protocol and the success status or human + readable success message. The true length of this + payload is available by calculating it from the SILC + Packet Header. +.in 3 + + + +.ti 0 +2.3.5 Failure Payload + +This is opposite of Success Payload. Indication of failure of +some protocol is sent in the payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Failure Indication ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 9: Failure Payload + + +.in 6 +o Failure Indication (variable length) - Indication of + the failure. This may be for example some flag that + indicates the protocol and the failure status or human + readable failure message. The true length of this + payload is available by calculating it from the SILC + Packet Header. +.in 3 + + +.ti 0 +2.3.6 Reject Payload + +This payload is sent when some protocol is rejected to be executed. +Other operations MAY send this as well that was rejected. The +indication of the rejection is sent in the payload. The indication +may be binary or human readable data. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Reject Indication ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 10: Reject Payload + + +.in 6 +o Reject Indication (variable length) - Indication of + the rejection. This maybe for example some flag that + indicates the protocol and the rejection status or human + readable rejection message. The true length of this + payload is available by calculating it from the SILC + Packet Header. +.in 3 + + +.ti 0 +2.3.7 Notify Payload + +Notify payload is used to send notify messages. The payload is usually +sent from server to client, however, server MAY send it to another +server as well. This payload MAY also be sent to a channel. Client +MUST NOT send this payload. The receiver of this payload MAY ignore +the contents of the payload, however, notify message SHOULD be audited. + +The payload may only be sent with SILC_PACKET_NOTIFY packet. It MUST +not be sent in any other packet type. The following diagram represents +the Notify Payload. + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Notify Type | Payload Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Argument Nums | ++-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 11: Notify Payload + + +.in 6 +o Notify Type (2 bytes) - Indicates the type of the notify + message. + +o Payload Length (2 bytes) - Length of the entire Notify Payload + including any associated Argument Payloads. + +o Argument Nums (2 bytes) - Indicates the number of Argument + Payloads associated to this payload. Notify types may define + arguments to be send along the notify message. +.in 3 + +The following list of currently defined notify types. The format for +notify arguments is same as in SILC commands described in [SILC4]. +Also, all ID's sent in arguments are sent inside ID Payload. + +.in 6 +0 SILC_NOTIFY_TYPE_NONE + + If no specific notify type apply for the notify message this type + MAY be used. + + Max Arguments: 1 + Arguments: (1) + + The is implementation specific free text string. + Receiver MAY ignore this message. + + +1 SILC_NOTIFY_TYPE_INVITE + + Sent when an client is invited to a channel. This is also sent + when the invite list of the channel is changed. This notify type + is sent between routers and if an client was invited, to the + client as well. In this case the packet is destined to the client. + + Max Arguments: 5 + Arguments: (1) (2) + (3) [] (4) [] + (5) [] + + The is the channel. The is the name + of the channel and is provided because the client which receives + this notify packet may not have a way to resolve the name of the + channel from the . The is the + Client ID which invited the client to the channel. The and the indicates the added or removed + client from the channel's invite list. The format of the and the is defined in the [SILC4] with + SILC_COMMAND_INVITE command. + + The and MUST NOT be sent when + the packet is destined to a client. + + +2 SILC_NOTIFY_TYPE_JOIN + + Sent when client has joined to a channel. The server MUST + distribute this type only to the local clients on the channel + and then send it to its primary router. The router or server + receiving the packet distributes this type to the local clients + on the channel and broadcast it to the network. + + Max Arguments: 2 + Arguments: (1) [] (2) + + The is the client that joined to the channel indicated + by the . + + +3 SILC_NOTIFY_TYPE_LEAVE + + Sent when client has left a channel. The server must distribute + this type only to the local clients on the channel and then send + it to its primary router. The router or server receiving the + packet distributes this type to the local clients on the channel + and broadcast it to the network. + + Max Arguments: 1 + Arguments: (1) + + The is the client which left the channel. + + +4 SILC_NOTIFY_TYPE_SIGNOFF + + Sent when client signoff from SILC network. The server MUST + distribute this type only to the local clients on the channel and + then send it to its primary router. The router or server receiving + the packet distributes this type to the local clients on the + channel and broadcast it to the network. + + Max Arguments: 2 + Arguments: (1) (2) + + The is the client which left SILC network. The + is free text string indicating the reason of the signoff. + + +5 SILC_NOTIFY_TYPE_TOPIC_SET + + Sent when topic is set/changed on a channel. This type must be + sent only to the clients which is joined on the channel which + topic was set or changed. + + Max Arguments: 2 + Arguments: (1) (2) + + The is the client which set or changed the . + + +6 SILC_NOTIFY_TYPE_NICK_CHANGE + + Sent when client changes nick on a channel. The server MUST + distribute this type only to the local clients on the channel + and then send it to its primary router. The router or server + receiving the packet distributes this type to the local clients + on the channel and broadcast it to the network. + + Max Arguments: 2 + Arguments: (1) (2) + + The is the old ID of the client which changed + the nickname. The is the new ID generated by + the change of the nickname. + + +7 SILC_NOTIFY_TYPE_CMODE_CHANGE + + Sent when channel mode has changed. This type MUST be sent only + to the clients which is joined on the channel which mode was + changed. + + Max Arguments: 4 + Arguments: (1) (2) + (3) [] (4) <[hmac>] + + The is the ID (usually Client ID but it can be + Server ID as well when the router is enforcing channel mode + change) of the entity which changed the mode. The + is the new mode mask of the channel. The client can safely + ignore the argument since the SILC_PACKET_CHANNEL_KEY + packet will force the new channel key change anyway. The + argument is important since the client is responsible of setting + the new HMAC and the hmac key into use. + + +8 SILC_NOTIFY_TYPE_CUMODE_CHANGE + + Sent when user mode on channel has changed. This type MUST be + sent only to the clients which is joined on the channel where + the target client is on. + + Max Arguments: 3 + Arguments: (1) (2) + (3) + + The is the ID (usually Client ID but it can be + Server ID as well when the router is enforcing user's mode + change) of the entity which changed the mode. The + is the new mode mask of the channel. The + is the client which mode was changed. + + +9 SILC_NOTIFY_TYPE_MOTD + + Sent when Message of the Day (motd) is sent to a client. + + Max Arguments: 1 + Arguments: (1) + + The is the Message of the Day. + + +10 SILC_NOTIFY_TYPE_CHANNEL_CHANGE + + Sent when channel's ID has changed for a reason or another. + This is sent by normal server to the client. This can also be + sent by router to other server to force the Channel ID change. + The Channel ID MUST be changed to use the new one. When sent + to clients, this type MUST be sent only to the clients which is + joined on the channel. + + Max Arguments: 2 + Arguments: (1) (2) + + The is the channel's old ID and the is the new one that MUST replace the old one. + + +11 SILC_NOTIFY_TYPE_SERVER_SIGNOFF + + Sent when server quits SILC network. Those clients from this + server that are on channels must be removed from the channel. + + Max Arguments: 2000 + Arguments: (1) (n) [ [...] + + The is the server's ID. The rest of the arguments + are the Client ID's of the client's which are coming from this + server and are thus quitting the SILC network also. If the + maximum number of arguments are reached another + SILC_NOTIFY_TYPE_SERVER_SIGNOFF notify packet MUST be sent. + When this notify packet is sent between routers the Client ID's + MAY be omitted. + + +12 SILC_NOTIFY_TYPE_KICKED + + Sent when a client has been kicked from a channel. This is + sent also to the client which was kicked from the channel. + The client which was kicked from the channel MUST be removed + from the channel. This notify type is always destined to the + channel. The router or server receiving the packet distributes + this type to the local clients on the channel and broadcast it + to the network. + + Max Arguments: 2 + Arguments: (1) (2) [] + + The is the client which was kicked from the channel. + The kicker may have set the to indicate the reason for + the kicking. + + +13 SILC_NOTIFY_TYPE_KILLED + + Sent when a client has been killed from the network. This is sent + also to the client which was killed from the network. The client + which was killed from the network MUST be removed from the network. + This notify type is destined directly to the client which was + killed and to channel if the client is on any channel. The router + or server receiving the packet distributes this type to the local + clients on the channel and broadcast it to the network. + + Max Arguments: 2 + Arguments: (1) (2) [] + + The is the client which was killed from the network. + The killer may have set the to indicate the reason for + the killing. + + +14 SILC_NOTIFY_TYPE_UMODE_CHANGE + + Sent when user's mode in the SILC changes. This type is sent + only between routers as broadcast packet. + + Max Arguments: 2 + Arguments: (1) (2) + + The is the client which mode was changed. The + is the new mode mask. + + +15 SILC_NOTIFY_TYPE_BAN + + Sent when the ban list of the channel is changed. This type is + sent only between routers as broadcast packet. + + Max Arguments: 3 + Arguments: (1) (2) [] + (3) [] + + The is the channel which ban list was changed. The + is used to indicate that a ban was added and the + is used to indicate that a ban was removed from + the ban list. The format of the and the + is defined in the [SILC4] with SILC_COMMAND_BAN + command. + +.in 3 + +Notify types starting from 16384 are reserved for private notify +message types. + + +.ti 0 +2.3.8 Error Payload + +Error payload is sent upon error. Error may occur in various +conditions when server sends this packet. Client MUST NOT send this +payload but MUST be able to accept it. However, client MAY +totally ignore the contents of the packet as server is going to +take action on the error anyway. However, it is recommended +that the client takes error packet seriously. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Error Message ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 12: Error Payload + + +.in 6 +o Error Message (variable length) - Human readable error + message. +.in 3 + + +.ti 0 +2.3.9 Channel Message Payload + +Channel messages are the most common messages sent in the SILC. +Channel Message Payload is used to send message to channels. These +messages can only be sent if client has joined to some channel. +Even though this packet is the most common in SILC it is still +special packet. Some special handling on sending and reception +of channel message is required. + +Padding MUST be applied into this payload since the payload is +encrypted separately from other parts of the packet with the +channel specific key. Hence the requirement of the padding. +The padding SHOULD be random data. The packet MUST be made +multiple by eight (8) or by the block size of the cipher, which +ever is larger. + +The SILC header in this packet is encrypted with the session key +of the next receiver of the packet. Nothing else is encrypted +with that key. Thus, the actual packet and padding to be +encrypted with the session key is SILC Header plus padding to it +to make it multiple by eight (8) or multiple by the block size +of the cipher, which ever is larger. + +Receiver of the the channel message packet is able to determine +the channel the message is destined to by checking the destination +ID from the SILC Packet header which tells the destination channel. +The original sender of the packet is also determined by checking +the source ID from the header which tells the client which sent +the message. + +The payload may only be sent with SILC_PACKET_CHANNEL_MESSAGE packet. +It MUST NOT be sent in any other packet type. The following diagram +represents the Channel Message Payload. + +(*) indicates that the field is not encrypted. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Flags | Message Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Message Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Padding Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Padding ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ MAC ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Initial Vector * ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 13: Channel Message Payload + + +.in 6 +o Flags (2 bytes) - Includes the flags of the channel + messages. The flags can indicate a reason or purpose + for the channel message. Note that the Private Message + Payload use these same flags for the same purpose. The + following flags are defined: + + 0x0000 SILC_MESSAGE_FLAG_NONE + + No specific flags set. + + 0x0001 SILC_MESSAGE_FLAG_AUTOREPLY + + This message is an automatic reply to an earlier + received message. + + 0x0002 SILC_MESSAGE_FLAG_NOREPLY + + There should not be reply messages to this + message. + + 0x0004 SILC_MESSAGE_FLAG_ACTION + + The sender is performing an action and the message + is the indication of the action. + + 0x0008 SILC_MESSAGE_FLAG_NOTICE + + The message is for example an informational notice + type message. + + 0x0010 SILC_MESSAGE_FLAG_REQUEST + + This is a generic request flag to send request + messages. A separate document should define any + payloads associated to this flag. + + 0x0020 SILC_MESSAGE_FLAG_SIGNED + + This flag indicates that the message is signed + with sender's private key and thus can be verified + by the receiver using the sender's public key. A + separate document should define the detailed procedure + of the signing process and any associated payloads + of this flag. + + 0x0040 - 0x0200 RESERVED + + Reserved for future flags + + 0x0400 - 0x8000 PRIVATE RANGE + + Private range for free use. + +o Message Length (2 bytes) - Indicates the length of the + the Message Data field in the payload, not including any + other field. + +o Message Data (variable length) - The actual message to + the channel. + +o Padding Length (2 bytes) - Indicates the length of the + Padding field in the payload, not including any other + field. + +o Padding (variable length) - The padding that MUST be + applied because this payload is encrypted separately from + other parts of the packet. + +o MAC (variable length) - The MAC computed from the + Message Length, Message Data, Padding Length and Padding + fields. This protects the integrity of the plaintext + channel message. The receiver can verify from the MAC + whether the message decrypted correctly. Also, if more than + one private key has been set for the channel, the receiver + can verify which of the keys decrypted the message + correctly. Note that, this field is encrypted and MUST + be added to the padding calculation. + +o Initial Vector (variable length) - The initial vector + that has been used in packet encryption. It needs to be + used in the packet decryption as well. What this field + includes is implementation issue. However, it is + RECOMMENDED that it would be random data or, perhaps, + a timestamp. It is NOT RECOMMENDED to use zero (0) as an + initial vector. This field is not encrypted. This field + is not included into the padding calculation. Length + of this field equals the cipher's block size. This field + is, however, authenticated. +.in 3 + + +.ti 0 +2.3.10 Channel Key Payload + +All traffic in channels are protected by channel specific keys. +Channel Key Payload is used to distribute channel keys to all +clients on the particular channel. Channel keys are sent when +the channel is created, when new user joins to the channel and +whenever a user has left a channel. Server creates the new +channel key and distributes it to the clients by encrypting this +payload with the session key shared between the server and +the client. After that, client starts using the key received +in this payload to protect the traffic on the channel. + +The client which is joining to the channel receives its key in the +SILC_COMMAND_JOIN command reply message thus it is not necessary to +send this payload to the entity which sent the SILC_COMMAND_JOIN +command. + +Channel keys are cell specific thus every router in the cell have +to create a channel key and distribute it if any client in the +cell has joined to a channel. Channel traffic between cell's +are not encrypted using channel keys, they are encrypted using +normal session keys between two routers. Inside a cell, all +channel traffic is encrypted with the specified channel key. +Channel key should expire periodically, say, in one hour, in +which case new channel key is created and distributed. + +The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet. +It MUST NOT be sent in any other packet type. The following diagram +represents the Channel Key Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Channel ID Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Channel ID ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Cipher Name Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Cipher Name ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Channel Key Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Channel Key ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 14: Channel Key Payload + + + +.in 6 +o Channel ID Length (2 bytes) - Indicates the length of the + Channel ID field in the payload, not including any other + field. + +o Channel ID (variable length) - The Channel ID of the + channel this key is meant for. + +o Cipher Name Length (2 bytes) - Indicates the length of the + Cipher name field in the payload, not including any other + field. + +o Cipher Name (variable length) - Name of the cipher used + in the protection of channel traffic. This name is + initially decided by the creator of the channel but it + MAY change during the life time of the channel as well. + +o Channel Key Length (2 bytes) - Indicates the length of the + Channel Key field in the payload, not including any other + field. + +o Channel Key (variable length) - The actual channel key + material. +.in 3 + + +.ti 0 +2.3.11 Private Message Payload + +Private Message Payload is used to send private message between +two clients (or users for that matter). The messages are sent only +to the specified user and no other user inside SILC network is +able to see the message. The message is protected by the session +key established by the SILC Key Exchange Protocol. However, +it is also possible to agree to use a private key to protect +just the private messages. See section 2.3.11 Private Message +Key Payload for detailed description of how to agree to use +specific key. + +If normal session key is used to protect the message, every server +between the sender client and the receiving client MUST decrypt the +packet and always re-encrypt it with the session key of the next +receiver of the packet. See section Client To Client in [SILC1]. + +When private key is used to protect the message, servers between +the sender and the receiver needs not to decrypt/re-encrypt the +packet. Section Client To Client in [SILC1] gives example of this +scheme as well. + +The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE +packet. It MUST NOT be sent in any other packet type. The following +diagram represents the Private Message Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Flags | Message Data Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Message Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Padding ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 15: Private Message Payload + + +.in 6 +o Flags (2 bytes) - This field includes the flags of the + private message. They can indicate a different reason or + purpose for the private message. See the section 2.3.9 + Channel Message Payload for defined flags. Note that + the Channel Message Payload use the same flags for the + same purpose. + +o Message Data Length (2 bytes) - Indicates the length of the + Message Data field, not includes any other field. + +o Message Data (variable length) - The actual message to + the client. Rest of the packet is reserved for the message + data. + +o Padding (variable length) - This field is present only + when the private message payload is encrypted with private + message key. In this case the padding is applied to make + the payload multiple by eight (8), or by the block size of + the cipher, which ever is larger. When encrypted with + normal session keys, this field MUST NOT be included. +.in 3 + + +.ti 0 +2.3.12 Private Message Key Payload + +This payload is used to send key from client to another client that +is going to be used to protect the private messages between these +two clients. If this payload is not sent normal session key +established by the SILC Key Exchange Protocol is used to protect +the private messages. + +This payload may only be sent by client to another client. Server +MUST NOT send this payload at any time. After sending this payload +the sender of private messages must set the Private Message Key +flag into SILC Packet Header. + +The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY +packet. It MUST NOT be sent in any other packet type. The following +diagram represents the Private Message Key Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Private Message Key Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Private Message Key ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Cipher Name Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Cipher Name ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 16: Private Message Key Payload + + + + +.in 6 +o Private Message Key Length (2 bytes) - Indicates the length + of the Private Message Key field in the payload, not including + any other field. + +o Private Message Key (variable length) - The actual private + message key material. + +o Cipher Name Length (2 bytes) - Indicates the length of the + Cipher Name field in the payload, not including any other + field. + +o Cipher Name (variable length) - Name of the cipher to use + in the private message encryption. If this field does not + exist then the default cipher of the SILC protocol is used. + See the [SILC1] for defined ciphers. +.in 3 + + + +.ti 0 +2.3.13 Command Payload + +Command Payload is used to send SILC commands from client to server. +Also server MAY send commands to other servers. The following diagram +represents the Command Payload. + + +.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 | SILC Command | Arguments Num | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Command Identifier | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 17: Command Payload + + +.in 6 +o Payload Length (2 bytes) - Length of the entire command + payload including any command argument payloads associated + with this payload. + +o SILC Command (1 byte) - Indicates the SILC command. This MUST + be set to non-zero value. If zero (0) value is found in this + field the packet MUST be discarded. + +o Arguments Num (1 byte) - Indicates the number of arguments + associated with the command. If there are no arguments this + field is set to zero (0). The arguments MUST follow the + command payload. See section 2.3.2.2 for definition of the + Argument Payload. + +o Command Identifier (2 bytes) - Identifies this command at the + sender's end. The entity which replies to this command MUST + set the value found from this field into the Command Payload + used to send the reply to the sender. This way the sender + can identify which command reply belongs to which originally + sent command. What this field includes is implementation + issue but it is RECOMMENDED that wrapping counter value is + used in the field. Value zero (0) in this field means that + no specific value is set. +.in 3 + +See [SILC4] for detailed description of different SILC commands, +their arguments and their reply messages. + + + + +.ti 0 +2.3.14 Command Reply Payload + +Command Reply Payload is used to send replies to the commands. The +Command Reply Payload is identical to the Command Payload thus see +the upper section for the Command Payload specification. + +The entity which sends the reply packet MUST set the Command Identifier +field in the reply packet's Command Payload to the value it received +in the original command packet. + +See SILC Commands in [SILC4] for detailed description of different +SILC commands, their arguments and their reply messages. + + +.ti 0 +2.3.15 Connection Auth Request Payload + +Client MAY send this payload to server to request the authentication +method that must be used in authentication protocol. If client knows +this information beforehand this payload is not necessary to be sent. +Server performing authentication with another server MAY also send +this payload to request the authentication method. If the connecting +server already knows this information this payload is not necessary +to be sent. + +Server receiving this request MUST reply with same payload sending +the mandatory authentication method. Algorithms that may be required +to be used by the authentication method are the ones already +established by the SILC Key Exchange protocol. See section Key +Exchange Start Payload in [SILC3] for detailed information. + +The payload may only be sent with SILC_PACKET_CONNECTION_AUTH_REQUEST +packet. It MUST NOT be sent in any other packet type. The following +diagram represents the Connection Auth Request Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Connection Type | Authentication Method | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 18: Connection Auth Request Payload + + +.in 6 +o Connection Type (2 bytes) - Indicates the type of the + connection. The following connection types are defined: + + + 1 Client connection + 2 Server connection + 3 Router connection + + If any other type is found in this field the packet MUST be + discarded and the authentication MUST be failed. + +o Authentication Method (2 bytes) - Indicates the authentication + method to be used in the authentication protocol. The following + authentication methods are defined: + + 0 NONE (mandatory) + 1 password (mandatory) + 2 public key (mandatory) + + If any other type is found in this field the packet MUST be + discarded and the authentication MUST be failed. If this + payload is sent as request to receive the mandatory + authentication method this field MUST be set to zero (0), + indicating that receiver should send the mandatory + authentication method. The receiver sending this payload + to the requesting party, MAY also set this field to zero (0) + to indicate that authentication is not required. In this + case authentication protocol still MUST be started but + server is most likely to respond with SILC_PACKET_SUCCESS + immediately. +.in 3 + + +.ti 0 +2.3.16 New ID Payload + +New ID Payload is a multipurpose payload. It is used to send newly +created ID's from clients and servers. When client connects to server +and registers itself to the server by sending SILC_PACKET_NEW_CLIENT +packet, server replies with this packet by sending the created ID for +the client. Server always creates the ID for the client. + +This payload is also used when server tells its router that new client +has registered to the SILC network. In this case the server sends +the Client ID of the client to the router. Similarly when router +distributes information to other routers about the client in the SILC +network this payload is used. + +Also, when server connects to router, router uses this payload to inform +other routers about new server in the SILC network. However, every +server (or router) creates their own ID's thus the ID distributed by +this payload is not created by the distributor in this case. Servers +create their own ID's. Server registers itself to the network by sending +SILC_PACKET_NEW_SERVER to the router it connected to. The case is same +when router connects to another router. + +However, this payload MUST NOT be used to send information about new +channels. New channels are always distributed by sending the dedicated +SILC_PACKET_NEW_CHANNEL packet. + +Thus, this payload is very important and used every time when some +new entity is registered to the SILC network. Client MUST NOT send this +payload. Both client and server (and router) MAY receive this payload. + +The packet uses generic ID Payload as New ID Payload. See section +2.3.2.1 for generic ID Payload. + + +.ti 0 +2.3.17 New Client Payload + +When client is connected to the server, keys has been exchanged and +connection has been authenticated client MUST register itself to the +server. Client's first packet after key exchange and authentication +protocols must be SILC_PACKET_NEW_CLIENT. This payload tells server all +the relevant information about the connected user. Server creates a new +client ID for the client when received this payload and sends it to the +client in New ID Payload. + +This payload sends username and real name of the user on the remote host +which is connected to the SILC server with SILC client. The server +creates the client ID according the information sent in this payload. +The nickname of the user becomes the username sent in this payload. +However, client should call NICK command after sending this payload to +set the real nickname of the user which is then used to create new +client ID. + +The payload may only be sent with SILC_PACKET_NEW_CLIENT packet. It +MUST NOT be sent in any other packet type. The following diagram +represents the New Client Payload. + + + + + + + + + + + + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Username Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Username ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Real Name Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Real Name ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 19: New Client Payload + + +.in 6 +o Username Length (2 bytes) - Length of the Username field. + +o Username (variable length) - The username of the user on + the host where connecting to the SILC server. + +o Real Name Length (2 bytes) - Length of the Real Name field. + +o Real Name (variable length) - The real name of the user + on the host where connecting to the SILC server. +.in 3 + + +.ti 0 +2.3.18 New Server Payload + +This payload is sent by server when it has completed successfully both +key exchange and connection authentication protocols. The server +MUST register itself to the SILC Network by sending this payload. +The first packet after these key exchange and authentication protocols +is SILC_PACKET_NEW_SERVER packet. The payload includes the Server ID +of the server that it has created by itself. It also includes a +name of the server that is associated to the Server ID. + +The payload may only be sent with SILC_PACKET_NEW_SERVER packet. It +MUST NOT be sent in any other packet type. The following diagram +represents the New Server Payload. + + + + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Server ID Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Server ID Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Server Name Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Server Name ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 20: New Server Payload + + +.in 6 +o Server ID Length (2 bytes) - Length of the Server ID Data + field. + +o Server ID Data (variable length) - The actual Server ID + data. + +o Server Name Length (2 bytes) - Length of the server name + field. + +o Server Name (variable length) - The server name. +.in 3 + + +.ti 0 +2.3.19 New Channel Payload + +Information about newly created channel is broadcasted to all routers +in the SILC network by sending this packet payload. Channels are +created by router of the cell. Server never creates channels unless +it is a standalone server and it does not have router connection, +in this case server acts as router. Normal server send JOIN command +to the router (after it has received JOIN command from client) which +then processes the command and creates the channel. Client MUST NOT +send this packet. + +The packet uses generic Channel Payload as New Channel Payload. See +section 2.3.2.3 for generic Channel Payload. The Mode Mask field in the +Channel Payload is the mode of the channel. + + + + +.ti 0 +2.3.20 Key Agreement Payload + +This payload is used by clients to request key negotiation between +another client in the SILC Network. The key agreement protocol used +is the SKE protocol. The result of the protocol, the secret key +material, can be used for example as private message key between the +two clients. This significantly adds security as the key agreement +is performed outside the SILC network. The server and router MUST NOT +send this payload. + +The sender MAY tell the receiver of this payload the hostname and the +port where the SKE protocol is running in the sender's end. The +receiver MAY then initiate the SKE negotiation with the sender. The +sender MAY also optionally not to include the hostname and the port +of its SKE protocol. In this case the receiver MAY reply to the +request by sending the same payload filled with the receiver's hostname +and the port where the SKE protocol is running. The sender MAY then +initiate the SKE negotiation with the receiver. + +The payload may only be sent with SILC_PACKET_KEY_AGREEMENT packet. +It MUST NOT be sent in any other packet type. The following diagram +represents the Key Agreement Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Hostname Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Hostname ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Port | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 21: Key Agreement Payload + + +.in 6 +o Hostname Length (2 bytes) - Indicates the length of the + Hostname field. + +o Hostname (variable length) - The hostname or IP address where + the SKE protocol is running. The sender MAY fill this field + when sending the payload. If the receiver sends this payload + as reply to the request it MUST fill this field. + +o Port (4 bytes) - The port where the SKE protocol is bound. + The sender MAY fill this field when sending the payload. If + the receiver sends this payload as reply to the request it + MUST fill this field. This is a 32 bit MSB first order value. +.in 3 + + +After the key material has been received from the SKE protocol it is +processed as the [SILC3] describes. If the key material is used as +channel private key then the Sending Encryption Key, as defined in +[SILC3] is used as the channel private key. Other key material must +be discarded. The [SILC1] defines the way to use the key material if +it is intended to be used as private message keys. Any other use for +the key material is undefined. + + +.ti 0 +2.3.21 Cell Routers Payload + +Cell Routers payload is used by router to notify its primary router what +other routers exist in the cell. The other routers are considered to be +backup routers and one of them will come active only in the case of +failure of the primary router. Normal server MAY send this packet if it +is acting as backup router. Client MUST NOT send this packet. To send +more than one backup router set the List flag and assemble the payloads +as list. + +The payload may only be sent with SILC_PACKET_CELL_ROUTERS packet. It +MUST NOT be sent in any other packet type. The Following diagram +represents the Cell Routers Payload. + + +.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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Hostname Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Hostname ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Port | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Server ID Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Server ID ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 22: Cell Routers Payload + + +.in 6 +o Hostname Length (2 bytes) - Indicates the length of the Hostname + field. + +o Hostname (variable length) - The hostname or IP address of + the backup router. + +o Port (4 bytes) - The port of the backup router it currently uses. + This is a 32 bit MSB first order value. + +o Server ID Length (2 bytes) - Indicates the length of the Server + ID field. + +o Server ID (variable length) - Consists of the Server ID of the + backup router. +.in 3 + + +.ti 0 +2.4 SILC ID Types + +ID's are extensively used in the SILC network to associate different +entities. The following ID's has been defined to be used in the SILC +network. + +.in 6 +0 No ID + + When ever specific ID cannot be used this is used. + +1 Server ID + + Server ID to associate servers. See the format of + this ID in [SILC1]. + +2 Client ID + + Client ID to associate clients. See the format of + this ID in [SILC1]. + +3 Channel ID + + Channel ID to associate channels. See the format of + this ID in [SILC1]. +.in 3 + + +.ti 0 +2.5 Packet Encryption And Decryption + +SILC packets are encrypted almost entirely. Only small part of SILC +header is not encrypted as described in section 5.2 SILC Packet Header. +The SILC Packet header is the first part of a packet to be encrypted +and it is always encrypted with the key of the next receiver of the +packet. The data payload area of the packet is always entirely +encrypted and it is usually encrypted with the next receiver's key. +However, there are some special packet types and packet payloads +that require special encryption process. These special cases are +described in the next sections. First is described the normal packet +encryption process. + + +.ti 0 +2.5.1 Normal Packet Encryption And Decryption + +Normal SILC packets are encrypted with the session key of the next +receiver of the packet. The entire SILC Packet header and the packet +data payload is is also encrypted with the same key. Padding of the +packet is also encrypted always with the session key, also in special +cases. Computed MAC of the packet must not be encrypted. + +Decryption process in these cases are straightforward. The receiver +of the packet MUST first decrypt the SILC Packet header, or some parts +of it, usually first 16 bytes of it. Then the receiver checks the +packet type from the decrypted part of the header and can determine +how the rest of the packet must be decrypted. If the packet type is +any of the special cases described in the following sections the packet +decryption is special. If the packet type is not among those special +packet types rest of the packet can be decrypted with the same key. + +Also, note that two bytes of the SILC Packet header are not encrypted +thus it must be noticed in the decryption process by starting the +decryption from the second byte of the header. This sets some rules +to padding generation as well, see the section 2.7 Packet Padding +Generation. + +With out a doubt, this sort of decryption processing causes some +overhead to packet decryption, but never the less, is required. + + +.ti 0 +2.5.2 Channel Message Encryption And Decryption + +Channel Messages (Channel Message Payload) are always encrypted with +the channel specific key. However, the SILC Packet header is not +encrypted with that key. As in normal case, the header is encrypted +with the key of the next receiver of the packet, who ever that might +be. Note that in this case the encrypted data area is not touched +at all; it MUST NOT be re-encrypted with the session key. + +Receiver of a channel message, who ever that is, is REQUIRED to decrypt +the SILC Packet header to be able to even recognize the packet to be as +channel message. This is same procedure as for normal SILC packets. +As the receiver founds the packet to be channel message, rest of the +packet processing is special. Rest of the SILC Packet header is +decrypted with the same session key along with the padding of the +packet. After that the packet is protected with the channel specific +key and thus can be decrypted only if the receiver is the client on +the channel. See section 2.7 Packet Padding Generation for more +information about padding on special packets. + +If the receiver of the channel message is router which is routing the +message to another router then it MUST decrypt the Channel Message +payload. Between routers (that is, between cells) channel messages +are protected with session keys shared between the routers. This +causes another special packet processing for channel messages. If +the channel message is received from another router then the entire +packet, including Channel Message payload, MUST be encrypted with the +session key shared between the routers. In this case the packet +decryption process is as with normal SILC packets. Hence, if the +router is sending channel message to another router the Channel +Message payload MUST have been decrypted and MUST be re-encrypted +with the session key shared between the another router. In this +case the packet encryption is as with any normal SILC packet. + +It must be noted that this is only when the channel messages are sent +from router to another router. In all other cases the channel +message encryption and decryption is as described above. This +different processing of channel messages with router to router +connection is because channel keys are cell specific. All cells has +their own channel keys thus the channel message traveling from one +cell to another MUST be protected as it would be any normal SILC +packet. + +If the SILC_CMODE_PRIVKEY channel mode has been set for the channel +then the router cannot decrypt the packet as it does not know the +private key. In this case the entire packet MUST be encrypted with +the session key and sent to the router. The router receiving the +packet MUST check the channel mode and decrypt the packet accordingly. + + +.ti 0 +2.5.3 Private Message Encryption And Decryption + +By default, private message in SILC are protected by session keys. +In this case the private message encryption and decryption process is +equivalent to normal packet encryption and decryption. + +However, private messages MAY be protected with private message key +which causes the packet to be special packet. The procedure in this +case is very much alike to channel packets. The actual private message +is encrypted with the private message key and other parts of the +packet is encrypted with the session key. See 2.7 Packet Padding +Generation for more information about padding on special packets. + +The difference from channel message processing is that server or router +en route never decrypts the actual private message, as it does not +have the key to do that. Thus, when sending packets between router +the processing is same as in any other case as well; the packet's header +and padding is protected by the session key and the data area is not +touched. + +The true receiver of the private message, client, that is, is able +to decrypt the private message as it shares the key with the sender +of the message. + + +.ti 0 +2.6 Packet MAC Generation + +Data integrity of a packet is protected by including a message +authentication code (MAC) at the end of the packet. The MAC is computed +from shared secret MAC key, that is established by the SILC Key Exchange +protocol, and from the original contents of the packet. The MAC is +always computed before the packet is encrypted, although after it is +compressed if compression is used. + +The MAC is computed from entire packet. Every bit of data in the packet, +including SILC Packet Header is used in the MAC computing. This way +the entire packet becomes authenticated. + +If the packet is special packet MAC is computed from the entire packet +but part of the packet may be encrypted before the MAC is computed. +This is case, for example, with channel messages where the message data +is encrypted with key that server may not now. In this case the MAC +has been computed from the encrypted data. + +See [SILC1] for defined and allowed MAC algorithms. + + +.ti 0 +2.7 Packet Padding Generation + +Padding is needed in the packet because the packet is encrypted. It +MUST always be multiple by eight (8) or multiple by the block size +of the cipher, which ever is larger. The padding is always encrypted. + +For normal packets the padding is added after the SILC Packet Header +and between the Data Payload area. The padding for normal packets +are calculated as follows: + +.in 6 +padding length = 16 - ((packet length - 2) mod 16) +.in 3 + +The 16 is the maximum padding allowed in SILC packet. Two (2) is +subtracted from the true length of the packet because two (2) bytes +is not encrypted in SILC Packet Header, see section 2.2 SILC Packet +Header. Those two bytes that are not encrypted MUST NOT be calculated +to the padding length. + +For special packets the padding calculation MAY be different as special +packets may be encrypted differently. In these cases the encrypted +data area MUST already be multiple by the block size thus in this case +the padding is calculated only for SILC Packet Header, not for any +other area of the packet. The same algorithm works in this case as +well, except that the `packet length' is now the SILC Packet Header +length. In this case, as well, two (2) is subtracted from the +length. + +The padding MUST be random data, preferably, generated by +cryptographically strong random number generator. + + +.ti 0 +2.8 Packet Compression + +SILC Packets MAY be compressed. In this case the data payload area +is compressed and all other areas of the packet MUST remain as they +are. After compression is performed for the data area, the length +field of Packet Header MUST be set to the compressed length of the +data. + +The compression MUST always be applied before encryption. When +the packet is received and decrypted the data area MUST be decompressed. +Note that the true sender of the packet MUST apply the compression and +the true receiver of the packet MUST apply the decompression. Any +server or router en route MUST NOT decompress the packet. + + +.ti 0 +2.9 Packet Sending + +The sender of the packet MUST assemble the SILC Packet Header with +correct values. It MUST set the Source ID of the header as its own +ID, unless it is forwarding the packet. It MUST also set the Destination +ID of the header to the true destination. If the destination is client +it will be Client ID, if it is server it will be Server ID and if it is +channel it will be Channel ID. + +If the sender wants to compress the packet it MUST apply the +compression now. Sender MUST also compute the padding as described +in above sections. Then sender MUST compute the MAC of the packet. + +Then sender MUST encrypt the packet as has been described in above +sections according whether the packet is normal packet or special +packet. The computed MAC MUST NOT be encrypted. + + +.ti 0 +2.10 Packet Reception + +On packet reception the receiver MUST check that all fields in the +SILC Packet Header are valid. It MUST check the flags of the +header and act accordingly. It MUST also check the MAC of the packet +and if it is to be failed the packet MUST be discarded. Also if the +header of the packet includes any bad fields the packet MUST be +discarded. + +See above sections on the decryption process of the received packet. + +The receiver MUST also check that the ID's in the header are valid +ID's. Unsupported ID types or malformed ID's MUST cause packet +rejection. The padding on the reception is always ignored. + +The receiver MUST also check the packet type and start parsing the +packet according to the type. However, note the above sections on +special packet types and their parsing. + + +.ti 0 +2.11 Packet Routing + +Routers are the primary entities in the SILC network that takes care +of packet routing. However, normal servers routes packets as well, for +example, when they are routing channel message to the local clients. +Routing is quite simple as every packet tells the true origin and the +true destination of the packet. + +It is still RECOMMENDED for routers that has several routing connections +to create route cache for those destinations that has faster route than +the router's primary route. This information is available for the router +when other router connects to the router. The connecting party then +sends all of its locally connected clients, servers and channels. These +informations helps to create the route cache. Also, when new channels +are created to a cell its information is broadcasted to all routers +in the network. Channel ID's are based on router's ID thus it is easy +to create route cache based on these informations. If faster route for +destination does not exist in router's route cache the packet MUST be +routed to the primary route (default route). + +For server which receives a packet to be routed to its locally connected +client the server MUST check whether the particular packet type is +allowed to be routed to the client. Not all packets may be sent by +some odd entity to client that is indirectly connected to the sender. +See section 2.3 SILC Packet Types and paragraph about indirectly connected +entities and sending packets to them. The section mentions the packets +that may be sent to indirectly connected entities. It is clear that +server cannot send, for example, disconnect packet to client that is not +directly connected to the server. + + +.ti 0 +2.12 Packet Broadcasting + +SILC packets MAY be broadcasted in SILC network. However, only router +server may send or receive broadcast packets. Client and normal server +MUST NOT send broadcast packets and they MUST ignore broadcast packets +if they receive them. Broadcast packets are sent by setting Broadcast +flag to the SILC packet header. + +Broadcasting packets means that the packet is sent to all routers in +the SILC network, except to the router that sent the packet. The router +receiving broadcast packet MUST send the packet to its primary route. +The fact that SILC routers may have several router connections can +cause problems, such as race conditions inside the SILC network, if +care is not taken when broadcasting packets. Router MUST NOT send +the broadcast packet to any other route except to its primary route. + +If the primary route of the router is the original sender of the packet +the packet MUST NOT be sent to the primary route. This may happen +if router has several router connections and some other router uses +the router as its primary route. + +Routers use broadcast packets to broadcast for example information +about newly registered clients, servers, channels etc. so that all the +routers may keep these informations up to date. + + +.ti 0 +3 Security Considerations + +Security is central to the design of this protocol, and these security +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 +4 References + +[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, April 2001. + +[SILC3] Riikonen, P., "SILC Key Exchange and Authentication + Protocols", Internet Draft, April 2001. + +[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001. + +[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. + +[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, + November 1998. + +[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, + September 1999. + +[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key + Infrastructure, Certificate and CRL Profile", RFC 2459, + January 1999. + +[Schneier] Schneier, B., "Applied Cryptography Second Edition", + John Wiley & Sons, New York, NY, 1996. + +[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography", + CRC Press 1997. + +[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + +[ISAKMP] Maughan D., et al, "Internet Security Association and + Key Management Protocol (ISAKMP)", RFC 2408, November + 1998. + +[IKE] Harkins D., and Carrel D., "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + +[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. + +[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +.ti 0 +5 Author's Address + +.nf +Pekka Riikonen +Snellmanninkatu 34 A 15 +70100 Kuopio +Finland + +EMail: priikone@silcnet.org + +This Internet-Draft expires XXX diff --git a/doc/draft-riikonen-silc-spec-04.nroff b/doc/draft-riikonen-silc-spec-04.nroff new file mode 100644 index 00000000..aaba37e8 --- /dev/null +++ b/doc/draft-riikonen-silc-spec-04.nroff @@ -0,0 +1,2046 @@ +.pl 10.0i +.po 0 +.ll 7.2i +.lt 7.2i +.nr LL 7.2i +.nr LT 7.2i +.ds LF Riikonen +.ds RF FORMFEED[Page %] +.ds CF +.ds LH Internet Draft +.ds RH XX XXXXXX 2001 +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-spec-04.txt XX XXXXXXX 2001 +Expires: XXXXXXX + +.in 3 + +.ce 3 +Secure Internet Live Conferencing (SILC), +Protocol Specification + + +.ti 0 +Status of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. + + +.ti 0 +Abstract + +This memo describes a Secure Internet Live Conferencing (SILC) +protocol which provides secure conferencing services over insecure +network channel. SILC is IRC [IRC] like protocol, however, it is +not equivalent to IRC and does not support IRC. Strong cryptographic +methods are used to protect SILC packets inside the SILC network. +Three other Internet Drafts relates very closely to this memo; +SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication +Protocols [SILC3] and SILC Commands [SILC4]. + + + + + + +.ti 0 +Table of Contents + +.nf +1 Introduction .................................................. 3 + 1.1 Requirements Terminology .................................. 4 +2 SILC Concepts ................................................. 4 + 2.1 SILC Network Topology ..................................... 4 + 2.2 Communication Inside a Cell ............................... 5 + 2.3 Communication in the Network .............................. 6 + 2.4 Channel Communication ..................................... 7 + 2.5 Router Connections ........................................ 7 + 2.6 Backup Routers ............................................ 8 +3 SILC Specification ............................................ 10 + 3.1 Client .................................................... 10 + 3.1.1 Client ID ........................................... 10 + 3.2 Server .................................................... 11 + 3.2.1 Server's Local ID List .............................. 12 + 3.2.2 Server ID ........................................... 13 + 3.2.3 SILC Server Ports ................................... 14 + 3.3 Router .................................................... 14 + 3.3.1 Router's Local ID List .............................. 14 + 3.3.2 Router's Global ID List ............................. 15 + 3.3.3 Router's Server ID .................................. 15 + 3.4 Channels .................................................. 16 + 3.4.1 Channel ID .......................................... 17 + 3.5 Operators ................................................. 17 + 3.6 SILC Commands ............................................. 18 + 3.7 SILC Packets .............................................. 18 + 3.8 Packet Encryption ......................................... 19 + 3.8.1 Determination of the Source and the Destination ..... 19 + 3.8.2 Client To Client .................................... 20 + 3.8.3 Client To Channel ................................... 21 + 3.8.4 Server To Server .................................... 22 + 3.9 Key Exchange And Authentication ........................... 22 + 3.9.1 Authentication Payload .............................. 22 + 3.10 Algorithms ............................................... 24 + 3.10.1 Ciphers ............................................ 24 + 3.10.2 Public Key Algorithms .............................. 25 + 3.10.3 Hash Functions ..................................... 26 + 3.10.4 MAC Algorithms ..................................... 26 + 3.10.5 Compression Algorithms ............................. 26 + 3.11 SILC Public Key .......................................... 27 + 3.12 SILC Version Detection ................................... 29 +4 SILC Procedures ............................................... 30 + 4.1 Creating Client Connection ................................ 30 + 4.2 Creating Server Connection ................................ 31 + 4.2.1 Announcing Clients, Channels and Servers ............ 32 + 4.3 Joining to a Channel ...................................... 33 + 4.4 Channel Key Generation .................................... 34 + 4.5 Private Message Sending and Reception ..................... 34 + 4.6 Private Message Key Generation ............................ 35 + 4.7 Channel Message Sending and Reception ..................... 35 + 4.8 Session Key Regeneration .................................. 36 + 4.9 Command Sending and Reception ............................. 37 + 4.10 Closing Connection ....................................... 37 +5 Security Considerations ....................................... 38 +6 References .................................................... 38 +7 Author's Address .............................................. 40 + + + +.ti 0 +List of Figures + +.nf +Figure 1: SILC Network Topology +Figure 2: Communication Inside cell +Figure 3: Communication Between Cells +Figure 4: Router Connections +Figure 5: SILC Public Key + + +.ti 0 +1. Introduction + +This document describes a Secure Internet Live Conferencing (SILC) +protocol which provides secure conferencing services over insecure +network channel. SILC is IRC [IRC] like protocol, however, it is +not equivalent to IRC and does not support IRC. + +Strong cryptographic methods are used to protect SILC packets inside +the SILC network. Three other Internet Drafts relates very closely +to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and +Authentication Protocols [SILC3] and SILC Commands [SILC4]. + +The protocol uses extensively packets as conferencing protocol +requires message and command sending. The SILC Packet Protocol is +described in [SILC2] and should be read to fully comprehend this +document and protocol. [SILC2] also describes the packet encryption +and decryption in detail. + +The security of SILC protocol, and for any security protocol for that +matter, is based on strong and secure key exchange protocol. The SILC +Key Exchange protocol is described in [SILC3] along with connection +authentication protocol and should be read to fully comprehend this +document and protocol. + +The SILC protocol has been developed to work on TCP/IP network +protocol, although it could be made to work on other network protocols +with only minor changes. However, it is recommended that TCP/IP +protocol is used under SILC protocol. Typical implementation would +be made in client-server model. + + +.ti 0 +1.1 Requirements Terminology + +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +MAY, and OPTIONAL, when they appear in this document, are to be +interpreted as described in [RFC2119]. + + +.ti 0 +2. SILC Concepts + +This section describes various SILC protocol concepts that forms the +actual protocol, and in the end, the actual SILC network. The mission +of the protocol is to deliver messages from clients to other clients +through routers and servers in secure manner. The messages may also +be delivered from one client to many clients forming a group, also +known as a channel. + +This section does not focus to security issues. Instead, basic network +concepts are introduced to make the topology of the SILC network +clear. + + +.ti 0 +2.1 SILC Network Topology + +SILC network is a cellular network as opposed to tree style network +topology. The rationale for this is to have servers that can perform +specific kind of tasks what other servers cannot perform. This leads +to two kinds of servers; normal SILC servers and SILC routers. + +A difference between normal server and router server is that routers +knows everything about everything in the network. They also do the +actual routing of the messages to the correct receiver. Normal servers +knows only about local information and nothing about global information. +This makes the network faster as there are less servers that needs to +keep global information up to date at all time. + +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. + + + + + + + +The following diagram represents SILC network topology. + +.in 8 +.nf + ---- ---- ---- ---- ---- ---- + | S8 | S5 | S4 | | S7 | S5 | S6 | + ----- ---- ----- ----- ---- ----- +| S7 | S/R1 | S2 | --- | S8 | S/R2 | S4 | + ---- ------ ---- ---- ------ ---- + | S6 | S3 | S1 | | S1 | S3 | S2 | ---- ---- + ---- ---- ---- ---- ---- ---- | S3 | S1 | + Cell 1. \\ Cell 2. | \\____ ----- ----- + | | | S4 | S/R4 | + ---- ---- ---- ---- ---- ---- ---- ------ + | S7 | S4 | S2 | | S1 | S3 | S2 | | S2 | S5 | + ----- ---- ----- ----- ---- ----- ---- ---- + | S6 | S/R3 | S1 | --- | S4 | S/R5 | S5 | ____/ Cell 4. + ---- ------ ---- ---- ------ ---- + | S8 | S5 | S3 | | S6 | S7 | S8 | ... etc ... + ---- ---- ---- ---- ---- ---- + Cell 3. Cell 5. +.in 3 + +.ce +Figure 1: SILC Network Topology + + +A cell is formed when a server or servers connect to one router. In +SILC network normal server cannot directly connect to other normal +server. Normal server may only connect to SILC router which then +routes the messages to the other servers in the cell. Router servers +on the other hand may connect to other routers to form the actual SILC +network, as seen in above figure. However, router is also normal SILC +server; clients may connect to it the same way as to normal SILC +server. Normal server also cannot have active connections to more +than one router. Normal server cannot be connected to two different +cells. Router servers, on the other hand, may have as many router to +router connections as needed. + +There are many issues in this network topology that needs to be careful +about. Issues like the size of the cells, the number of the routers in +the SILC network and the capacity requirements of the routers. These +issues should be discussed in the Internet Community and additional +documents on the issue may be written. + + +.ti 0 +2.2 Communication Inside a Cell + +It is always guaranteed that inside a cell message is delivered to the +recipient with at most two server hops. A client which is connected to +server in the cell and is talking on channel to other client connected +to other server in the same cell, will have its messages delivered from +its local server first to the router of the cell, and from the router +to the other server in the cell. + +The following diagram represents this scenario: + + +.in 25 +.nf +1 --- S1 S4 --- 5 + S/R + 2 -- S2 S3 + / | + 4 3 +.in 3 + + +.ce +Figure 2: Communication Inside cell + + +Example: Client 1. connected to Server 1. send message to + Client 4. connected to Server 2. travels from Server 1. + first to Router which routes the message to Server 2. + which then sends it to the Client 4. All the other + servers in the cell will not see the routed message. + + +If the client is connected directly to the router, as router is also normal +SILC server, the messages inside the cell are always delivered only with +one server hop. If clients communicating with each other are connected +to the same server, no router interaction is needed. This is the optimal +situation of message delivery in the SILC network. + + +.ti 0 +2.3 Communication in the Network + +If the message is destined to server that does not belong to local cell +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. The following diagram +represents message sending between cells. + + +.in 16 +.nf +1 --- S1 S4 --- 5 S2 --- 1 + S/R - - - - - - - - S/R + 2 -- S2 S3 S1 + / | \\ + 4 3 2 + + Cell 1. Cell 2. +.in 3 + + +.ce +Figure 3: Communication Between Cells + + +Example: Client 5. connected to Server 4. in Cell 1. sends message + to Client 2. connected to Server 1. in Cell 2. travels + from Server 4. to Router which routes the message to + Router in Cell 2, which then routes the message to + Server 1. All the other servers and routers in the + network will not see the routed message. + + +The optimal case of message delivery from the client point of view is +when clients are connected directly to the routers and the messages +are delivered from one router to the other. + + +.ti 0 +2.4 Channel Communication + +Messages may be sent to group of clients as well. Sending messages to +many clients works the same way as sending messages point to point, from +message delivery point of view. Security issues are another matter +which are not discussed in this section. + +Router server handles the message routing to multiple recipients. If +any recipient is not in the same cell as the sender the messages are +routed further. + +Server distributes the channel message to its local clients which are +joined to the channel. Router also distributes the message to its +local clients on the channel. + + +.ti 0 +2.5 Router Connections + +Router connections play very important role in making the SILC like +network topology to work. For example, sending broadcast packets in +SILC network require special connections between routers; routers must +be connected in a specific way. + +Every router has their primary route which is a connection to another +router in the network. Unless there is only two routers in the network +must not routers use each other as their primary routes. The router +connections in the network must form a circular. + + + + + + + +Example with three routers in the network: + + +.in 16 +.nf + S/R1 - > - > - > - > - > - > - S/R2 + \\ / + ^ v + \\ - < - < - S/R3 - < - < - / +.in 3 + + +.ce +Figure 4: Router Connections + + +Example: Network with three routers. Router 1. uses Router 2. as its + primary router. Router 2. uses Router 3. as its primary router, + and Router 3. uses Router 1. as its primary router. There may + be other direct connections between the routers but they must + not be used as primary routes. + +The above example is applicable to any amount of routers in the network +except for two routers. If there are only two routers in the network both +routers must be able to handle situation where they use each other as their +primary routes. + +The issue of router connections are very important especially with SILC +broadcast packets. Usually all router wide information in the network is +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 the 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 is 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 routers 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 a spare server in the +cell that does not accept normal client connections at all. It may be +reserved purely for the backup purposes. These, however, are cell +management issues. + +If also 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 + +This section describes the SILC protocol. However, [SILC2] and +[SILC3] describes other important protocols that are part of this SILC +specification and must be read. + + +.ti 0 +3.1 Client + +A client is a piece of software connecting to SILC server. SILC client +cannot be SILC server. Purpose of clients is to provide the user +interface of the SILC services for end user. Clients are distinguished +from other clients by unique Client ID. Client ID is a 128 bit ID that +is used in the communication in the SILC network. The client ID is +based on the nickname selected by the user. User uses logical nicknames +in communication which are then mapped to the corresponding Client ID. +Client ID's are low level identifications and must not be seen by the +end user. + +Clients provide other information about the end user as well. Information +such as the nickname of the user, username and the host name of the end +user and user's real name. See section 3.2 Server for information of +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 +between SILC and IRC. This causes the server names or client's host 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. 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, +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 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 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 + hash value is used to search the user's Client ID from + the ID lists. + +.in 3 +Collisions could occur when more than 2^8 clients using same nickname +from the same server IP address is connected to the SILC network. +Server MUST be able to handle this situation by refusing to accept +anymore of that nickname. + +Another possible collision may happen with the truncated hash value of +the nickname. It could be possible to have same truncated hash value for +two different nicknames. However, this is not expected to happen nor +cause any problems if it would occur. Nicknames are usually logical and +it is unlikely to have two distinct logical nicknames produce same +truncated hash value. + + +.ti 0 +3.2 Server + +Servers are the most important parts of the SILC network. They form the +basis of the SILC, providing a point to which clients may connect to. +There are two kinds of servers in SILC; normal servers and router servers. +This section focus on the normal server and router server is described +in the section 3.3 Router. + +Normal servers MUST NOT directly connect to other normal server. Normal +servers may only directly connect to router server. If the message sent +by the client is destined outside the local server it is always sent to +the router server for further routing. Server may only have one active +connection to router on same port. Normal server MUST NOT connect to other +cell's router except in situations where its cell's router is unavailable. + +Servers and routers in the SILC network are considered to be trusted. +With out a doubt, servers that are set to work on ports above 1023 are +not considered to be trusted. Also, the service provider acts important +role in the server's trustworthy. + + +.ti 0 +3.2.1 Server's Local ID List + +Normal server keeps various information about the clients and their end +users connected to it. Every normal server MUST keep list of all locally +connected clients, Client ID's, nicknames, usernames and host names and +user's real name. Normal servers only keeps local information and it +does not keep any global information. Hence, normal servers knows only +about their locally connected clients. This makes servers efficient as +they don't have to worry about global clients. Server is also responsible +of creating the Client ID's for their clients. + +Normal server also keeps information about locally created channels and +their Channel ID's. + + +Hence, local list for normal server includes: + +.in 6 +server list - Router connection + o Server name + o Server IP address + o Server ID + o Sending key + o Receiving key + o Public key + +client list - All clients in server + o Nickname + o Username@host + o Real name + o Client ID + o Sending key + o Receiving key + o Public key + + +channel list - All channels in server + o Channel name + o Channel ID + o Client ID's on channel + o Client ID modes on channel + o Channel key +.in 3 + + +.ti 0 +3.2.2 Server ID + +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: + +32 bit IP address of the server +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. + +o Port - This is the port the server is bound to. + +o Random number - This is used to further randomize the Server ID. + +.in 3 +Collisions are not expected to happen in any conditions. The Server ID +is always created by the server itself and server is responsible of +distributing it to the router. + + +.ti 0 +3.2.3 SILC Server Ports + +The following ports has been assigned by IANA for the SILC protocol: + +.in 10 +silc 706/tcp SILC +silc 706/udp SILC +.in 3 + + +If there are needs to create new SILC networks in the future the port +numbers must be officially assigned by the IANA. + +Server on network above privileged ports (>1023) SHOULD NOT be trusted +as they could have been set up by untrusted party. + + +.ti 0 +3.3 Router + +Router server in SILC network is responsible for keeping the cell together +and routing messages to other servers and to other routers. Router server +is also a normal server thus clients may connect to it as it would be +just normal SILC server. + +However, router servers has a lot of important tasks that normal servers +do not have. Router server knows everything about everything in the SILC. +They know all clients currently on SILC, all servers and routers and all +channels in SILC. Routers are the only servers in SILC that care about +global information and keeping them up to date at all time. And, this +is what they must do. + + +.ti 0 +3.3.1 Router's Local ID List + +Router server as well MUST keep local list of connected clients and +locally created channels. However, this list is extended to include all +the informations of the entire cell, not just the server itself as for +normal servers. + +However, on router this list is a lot smaller since routers do not need +to keep information about user's nickname, username and host name and real +name since these are not needed by the router. The router keeps only +information that it needs. + + +Hence, local list for router includes: + +.in 6 +server list - All servers in the cell + o Server name + o Server ID + o Router's Server ID + o Sending key + o Receiving key + +client list - All clients in the cell + o Client ID + + +channel list - All channels in the cell + o Channel ID + o Client ID's on channel + o Client ID modes on channel + o Channel key +.in 3 + + +Note that locally connected clients and other information include all the +same information as defined in section section 3.2.1 Server's Local ID +List. + + +.ti 0 +3.3.2 Router's Global ID List + +Router server MUST also keep global list. Normal servers do not have +global list as they know only about local information. Global list +includes all the clients on SILC, their Client ID's, all created channels +and their Channel ID's and all servers and routers on SILC and their +Server ID's. That is said, global list is for global information and the +list must not include the local information already on the router's local +list. + +Note that the global list does not include information like nicknames, +usernames and host names or user's real names. Router does not need to +keep these informations as they are not needed by the router. This +information is available from the client's server which maybe queried +when needed. + +Hence, global list includes: + +.in 6 +server list - All servers in SILC + o Server name + o Server ID + o Router's Server ID + +client list - All clients in SILC + o Client ID + +channel list - All channels in SILC + o Channel ID + o Client ID's on channel + o Client ID modes on channel +.in 3 + + + + + + + + +.ti 0 +3.3.3 Router's Server ID + +Router's Server ID's are equivalent to normal Server ID's. As routers +are normal servers as well same types of ID's applies for routers as well. +Thus, see section 3.2.2 Server ID. + + +.ti 0 +3.4 Channels + +A channel is a named group of one or more clients which will all receive +messages addressed to that channel. The channel is created when first +client requests JOIN command to the channel, and the channel ceases to +exist when the last client has left it. When channel exists, any client +can reference it using the name of the channel. + +Channel names are unique although the real uniqueness comes from 64 bit +Channel ID. However, channel names are still 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 MUST 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. The following operators on channel exist on +the SILC network. + +.in 6 +o Channel founder - When channel is created the joining client becomes + channel founder. Channel founder is channel operator with some more + privileges. Basically, channel founder can fully operate the channel + and all of its modes. The privileges are limited only to the + particular channel. There can be only one channel founder per + channel. Channel founder supersedes channel operator's privileges. + + Channel founder privileges cannot be removed by any other operator on + channel. When channel founder leaves the channel there is no channel + founder on the channel. However, it is possible to set a mode for + the channel which allows the original channel founder to regain the + founder privileges even after leaving the channel. Channel founder + also cannot be removed by force from the channel. + +o Channel operator - When client joins to channel that has not existed + previously it will become automatically channel operator (and channel + founder discussed above). Channel operator is able administrate the + channel, set some modes on channel, remove a badly behaving client + from the channel and promote other clients to become channel + operator. The privileges are limited only to the particular channel. + + Normal channel user may be promoted (opped) to channel operator + gaining channel operator privileges. Channel founder or other + channel operator may also demote (deop) channel operator to normal + channel user. +.in 3 + + +.ti 0 +3.4.1 Channel ID + +Channels are distinguished from other channels by unique Channel ID. +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: + +32 bit Router's Server ID IP address (bits 1-32) +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 + where this channel resides in the SILC network. + +o Router's Server ID port - Indicates the port of the channel on + the server. This is taken from the router's Server ID. + +o Random number - To further randomize the Channel ID. This makes + sure that there are no collisions. This also means that + in a cell there can be 2^16 channels. +.in 3 + + +.ti 0 +3.5 Operators + +Operators are normal users with extra privileges to their server or +router. Usually these people are SILC server and router administrators +that take care of their own server and clients on them. The purpose of +operators is to administrate the SILC server or router. However, even +an operator with highest privileges is not able to enter invite-only +channel, to gain access to the contents of a encrypted and authenticated +packets traveling in the SILC network or to gain channel operator +privileges on public channels without being promoted. They have the +same privileges as everyone else except they are able to administrate +their server or router. + + +.ti 0 +3.6 SILC Commands + +Commands are very important part on SILC network especially for client +which uses commands to operate on the SILC network. Commands are used +to set nickname, join to channel, change modes and many other things. + +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 MUST NOT send commands +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, +choose to ignore the command reply. + +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. 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, +SILC_COMMAND_LEAVE and SILC_COMMAND_KILL 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 [SILC4]. + + +.ti 0 +3.7 SILC Packets + +Packets are naturally the most important part of the protocol and the +packets are what actually makes the protocol. Packets in SILC network +are always encrypted using, usually the shared secret session key +or some other key, for example, channel key, when encrypting channel +messages. The SILC Packet Protocol is a wide protocol and is described +in [SILC2]. This document does not define or describe details of +SILC packets. + + + + + +.ti 0 +3.8 Packet Encryption + +All packets passed in SILC network MUST be encrypted. This section +defines how packets must be encrypted in the SILC network. The detailed +description of the actual encryption process of the packets are +described in [SILC2]. + +Client and its server shares secret symmetric session key which is +established by the SILC Key Exchange Protocol, described in [SILC3]. +Every packet sent from client to server, with exception of packets for +channels, are encrypted with this session key. + +Channels has their own key that are shared by every client on the channel. +However, the channel keys are cell specific thus one cell does not know +the channel key of the other cell, even if that key is for same channel. +Channel key is also known by the routers and all servers that has clients +on the channel. However, channels MAY have channel private keys that +are entirely local setting for the client. All clients on the channel +MUST know the channel private key before hand to be able to talk on the +channel. In this case, no server or router know the key for channel. + +Server shares secret symmetric session key with router which is +established by the SILC Key Exchange Protocol. Every packet passed from +server to router, with exception of packets for channels, are encrypted +with the shared session key. Same way, router server shares secret +symmetric key with its primary route. However, every packet passed +from router to other router, including packets for channels, are +encrypted with the shared session key. Every router connection has +their own session keys. + + +.ti 0 +3.8.1 Determination of the Source and the Destination + +The source and the destination of the packet needs to be determined +to be able to route the packets to correct receiver. This information +is available in the SILC Packet Header which is included in all packets +sent in SILC network. The SILC Packet Header is described in [SILC2]. + +The header MUST be encrypted with the session key who is next receiver +of the packet along the route. The receiver of the packet, for example +a router along the route, is able to determine the sender and the +destination of the packet by decrypting the SILC Packet Header and +checking the ID's attached to the header. The ID's in the header will +tell to where the packet needs to be sent and where it is coming from. + +The header in the packet MUST NOT change during the routing of the +packet. The original sender, for example client, assembles the packet +and the packet header and server or router between the sender and the +receiver MUST NOT change the packet header. + +Note that the packet and the packet header may be encrypted with +different keys. For example, packets to channels are encrypted with +the channel key, however, the header is encrypted with the session key +as described above. However, the header and the packet may be encrypted +with same key. This is the case, for example, with command packets. + + +.ti 0 +3.8.2 Client To Client + +The process of message delivery and encryption from client to another +client is as follows. + +Example: Private message from client to another client on different + servers. Clients do not share private message delivery + keys; normal session keys are used. + +o Client 1. sends encrypted packet to its server. The packet is + encrypted with the session key shared between client and its + server. + +o Server determines the destination of the packet and decrypts + the packet. Server encrypts the packet with session key shared + between the server and its router, and sends the packet to the + router. + +o Router determines the destination of the packet and decrypts + the packet. Router encrypts the packet with session key + shared between the router and the destination server, and sends + the packet to the server. + +o Server determines the client to which the packet is destined + to and decrypts the packet. Server encrypts the packet with + session key shared between the server and the destination client, + and sends the packet to the client. + +o Client 2. decrypts the packet. + + +Example: Private message from client to another client on different + servers. Clients has established secret shared private + message delivery key with each other and that is used in + the message encryption. + +o Client 1. sends encrypted packet to its server. The packet is + encrypted with the private message delivery key shared between + clients. + +o Server determines the destination of the packet and sends the + packet to the router. + +o Router determines the destination of the packet and sends the + packet to the server. + +o Server determines the client to which the packet is destined + to and sends the packet to the client. + +o Client 2. decrypts the packet with the secret shared key. + + +If clients share secret key with each other the private message +delivery is much simpler since servers and routers between the +clients do not need to decrypt and re-encrypt the packet. + +The process for clients on same server is much simpler as there are +no need to send the packet to the router. The process for clients +on different cells is same as above except that the packet is routed +outside the cell. The router of the destination cell routes the +packet to the destination same way as described above. + + +.ti 0 +3.8.3 Client To Channel + +Process of message delivery from client on channel to all the clients +on the channel. + +Example: Channel of four users; two on same server, other two on + different cells. Client sends message to the channel. + +o Client 1. encrypts the packet with channel key and sends the + packet to its server. + +o Server determines local clients on the channel and sends the + packet to the Client on the same server. Server then sends + the packet to its router for further routing. + +o Router determines local clients on the channel, if found + sends packet to the local clients. Router determines global + clients on the channel and sends the packet to its primary + router or fastest route. + +o (Other router(s) do the same thing and sends the packet to + the server(s)) + +o Server determines local clients on the channel and sends the + packet to the client. + +o All clients receiving the packet decrypts the packet. + + +.ti 0 +3.8.4 Server To Server + +Server to server packet delivery and encryption is described in above +examples. Router to router packet delivery is analogous to server to +server. However, some packets, such as channel packets, are processed +differently. These cases are described later in this document and +more in detail in [SILC2]. + + +.ti 0 +3.9 Key Exchange And Authentication + +Key exchange is done always when for example client connects to server +but also when server and router, and router and router connects to each +other. The purpose of key exchange protocol is to provide secure key +material to be used in the communication. The key material is used to +derive various security parameters used to secure SILC packets. The +SILC Key Exchange protocol is described in detail in [SILC3]. + +Authentication is done after key exchange protocol has been successfully +completed. The purpose of authentication is to authenticate for example +client connecting to the server. However, usually clients are accepted +to connect to server without explicit authentication. Servers are +required use authentication protocol when connecting. The authentication +may be based on passphrase (pre-shared-secret) or public key. The +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 become 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 Method (2) - The method of the authentication. + The authentication methods are defined in [SILC2] in the + Connection Auth Request Payload. The NONE authentication + method SHOULD NOT be used. + +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 Length 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 function 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) which 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 + +This section defines all the allowed algorithms that can be used in +the SILC protocol. This includes mandatory cipher, mandatory public +key algorithm and MAC algorithms. + + +.ti 0 +3.10.1 Ciphers + +Cipher is the encryption algorithm that is used to protect the data +in the SILC packets. See [SILC2] of the actual encryption process and +definition of how it must be done. SILC has a mandatory algorithm that +must be supported in order to be compliant with this protocol. + +The following ciphers are defined in SILC protocol: + +.in 6 +aes-256-cbc AES in CBC mode, 256 bit key (REQUIRED) +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 + + +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 +debugging mode. + +Additional ciphers MAY be defined to be used in SILC by using the +same name format as above. + + +.ti 0 +3.10.2 Public Key Algorithms + +Public keys are used in SILC to authenticate entities in SILC network +and to perform other tasks related to public key cryptography. The +public keys are also used in the SILC Key Exchange protocol [SILC3]. + +The following public key algorithms are defined in SILC protocol: + +.in 6 +rsa RSA (REQUIRED) +dss DSS (OPTIONAL) +.in 3 + +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 following +notes: The signature encoding is always in same format as the encryption +encoding regardless 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 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: + +.in 6 +sha1 SHA-1, length = 20 (REQUIRED) +md5 MD5, length = 16 (OPTIONAL) +.in 3 + + +.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. + +The following MAC algorithms are defined in SILC protocol: + +.in 6 +hmac-sha1-96 HMAC-SHA1, length = 12 (REQUIRED) +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 + +The none MAC is not recommended to be used as the packet is not +authenticated when MAC is not computed. It is recommended that no +client or server would accept none MAC except in special debugging +mode. + +The HMAC algorithm is described in [HMAC] and hash algorithms that +are used as part of the HMACs are described in [Scheneir] and in +[Menezes] + +Additional MAC algorithms MAY be defined to be used in SILC. + + +.ti 0 +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 +significantly speed up the data transmission. By default, SILC does not +use compression which is the mode that must be supported by all SILC +implementations. + + + +The following compression algorithms are defined: + +.in 6 +none No compression (REQUIRED) +zlib GNU ZLIB (LZ77) compression (OPTIONAL) +.in 3 + +Additional compression algorithms MAY be defined to be used in SILC. + + +.ti 0 +3.11 SILC Public Key + +This section defines the type and format of the SILC public key. All +implementations MUST support this public key type. See [SILC3] for +other optional public key and certificate types allowed in the SILC +protocol. Public keys in SILC may be used to authenticate entities +and to perform other tasks related to public key cryptography. + +The format of the SILC Public Key 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Public Key Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Algorithm Name Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Algorithm Name ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Identifier Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Identifier ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Public Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 5: SILC Public Key + + +.in 6 +o Public Key Length (4 bytes) - Indicates the full length + of the public key, not including this field. + +o Algorithm Name Length (2 bytes) - Indicates the length + of the Algorithm Length field, not including this field. + +o Algorithm name (variable length) - Indicates the name + of the public key algorithm that the key is. See the + section 3.10.2 Public Key Algorithms for defined names. + +o Identifier Length (2 bytes) - Indicates the length of + the Identifier field, not including this field. + +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 the following + format: + + UN User name + HN Host name or IP address + RN Real name + E EMail address + O Organization + C Country + + + Examples of an identifier: + + `UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi' + + `UN=sam, HN=dummy.fi, RN=Sammy Sam, O=Company XYZ, C=Finland' + + At least user name (UN) and host name (HN) MUST be provided as + identifier. The fields are separated by commas (`,'). If + comma is in the identifier string it must be written as `\\,', + for example, `O=Company XYZ\\, Inc.'. + +o Public Data (variable length) - Includes the actual + public data of the public key. + + The format of this field for RSA algorithm is + as follows: + + 4 bytes Length of e + variable length e + 4 bytes Length of n + variable length n + + + The format of this field for DSS algorithm is + as follows: + + 4 bytes Length of p + variable length p + 4 bytes Length of q + variable length q + 4 bytes Length of g + variable length g + 4 bytes Length of y + variable length y + + The variable length fields are multiple precession + integers encoded as strings in both examples. + + Other algorithms must define their own type of this + field if they are used. +.in 3 + +All fields in the public key are in MSB (most significant byte first) +order. + + +.ti 0 +3.12 SILC Version Detection + +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 the following format: + +.in 6 +SILC-- +.in 3 + +The version strings are of the following format: + +.in 6 +protocol version = . +software version = [.[.]] +.in 3 + +Protocol version MAY provide both major and minor version. Currently +implementations MUST set the protocol version and accept the protocol +version as SILC-1.0-. + +Software version MAY provide major, minor and build version. The +software version MAY be freely set and accepted. + + +Thus, the version string could be, for example: + +.in 6 +SILC-1.0-1.2 +.in 3 + + + + +.ti 0 +4 SILC Procedures + +This section describes various SILC procedures such as how the +connections are created and registered, how channels are created and +so on. The section describes the procedures only generally as details +are described in [SILC2] and [SILC3]. + + +.ti 0 +4.1 Creating Client Connection + +This section describes the procedure when client connects to SILC server. +When client connects to server the server MUST perform IP address lookup +and reverse IP address lookup to assure that the origin host really is +who it claims to be. Client, host, connecting to server SHOULD have +both valid IP address and fully qualified domain name (FQDN). + +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 +example, the connecting client's IP address from the connection list +before the SILC Key Exchange protocol has been started. Reason for +this is that if the host is not allowed to connect to the server there +is no reason to perform the key exchange protocol. + +After successful key exchange protocol the client and server performs +connection authentication protocol. The purpose of the protocol is to +authenticate the client connecting to the server. Flexible +implementation could also accept the client to connect to the server +without explicit authentication. However, if authentication is +desired for a specific client it may be based on passphrase or +public key authentication. If authentication fails the connection +MUST be terminated. The connection authentication protocol is described +in [SILC3]. + +After successful key exchange and authentication protocol the client +registers itself by sending SILC_PACKET_NEW_CLIENT packet to the +server. This packet includes various information about the client +that the server uses to create the client. Server creates the client +and sends SILC_PACKET_NEW_ID to the client which includes the created +Client ID that the client MUST start using after that. After that +all SILC packets from the client MUST have the Client ID as the +Source ID in the SILC Packet Header, described in [SILC2]. + +Client MUST also get the server's Server ID that is to be used as +Destination ID in the SILC Packet Header when communicating with +the server (for example when sending commands to the server). The +ID may be resolved in two ways. Client can take the ID from an +previously received packet from server that MUST include the ID, +or to send SILC_COMMAND_INFO command and receive the Server ID as +command reply. + +Server MAY choose not to use the information received in the +SILC_PACKET_NEW_CLIENT packet. For example, if public key or +certificate were used in the authentication, server MAY use those +informations rather than what it received from client. This is suitable +way to get the true information about client if it is available. + +The nickname of client is initially set to the username sent in the +SILC_PACKET_NEW_CLIENT packet. User should set the nickname to more +suitable by sending SILC_COMMAND_NICK command. However, this is not +required as part of registration process. + +Server MUST also distribute the information about newly registered +client to its router (or if the server is router, to all routers in +the SILC network). More information about this in [SILC2]. + + +.ti 0 +4.2 Creating Server Connection + +This section describes the procedure when server connects to its +router (or when router connects to other router, the cases are +equivalent). The procedure is very much alike when client connects +to the server thus it is not repeated here. + +One difference is that server MUST perform connection authentication +protocol with proper authentication. A proper authentication is based +on passphrase or public key authentication. + +After server and router has successfully performed the key exchange +and connection authentication protocol, the server register itself +to the router by sending SILC_PACKET_NEW_SERVER packet. This packet +includes the server's Server ID that it has created by itself and +other relevant information about the server. + +After router has received the SILC_PACKET_NEW_SERVER packet it +distributes the information about newly registered server to all routers +in the SILC network. More information about this in [SILC2]. + +As client needed to resolve the destination ID this MUST be done by the +server that connected to the router, as well. The way to resolve it is +to get the ID from previously received packet. The server MAY also +use SILC_COMMAND_INFO command to resolve the ID. Server MUST also start +using its own Server ID as Source ID in SILC Packet Header and the +router's Server ID as Destination when communicating with the router. + + +.ti 0 +4.2.1 Announcing Clients, Channels and Servers + +After server or router has connected to the remote router, and it already +has connected clients and channels it MUST announce them to the router. +If the server is router server, also all the local servers in the cell +MUST be announced. + +All clients are announced by compiling a list of ID Payloads into the +SILC_PACKET_NEW_ID packet. All channels are announced by compiling a +list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet. Also, +the channel users on the channels must be announced by compiling a +list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into +the SILC_PACKET_NOTIFY packet. The users' modes on the channel must +also be announced by compiling list of Notify Payloads with the +SILC_NOTIFY_TYPE_CUMODE_CHANGE notify type into the SILC_PACKET_NOTIFY +packet. + +The router MUST also announce the local servers by compiling list of +ID Payloads into the SILC_PACKET_NEW_ID packet. + +The router which receives these lists MUST process them and broadcast +the packets to its primary route. + +When processing the announced channels and channel users the router MUST +check whether a channel exists already with the same name. If channel +exists with the same name it MUST check whether the Channel ID is +different. If the Channel ID is different the router MUST send the notify +type SILC_NOTIFY_TYPE_CHANNEL_CHANGE to the server to force the channel ID +change to the ID the router has. If the mode of the channel is different +the router MUST send the notify type SILC_NOTIFY_TYPE_CMODE_CHANGE to the +server to force the mode change to the mode that the router has. + +The router MUST also generate new channel key and distribute it to the +channel. The key MUST NOT be generated if the SILC_CMODE_PRIVKEY mode +is set. + +If the channel has channel founder on the router the router MUST send +the notify type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server to force +the mode change for the channel founder on the server. The channel +founder privileges MUST be removed. + +The router processing the channels MUST also compile a list of +Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into the +SILC_PACKET_NOTIFY and send the packet to the server. This way the +server (or router) will receive the clients on the channel that +the router has. + + +.ti 0 +4.3 Joining to a Channel + +This section describes the procedure when client joins to a channel. +Client joins to channel by sending command SILC_COMMAND_JOIN to the +server. If the receiver receiving join command is normal server the +server MUST check its local list whether this channel already exists +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 channel, new channel key is created and information about +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 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 sent to the client which sent the command originally. +Server will also receive the channel key from the server that it MUST +send to the client which 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. +If this is the case the client is joined to the channel and reply is +sent to the client. If the command was sent by server the command reply +is sent to the server which 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. 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 +the client is joined to the channel as described previously. If +the channel does not exist the channel is created and the client +is joined to the channel. The channel key is also created and +distributed as previously described. The client joining to the created +channel is made automatically channel founder and both channel founder +and channel operator privileges is set for the client. + +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 which receives the reply to +the join command MUST start using the received Channel ID in the channel +message communication thereafter. Client also receives the key for the +channel in the command reply. Note that the channel key is never +generated if the SILC_CMODE_PRIVKEY mode is set. + + +.ti 0 +4.4 Channel Key Generation + +Channel keys are created by router which creates the channel by taking +enough randomness from cryptographically strong random number generator. +The key is generated always when channel is created, when new client +joins a channel and after the key has expired. Key could expire for +example in an hour. + +The key MUST also be re-generated whenever some client leaves a channel. +In this case the key is created from scratch by taking enough randomness +from the random number generator. After that the key is distributed to +all clients on the channel. However, channel keys are cell specific thus +the key is created only on the cell where the client, which left the +channel, exists. While the server or router is creating the new channel +key, no other client may join to the channel. Messages that are sent +while creating the new key are still processed with the old key. After +server has sent the SILC_PACKET_CHANNEL_KEY packet MUST client start +using the new key. If server creates the new key the server MUST also +send the new key to its router. See [SILC2] on more information about +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. +Note that the server MUST also save the channel key. + + +.ti 0 +4.5 Private Message Sending and Reception + +Private messages are sent point to point. Client explicitly destines +a private message to specific client that is delivered to only to that +client. No other client may receive the private message. The receiver +of the private message is destined in the SILC Packet Header as any +other packet as well. + +If the sender of a private message does not know the receiver's Client +ID, it MUST resolve it from server. There are two ways to resolve the +client ID from server; it is RECOMMENDED that client implementations +send SILC_COMMAND_IDENTIFY command to receive the Client ID. Client +MAY also send SILC_COMMAND_WHOIS command to receive the Client ID. +If the sender has received earlier a private message from the receiver +it should have cached the Client ID from the SILC Packet Header. + +See [SILC2] for description of private message encryption and decryption +process. + + +.ti 0 +4.6 Private Message Key Generation + +Private message MAY be protected by the key generated by the client. +The key may be generated and sent to the other client by sending packet +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. + +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. + +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 + +Channel messages are delivered to group of users. The group forms a +channel and all clients on the channel receives messages sent to the +channel. + +Channel messages are destined to channel by specifying the Channel ID +as Destination ID in the SILC Packet Header. The server MUST then +distribute the message to all clients on the channel by sending the +channel message destined explicitly to a client on the channel. + +See [SILC2] for description of channel message encryption and decryption +process. + + +.ti 0 +4.8 Session Key Regeneration + +Session keys MUST be regenerated periodically, say, once in an hour. +The re-key process is started by sending SILC_PACKET_REKEY packet to +other end, to indicate that re-key must be performed. The initiator +of the connection SHOULD initiate the re-key. + +If perfect forward secrecy (PFS) flag was selected in the SILC Key +Exchange protocol [SILC3] the re-key MUST cause new key exchange with +SKE protocol. In this case the protocol is secured with the old key +and the protocol results to new key material. See [SILC3] for more +information. After the SILC_PACKET_REKEY packet is sent the sender +will perform the SKE protocol. + +If PFS flag was set the resulted key material is processed as described +in the section Processing the Key Material in [SILC3]. The difference +with re-key in the processing is that the initial data for the hash +function is just the resulted key material and not the HASH as it +is not computed at all with re-key. Other than that, the key processing +it equivalent to normal SKE negotiation. + +If PFS flag was not set, which is the default case, then re-key is done +without executing SKE protocol. In this case, the new key is created by +providing the current sending encryption key to the SKE protocol's key +processing function. The process is described in the section Processing +the Key Material in [SILC3]. The difference in the processing is that +the initial data for the hash function is the current sending encryption +key and not the SKE's KEY and HASH values. Other than that, the key +processing is equivalent to normal SKE negotiation. + +After both parties has regenerated the session key, both MUST send +SILC_PACKET_REKEY_DONE packet to each other. These packets are still +secured with the old key. After these packets, the subsequent packets +MUST be protected with the new key. + + + + +.ti 0 +4.9 Command Sending and Reception + +Client usually sends the commands in the SILC network. In this case +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 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 +further to receive the exact information about the requested client. +The WHOIS command travels all the way to the server which owns the client +and it replies with command reply packet. Finally, the server which +sent the command receives the command reply and it must be able to +determine which client sent the original command. The server then +sends command reply to the client. Implementations should have some +kind of cache to handle, for example, WHOIS information. Servers +and routers along the route could all cache the information for faster +referencing in the future. + +The commands sent by server may be sent hop by hop until someone is able +to process the command. However, it is preferred to destine the command +as precisely as it is possible. In this case, other routers en route +MUST route the command packet by checking the true sender and true +destination of the packet. However, servers and routers MUST NOT route +command reply packets to clients coming from other server. Client +MUST NOT accept command reply packet originated from anyone else but +from its own server. + + +.ti 0 +4.10 Closing Connection + +When remote client connection is closed the server MUST send the notify +type SILC_NOTIFY_TYPE_SIGNOFF to its primary router and to all channels +the client was joined. The server MUST also save the client's information +for a period of time for history purposes. + +When remote server or router connection is closed the server or router +MUST also remove all the clients that was behind the server or router +from the SILC Network. The server or router MUST also send the notify +type SILC_NOTIFY_TYPE_SERVER_SIGNOFF to its primary router and to all +local clients that are joined on the same channels with the remote +server's or router's clients. + + +.ti 0 +5 Security Considerations + +Security is central to the design of this protocol, and these security +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. + +Special attention must also be paid on the servers and routers that are +running the SILC service. The SILC protocol's security depends greatly +on the security and the integrity of the servers and administrators that +are running the service. It is recommended that some form of registration +is required by the server and router administrator prior acceptance to +the SILC Network. The clients must be able to trust the servers they +are using. + +It must also be noted that if the client requires absolute security by +not trusting any of the servers or routers in the SILC Network, this can +be accomplished by negotiating private keys outside the SILC Network, +either using SKE or some other key negotiation protocol, or to use some +other external means for distributing the keys. This applies for all +messages, private messages and channel messages. It is important to note +that SILC, like any other security protocol is not full proof system and +cannot secure from insecure environment; the SILC servers and routers could +very well be compromised. However, to provide acceptable level of security +and usability for end user the protocol uses many times session keys or +other keys generated by the servers to secure the messages. If this is +unacceptable for the client or end user, the private keys negotiatied +outside the SILC Network should always be used. In the end it is always +implementor's choice whether to negotiate private keys by default or +whether to use the keys generated by the servers. + +It is also recommended that router operators in the SILC Network would +form a joint forum to discuss the router and SILC Network management +issues. Also, router operators along with the cell's server operators +should have a forum to discuss the cell management issues. + + +.ti 0 +6 References + +[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + April 2001. + +[SILC3] Riikonen, P., "SILC Key Exchange and Authentication + Protocols", Internet Draft, April 2001. + +[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001. + +[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. + +[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, + November 1998. + +[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, + September 1999. + +[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key + Infrastructure, Certificate and CRL Profile", RFC 2459, + January 1999. + +[Schneier] Schneier, B., "Applied Cryptography Second Edition", + John Wiley & Sons, New York, NY, 1996. + +[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography", + CRC Press 1997. + +[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + +[ISAKMP] Maughan D., et al, "Internet Security Association and + Key Management Protocol (ISAKMP)", RFC 2408, November + 1998. + +[IKE] Harkins D., and Carrel D., "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + +[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. + +[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +.ti 0 +7 Author's Address + +.nf +Pekka Riikonen +Snellmanninkatu 34 A 15 +70100 Kuopio +Finland + +EMail: priikone@silcnet.org + +This Internet-Draft expires XXX -- 2.24.0