+Sun Oct 5 20:22:08 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * Backup router protocol version 1.2 implemented. Testing still
+ required. Affected files in silcd/server_backup.[ch], server.c,
+ packet_receive.c and server_internal.h.
+
+Sun Oct 5 12:36:37 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * silc_client_send_[channel|private]_message now return TRUE
+ or FALSE. Affected file lib/silcclien/client_channel.c and
+ client_prvmsg.c.
+
+Thu Oct 2 17:03:09 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * Check for explicit nickname in INVITE and BAN processing
+ during join as well (and don't expect only wildcards in
+ invite/ban strings). Affected file silcd/command.c.
+
+ * Fixed the INVITE and BAN by public key. The public key saved
+ is the PK payload (as specified) not the raw data. Affected
+ file silcd/server_util.c.
+
+Wed Oct 1 20:29:06 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * UTF-8 text message support for actions and notices in SILC
+ Client. Affected file irssi/src/silc/core/client_ops.c.
+
+ * silc_get_username and silc_get_real_name now returns sensible
+ data on Win32. Patch by Toni Willberg. Affected file is
+ lib/silcutil/win32/silcwin32util.c.
+
Sun Aug 24 23:35:19 CEST 2003 Jochen Eisinger <c0ffee@penguin-breeder.org>
* Provide a signal handler to send MIME encoded messages and emit
A sample perl script will be supplied at a later point.
- Affected files are irssi/docs/signals.txt,
- irssi/src/silc/core/client_ops.[ch],
+ Affected files are irssi/docs/signals.txt,
+ irssi/src/silc/core/client_ops.[ch],
irssi/src/silc/core/silc-{channels,servers}.c
Sun Aug 24 12:58:30 CEST 2003 Jochen Eisinger <c0ffee@penguin-breeder.org>
Affected files are irssi/src/silc/core/silc-{lag,core}.c.
+Mon Aug 11 17:14:17 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * Remove the channel auth list in normal server if router
+ encofrces its list during connecting. Send notify to channel
+ to remove the mode to remove the list. Affected files are
+ silcd/server_util.c and silcd/packet_receive.c.
+
+Wed Aug 6 14:52:04 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * Added support for channel public keys. Updated protocol specs
+ and implemented it. Affected files are
+ silcd/command.c, command_reply.c, lib/silcclient/command.c,
+ lib/silcclient/command_reply.c.
+
+Wed Jul 23 12:17:01 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * Ignore SIGXFSZ and SIGXCPU signals in server. They can
+ terminate the process on Linux. Affected file silcd/silcd.c.
+
+Mon Jun 2 19:13:27 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
+
+ * Check for NULL buffer in silc_buffer_clear. Affected file
+ is lib/silcutil/silcbuffer.h.
+
+ * Simplified the backup router protocol by removing the _GLOBAL
+ types. Updated protocol specs and the code. Affected files
+ are silcd/server_backup.[ch].
+
Thu Apr 24 19:50:25 EEST 2003 Pekka Riikonen <priikone@silcnet.org>
* Deny '@' and '!' from nicknames since they are reserved
lib/silcutil/silcschedule.c.
* Changed Win32 implementation of SilcThread to use modern
- Win32 interface. Affected file is
+ Win32 interface. Affected file is
lib/silcutil/win32/silcwin32thread.c A patch by Mikko L.
Thu Dec 12 12:06:59 CET 2002 Jochen Eisinger <c0ffee@penguin-breeder.org>
* Don't print signed messages when sending failed. Affected files
- irssi/src/silc/core/silc-[servers.c/commands.h]
+ irssi/src/silc/core/silc-[servers.c/commands.h]
* Send adquate signal when founding a channel by joing it. Affect
file irssi/src/silc/core/client_ops.c
* Fixed double free in SKE library error hadling when signature
error occurred. Affected file lib/silcske/silcske.c.
- * Save the fingerprint to new SilcClientEntry after changing
+ * Save the fingerprint to new SilcClientEntry after changing
nickname. Affected file lib/silcclient/client_notify.c.
* Print SIGNOFF in Irssi SILC client only if the nickname is
* Fixed bugs in Irssi's theme parsing. Affected files
irssi/src/fe-common/core/themes.c
-
+
Wed Dec 4 18:29:13 EET 2002 Pekka Riikonen <priikone@silcnet.org>
* Calculate the correct length for signed messages before
* Do reverse lookups for server when /connecting. Affected files
irssi/silc.conf, irssi/src/core/servers.c, irssi/src/core/network.c,
irssi/src/core/net-nonblock.*
-
+
Thu Nov 28 16:19:18 CET 2002 Pekka Riikonen <priikone@silcnet.org>
* Added library versioning for shared libraries. Affected
* SILC_UMODE_GONE changes are now propagated correctly to the
Irssi client. Closes #54
-
+
Tue Nov 12 19:42:18 CET 2002 Jochen Eisinger <c0ffee@penguin-breeder.org>
* Fixed example in /HELP KEY
the command call simpler for the application. The library
now handles the command line parsing, command finding and
execution. Application only needs to call the function
- with the command line. Affected files are
+ with the command line. Affected files are
lib/silcclient/silcclient.h, command.[ch].
* Fixed silc_get_input to NULL-terminate the returned input.
* Fixed connection closing in client library to not crash.
Moved the connection freeing totally to function
- silc_clinet_del_connection. Affected file
+ silc_clinet_del_connection. Affected file
lib/silcclinet/client.c.
Fri Nov 1 18:57:02 EET 2002 Pekka Riikonen <priikone@silcnet.org>
usage. Affected files lib/silcclient/client_internal.h
lib/silcclient/silcclient.h.
- * Fixed a bug in query resolving in server. Used wrong
+ * Fixed a bug in query resolving in server. Used wrong
variable in a for loop and crashed. Affected file is
silcd/server_query.c.
over. Affected file silcd/packet_receive.c. Bug #37.
* Resolve incomplete client entrys in CUMODE_CHANGE and
- CMODE_CHANGE notifys. Affected file is
+ CMODE_CHANGE notifys. Affected file is
lib/silcclient/client_notify.c. Bug #42.
Thu Oct 24 12:22:35 EEST 2002 Pekka Riikonen <priikone@silcnet.org>
* Fixed attribute encoding and decoding bugs. Affected
files lib/silccore/silcattrs.[ch].
- * Added ATTR command to Irssi SILC Client which is used to
+ * Added ATTR command to Irssi SILC Client which is used to
manage user's Requested Attributes sending and values for
WHOIS command. Affected files around Irssi SILC client.
Affected files lib/silcske/silcske.c, silcske_status.h and
payload.c.
- * Save the PKCS key length even if only private key is set to
+ * Save the PKCS key length even if only private key is set to
SilcPKCS. Affected file lib/silccrypt/silcpkcs.[ch] and rsa.c.
* Fixed the usage of silc_pkcs_get_key_len since it returns the
silcd/packet_receive.c.
* From now on distribution versions are used as protocol versions
- instead of by default using the Toolkit base version as protocol
+ instead of by default using the Toolkit base version as protocol
version. Affected file prepare.
* Do not set the locally resolved hostname for local client
* Fixed pending command deletion in server and client library
to check the whole list instead of breaking after first found.
- The affected files are silcd/command.[ch] and
+ The affected files are silcd/command.[ch] and
lib/silcclient/command.[ch].
Sat Jun 29 17:40:12 EEST 2002 Pekka Riikonen <priikone@silcnet.org>
It expected it to always be only client and ignored the
notify. Affected file silcd/packet_recieve.c.
- * Removed some (unnecessary) debug printing from
+ * Removed some (unnecessary) debug printing from
lib/silccore/silcid.c and lib/silccore/silcargument.c.
* Do not force CMODE_CHANGE when server is announcing new
fixes some problems too. Affected file silcd/packet_receive.c.
* Fixed SERVER_SIGNOFF sending to local clients. It was
- totally broken and sent the notify to all local clients,
+ totally broken and sent the notify to all local clients,
instead of only to those that was on same channel as the
signing off clients. Affected file silcd/server_util.c.
when that mode is set. Protocol TODO #17. Affected
files are silcd/server.[ch], server_util.[ch],
silcd/command.c, silcd/packet_receive.c and
- lib/silcclient/command.c.
+ lib/silcclient/command.c.
Fri May 3 18:36:51 EEST 2002 Pekka Riikonen <priikone@silcnet.org>
silcd/command.c and silcd/command_reply.c.
* Fixed client info resolving on LEAVE command in client
- library to not crash. Affected file is
+ library to not crash. Affected file is
lib/silcclient/client_notify.c.
Thu May 2 08:45:11 CEST 2002 Pekka Riikonen <priikone@silcnet.org>
Moved the silc_client_command_status_messages table to the
lib/silcutil/silcutil.c and added new funtion
silc_get_status_message, which deprecates function
- silc_client_status_message. Affected files are
+ silc_client_status_message. Affected files are
lib/silccore/silcstatus.h, lib/silcclient/command_reply.[ch],
lib/silcutil/silcutil.[ch].
* Defined the use of extra WHOIS attributes in WHOIS command.
The <Requested Attributes> (defined in a separate document)
- can be used to request additional information about user
+ can be used to request additional information about user
not returned by standard WHOIS command. Defined that server
can send WHOIS command directly to client. Client provides
the requested attributes to the server. Updated the protocol
specs. Protocol TODO #4. Implementation is not done yet
(Protocol TODO #24).
- * Renamed function silc_client_command_status_message to
+ * Renamed function silc_client_command_status_message to
silc_client_status_message. Affected files are
lib/silcclient/command_reply.[ch].
Fri Apr 12 20:09:08 EEST 2002 Pekka Riikonen <priikone@silcnet.org>
* Added resolve_cmd_ident field to the SilcClientEntry structure
- too so that if the entry is for example being resolved so
+ too so that if the entry is for example being resolved so
another command may attach to the same pending command reply
without requiring to resolve the same entry again. Added
support for adding multiple pending commands for one
Private Message Key flag is set (using private keys to protect
private messages). Updated protocol specs and code in client
and server and core library. Protocol TODO #23. Affected
- files are lib/silccore/silcmode.h, silcd/server.[ch],
+ files are lib/silccore/silcmode.h, silcd/server.[ch],
irssi/src/silc/core/client_ops.c, silcd/packet_receive.c,
irssi/docs/help/in/umode.in, lib/silcclient/command.c.
* Added more IM-like features by introducing new user modes
for setting various presence information. Added new modes:
INDISPOSED, BUSY, PAGE, HYPER and ROBOT. Updated protocol
- specs and code. Protocol TODO #19. Affected files are
+ specs and code. Protocol TODO #19. Affected files are
lib/silccore/silcmode.h, irssi/src/silc/core/client_ops.c,
irssi/docs/help/in/umode.in and lib/silcclient/command.c.
* Added STATS command to the protocol after all, to return
various statistical information about the network. It can
be used by clients to retrieve statistical information, and
- servers may use it to to fetch cell and network wide
+ servers may use it to to fetch cell and network wide
statistics from router. Updated the protocol specs and
implemented it to the server. Protocol TODO #16.
Affected files are lib/silccore/silccommand, silcd/command.[ch],
Sat Apr 6 17:08:58 EEST 2002 Pekka Riikonen <priikone@silcnet.org>
* The LIST command reply in client libary now adds new channel
- entry if the returned channel doesn't exist yet in cache,
+ entry if the returned channel doesn't exist yet in cache,
and returns the channel entry to the application in the
command_reply client operation. Affected file is
lib/silcclient/command_reply.c.
* Defined that the security property fields in SKE SHOULD be
UTF-8 encoded, defined that version string MUST be US-ASCII
- encoded, defined that passphrases sent in connection
+ encoded, defined that passphrases sent in connection
authentication protocol MUST be UTF-8 encoded. Implemented
these to the client and server. Defined also that other
passphrases sent in the protocol MUST be UTF-8 encoded.
- Affected files are lib/silcske/silcske.c,
- lib/silcclient/protocol.c, silcd/protocol.c,
+ Affected files are lib/silcske/silcske.c,
+ lib/silcclient/protocol.c, silcd/protocol.c,
silcd/serverconfig.c, and lib/silccore/silcauth.c.
* Changed the silc_client_close_connection interface to not
* Added the killer's client ID to the KILLED notify and added
it to protocol specs and implemented it to client and server.
Protocol TODO #13. Affected files are silcd/command.c,
- silcd/packet_receive.c, packet_send.[ch],
+ silcd/packet_receive.c, packet_send.[ch],
lib/silcclient/client_notify.c, irssi/src/silc/core/client_ops.c.
The killer's client entry is now returned to application in
the `notify' client operation.
Changed the client library to return the message length
to application as well in the channel_message and private_message
- client operations. Affected files are
+ client operations. Affected files are
lib/silcclient/client_prvmsg, lib/silcclient/client_channel.c,
lib/silcclient/silcclient.h, irssi/src/silc/core/client_ops.c,
and lib/silcclient/client_ops_example.c.
* Deprecated all administrative commands from SILC protocol
since they are highly implementation specific commands.
- Updated protocol specs. Moved the old commands in
+ Updated protocol specs. Moved the old commands in
implementations to private range of command types. Affected
files are silcd/command.c, lib/silcclient/command.c and
lib/silcclient/command_reply.c. Protocol TODO #8.
Wed Apr 3 09:57:47 CEST 2002 Pekka Riikonen <priikone@silcnet.org>
* Added SILC_PROTOCOLVERSION macro to check protocol version
- of a socket connection. The affected file is
+ of a socket connection. The affected file is
lib/silcutil/silcsockconn.h.
* Added better error logging in rekey protocol. Affected file
Tue Apr 2 14:55:06 CEST 2002 Pekka Riikonen <priikone@silcnet.org>
* Some client implementations quit network by doing first LEAVE
- and then immediately SIGNOFF (like Bombyx). We now do check
- after a short time after LEAVE notify and check whether the
- client is still valid after LEAVE, and if not we remove it from
+ and then immediately SIGNOFF (like Bombyx). We now do check
+ after a short time after LEAVE notify and check whether the
+ client is still valid after LEAVE, and if not we remove it from
cache. Affected file is lib/silcclient/client_notify.c.
Tue Apr 2 13:39:04 CEST 2002 Johnny Mnemonic <johnny@themnemonic.org>
* Fixed the silc_log_quick handling in the logging routines.
It didn't log quickly when it was TRUE. Affected file is
lib/silcutil/silclog.c. Also the flush delay was set even
- if it was 0 in config file. Affected file is
+ if it was 0 in config file. Affected file is
silcd/serverconfig.c.
* Added support for changing key pair of the server in rehash.
called the application does not call silc_packet_send_prepare
because the library will call it automatically. These
interfaces now also return a reference to the outgoing buffer
- which includes the assembled packet, which the application can
+ which includes the assembled packet, which the application can
use to encrypt the packet.
Affected files are lib/silccore/silcpacket.[ch],
Mon Mar 18 21:00:41 EET 2002 Pekka Riikonen <priikone@silcnet.org>
* Added macro SILC_PACKET_DATALEN which can be used during
- packet assembling to check whether the data to be added to
+ packet assembling to check whether the data to be added to
the packet will fit to SILC_PACKET_MAX_LEN. If not the data
len is truncated until it fits it.
* Added the deleting of server's own ID cache entry to the
silc_server_free function. Free also everything else that
- has been allocated in silc_server_init. The affected file
+ has been allocated in silc_server_init. The affected file
is silcd/server.c.
Sun Mar 17 15:44:56 EET 2002 Pekka Riikonen <priikone@silcnet.org>
* Added new configuration params: version_protocol, version_software
and version_software_vendor to specify what version the remote
host must at least be to be able to connect to server. The vendor
- string can be regex matched too. Added new function
+ string can be regex matched too. Added new function
silc_server_connection_allowed to check maximum number of allowed
connections, and allowed versions for incoming connections.
Affected files are silcd/server.c, server_util.[ch] and
Renamed silc_schedule_wakeup_init and silc_schedule_wakeup_uninit
to silc_schedule_internal_init and silc_schedule_internal_uninit.
Added new platform specific routines
- silc_schedule_internal_signals_[un]block and
+ silc_schedule_internal_signals_[un]block and
silc_schedule_internal_signal_[un]register.
Added new functions to SILC Schedule API:
it was mistakenly updated to SILC Protocol 1.0 even though it
is to be included in 1.1. Since it is not in 1.0 it is not
mandatory, and this fix now handles it only if it is provided,
- and it is not error if it is not provided. Affected file
+ and it is not error if it is not provided. Affected file
lib/silcclient/client_notify.c.
Sat Mar 16 09:07:27 EET 2002 Pekka Riikonen <priikone@silcnet.org>
* Fixed the server to check correctly the amount of connections
from single host, by checking also the type of the connection.
Fixed also the comparison of number of connections and number
- of allowed connections. Affected files are silcd/server.c,
+ of allowed connections. Affected files are silcd/server.c,
server_util.[ch].
Fri Mar 8 17:16:41 EET 2002 Pekka Riikonen <priikone@silcnet.org>
reconnect_interval_max, reconnect_keep_trying and
require_reverser_lookup. Added ConnectionParam block, and
implemented the connection parameters when connecting as
- initiator and when accepting connections as responder.
+ initiator and when accepting connections as responder.
Added CONFIG_IS_DOUBLE macro in config file parsing, to check
whether given configuration value has been given already.
* Removed doc/example_silc.conf.in since it is redundant.
The make install will now install irssi/silc.conf file.
- * Added new Passphrase and Publickey authentication methods to
+ * Added new Passphrase and Publickey authentication methods to
config file, allowing both public key and passphrase based
authentication to be set at the same time.
* Fixed the file transfer's key agreement payload to include
zero port also if the hostname is NULL because it could not
- be bound.
+ be bound.
Call file transfer monitor callback now also if error occurs
during key agreement protocol.
Thu Jan 31 19:06:22 EET 2002 Pekka Riikonen <priikone@silcnet.org>
- * Added function silc_client_add_channel,
+ * Added function silc_client_add_channel,
silc_client_replace_channel_id, and removed functions
silc_client_new_channel_id and silc_idlist_get_channel_by_id
from client library.
- * Added cross reference of the joined channels to the
+ * Added cross reference of the joined channels to the
SilcClientEntry, and changed the SilcChannelEntry's
users list to SilcHashTable. The affected files are
lib/silcclient/idlist.[ch].
* Changed all hash table traversing to call the new
silc_hash_table_list_reset in server and in client library.
- * Added function silc_client_on_channel to return the
+ * Added function silc_client_on_channel to return the
SilcChannelUser entry if the specified client entry is joined
on the specified channel. This is exported to application as
well. Affected files lib/silcclient/client_channel.c, silcapi.h.
* Fixed the CHANNEL_CHANGE notify to re-announce the channel
which ID was changed. This way the router will send the
- user list for the channel again, and server won't be in
+ user list for the channel again, and server won't be in
desync in some rare circumstances. Affected file is
silcd/packet_receive.c.
* Added silc_client_start_key_exchange_cb and lookup the
remote hostname and IP address before starting the key
- exchange with server. The affected file is
+ exchange with server. The affected file is
lib/silcclient/client.c.
* The server's public key is now saved using the IP address
context. When error occurs during socket operation (read
or write) the error is saved. Added also new function
silc_socket_get_error to return human readable socket error
- message. Affected files are lib/silcutil/silcsockconn.[ch],
+ message. Affected files are lib/silcutil/silcsockconn.[ch],
lib/silcutil/unix/silcunixsockconn.c, and
lib/silcutil/win32/silcwin32sockconn.c.
* Fixed the `created' channel information sending from router
to server in JOIN command. Checks now whether the channel
- really was created or not and set it according that.
+ really was created or not and set it according that.
Fixed the JOIN command to use the client entry's current
ID during the joining procedure instead of the one it sent
in the command (it is checked though), since it can change
- between the packet processing and command processing, and
+ between the packet processing and command processing, and
would just case unnecessary pain in the client end. Affected
file silcd/command.c.
The server now checks that if unauthenticated connection
sends data and its processing fails the server will close
- the connection since it could be a malicious flooder.
+ the connection since it could be a malicious flooder.
Affected files lib/silccore/silcpacket.[ch], silcd/server.c.
too much useless log). Affected file lib/silcutil/silclog.c.
Wed Dec 19 18:21:51 CET 2001 Johnny Mnemonic <johnny@themnemonic.org>
-
+
* Made the silc_server_daemonise() function more readable.
Affected file silcd/server.c.
-
+
* Pid file is now optional, the user may comment it out from
the config file. Removed define SILC_SERVER_PID_FILE, we
don't need a default any longer. Affected file
configure.in.pre, lib/Makefile.am.pre.
-
+
* Make some use of the pid file. The server now dies at startup
if it detects a valid pid file on his path. The server would
die anyway in this circumstance, because of the bind() failure.
Affected file silcd/silcd.c.
-
+
* No longer compiling lib/dotconf.
Mon Dec 17 18:24:27 EET 2001 Pekka Riikonen <priikone@silcnet.org>
* Fied the NICK_CHANGE notify to add the new client entry
even it is resolved. This removes an <[unknown]> nick
- thingy bug in the client. Affected file is
+ thingy bug in the client. Affected file is
lib/silcclient/client_notify.c.
* Do not try to allocate 0 bytes (efence does not like it)
in WHOIS or IDENTIFY from router, and it is global client,
we'll check whether it is on some channel. If it is not
then we cannot be sure about its validity and will resolve it
- from router. Fixes a bug in WHOIS and IDENTIFY. Affected
+ from router. Fixes a bug in WHOIS and IDENTIFY. Affected
file silcd/command.c.
* Search channel by name (if possible) rather than by ID
* Implemented the <founder auth> payload handling in the JOIN
command. If provided all conditions for channel joining
- except requirement to provide correct passphrase can be
+ except requirement to provide correct passphrase can be
overrided by the channel founder. Updated the protocol specs.
Affected file silcd/command.c.
IP/hostname. Affected file lib/silcutil/silcnet.c.
* Defined <founder auth> argument to the SILC_COMMAND_JOIN
- command. It can be used to gain founder privileges at
+ command. It can be used to gain founder privileges at
the same time when joining the channel.
- Defined that the SILC_NOTIFY_TYPE_KICKED send the
+ Defined that the SILC_NOTIFY_TYPE_KICKED send the
kicker's client ID as well. Updated protocol specs.
Defined that the server must send SILC_COMMAND_IDENTIFY
Fri Nov 23 23:30:59 EET 2001 Pekka Riikonen <priikone@silcnet.org>
* Pid file configuration, and server's config file fixes
- patch by toma. Updated CREDITS file.
+ patch by toma. Updated CREDITS file.
Sun Nov 18 01:34:41 EET 2001 Pekka Riikonen <priikone@silcnet.org>
Should fix /NAMES bit more. The affected file is
irssi/src/silc/core/silc-channels.c.
- * Added `fingerprint' field to the SilcIDListData in the
+ * Added `fingerprint' field to the SilcIDListData in the
silcd/idlist.h to hold the fingerprint of the client's
public key.
Sat Nov 3 17:48:55 EET 2001 Pekka Riikonen <priikone@silcnet.org>
- * Added silc_pkcs_public_key_compare to compare two
+ * Added silc_pkcs_public_key_compare to compare two
public keys. Affected file lib/silccrypt/silcpkcs.[ch].
* Check that the client who set the founder mode on the
client library. Affected file lib/silcclient/client.c.
* Fixed the silc_client_packet_parse to not to increase
- the packet sequence number if the conn->sock and the
+ the packet sequence number if the conn->sock and the
current socket connection is not same. This can happen
for example during key agreement when the conn includes
multiple socket connections (listeners). Affected file
corresponding private key is verified by the server).
Updated to the protocol specification.
- * Added support of receiving the client's public key's
+ * Added support of receiving the client's public key's
fingerprint in command reply in client library. Affected
file is lib/silcclient/command_reply.c, and
lib/silcclient/idlist.[ch].
the provided table of client entries. Affected file
silcd/packet_send.[ch].
- * Fixed a crash in client resolving in client_prvmsg.c in
+ * Fixed a crash in client resolving in client_prvmsg.c in
client library. Affected file lib/silcclient/client_prvmsg.c.
* Do not actually remove the client directly from ID cache
silcd/packet_receive.c.
* Check for partial packet in data queue after every packet that
- was found from the queue. Return and wait for more data if
+ was found from the queue. Return and wait for more data if
there is partial data in queue. Affected file is
lib/silccore/silcpacket.c.
lib/silcclient/client.c.
* SilcPacketParserCallback now returns TRUE or FALSE to indicate
- whether library should continue processing the packet.
+ whether library should continue processing the packet.
Affected file lib/silccore/silcpacket.h.
* Added SilcSFTPMonitor callback, SilcSFTPMonitors and
* Added new local command FILE to the Irssi SILC Client.
It is used to perform the file transfer. It has subcommands
SEND, RECEIVE, SHOW and CLOSE. Affected files
- irssi/src/silc/core/client_ops.c,
+ irssi/src/silc/core/client_ops.c,
irssi/src/silc/core/silc-server.[ch].
Mon Oct 22 12:50:08 EDT 2001 Pekka Riikonen <priikone@silcnet.org>
* Renamed silc_file_read and silc_file_write to functions
silc_file_readfile and silc_file_writefile. Added function
- silc_file_open and silc_file_close. Affected files
+ silc_file_open and silc_file_close. Affected files
lib/silcutil/silcutil.[ch].
Thu Oct 18 20:58:13 EDT 2001 Pekka Riikonen <priikone@silcnet.org>
(SSH File Transfer Protocol). Affected file in addition
of the internet draft is lib/silccore/silcpacket.h.
- * Deprecated the SILC_PACKET_CELL_ROUTERS and defined new
+ * Deprecated the SILC_PACKET_CELL_ROUTERS and defined new
packet SILC_PACKET_RESUME_ROUTER instead. The new packet
is used as part of backup router protocol when the primary
router of the cell is back online and wishes to resume
change causes incompatibilities in the protocol.
* Redefined also the MAC computation from the packet.
- An packet sequence number is now added to the MAC
+ An packet sequence number is now added to the MAC
computation. This prevents possible replay attacks against
the protocol. This change too causes incompatibilities
in the protocol.
case all found clients are already disconnected (WHOWAS would
found them) in the server. Affected file silcd/command.c.
- * Update the last_receive (time of last data received) to be
+ * Update the last_receive (time of last data received) to be
updated only when received private or channel message so that
the idle time showed in WHOIS makes more sense.
* Removed channel key rekey task deleting from the function
silc_server_save_channel_key. Affected file silcd/server.c.
- Added explicit timeout task context instead that is used to
+ Added explicit timeout task context instead that is used to
delete the task if we are registering a new task before the
new task has elapsed.
as well. This replaced the old boolean registered field as well.
Added resolve_cmd_ident field to the SilcClientEntry structure
- too so that if the entry is for example being resolved so
+ too so that if the entry is for example being resolved so
another command may attach to the same pending command reply
without requiring to resolve the same entry again. This concept
should optimize the WHOIS and the IDENTIFY resolving under
* Changed the silc_client_get_clients_local to accept the formatted
nickname as argument. It accepts the real nickname too but the
- formatted nickname can be used to find the true entry from
+ formatted nickname can be used to find the true entry from
multiple entries. Affected file lib/silcclient/silcapi.h and
lib/silcclient/idlist.c.
provided then the library will use the string as is. The
affected file is lib/silcclient/silcapi.h.
- * All the nickname strings passed to the client library in
+ * All the nickname strings passed to the client library in
commands are now expected to be formatted nickname strings.
If the command does not support the formatted nickname string
it will assume that the sent string is the actual nickname.
application can call this function if it does not know the
current authentication method.
- Affected files are lib/silcclient/client.c and
+ Affected files are lib/silcclient/client.c and
lib/silcclient/silcapi.h.
* The Irssi SILC client now automatically resolves the authentication
* Changed the silc_id_create_client_id to be collision
resistant. It is now assured that there cannot be created
- two same client ID's. I suspect that some weird bugs in
+ two same client ID's. I suspect that some weird bugs in
the server were actually caused by duplicate Client IDs.
Affected file silcd/serverid.[ch]. A router receiving
new ID now also assures and informs the sending server
if client could not be added to ID cache. Affected files
silcd/packet_receive.c and silcd/server.c.
- * When client's sock->user_data is freed, NULL also the
+ * When client's sock->user_data is freed, NULL also the
client->router and client->connection pointers. Added check
for these pointers being NULL to various places around the
code. Affected file silcd/server.c.
are not handled when it is not allowed. Affected file
silcd/server.c.
- * Added `bool registered' fields to all
+ * Added `bool registered' fields to all
silc_idlist_[server|client]_get_* routines to indicate whether
the fetched client needs to be registered or not. Affected
file silcd/idlist.[ch].
Wed Jul 18 18:34:01 EEST 2001 Pekka Riikonen <priikone@silcnet.org>
- * Call silc_schedule_task_del_by_context in the
+ * Call silc_schedule_task_del_by_context in the
silc_protocol_cancel instead of silc_schedule_task_del_by_callback.
Affected file lib/silccore/silcprotocol.c.
updated the protocol specs.
* Completed the GETKEY command in client. It can be now used
- to fetch also servers public key not only some clients.
+ to fetch also servers public key not only some clients.
Affected files lib/silcclient/command[_reply].c.
* Added silc_client_get_server to return server entry by the
The INFO command now allocates the SilcServerEntry context
and saves the server info there. The COMMAND_REPLY in
- the INFO now returns the parameters to application in
+ the INFO now returns the parameters to application in
same order as defined in the protocol specification.
The entries are cached in the client->server_cache.
* Fixed a channel joining bug in router. The router must also
check the channel modes, invite and ban lists etc. when serving
the JOIN command sent by normal server. Affected file is
- silcd/command.c. The router now resolves the client's
+ silcd/command.c. The router now resolves the client's
information from the server who sent the JOIN command if it
does not know it, and processes the JOIN command only after
that.
* Added SILC_MUTEX_DEFINE to define the mutex on environments
that may or may not compile the mutex support in.
-
+
Changed the silc_mutex_alloc interface. It allocates the
mutex now to the sent pointer and returns TRUE or FALSE.
* Fixed the KICK notify handling in the Irssi SILC client to
update the channel records so that the kicked client does not
- appear to be on the channel. The affected file is
+ appear to be on the channel. The affected file is
irssi/src/silc/core/silc-channels.c.
* Always update the conn->current_channel when executing command
* Fixed KILL notify handling, client does not crash anymore.
Affected file irssi/src/silc/core/silc-channels.c.
- * Reduced the default packet buffer size from 2048 to 1024 in
+ * Reduced the default packet buffer size from 2048 to 1024 in
lib/silccore/silcpacket.c.
* Added SILC_SKE_STATUS_FREED SKE status type and a reference
counter to the SKE context that is incresed when the SKE library
performs async operation outside the library. If the outside
- process frees the SKE context and FREED status will be set
+ process frees the SKE context and FREED status will be set
and the library will detect after the sync operation that the
libary is freed. The affected files are
lib/silcske/silcske[_status].[ch].
passed as client entry to the application. */
* Fixed the task timeout calculation to assure that there is
- never negative timeouts. The affected file is
+ never negative timeouts. The affected file is
lib/silcutil/silcschedule.c.
* Fixed the channel user mode notification sending in server.
* Fixed a possible crash in silc_packet_send_prepare. It now
assures always that there is enough space in the buffer and
- at the tail area of the buffer (for MAC).
+ at the tail area of the buffer (for MAC).
Fixed the inbound buffer reallocation in silc_packet_read.
It was old code and did not handle the reallocation correctly.
Irssi SILC client's message modules formats.
Added the handing of the KILL notify to the Irssi SILC client
- as it was missing. Added the kill message module formats
+ as it was missing. Added the kill message module formats
as well.
The affected file is irssi/src/silc/core/silc-channels.c.
Thu Jun 7 08:57:16 CEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * Close log file after open. Affected file
+ * Close log file after open. Affected file
lib/silcutil/silclog.c.
* Check whether sock == NULL in silc_client_send_packet and return
Tue Jun 5 08:08:21 CEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * Merged a splitted window bugfix from Irssi CVS tree. The
+ * Merged a splitted window bugfix from Irssi CVS tree. The
affected file is irssi/src/fe-text/textbuffer-view.c.
* Fixed the ME, ACTION and NOTICE printing in Irssi Client.
silcd/serverconfig.[h] and silcd/server.c.
* Changed the layout of the header files of the public interfaces
- in the SILC libraries. The new layout supports ROBODoc
+ in the SILC libraries. The new layout supports ROBODoc
documentation tool (and some others) so that it is easy to create
a library reference manual. All the other headers and source
code must still follow the CodingStyle document. Also source
error message printing to module formats in the Irssi SILC client.
* Added new silc_client_set_away_message to set the away message
- that is back to the person who sent private message. The
+ that is back to the person who sent private message. The
affected file lib/silcclient/silcapi.h and the
lib/silcclient/client_prvmsg.c.
Sat May 26 12:13:37 EEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Changed the ask_passphrase client operation to be ascynchronous.
- It has now a completion callback and a context that the
+ It has now a completion callback and a context that the
application must call after it has got the passphrase from
the user. Affected files lib/silcclient/silcapi.h,
lib/silcclient/protocol.c, lib/silcclient/command.c and
as well. Defined SilcVerifyPublicKey callback that is used to
indicate the success of the public key verification process.
- Changed the server and client to use the new async client
+ Changed the server and client to use the new async client
operations.
* Changed the Irssi SILC client's internal scheduler to be called
* Replaced the client entry's `channel' list and channel entry's
`user_list' list to hash tables for optimized lookup. Changed
- the code to use the hash table interface around the code.
+ the code to use the hash table interface around the code.
Affected file lib/silcd/idlist.[ch].
* Added `auto_rehash' boolean argument to the function
with Client ID but with the hash of the ID (which is a hash of
the nickname) as well without any difference in performance.
- Added also silc_idcache_find_by_id_one_ext to do one on one
+ Added also silc_idcache_find_by_id_one_ext to do one on one
searching when we have the actual ID. Added also function
silc_hash_client_id_compare. The affected files are
lib/silccore/idcache.[ch] and lib/silcutil/silcutil.[ch].
case sensitive.
* Fixed a bug in server with channel message sending. It put
- wrong ID type as destination ID. The affected file
+ wrong ID type as destination ID. The affected file
silcd/packet_send.c.
* silc_idcache_del_by_context now deletes from all hash tables
The affected files are lib/silccore/id.[ch] and other files
around the tree using these routines.
- * Removed the ID length arguments in server from various
- silc_server_send_notify_* routines -> they are not needed
+ * Removed the ID length arguments in server from various
+ silc_server_send_notify_* routines -> they are not needed
anymore.
Sat May 5 13:56:33 EEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
Tue May 1 14:18:13 EEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Fixed the silc_verify_public_key client operation function to
- save the public keys differently. The fingerprint is now
+ save the public keys differently. The fingerprint is now
used as filename and not the hostname. This way also the
client keys are saved uniquely and not with hostnames. The
affected file is silc/client_ops.c.
incoming connection before executing any KE or authentication
protocols.
- * The connection configuration is now saved to the KE and
- connection auth protocol contexts and not fetched anymore in
+ * The connection configuration is now saved to the KE and
+ connection auth protocol contexts and not fetched anymore in
the protocol. Affected files silcd/server.c, silcd/protocol.[ch].
* The local hosts listenning address and port is also resolved
* Added function silc_server_config_is_primary_route to check
whether primary router connection has been configured (a router
- configuration that we are initiating). If there is not, we
+ configuration that we are initiating). If there is not, we
will assume that there is only two routers in the SILC network
and we will use the incoming router connection as our primary
route. Affected files silcd/serverconfig.[ch], silcd/server.c.
* Removed the client's failure_callback handling with timeout
and handle it immediately when received.
- * The SKE library returned wrong type in SUCCESS and FAILURE
+ * The SKE library returned wrong type in SUCCESS and FAILURE
packets. They must be 32 bit MSB not 16 bit MSB.
Fri Apr 13 00:09:08 EEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
function is silc_[server/client]_packet_send_real to check
the situation.
- * Replaced the SIM paths from example config files to
+ * Replaced the SIM paths from example config files to
/usr/local/modules. Also, make install creates now
/usr/local/silc/logs directory to hold all the SILC server
logs.
Wed Apr 4 16:32:31 EEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Do not ask whether user wants to use the negotiated private key
- for private messages, just use it. Affected file is
+ for private messages, just use it. Affected file is
silc/local_command.c.
- * Added `send_enc_key' and `enc_key_len' fields to the
+ * Added `send_enc_key' and `enc_key_len' fields to the
SilcIDListData structure since they are needed in the re-key
phase. Affected file is silcd/idlist.[ch].
int64 of at least the xintXX size. If void * is less that 4
bytes uint32 * will be used. Defined bool as boolean.
- * Changed _ALL_ unsigned long and unsigned int to uint32,
+ * Changed _ALL_ unsigned long and unsigned int to uint32,
unsgined short to uint16 in the source tree.
* Fixed a fatal bug in silc_server_remove_clients_by_server. Do
This fixes some bugs with WHOIS, WHOWAS and IDENTIFY commands
and command replies.
- * All command reply functions in the server now calls the
+ * All command reply functions in the server now calls the
pending command callback even if error occured. This way the
error will be delivered to the client as well. Affected files
silcd/command.c and silcd/command_reply.c.
code and the protocol specs.
* A little fix to IDENTIFY command in the server. Search the
- client first by hash not nickname. Affected file is
+ client first by hash not nickname. Affected file is
silcd/command.c.
* Fixed the silc_client_close_connection to support closing
server's CMODE command. Affected file silcd/command.c.
* Added the following new functions into lib/silccore/silcauth.[ch]:
- silc_auth_get_method and silc_auth_get_data.
+ silc_auth_get_method and silc_auth_get_data.
* The server now saves the remote hosts public key to the
SilcIDListData pointer. Affected file silcd/protocol.c.
* The normal server now does not remove the channel entry from
the cache if the founder authentication data is set. It used
- to remove it if the founder was the last one on the channel on
+ to remove it if the founder was the last one on the channel on
the server and left the channel. The auth data is saved and
if the channel is re-joined later the old entry is used with
the old auth data. Affected files silcd/command_reply.c and
message to a channel with SILC_MESSAGE_FLAG_ACTION to indicate
some action. Affected file silc/local_command.[ch].
- * Changed channel_message and private_message client operations
+ * Changed channel_message and private_message client operations
to deliver the message flags to the application. Added also
the `flags' arguments to the silc_client_send_channel_message
and silc_client_send_private_message functions. Affected file
* Added `sockets' and `sockets_count' fields to the SilcClient
object. They hold the sockets of the listenning sockets in
- the client. Listenning sockets may be for example the key
+ the client. Listenning sockets may be for example the key
agreement server. Affected file lib/silcclient/client.[ch].
Added functions the silc_client_add_socket and the
silc_client_del_socket. They are exported to the application
* Added <cipher> and <hmac> argument to the CMODE_CHANGE notify
type to indicate the change of the current cipher and hmac
on the channel. Client can safely ignore the <cipher> argument
- (if it chooses to do so) since the CHANNEL_KEY packet will
+ (if it chooses to do so) since the CHANNEL_KEY packet will
force the channel key change anyway. The <hmac> argument is
important since the client is responsible of setting the new
HMAC and the hmac key into use.
client must be removed from all channels when receiving the
KILLED notify.
- Also, do not remove the client entry when giving the KILL
+ Also, do not remove the client entry when giving the KILL
command but when the KILLED notify is received.
* Removed silc_idlist_find_client_by_nickname from the server.
* Added silc_server_send_notify_ban to send the BAN notify
type between routers.
- * Chaned the silc_notify_payload_encode to support that if
+ * Chaned the silc_notify_payload_encode to support that if
argument is NULL it ignores and checks the next argument.
Affected file lib/silccore/silcnotify.c.
* Added new command SILC_COMMAND_BAN that can be used to manage
the ban list of the channel. Updated the protocol specs.
- * Removed the channel modes: the SILC_CMODE_BAN and the
+ * Removed the channel modes: the SILC_CMODE_BAN and the
SILC_CMODE_INVITE_LIST as they were a bit kludge to be included
in the CMODE command. The equivalent features are now available
using INVITE and BAN commands. Updated the protocol specs.
in the network about change in the current ban list. The notify
type is not used by the client.
- * Redefined parts of the SILC_NOTIFY_TYPE_INVITE command to
+ * Redefined parts of the SILC_NOTIFY_TYPE_INVITE command to
support the invite lists.
Thu Mar 22 22:52:23 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Fixed various bugs in WHOIS and IDENTIFY command handling as
they were buggy because of the WHOWAS information.
- * Fixed local command MSG to handle the async resolving of
+ * Fixed local command MSG to handle the async resolving of
the remote client properly. It used to fail the first MSG.
Affected file silc/local_command.c.
about the changed user mode.
Implemented the notify handling in the server. Affected file is
- silcd/packet_receive.c. Added the function
+ silcd/packet_receive.c. Added the function
silc_server_send_notify_umode to the silcd/packet_send.[ch].
* Added new generic Channel Payload and deprecated the New Channel
like _send_private_message_key, _relay_notify etc. Affected
file is silcd/packet_send.[ch].
- Removed silc_server_send_key_agreement,
+ Removed silc_server_send_key_agreement,
silc_server_send_private_message_key and
silc_server_packet_relay_notify functions from the file
silcd/packet_send.[ch].
library in the file lib/silcclient/command.c.
* Changed the silc_server_send_notify_on_channels's `sender'
- argument from SilcSocketConnection to SilcClientEntry to
+ argument from SilcSocketConnection to SilcClientEntry to
check the sender as entry and not as connection object and not
to send to the client provided as argument. The affected file
is silcd/packet_send.[ch].
it to the client. Affected file silcd/packet_send.[ch].
Added also silc_server_packet_process_relay_notify to check
- whereto relay the notify. Affected file is
+ whereto relay the notify. Affected file is
silcd/packet_receive.[ch].
* Implemented the KILL command to the server.
Tue Mar 13 13:26:18 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Added support to the server to enforce that commands are not
- executed more than once in 2 seconds. If server receives
+ executed more than once in 2 seconds. If server receives
commands from client more frequently, timeout is registered
to process the commands. Affected file silcd/command.c.
Added new function silc_server_command_process_timeout.
* Removed error printing from the WHOIS and IDENTIFY commands.
If error occurs then it is ignored silently in the client library.
- The application, however, may map the received error to
+ The application, however, may map the received error to
human readable error string. The application currently maps
the NO_SUCH_NICKNAME error to string.
* Made the command status message public to the application. Moved
- them from lib/silcclient/command_reply.c to
+ them from lib/silcclient/command_reply.c to
lib/silcclient/command_reply.h. The application can map the
received command status to the string with the
silc_client_command_status_message function.
* Added SilcChannelPrivateKey argument to the function
silc_client_send_channel_message so that application can choose
to use specific private ke if it wants to. If it is not provided,
- the normal channel key is used, unless private keys are set.
- In this case the first (key that was added first) is used
+ the normal channel key is used, unless private keys are set.
+ In this case the first (key that was added first) is used
as the encryption key.
* Implemented the support for channel private key handling.
* Removed the statement that server (or router) must send USERS
command reply when joining to the channel so that the client
- knows who are on the channel. Instead, the client list and
+ knows who are on the channel. Instead, the client list and
client's mode list is now sent in the JOIN command reply to the
client who joined channel. This is better solution.
lib/silccore/silcchannel.[ch].
* Moved the channel message etc, check from silc_packet_decrypt
- to applications. The library calls now a generic
+ to applications. The library calls now a generic
SilcPacketCheckDecrypt callback which is to return TRUE or FALSE
when the packet is either normal or special. This was done to
allow more wide range of checking that was not allowed when
file: lib/silcutil/silcbuffmt.c.
* Changed to auto-reconnect to check whether the remote host is
- router and register the re-connect timeout if it is. It used
+ router and register the re-connect timeout if it is. It used
to check that whether we are normal server, but router must do
auto-reconnect with another router as well. Affected file
silcd/server.c.
* Redefined the mandatory HMAC algorithms and added new algorithms.
Added hmac-sha1-96 and hmac-md5-96 which are normal hmac-sha1
- and hmac-md5 truncated to 96 bits. The mandatory is now
+ and hmac-md5 truncated to 96 bits. The mandatory is now
hmac-sha1-96. Rest are optional (including the one that used
to be mandatory). Rationale for this is that the truncated HMAC
length is sufficient from security point of view and can actually
another remote client. The key material is passed to the
application after the protocol is over.
- * Created client_keyagr.c to include all the key agreement
+ * Created client_keyagr.c to include all the key agreement
routines.
* Added macro SILC_TASK_CALLBACK_GLOBAL which is equal to the
files: lib/silccrypt/silccipher.[ch].
* Implemented silc silc_client_add_private_message_key,
- silc_client_add_private_message_key_ske,
+ silc_client_add_private_message_key_ske,
silc_client_del_private_message_key,
silc_client_list_private_message_keys and
silc_client_free_private_message_keys functions in the
code accordingly. The default key length is now 256 bits.
* Fixed SKE key distribution function silc_ske_process_key_material
- when the key length is more than 128 bits. The default key
+ when the key length is more than 128 bits. The default key
length in SILC is now 256 bits.
* Added new command status type: SILC_STATUS_ERR_UNKOWN_ALGORITHM
* Also deprecated the following packet types: REPLACE_ID,
NEW_CHANNEL_USER and REMOVE_CHANNEL_USER packet types.
-
+
* Added list support for Notify packet in server.
* Added silc_server_send_notify_channel_change to send the
* Added silc_server_send_notify_leave to send LEAVE notify type.
Deprecates the function silc_server_send_remove_channel_user.
- * Added silc_server_send_notify_cmode and
+ * Added silc_server_send_notify_cmode and
silc_server_send_notify_cumode to send CMODE and CUMODE notify
types. Deprecates the silc_server_send_set_mode function.
* Added SERVER_SIGNOFF notify type to indicate that server has
- quit. This means that all clients on the channel from that
+ quit. This means that all clients on the channel from that
server will drop. This can be also used when netsplit happens.
Deprecated REMOVE_ID packet type since it is not needed anymore
SIGNOFF notify type.
* Employed the PKCS #1. It is the mandatory way to do RSA in the
- SILC protocol from this day on. Changed the protocol
+ SILC protocol from this day on. Changed the protocol
specification as well.
* Added silc_server_send_notify_topic_set to send TOPIC_SET
* The JOIN notify type now takes one extra argument <Channel ID>.
The packet used to be destined to the channel but now the
- JOIN type may be sent as list thus it is impossible to
+ JOIN type may be sent as list thus it is impossible to
destine it to any specific channel. By adding this argument
it is again possible.
* Created Global RNG API which is global RNG that application can
initialize. After initializing, any routine anywhere in the
code (including library) can use RNG without allocating a new
- RNG object. This was done to allow this sort of use of the
+ RNG object. This was done to allow this sort of use of the
RNG in code that has no chance to allocate RNG object. All
applications currently allocate this and many routines in the
library use this. Affected file lib/silccrypt/silcrng.[ch].
* Added silc_pkcs_encrypt, silc_pkcs_decrypt, silc_pkcs_sign,
silc_pkcs_verify and silc_pkcs_sign_with_hash and
- silc_pkcs_verify_with_hash functions into the file
+ silc_pkcs_verify_with_hash functions into the file
lib/silccrypt/silcpkcs.[ch].
Mon Feb 19 19:59:28 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * The client entry's userinfo pointer must be always valid.
+ * The client entry's userinfo pointer must be always valid.
Otherwise the [<unknown>] bug will surface beacuse the WHOIS
will fail since it requires the userinfo. Now, the userinfo
is allocated as "" if actual userinfo does not exist. Actually,
All this applies for client library code as well. Similar
changes were made there as well for the pending commands.
- In the client, the application must now allocate the
+ In the client, the application must now allocate the
SilcClientCommandContext with the silc_client_command_alloc
function.
* Added reference counter to the SilcServerCommandContext. Added
- function silc_server_command_alloc and silc_server_command_dup
+ function silc_server_command_alloc and silc_server_command_dup
functions.
Same type of functions added to the client library for the same
purpose as well.
- * Removed the cmd_ident from IDListData away since it is now
+ * Removed the cmd_ident from IDListData away since it is now
global for all connections. It is the command identifier used
in command sending and with pending commands. The affected file
is silcd/idlist.h.
* Added new functions into the silcd/packet_receive.[ch]:
silc_server_new_id_list, silc_server_new_channel_list and
- silc_server_new_channel_user_list to handle the incoming
+ silc_server_new_channel_user_list to handle the incoming
NEW_ID_LIST, NEW_CHANNEL_LIST and NEW_CHANNEL_USER_LIST packets.
* Added support of changing Channel ID in the function
Thu Feb 15 20:07:37 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Added new packet type SILC_PACKET_HEARTBEAT that is used to
- send keepalive packets. The packet can be sent by clients,
+ send keepalive packets. The packet can be sent by clients,
servers and routers.
Added function silc_socket_set_heartbeat into the file
lib/silccore/silcsockconn.[ch] to set the heartbeat timeout.
- If not set, the heartbeat is not performed. The actual
+ If not set, the heartbeat is not performed. The actual
heartbeat is implemented in the low level socket connection
library. However, application is responsible of actually
sending the packet.
reverse order. For this reason, MAC check failed. Now, this
is fixed by not sending the Channel Key packet immediately but
putting it to queue. However, this is more fundamental problem:
- packets that are in queue should actually not be encrypted
+ packets that are in queue should actually not be encrypted
because packets that are sent immediately gets encrypted
actually with wrong IV (and thus MAC check fails). So, packets
that are in queue should be encrypted when they are sent to
whether the requested user and group actually exists.
* Added sanity check to SKE's silc_ske_responder_finish to check
- that the public and private key actually is valid.
+ that the public and private key actually is valid.
* Invalidate the client's nickname when receiving Replace ID
packet and the Client ID is being replaced. This means that the
* Fixed some places where client was added to the IDList. The
rule of thumb is following (in order to get everything right):
- If the client is directly connected local client then the
- `connection' argument must be set and `router' argument must be
+ If the client is directly connected local client then the
+ `connection' argument must be set and `router' argument must be
NULL to silc_idlist_add_client function. If the client is not
directly connected client then the `router' argument must
bet set and the `connection' argument must be NULL to the
Sat Feb 10 21:13:45 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * A big code auditing weekend happening. Auditing code for
+ * A big code auditing weekend happening. Auditing code for
obvious mistakes, bugs and errors. Also, removing any code
that is obsolete.
o The buffer formatting routines now check that the destination
buffer really has enough space to add the data. This applies for
- both buffer formatting and unformatting
+ both buffer formatting and unformatting
(lib/silcutil/silcbuffmt.[ch]). Also, the entire buffer
- unformatting was changed to accomodate following rules:
+ unformatting was changed to accomodate following rules:
XXX_*STRING_ALLOC will allocate space for the data into the pointer
- sent to the function while XXX_*STRING will not allocate or copy
+ sent to the function while XXX_*STRING will not allocate or copy
the data into the buffer. Instead it sets the pointer from the
buffer into the pointer sent as argument (XXX_*STRING used to
require that the pointer must be allocated already). This change
channels and clients channel modes) to all routers in the
network. Updated the protocol specification accordingly.
- Added functions into silcd/packet_send.c and
- silcd/packet_receive.c: silc_server_send_set_mode,
+ Added functions into silcd/packet_send.c and
+ silcd/packet_receive.c: silc_server_send_set_mode,
silc_server_set_mode.
Added new files silcmode.[ch] into lib/silccore that implements
Sat Feb 3 15:44:54 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * Oops, a little mistake in server's connection authentication
+ * Oops, a little mistake in server's connection authentication
protocol. The protocol is not ended with FAILURE but with
SUCCESS if the authentication is Ok. :) Affected file is
silcd/protocol.c.
the local clients on the channel. After the changing nickname
in router environment snhould work and the [<unknown>] nickname
should appear no more.
-
+
The silc_server_replace_id function that receives the Replace ID
payload now sends the NICK_CHANGE notify type also in the file
silcd/packet_receive.c
* Changed WHOIS and IDENTIFY command to support the maximum amount
- of arguments defined in protocol specs (3328 arguments). This
+ of arguments defined in protocol specs (3328 arguments). This
fixed a bug that caused problems when there were more than three
users on a channel.
* Fixed some minor bugs in client when sending WHOIS command. The
arguments was in wrong order.
- * Removed statis function add_to_channel from server in
+ * Removed statis function add_to_channel from server in
silcd/command.c that was previously used with the joining but
is obsolete now.
Changed the function silc_client_command_pending and
silc_client_command_pending_del and added new function
- silc_client_command_pending_check. Removed the
+ silc_client_command_pending_check. Removed the
SILC_CLIENT_CMD_REPLY_EXEC, and SILC_CLIENT_PENDING_COMMAND_CHECK
macros.
global list who is joining and JOINs it to the channel. This is
for normal server, that is.
- Changed silc_server_send_notify_on_channel,
- silc_server_packet_relay_to_channel and
+ Changed silc_server_send_notify_on_channel,
+ silc_server_packet_relay_to_channel and
silc_server_packet_send_to_channel check if we are normal server
and client has router set (ie. global client) do not send the
message to that client, as it is already routed to our router.
- * Implemented LEAVE notify type handling in silc_server_notify
+ * Implemented LEAVE notify type handling in silc_server_notify
function.
* Tested LEAVE command in router environment successfully. Tested
client.[ch] into client library.
* Changed JOIN command reply to send information whether the channel
- was created or not (is existing already) and the channel key
+ was created or not (is existing already) and the channel key
payload. Changed protocol specs accordingly.
* Fixed bugs in WHOIS and IDENTIFY command reply sending when
* Fixed a bug in Client library. IDENTIFY and WHOIS reply functions
now correctly save the received data.
- * silc_server_free_sock_user_data now notifies routers in the
+ * silc_server_free_sock_user_data now notifies routers in the
network about entities leaving the network.
At the same time implemented functions silc_server_remove_id
IDENTIFY command now also checks that client->nickname must be
valid. If it is not if will request the data from the server who
- owns the client. Added new function
+ owns the client. Added new function
silc_server_command_identify_check.
* Added silc_command_set_command into lib/silccore/silcommand.[ch]
Sat Dec 16 17:39:54 EET 2000 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Implemented version string checking to both client and server.
- The check is incomplete currently due to the abnormal version
+ The check is incomplete currently due to the abnormal version
strings used in development version of SILC.
* Changed all command functions in server to use the new
support binary data as ID Cache data. Changed code to support
binary data in lib/silccore/idcache.c.
- * Renamed silc_server_packet_relay_command_reply to
+ * Renamed silc_server_packet_relay_command_reply to
silc_server_command_reply as it is normal packet receiving
function. Rewrote the function to accept command replys for
servers and not only for clients.
* Fixed the JOIN command to really work in router environment. If the
channel is created it is always created by the router. Router is
also responsible of making the initial joining to the channel,
- sending JOIN notify to the sending server and distributing
+ sending JOIN notify to the sending server and distributing
NEW_CHANNEL and NEW_CHANNEL_USER packets. Hence, if the channel
does not exist server doesn't do anything else but forward the
command to the router which performs everything.
* The channel key is now distributed to the local client as soon
as it is received from the router (in router environment) so that
- no other packet may be sent for the channel until client has
+ no other packet may be sent for the channel until client has
received the key.
* silc_server_remove_channel_user now broadcasts the received
silc_[client/server]_packet_parse_type the packet context must
be duplicated by calling silc_packet_context_dup. Otherwise it
gets free'd after silc_[client/server]_packet_parse_type returns.
- Also, one must remember that if packet is duplicated then its
+ Also, one must remember that if packet is duplicated then its
reference count must be decresed by calling the free function as
many times as it was duplicated.
Thu Nov 2 16:28:01 EET 2000 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * Changed client's channel table to SilcList and changed code
+ * Changed client's channel table to SilcList and changed code
accordingly. Also changed SilcChannelClientEntry to include back-
pointer to the channel so that client entry can use that structure
as list as well and we have fast cross-reference to the channel.
* NAMES command reply now shows users mode with the nickname when
joining to channel.
- * Moved silc_client_ch[u]mode[_char] functions from
+ * Moved silc_client_ch[u]mode[_char] functions from
silc/clientutil.[ch] to lib/silcclient/client.[ch]. Though, that
place sucks, they are utility functions and should be in some
other file.
already defined as a list. It is not suitable to add just some
context to the list (in TRQ, the context is the list actually).
- So, I defined SilcDList that can be used for the purpose where
+ So, I defined SilcDList that can be used for the purpose where
predefined list structure does not exit. This can be used as
such list. Now some context just can be added to the SilcDList.
Currently this list is not used in the SILC just yet, though there
Also fixed some annoying warning messages that the original TRQ
code generated. Also minor changes to TRQ's Makefile.in.
- * Added support for querying by Client ID to both WHOIS and
+ * Added support for querying by Client ID to both WHOIS and
IDENTIFY commands into server, as required by the protocol.
* Removed method function pointers from SilcBuffer structure. They
no good reason. This change also made silc_buffer_alloc and
silc_buffer_free functions inline functions.
- * Disabled command flooding detection support until it's fixed so
+ * Disabled command flooding detection support until it's fixed so
that it accepts commands in but does not execute them more than once
in two seconds.
that the message is sent only once per client.
* Moved silc_log_format (from lib/silcutil/silclog.[ch] into
- lib/silcutil/silcutil.[ch] as silc_format function. The new
+ lib/silcutil/silcutil.[ch] as silc_format function. The new
function is generic and is used by server as well, not only by
the logging routines.
does not reside in the SKE library. The function checks the version
string remote end sent.
- * Added back pointers (to opaque context and to SilcSocketConnection)
+ * Added back pointers (to opaque context and to SilcSocketConnection)
into SilcPacketContext structure into lib/silccore/silcpacket.h.
* Added silc_packet_context_dup into lib/silccore/silcpacket.[ch] to
to application (otherwise application doesn't know that it is for
channel (library gets it from packet's Destination ID)).
- * Added silc_client_remove_from_channels into client library to
- remove a client from all channels it has joined to. Used when
+ * Added silc_client_remove_from_channels into client library to
+ remove a client from all channels it has joined to. Used when
received SIGNOFF notify from server. Added also new function
silc_client_replace_from_channels to replace old ID entry with
new ID entry on all channels. Used when received NICK_CHANGE
notify from server.
- * Fixed ID Cache list handling in silc_idlist_get_client in
+ * Fixed ID Cache list handling in silc_idlist_get_client in
lib/silcclient/idlist.c. Also, added silc_idlist_get_client_by_id
to get (or query) client by ID.
Mon Oct 9 20:57:02 EEST 2000 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * Changed SILC_COMMAND_IDENTIFY in protocol specification to
+ * Changed SILC_COMMAND_IDENTIFY in protocol specification to
accept searching by Client ID as well.
* Added support for LEAVE and SIGNOFF notify types in client library.
* Added into lib/silccore/silcbufutil.[ch] new function;
silc_buffer_realloc.
- * Moved generic packet sending/encryption functions to
+ * Moved generic packet sending/encryption functions to
lib/silccore/silcpacket.[ch] from client and server. Some
rewriting of the functions.
Tue Jul 11 20:27:26 EEST 2000 Pekka Riikonen <priikone@poseidon.pspt.fi>
- * Rewrote major parts of the ID cache system. Don't know
+ * Rewrote major parts of the ID cache system. Don't know
whether it is better now or not but at least the API is more
cleaner now.
* Added public key verification process into client's protocol.c.
The client now verifies the public key from user and saves
- it into ~./silc/serverkeys/ directory.
+ it into ~./silc/serverkeys/ directory.
Added into: clientutil.[ch]: silc_client_verify_server_key.
* Removed wrong way of sending command status messages from
server to client in server's command.c. The old way violated
- protocol specification.
+ protocol specification.
Changes to silccore/silccommand.[ch]: removed
silc_command_encode_status_payload -> not needed anymore,
* Implemented LEAVE command on client and server.
- * Previously deprecated SILC_PACKET_FORWARDED flag is now in use
+ * Previously deprecated SILC_PACKET_FORWARDED flag is now in use
again. This change was made to the protocol as well. Server
should not violate the protocol specification anymore.
TODO for SILC Server 1.0
========================
+ o The status type arguments from commands-06.txt
+
o Fix CUMODE_CHANGE founder key things.
- o 1.2 backup router support
+ o Backup router testing
+
+ - test all resume error cases for backup router
+ - test all resume error cases for normal server
+ - test all resume error cases for primary router
+ - test communication
o Testing
example), and how external projects can use Toolkit without gluing into
it (how to link etc), debugging, architecture, types, etc.
- o Searching of predefined keywords, exact and partial matches (would be
+ o Searching of predefined keywords, exact and partial matches (would be
nice).
sender with the hostname and port of your key agreement
server with this command.
- If the hostname and port are ommitted, the irssi boolean
+ If the hostname and port are ommitted, the boolean
variable use_auto_addr will be examined. If it is set
the value of auto_bind_ip will be used as the IP address
to listen for the return reply, the value of auto_public_ip
will be the IP address sent to the remote client, and the
auto_bind_port will be the port value to be bound to and
sent to the remote client. If auto_public_ip is unset, but
- auto_bind_ip is set, irssi will send the auto_bind_ip
+ auto_bind_ip is set, silc client will send the auto_bind_ip
variable's value to the remote client.
negotiate [<hostname> [<port>]]
LIB_BASE_VERSION=1.0
# libsilc versions
-LIBSILC_CURRENT=1
+LIBSILC_CURRENT=2
LIBSILC_REVISION=0
-LIBSILC_AGE=1
+LIBSILC_AGE=0
# libsilcclient versions
-LIBSILCCLIENT_CURRENT=1
-LIBSILCCLIENT_REVISION=1
+LIBSILCCLIENT_CURRENT=2
+LIBSILCCLIENT_REVISION=0
LIBSILCCLIENT_AGE=0
# Substitute the version numbers
makerfc = ../scripts/makerfc
all:
- touch draft-riikonen-silc-spec-07.txt
- touch draft-riikonen-silc-pp-07.txt
+ touch draft-riikonen-silc-spec-08.txt
+ touch draft-riikonen-silc-pp-08.txt
touch draft-riikonen-silc-ke-auth-07.txt
- touch draft-riikonen-silc-commands-05.txt
+ touch draft-riikonen-silc-commands-06.txt
touch draft-riikonen-silc-flags-payloads-03.txt
touch draft-riikonen-presence-attrs-02.txt
dist-hook:
$(SILC_TOP_SRCDIR)/scripts/manpages.pl
- touch draft-riikonen-silc-spec-07.txt
- touch draft-riikonen-silc-pp-07.txt
+ touch draft-riikonen-silc-spec-08.txt
+ touch draft-riikonen-silc-pp-08.txt
touch draft-riikonen-silc-ke-auth-07.txt
- touch draft-riikonen-silc-commands-05.txt
+ touch draft-riikonen-silc-commands-06.txt
touch draft-riikonen-silc-flags-payloads-03.txt
touch draft-riikonen-presence-attrs-02.txt
- $(makerfc) draft-riikonen-silc-spec-07.nroff \
- draft-riikonen-silc-spec-07.txt
- $(makerfc) draft-riikonen-silc-pp-07.nroff \
- draft-riikonen-silc-pp-07.txt
+ $(makerfc) draft-riikonen-silc-spec-08.nroff \
+ draft-riikonen-silc-spec-08.txt
+ $(makerfc) draft-riikonen-silc-pp-08.nroff \
+ draft-riikonen-silc-pp-08.txt
$(makerfc) draft-riikonen-silc-ke-auth-07.nroff \
draft-riikonen-silc-ke-auth-07.txt
- $(makerfc) draft-riikonen-silc-commands-05.nroff \
- draft-riikonen-silc-commands-05.txt
+ $(makerfc) draft-riikonen-silc-commands-06.nroff \
+ draft-riikonen-silc-commands-06.txt
$(makerfc) draft-riikonen-silc-flags-payloads-03.nroff \
draft-riikonen-silc-flags-payloads-03.txt
$(makerfc) draft-riikonen-presence-attrs-02.nroff \
dist-hook:
$(SILC_TOP_SRCDIR)/scripts/manpages.pl
rm draft-riikonen*.txt
- touch draft-riikonen-silc-spec-07.txt
- touch draft-riikonen-silc-pp-07.txt
+ touch draft-riikonen-silc-spec-08.txt
+ touch draft-riikonen-silc-pp-08.txt
touch draft-riikonen-silc-ke-auth-07.txt
- touch draft-riikonen-silc-commands-05.txt
+ touch draft-riikonen-silc-commands-06.txt
touch draft-riikonen-silc-flags-payloads-04.txt
touch draft-riikonen-presence-attrs-02.txt
endif
--- /dev/null
+.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 12 August 2003
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-commands-06.txt 12 August 2003
+Expires: 12 February 2004
+
+.in 3
+
+.ce 2
+SILC Commands
+<draft-riikonen-silc-commands-06.txt>
+
+.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 [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 ...................................... 4
+ 2.2 SILC Command Argument Idioms .............................. 4
+ 2.3 SILC Commands List ........................................ 5
+ 2.4 SILC Command Status Payload ............................... 42
+3 SILC Status Types ............................................. 43
+4 Security Considerations ....................................... 50
+5 References .................................................... 50
+6 Author's Address .............................................. 51
+Appendix A ...................................................... 51
+Full Copyright Statement ........................................ 53
+
+
+.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 [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) <nickname> (2) <username@host>
+.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) <nickname>[@<server>] (2) <message>
+ (3) [<count>]
+
+The command has maximum of 3 arguments. However, only first
+and second arguments are mandatory.
+
+First argument <nickname> is mandatory but may have optional
+<nickname@server> format as well. Second argument is mandatory
+<message> argument. Third argument is optional <count> 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
+<message> argument, regardless of the ordering of the arguments in
+the Command Payload.
+
+Reply messages to the command:
+
+Max Arguments: 4
+ Arguments: (1) <Status Payload> (2) [<channel list>]
+ (3) <idle time> (4) [<away message>]
+
+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 <Status Payload>, 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_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_NICK
+
+Every command reply also defines set of status message that it
+may return inside the <Status Payload>. All status messages
+are defined in the section 2.3 SILC Command Status Payload
+The status messages defined with the command are recommendations.
+It is possible to return other status messages not listed with
+the command reply definition.
+.in 3
+
+
+.ti 0
+2.2 SILC Command Argument Idioms
+
+All commands that has an ID as argument (for example <Client ID>) are
+actually ID Payloads, defined in [SILC2] that includes the type of the
+ID, length of the ID and the actual ID data. This way variable length
+ID's can be sent as arguments.
+
+All passphrases that may be sent in commands as arguments MUST be
+UTF-8 [RFC2279] encoded.
+
+All public keys and certificates that are sent as arguments are actually
+Public Key Payloads [SILC2]. This way it is possible to send different
+kind of public keys and certificate types as arguments.
+
+
+
+
+.ti 0
+2.3 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: 256
+ Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
+ (3) [<Requested Attributes>] (4) [<Client ID>]
+ (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 <count> 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 <count> is
+ 32 bit MSB first order integer.
+
+ It is also possible to search the user by Client ID. If the
+ <Client ID> is provided server MUST use it as the search value
+ instead of the <nickname>. One of the arguments MUST be given.
+ It is also possible to define multiple Client ID's to search
+ multiple users sending only one 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 explicit 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, if
+ the router is unable to provide all mandatory information about
+ the 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.
+
+ The <Requested Attributes> is defined in [ATTRS] and can be used
+ to request various information about the client. See Appendix A
+ for definition of using these attributes in SILC.
+
+ Reply messages to the command:
+
+ Max Arguments: 11
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) <nickname>[@<server>] (4) <username@host>
+ (5) <real name> (6) [<Channel Payload
+ list>]
+ (7) [<user mode>] (8) [<idle time>]
+ (9) [<fingerprint>] (10) <channel user
+ mode list>
+ (11) [<Attributes>]
+
+
+ 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. If multiple Client IDs was requested then each found
+ and unfound client MUST cause successful or error reply,
+ respectively.
+
+ 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
+ <count> option were defined in the query there will be only
+ <count> many replies from the server.
+
+ The server returns the list of channels if the client has
+ joined channels. In this case the list is list of Channel
+ Payloads. The Mode Mask in the Channel Payload is the channel's
+ mode. The list is encoded by adding the Channel Payloads one
+ after the other. Private and secret channels MUST NOT be sent,
+ except if the sender of this command is on those channels, or
+ the sender is server. The <channel user mode list> MUST also
+ be sent if client is joined channels. This list includes 32 bit
+ MSB first order values one after the other and each indicate
+ the user's mode on a channel. The order of these values MUST
+ be same as the channel order in the <Channel Payload list>.
+
+ The server also returns client's user mode, idle time, and the
+ fingerprint of the client's public key. The <fingerprint> is the
+ binary hash digest of the public key. The fingerprint MUST NOT
+ be sent if the server has not verified the proof of possession of
+ the corresponding private key. Server can do this during the
+ SILC Key Exchange protocol. The <fingerprint> is SHA1 digest.
+
+ The <Attributes> is the reply to the <Requested Attributes>.
+ See the Appendix A for more information.
+
+ 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) <nickname>[@<server>] (2) [<count>]
+
+ 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 <count> 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 <count> is 32 bit MSB first order integer.
+
+ 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) <Status Payload> (2) <Client ID>
+ (3) <nickname>[@<server>] (4) <username@host>
+ (5) [<real name>]
+
+ This command may reply with several command reply messages to form
+ a list of results. In this case the status payload will include
+ 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: 256
+ Arguments: (1) [<nickname>[@<server>]] (2) [<server name>]
+ (3) [<channel name>] (4) [<count>]
+ (5) [<ID Payload>] (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, servers and channels.
+
+ The query may find multiple matching entities. The <count> 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
+ <count> is 32 bit MSB first order integer.
+
+ It is also possible to search the entity by its ID. If the
+ <ID Payload> 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 most likely 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) <Status Payload> (2) <ID Payload>
+ (3) [<entity's name>] (4) [<info>]
+
+ 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. If multiple Client
+ IDs was requested then each found and unfound client must cause
+ successful or error reply, respectively.
+
+ When querying clients the <entity's name> must include the client's
+ nickname in the following format: nickname[@server]. The
+ <info> must include the client's username and host in the following
+ format: username@host.
+
+ When querying servers the <entity's name> must include the server's
+ full name. The <info> may be omitted.
+
+ When querying channels the <entity's name> must include the
+ channel's name. The <info> may be omitted.
+
+ If the <count> option were defined in the query there will be only
+ <count> 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) <nickname>
+
+ Set/change nickname. This command is used to set nickname for
+ user. Nickname MUST NOT include any whitespaces (` '),
+ non-printable characters, commas (`,'), '@', '!' or any wildcard
+ characters.
+
+ 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_NOTIFY_TYPE_NICK_CHANGE notify to its primary route to
+ notify about nickname and Client ID change.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <New ID Payload>
+ (3) <nickname>
+
+ This command replies 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]. The <nickname> is the user's new
+ nickname.
+
+ 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) [<Channel ID>]
+
+ The list command is used to list channels and their topics on the
+ current server. If the <Channel ID> parameter is used, only the
+ status of that channel is displayed. Secret channels are not
+ listed at all. Private channels are listed with status indicating
+ that the channel is private. Router MAY reply with all channels
+ it knows about.
+
+ Reply messages to the command:
+
+ Max Arguments: 5
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) <channel> (4) [<topic>]
+ (5) [<user count>]
+
+ This command may reply with several command reply messages to form
+ a list of results. In this case the status payload will include
+ 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 <topic> 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) <Channel ID> (2) [<topic>]
+
+ This command is used to change or view the topic of a channel.
+ The topic for channel <Channel ID> is returned if there is no
+ <topic> given. If the <topic> 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) <Status Payload> (2) <Channel ID>
+ (3) [<topic>]
+
+ 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) <Channel ID> (2) [<Client ID>]
+ (3) [<add | del>] (4) [<invite list>]
+
+ This command can be used to invite other clients to join to a
+ channel, and to manage the channel's invite list. The <Client
+ ID> argument is the target client's ID that is being invited.
+ The <Channel ID> is the Channel ID of the requested channel.
+ The sender of this command MUST be on the channel. The server
+ MUST also send the notify type SILC_NOTIFY_TYPE_INVITE to its
+ primary router and then to the client indicated by the <Client
+ ID>.
+
+ The <add | del> is an argument of size of 1 byte where 0x00 means
+ adding a client to invite list, and 0x01 means deleting a client
+ from invite list. The <invite list>, if present, indicates
+ the information to be added to or removed from the invite list.
+ It may include a string for matching clients, public key of a
+ client (Public Key Payload) or Client ID of a client. The
+ <invite list> is an Argument List Payload.
+
+ The following Argument Types has been defined for invite list
+ Argument Payloads:
+
+ 0x01 - Argument is an invite string of following format:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname or IP/MASK>]
+
+ The <hostname> may also be in format of IP/MASK to indicate
+ a network, for example 10.2.1.0/255.255.0.0.
+
+ 0x02 - Argument is the public key of a client
+ 0x03 - Argument is the Client ID of a client
+
+ If unknown type value is received or there is invalid amount of
+ Argument Payloads present in the list, the command MUST be
+ discarded. When argument that is to be deleted from the invite
+ list does not exist in the list the argument is ignored.
+
+ When adding to or removing from the invite list the server MUST
+ send the notify type SILC_NOTIFY_TYPE_INVITE to its primary router.
+ 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. When this
+ command is used to invite explicit client with <Client ID> the
+ ID MUST be added to the invite list by the server.
+
+ When this command is given with only <Channel ID> argument then
+ the command merely returns the invite list of the channel. This
+ command MUST fail if the requested channel does not exist, the
+ requested <Client ID> is already on the channel or if the channel
+ is invite only channel and the caller of this command does not
+ have at least channel operator privileges on the channel.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<invite list>]
+
+ This command replies with the invite list of the channel if it
+ exists.
+
+ 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
+ SILC_STATUS_ERR_RESOURCE_LIMIT
+
+
+ 8 SILC_COMMAND_QUIT
+
+ Max Arguments: 1
+ Arguments: (1) [<quit message>]
+
+ This command is used by client to end SILC session. The server
+ must close the connection to a client which sends this command.
+ if <quit message> 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: 3
+ Arguments: (1) <Client ID> (2) [<comment>]
+ (3) [<auth payload>]
+
+ This command can be used by SILC operators to remove a client from
+ SILC network. It also can be used by a normal client to remove
+ its own client from network by providing correct authentication
+ data.
+
+ Router operator killing a client:
+
+ The removing has temporary effects and client may reconnect to
+ SILC network. The <Client ID> is the client to be removed from SILC.
+ The <comment> argument may be provided to give to the removed client
+ some information why it was removed from the network. The killer
+ MUST have SILC operator privileges.
+
+ 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
+ destined directly to the client which was killed. The killed
+ client MUST also be removed from the invite lists of joined
+ channels if it is explicitly added in the invite lists.
+
+ Normal client killing by authentication:
+
+ When normal client executes this command the <Client ID> is the
+ destination client to be removed from the network. The client
+ MUST provide the <auth payload> which includes a digital signature
+ that MUST be verified with the public key of the client indicated
+ by <Client ID>. The <Client ID> MUST be local client to the server.
+ If the signature verification is successful the server sends
+ SILC_NOTIFY_TYPE_SIGNOFF to network and to the destination client.
+ The SILC_NOTIFY_TYPE_KILLED MUST NOT be used in this case. If the
+ verification fails the destination client remains in network.
+ The hash function used in <auth payload> computing is SHA1.
+
+ Reply messages to the command:
+
+ Max Arguments: 2
+ Arguments: (1) <Status Payload> (2) <Client ID>
+
+ This command returns with the requested Client ID.
+
+ 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) [<server>] (2) [<Server ID>]
+
+ This command is used to fetch various information about a server.
+ If <server> argument is specified the command MUST be sent to
+ the requested server.
+
+ If the <Server ID> is specified the server information if fetched
+ by the provided Server ID. One of the arguments MUST always be
+ present.
+
+ Reply messages to the command:
+
+ Max Arguments: 4
+ Arguments: (1) <Status Payload> (2) <Server ID>
+ (3) <server name> (4) <string>
+
+ This command replies with the Server ID of the server and a
+ string which tells the information about the server.
+
+ 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_STATS
+
+ Max Arguments: 1
+ Arguments: (1) <Server ID>
+
+ This command is used to fetch various statistical information
+ from the server indicated by <Server ID>, which is the ID of
+ server where sender is connected to. Server receiving this
+ command MAY also send this further to its router for fetching
+ other cell and network wide statistics to accompany the reply.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Server ID>
+ (3) [<statistics structure>]
+
+ This command replies with the Server ID of the server and
+ optional statistics structure which includes 32 bit MSB first
+ ordered integer values to represent various statistical
+ information. The structure is as follows:
+
+ starttime - time when server was started
+ uptime - uptime of the server
+ my clients - number of locally connected clients
+ my channels - number of locally created channels
+ my server ops - number of local server operators
+ my router ops - number of local router operators
+ cell clients - number of clients in local cell
+ cell channels - number of channels in local cell
+ cell servers - number of servers in local cell
+ clients - number of client in SILC network
+ channels - number of channels in SILC network
+ servers - number of servers in SILC network
+ routers - number of routers in SILC network
+ server ops - number of server operators in SILC network
+ router ops - number of router operators in SILC network
+
+ If some value is unknown it is set to zero (0) value. The
+ "starttime" is the start time of the server, and is seconds
+ since Epoch (POSIX.1). The "uptime" is time difference of
+ current time and "starttime" in the server, and is seconds
+ in value.
+
+ 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_SERVER_ID
+ SILC_STATUS_ERR_NO_SUCH_SERVER
+ SILC_STATUS_ERR_NO_SERVER_ID
+
+
+ 12 SILC_COMMAND_PING
+
+ Max Arguments: 1
+ Arguments: (1) <Server ID>
+
+ 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 <Server ID> is the ID of the server the
+ sender is connected to.
+
+ Reply messages to the command:
+
+ Max Arguments: 1
+ Arguments: (1) <Status Payload>
+
+ 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) <username> (2) <authentication payload>
+
+ This command is used by normal client to obtain server operator
+ privileges on some server or router. Note that router operator
+ 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 <username> is the username set in the server configurations
+ as operator. The <authentication payload> is the data that the
+ client is authenticated against. It may be passphrase prompted
+ for user on client's screen or it may be public key authentication
+ based on digital signatures. The public key used to verify the
+ signature should be locally saved in the server, and server should
+ not use public key received during the SKE to verify this signature.
+
+ 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) <Status Payload>
+
+ 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: 7
+ Arguments: (1) <channel> (2) <Client ID>
+ (3) [<passphrase>] (4) [<cipher>]
+ (5) [<hmac>] (6) [<founder auth>]
+ (7) [<channel auth>]
+
+ 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 <channel> MUST NOT include any spaces (` '),
+ non-printable characters, commas (`,') or any wildcard characters.
+
+ The second argument <Client ID> is the Client ID of the client
+ which is joining to the client. When client sends this command
+ to the server the <Client ID> MUST be the client's own ID.
+
+ Cipher to be used to secure the traffic on the channel MAY be
+ requested by sending the name of the requested <cipher>. This
+ is used only if the channel does not exist and is created. If
+ the channel already exists the cipher set previously for the
+ channel will be used to secure the traffic. The computed MACs
+ of the channel message are produced by the default HMAC or by
+ the <hmac> provided for the command.
+
+ The <founder auth> is Authentication Payload providing the
+ authentication for gaining founder privileges on the channel
+ when joining the channel. The client may provide this if it
+ knows that it is the founder of the channel and that the
+ SILC_CMODE_FOUNDER_AUTH mode is set on the channel. The server
+ MUST verify whether the client is able to gain the founder
+ privileges the same way as the client had given the
+ SILC_COMMAND_CUMODE command to gain founder privileges. The
+ client is still able to join the channel even if the founder
+ privileges could not be gained. The hash function used with
+ the <founder payload> MUST be sha1.
+
+ If the <channel auth> is present and the channel mode
+ SILC_CMODE_CHANNEL_AUTH is set the server MUST verify the
+ <channel auth> with channel public key(s). If public key that
+ can verify <channel auth> does not exist on the channel public
+ key list the client MUST NOT be allowed to join the channel.
+ Because more than one public key may be set on channel the
+ <channel auth> Authentication Payload's Public Data field
+ MUST include an indication of the public key to be used. The
+ first 20 bytes of the Public Data field MUST be SHA-1 digest of
+ the public key that must be used in verification. Rest of the
+ Public Data field are set as defined in [SILC1]. This way server
+ can determine from the digest whether that public key exist on the
+ channel and then use that key in verification. The hash function
+ used with <channel auth> MUST be sha1.
+
+ 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/public key
+ MUST NOT match any active bans.
+
+ o The correct passphrase MUST be provided if passphrase
+ is set to the channel, and/or digital signature verification
+ with channel public key MUST be successful if public keys
+ has been set to the channel.
+
+ o The user count limit, if set, MUST NOT be reached.
+
+ If the client provided correct <founder auth> payload it can
+ override these conditions, except the condition for the passphrase.
+ The correct passphrase MUST be provided even if <founder auth>
+ payload is provided.
+
+ Reply messages to the command:
+
+ Max Arguments: 16
+ Arguments: (1) <Status Payload> (2) <channel>
+ (3) <Channel ID> (4) <Client ID>
+ (5) <channel mode mask> (6) <created>
+ (7) [<Channel Key Payload>] (8) [<ban list>]
+ (9) [<invite list>] (10) [<topic>]
+ (11) [<hmac>] (12) <list count>
+ (13) <Client ID list> (14) <client mode list>
+ (15) [<founder pubkey>] (16) [<channel pubkeys>]
+
+ 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 <Client ID> is the Client ID which was joined
+ to the channel. It also replies with the channel mode mask
+ which tells all the modes set on the channel. If the channel
+ is created the mode mask is zero (0) and <created> is 0x01.
+ If ban mask and/or invite list is set they are sent as well.
+
+ The <list count>, <Client ID list> and <client mode list> are
+ the clients currently on the channel and their modes on the
+ channel. The <Client ID list> is formed by adding the ID Payloads
+ one after the other. The <client mode list> is formed by adding
+ 32 bit MSB first order values one after the other. The <founder
+ pubkey> is the public key (or certificate) of the channel founder.
+ The <channel pubkeys> is Argument List Payload containing the
+ channel public keys that has been set for the channel.
+
+ Client receives the channel key in the reply message as well
+ inside <Channel Key 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_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) <server>
+
+ This command is used to query the Message of the Day of the server.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Server ID>
+ (3) [<motd>]
+
+ 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) <Client ID> (2) [<client mode mask>]
+
+ 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:
+
+ 0x00000000 SILC_UMODE_NONE
+
+ No specific mode for client. This is the initial
+ setting when new client is created. The client is
+ normal client and is present in the network.
+
+
+ 0x00000001 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.
+
+
+ 0x00000002 SILC_UMODE_ROUTER_OPERATOR
+
+ Marks the user as router (SILC) operator. Client
+ MUST NOT set 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.
+
+
+ 0x00000004 SILC_UMODE_GONE
+
+ Marks that the user is not currently present in the
+ SILC Network. Client MAY set and unset this mode.
+
+
+ 0x00000008 SILC_UMODE_INDISPOSED
+
+ Marks that the user is currently indisposed and may
+ not be able to receive any messages, and that user may
+ not be present in the network. Client MAY set and
+ unset this mode.
+
+
+ 0x00000010 SILC_UMODE_BUSY
+
+ Marks that the user is currently busy and may not
+ want to receive any messages, and that user may not
+ be present in the network. Client MAY set and unset
+ this mode.
+
+
+ 0x00000020 SILC_UMODE_PAGE
+
+ User is not currently present or is unable to receive
+ messages, and prefers to be paged in some mechanism
+ if the user needs to be reached. Client MAY set and
+ unset this mode.
+
+
+ 0x00000040 SILC_UMODE_HYPER
+
+ Marks that the user is hyper active and is eager to
+ receive and send messages. Client MAY set and unset
+ this mode.
+
+
+ 0x00000080 SILC_UMODE_ROBOT
+
+ Marks that the client is actually a robot program.
+ Client MAY set and unset this mode.
+
+
+ 0x00000100 SILC_UMODE_ANONYMOUS
+
+ Marks that the client is anonymous client. Server
+ that specifically is designed for anonymous services
+ can set and unset this mode. Client MUST NOT set or
+ unset this mode itself. A client with this mode set
+ would have the username and the hostname information
+ scrambled by the server which set this mode.
+
+
+ 0x00000200 SILC_UMODE_BLOCK_PRIVMSG
+
+ Marks that the client wishes to block private
+ messages sent to the client, unless the Private
+ Message Key flag is set in the SILC packet header.
+ If this mode is set server MUST NOT deliver private
+ messages to the client without the Private Message
+ Key flag being set. The Private Message Key flag set
+ indicates that the private message is protected with
+ a key shared between the sender and the recipient.
+
+ A separate service could provide additional filtering
+ features for accepting private messages from certain
+ sender. However, this document does not specify such
+ service.
+
+ The client MAY set and unset this mode.
+
+
+ 0x00000400 SILC_UMODE_DETACHED
+
+ Marks that the client is detached from the SILC network.
+ This means that the actual network connection to the
+ client is lost but the client entry is still valid. The
+ detached client can be resumed at a later time. This
+ mode MUST NOT be set by client. It can only be set when
+ client has issued command SILC_COMMAND_DETACH. The server
+ sets this mode. This mode cannot be unset with this
+ command. It is unset when the client is resuming back to
+ the network and SILC_PACKET_RESUME_CLIENT packet is
+ received.
+
+ This flag MUST NOT be used to determine whether a packet
+ can be sent to the client or not. Only the server that
+ had the original client connection can make the decision
+ by knowing that the network connection is not active.
+ In this case the default case is to discard the packet.
+
+
+ 0x00000800 SILC_UMODE_REJECT_WATCHING
+
+ Marks that the client rejects that it could be watched
+ by someone else. If this mode is set notifications about
+ this client is not send, even if someone is watching the
+ same nickname this client has. Client MAY set and unset
+ this mode. Any changes for this client MUST NOT be
+ notified to any watcher when this mode is set.
+
+ A separate service could provide additional filtering
+ features for rejecting and accepting the watching from
+ certain users. However, this document does not specify
+ such service.
+
+
+ 0x00001000 SILC_UMODE_BLOCK_INVITE
+
+ Marks that the client wishes to block incoming invite
+ notifications. Client MAY set and unset this mode.
+ When set server does not deliver invite notifications
+ to the client. Note that this mode may make it harder
+ to join invite-only channels.
+
+ If the <client mode mask> was not provided this command merely
+ returns the mode mask to the client.
+
+
+ Reply messages to the command:
+
+ Max Arguments: 2
+ Arguments: (1) <Status Payload> (2) <client mode mask>
+
+ 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: 9
+ Arguments: (1) <Channel ID> (2) [<channel mode mask>]
+ (3) [<user limit>] (4) [<passphrase>]
+ (5) [<cipher>] (6) [<hmac>]
+ (7) [<auth payload>] (8) [<founder pubkey>]
+ (9) [<channel pubkey>]
+
+ 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 <Channel ID> is the ID of the
+ target channel. The client changing channel mode MUST be on
+ the same channel and posses 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:
+
+ 0x00000000 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.
+
+
+ 0x00000001 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.
+
+
+ 0x00000002 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.
+
+
+ 0x00000004 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 SHOULD 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.
+
+
+ 0x00000008 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.
+
+
+ 0x00000010 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.
+
+
+ 0x00000020 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 <user limit> argument is the
+ number of limited users.
+
+
+ 0x00000040 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 <passphrase> argument is the
+ set passphrase.
+
+
+ 0x00000080 SILC_CMODE_CIPHER
+
+ Sets specific cipher to be used to protect channel
+ traffic. The <cipher> argument is the requested cipher.
+ When set or unset the server must re-generate new
+ channel key. Only channel founder MAY set the cipher of
+ the channel. When unset the new key is generated using
+ default cipher for the channel.
+
+
+ 0x00000100 SILC_CMODE_HMAC
+
+ Sets specific hmac to be used to compute the MACs of the
+ channel message. The <hmac> argument is the requested hmac.
+ Only channel founder may set the hmac of the channel.
+
+
+ 0x00000200 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 <auth payload> is the Authentication Payload
+ consisting of the public key authentication method and the
+ digital signature for that method. The passphrase or NONE
+ authentication methods MUST NOT be accepted.
+
+ The server does not save <auth payload> but MUST verify it.
+ The public key used to verify the payload is the <founder
+ pubkey> if present, or the public key of the client sending
+ this command. If <founder pubkey> is present also that
+ public key MUST be saved as founder's public key. This
+ mode may be set only if the <auth payload> was verified
+ successfully. The hash function used with the <auth
+ payload> MUST be sha1.
+
+ The public key of the founder is sent in the
+ SILC_NOTIFY_TYPE_CMODE_CHANGE notify type so that other
+ routers and servers in the network may save the public key.
+ This way the founder can reclaim the founder rights back
+ to the channel from any server in the network. The founder
+ rights can be regained by the SILC_CUMODE_FOUNDER channel
+ user mode, or during joining procedure with the command
+ SILC_COMMAND_JOIN.
+
+ If this mode is already set but the <founder pubkey> is
+ different the new key will replace the old founder key and
+ the new key is distributed in the network with the
+ SILC_NOTIFY_TYPE_CMODE_CHANGE notify. Only the original
+ founder may set this mode multiple times and the client
+ MUST have SILC_CUMODE_FOUNDER mode on the channel.
+
+ When this channel mode is set the channel also becomes
+ permanent. If all clients leave the channel while this
+ mode is set the channel MUST NOT be destroyed. The founder
+ can reclaim the founder mode back on these empty channels
+ at any time. Implementations MAY limit the number of how
+ many channels a user can own and how long they remain
+ persistent.
+
+
+ 0x00000400 SILC_CMODE_SILENCE_USERS
+
+ Channel founder may set this mode to silence normal users
+ on the channel. Users with operator privileges are not
+ affected by this mode. Messages sent by normal users
+ are dropped by servers when this mode is set. This mode
+ can be used to moderate the channel. Only channel founder
+ may set/unset this mode.
+
+
+ 0x00000800 SILC_CMODE_SILENCE_OPERS
+
+ Channel founder may set this mode to silence operators
+ on the channel. When used with SILC_CMODE_SILENCE_USERS
+ mode this can be used to set the channel in state where only
+ the founder of the channel may send messages to the channel.
+ Messages sent by operators are dropped by servers when this
+ mode is set. Only channel founder may set/unset this mode.
+
+
+ 0x00001000 SILC_CMODE_CHANNEL_AUTH
+
+ When this mode is set the channel has one or more public keys
+ or certificates set, and ability to join the channel requires
+ a client to provide digital signature that can be successfully
+ verified with one of the channel public keys. This mode is
+ equivalent to the SILC_MODE_PASSPHRASE except that digital
+ signatures are used to gain access to the channel. Both
+ modes MAY be set at the same time. Channel founder may set
+ and unset this mode.
+
+ The <channel pubkey> argument is an Argument List Payload
+ where each argument is Public Key Payload including public
+ key to be added or removed from the channel public key list.
+ To add a public key to channel this mode is set and the
+ argument type is 0x00, and the argument is the public key.
+ To remove a public key from channel public key list the
+ argument type is 0x01, and the argument is the public key
+ to be removed from the list. To remove all public keys at
+ once this mode is unset. An implementation MAY limit the
+ number of public keys that can be set for the channel.
+ This mode MUST NOT be set if <channel pubkey> is not present
+ when the mode is set for the first time. Implementation MAY
+ add and remove multiple public keys at the same time by
+ including multiple arguments to the <channel pubkey>
+ Argument List Payload.
+
+
+ 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. If the <channel mode mask> was
+ not provided this command returns the mode mask, founder key
+ and channel public key list to the client.
+
+ Reply messages to the command:
+
+ Max Arguments: 5
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) <channel mode mask> (4) [<founder pubkey>]
+ (5) [<channel pubkeys>]
+
+ This command replies with the changed channel mode mask that
+ client MUST keep locally. It may also return the channel
+ founder's public key if it is set. It may also return list of
+ channel public keys when the list was altered. The <channel
+ pubkeys> is Argument List Payload and each argument includes
+ one public key.
+
+ 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_NO_CHANNEL_FOPRIV
+ 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) <Channel ID> (2) <mode mask>
+ (3) <Client ID> (4) [<auth payload>]
+
+ This command is used by client to change channel user modes on
+ channel. Users on channel may have some special modes and this
+ command is used by channel operators to set or change these modes.
+ The <Channel ID> is the ID of the target channel. The <mode mask>
+ is OR'ed mask of modes. The <Client ID> is the target client.
+ The client changing channel user modes MUST be on the same channel
+ as the target client and posses 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:
+
+ 0x00000000 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.
+
+
+ 0x00000001 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 <auth payload> that the server will use
+ to authenticate the client. The public key that server will
+ use to verify the <auth payload> MUST be 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.
+
+
+ 0x00000002 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. The client MAY remove this mode
+ at any time.
+
+
+ 0x00000004 SILC_CUMODE_BLOCK_MESSAGES
+
+ Marks that the client wishes not to receive any channel
+ messages sent for the channel. Client MAY set and unset
+ this mode to itself. Client MUST NOT set it to anyone else.
+ When this mode is set server MUST NOT deliver channel
+ messages to this client. Other packets such as channel
+ key packets are still sent to the client.
+
+ A separate service could provide additional filtering
+ features for accepting channel messages from certain
+ sender. However, this document does not specify such
+ service.
+
+
+ 0x00000008 SILC_CUMODE_BLOCK_MESSAGES_USERS
+
+ Marks that the client wishes not to receive any channel
+ messages sent from normal users. Only messages sent by
+ channel founder or channel operator is accepted. Client
+ MAY set and unset this mode to itself. Client MUST NOT
+ set it to anyone else. When this mode is set server MUST
+ NOT deliver channel messages that are sent by normal users
+ to this client.
+
+ A separate service could provide additional filtering
+ features for accepting channel messages from certain
+ sender. However, this document does not specify such
+ service.
+
+
+ 0x00000010 SILC_CUMODE_BLOCK_MESSAGES_ROBOTS
+
+ Marks that the client wishes not to receive any channel
+ messages sent from robots. Messages sent by users with
+ the SILC_UMODE_ROBOT user mode set are not delivered.
+ Client MAY set and unset this mode to itself. Client MUST
+ NOT set it to anyone else. When this mode is set server
+ MUST NOT deliver channel messages that are sent by robots
+ to this client.
+
+
+ 0x00000020 SILC_CUMODE_QUIET
+
+ Marks that the client cannot talk on the channel. This
+ mode can be set by channel operator or channel founder to
+ some other user that is not operator or founder. The
+ target client MUST NOT unset this mode. When this mode
+ is set the server MUST drop messages sent by this client
+ to the channel.
+
+
+ Reply messages to the command:
+
+ Max Arguments: 4
+ Arguments: (1) <Status Payload> (2) <channel user mode mask>
+ (3) <Channel ID> (4) <Client ID>
+
+ This command replies with the changed channel user mode mask that
+ client MUST keep locally. The <Channel ID> is the specified
+ channel. The <Client ID> is the target client.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_BAD_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+ 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) <Channel ID> (2) <Client ID>
+ (3) [<comment>]
+
+ This command is used by channel operators to remove a client from
+ channel. The <channel> argument is the channel the client to be
+ removed is on currently. Note that the "kicker" must be on the same
+ channel. If <comment> is provided it will be sent to the removed
+ client.
+
+ After kicking the client the server MUST send the notify type
+ SILC_NOTIFY_TYPE_KICKED to the channel and to its primary router.
+ The client is removed from the channel after sending this notify.
+ The kicked client MUST be removed from the invite list of the
+ channel if it is explicitly added in the list. 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: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) <Client ID>
+
+ This command returns the Channel ID and Client ID that was kicked
+ from the channel.
+
+ 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) <Channel ID> (2) [<add | del>]
+ (3) [<ban list>]
+
+ This command is used to manage the ban list of the channel
+ indicated by the <Channel ID>. A client that is banned from
+ channel is no longer able to join the channel. The client which
+ is executing this command MUST have at least channel operator
+ privileges on the channel.
+
+ The <add | del> is an argument of size of 1 byte where 0x00 means
+ adding a client to ban list, and 0x01 means deleting a client
+ from ban list. The <ban list>, if present, indicates the
+ information to be added to or removed from the ban list. It
+ may include a string for matching clients, public key of a
+ client (Public Key Payload) or Client ID of a client. The
+ <ban list> is an Argument List Payload.
+
+ The following Argument Types has been defined for ban list
+ Argument Payloads:
+
+ 0x01 - Argument is an ban string of following format:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname or IP/MASK>]
+
+ The <hostname> may also be in format of IP/MASK to indicate
+ a network.
+
+ 0x02 - Argument is the public key of a client
+ 0x03 - Argument is the Client ID of a client
+
+ If unknown type value is received or there is invalid amount of
+ Argument Payloads present in the list, the command MUST be
+ discarded. When argument that is to be deleted from the ban
+ list does not exist in the list the argument is ignored.
+
+ 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 this command
+ is executed without the ban arguments the command merely replies
+ with the current ban list.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<ban list>]
+
+ This command replies with the <Channel ID> of the channel and
+ the current <ban list> of the channel if it exists.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ SILC_STATUS_ERR_RESOURCE_LIMIT
+
+
+
+
+ 21 SILC_COMMAND_DETACH
+
+ Max Arguments: 0
+ Arguments:
+
+ This command is used to detach from the network. Client can
+ send this command to its server to indicate that it will be
+ detached. By detaching the client remains in the network but
+ the actual network connection to the server is closed. The
+ client may then later resume the old session back.
+
+ When this command is received the server MUST check that the
+ client is locally connected client, and set the user mode
+ SILC_UMODE_DETACHED flag. The SILC_NOTIFY_TYPE_UMODE_CHANGE
+ MUST be also sent to routers. The server then sends command
+ reply to this command and closes the network connection.
+ The server MUST NOT remove the client from its lists, or send
+ any signoff notifications for this client. See the [SILC1]
+ for detailed information about detaching.
+
+ Reply messages to the command:
+
+ Max Arguments: 1
+ Arguments: (1) <Status Payload>
+
+ This command replies only with the status indication.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_REGISTERED
+
+
+
+ 22 SILC_COMMAND_WATCH
+
+ Max Arguments: 3
+ Arguments: (1) <Client ID> (2) [<add nickname>]
+ (3) [<del nickname>]
+
+ This command is used to set up a watch for <add nickname>
+ nickname. When a user in the network appears with the
+ nickname, or signoffs the network or user's mode is changed
+ the client which set up the watch will be notified about
+ this change. This can be used to watch for certain nicknames
+ in the network and receive notifications when for example a
+ friend appears in the network or leaves the network.
+
+ The <del nickname> is a nickname that has been previously
+ added to watch list and is now removed from it. Notifications
+ for that nickname will not be delivered anymore.
+
+ The <Client ID> is the Client ID of the sender of this command.
+
+ The nickname set to watch MUST NOT include any wildcards.
+ Note also that a nickname may match several users since
+ nicknames are not unique. Implementations MAY set limits
+ for how many nicknames client can watch.
+
+ When normal server receives this command from client it
+ MUST send it to its router. Router will process the command
+ and actually keeps the watch list.
+
+ Reply messages to the command:
+
+ Max Arguments: 1
+ Arguments: (1) <Status Payload>
+
+ This command replies only with the status indication.
+
+ 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_BAD_NICKNAME
+ SILC_STATUS_ERR_WILDCARDS
+ SILC_STATUS_ERR_RESOURCE_LIMIT
+ SILC_STATUS_ERR_NO_SUCH_NICK
+ SILC_STATUS_ERR_NICKNAME_IN_USE
+
+
+ 23 SILC_COMMAND_SILCOPER
+
+ Max Arguments: 2
+ Arguments: (1) <username> (2) <authentication payload>
+
+ 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 <username> is the username set in the server configurations
+ as operator. The <authentication payload> is the data that the
+ client is authenticated against. It may be passphrase prompted
+ for user on client's screen or it may be public key 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) <Status Payload>
+
+ 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) <Channel ID>
+
+ 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: 2
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+
+ The <Channel ID> is the ID of left channel.
+
+ 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) [<Channel ID>] (2) [<channel name>]
+
+ This command is used to list user names currently on the requested
+ channel; either the argument <Channel ID> or the <channel name>.
+ One of these arguments must be present. The server MUST resolve
+ the joined clients and reply with a lists of users on the channel
+ and with list of user modes on the channel.
+
+ If the requested channel is a private or secret channel, this
+ command MUST NOT send the list of users, except if the sender is
+ on the channel, or the sender is a server. Otherwise, error is
+ returned to the sender.
+
+ Reply messages to the command:
+
+ Max Arguments: 5
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) <list count> (4) <Client ID list>
+ (5) <client mode list>
+
+ This command replies with the Channel ID of the requested channel
+ Client ID list of the users on the channel and list of their modes.
+ The Client ID list has Client ID's of all users in the list. The
+ <Client ID list> is formed by adding Client ID's one after another.
+ The <client mode list> is formed by adding client's user modes on
+ the channel one after another (4 bytes (32 bits) each). The <list
+ count> of length of 4 bytes (32 bits), tells the number of entries
+ in the lists. Both lists MUST have equal number of entries.
+
+ Status messages:
+
+ SILC_STATUS_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) <ID Payload>
+
+ This command is used to fetch the public key of the client or
+ server indicated by the <ID Payload>. The public key is fetched
+ from the server where to the client is connected.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <ID Payload>
+ (3) [<Public Key Payload>]
+
+ This command replies with the client's or server's ID and with
+ the <Public Key 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_CLIENT_ID
+ SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+
+
+ 27 SILC_COMMAND_SERVICE
+
+ Max Arguments: 256
+ Arguments: (1) [<service name>] (2) [<auth payload>]
+ (n) [...]
+
+ This command is used to negotiate a service agreement with a
+ remote server. If this command is given without arguments it
+ MAY return the service list, if it is publicly available. The
+ <service name> is a service specific identifier, and the
+ <auth payload> MAY be used to authenticate the requester to the
+ remote service. The authentication to a service may be based
+ on previous agreement with the requester and the service
+ provider. The command MAY also take additional service
+ specific arguments.
+
+ This document does not specify any services. How the services
+ are configured and put available in a server is also out of
+ scope of this document.
+
+ This command MAY be used by client to start using some service
+ in a server, but it also MAY be used by server to negotiate
+ to start using a service in some other server or router.
+
+ After the negotiation is done both of the parties need to know
+ from the service identifier how the service can be used. The
+ service can be considered to be a protocol which both of the
+ parties need to support.
+
+ Reply messages to the command:
+
+ Max Arguments: 256
+ Arguments: (1) <Status Payload> (2) [<service list>]
+ (3) [<service name>] (n) [...]
+
+
+ This command MAY reply with the <service list> when command is
+ given without arguments, and the list is a comma separated list
+ of service identifiers. The <service name> is the service that
+ the sender requested and this is provided when the server has
+ accepted the sender to use the <service name>. The command
+ reply MAY also have additional service specific arguments.
+
+ 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_SERVICE
+ SILC_STATUS_ERR_AUTH_FAILED
+ SILC_STATUS_ERR_PERM_DENIED
+
+
+
+ 28 - 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.4 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 in length. The following
+diagram represents the Command Status Payload (fields are always in
+MSB first order).
+
+
+.in 21
+.nf
+ 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Status | Error |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 6: SILC Command Status Payload
+
+
+.in 6
+o Status (1 byte) - Indicates the status message type,
+ error, start of list, entry of list or end of list.
+
+o Error (1 byte) - Indicates the error if the Status
+ field is some list status, which means there are list
+ of errors.
+.in 3
+
+The values in Status and Error fields are set according
+the following rules:
+
+.in 6
+o If there is single reply and error has not occurred
+ then Status field includes value SILC_STATUS_OK, and
+ the Error field MUST be ignored (and set to zero
+ value).
+
+o If there is single error, then Status field includes
+ one of the error values, and the Error field MUST be
+ ignored (and set to zero value).
+
+o If there will be multiple successful command replies
+ then Status field includes SILC_STATUS_LIST_START,
+ SILC_STATUS_LIST_ITEM or SILC_STATUS_LIST_END value,
+ and Error field is set to SILC_STATUS_OK.
+
+o If there are multiple error replies then Status field
+ includes SILC_STATUS_LIST_START, SILC_STATUS_LIST_ITEM
+ or SILC_STATUS_LIST_END value, and the Error field
+ includes the error value.
+.in 3
+
+This way it is possible to send single successful or
+single error reply, but also multiple successful and
+multiple error replies. Note that it is possible to
+send both list of successful replies and list of error
+replies at the same time, however in this case the
+list of error replies MUST be sent after the successful
+replies. This way the recipient may ignore the multiple
+errors if it wishes to do so. Also note that in this
+case the successful and error replies belong to the
+same list.
+
+All Status messages are described in the next section.
+
+
+.ti 0
+3 SILC Status Types
+
+Status messages are returned in SILC protocol in command reply
+packet and in notify packet. The SILC_PACKET_COMMAND_REPLY is
+the command reply packet and status types are sent inside the
+Status Payload as one of command reply argument, as defined in
+previous sections. For SILC_PACKET_NOTIFY packet they can be sent
+as defined in [SILC2] for SILC_NOTIFY_TYPE_ERROR type. The same
+types defined in this section are used in both cases.
+
+When returning status messages in the command reply message they
+indicate whether the command was executed without errors. If error
+occurred the status indicates which error occurred. If error
+occurred the arguments to the command replies are dictated by the
+error type. If arguments are to be sent, they are defined below
+with the error status types.
+
+When sending status messages in SILC_NOTIFY_TYPE_ERROR notify type
+they always send some error status. Usually they are sent to
+indicate that error occurred while processing some SILC packet.
+Please see the [SILC1] and [SILC2] for more information sending
+status types in SILC_NOTIFY_TYPE_ERROR notify.
+
+The Status Types are only numeric values and the receiver must
+convert the numeric values into human readable messages if this
+is desired in the application.
+
+List of all defined status types:
+
+.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.
+ The next argument MUST be the requested nickname.
+
+ 11 SILC_STATUS_ERR_NO_SUCH_CHANNEL
+
+ "No such channel". Requested channel name does not exist.
+ The next argument MUST be the requested channel name.
+
+ 12 SILC_STATUS_ERR_NO_SUCH_SERVER
+
+ "No such server". Requested server name does not exist.
+ The next argument MUST be the requested server name.
+
+ 13 SILC_STATUS_ERR_INCOMPLETE_INFORMATION
+
+ "Incomplete registration information". Information remote
+ sent was incomplete.
+
+ 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.
+ The next argument MUST be the provided ID.
+
+ 21 SILC_STATUS_ERR_BAD_CHANNEL_ID
+
+ "Bad Channel ID". Channel ID provided were erroneous.
+ The next argument MUST be the provided ID.
+
+ 22 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+
+ "No such Client ID". Client ID provided does not exist.
+ The unknown Client ID MUST be provided as next argument
+ in the reply.
+
+ 23 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+
+ "No such Channel ID". Channel ID provided does not exist.
+ The unknown Channel ID MUST be provided as next argument
+ in the reply.
+
+ 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. The next argument MUST be the
+ Channel ID.
+
+ 26 SILC_STATUS_ERR_USER_NOT_ON_CHANNEL
+
+ "They are not on channel". The requested target client is not
+ on requested channel. The next two arguments, in this order,
+ MUST be the requested Client ID and Channel ID.
+
+ 27 SILC_STATUS_ERR_USER_ON_CHANNEL
+
+ "User already on channel". User were invited on channel they
+ already are on. The next two arguments, in this order, MUST be
+ the requested Client ID and Channel ID.
+
+ 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. The next argument MUST be
+ the Channel ID.
+
+ 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. The next
+ argument MUST be the Channel ID.
+
+ 36 SILC_STATUS_ERR_BANNED_FROM_CHANNEL
+
+ "Cannot join channel. You have been banned". The client has
+ been banned from the channel. The next argument MUST be the
+ Channel ID.
+
+ 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. The next argument MUST be
+ the Channel ID.
+
+ 40 SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+
+ "Permission denied. You are not channel founder". Command may
+ be executed only by channel operator. The next argument MUST be
+ the Channel ID.
+
+ 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.
+ The unknown Server ID MUST be provided as next argument
+ in the reply.
+
+ 48 SILC_STATUS_ERR_RESOURCE_LIMIT
+
+ "No more resources available". This can mean that server cannot
+ or will not accept something due to resource limitations.
+
+ 49 SILC_STATUS_ERR_NO_SUCH_SERVICE
+
+ "Service does not exist". Requested service identifier is
+ unknown.
+
+ 50 SILC_STATUS_ERR_NOT_AUTHENTICATED
+
+ "You have not been authenticated". Remote connection is not
+ authenticated even though it is supposed to be.
+
+ 51 SILC_STATUS_ERR_BAD_SERVER_ID
+
+ "Server ID is not valid". Provided server ID is not valid.
+ The next argument MUST be the provided ID.
+
+ 52 SILC_STATUS_ERR_KEY_EXCHANGE_FAILED
+
+ "Key exchange failed". Key Exchange protocol failed.
+
+ 53 SILC_STATUS_ERR_BAD_VERSION
+
+ "Bad version". Protocol or software version mismatch.
+
+ 54 SILC_STATUS_ERR_TIMEDOUT
+
+ "Operation timed out". Operation or service request timed
+ out, and thus was not processed.
+
+ 55 SILC_STATUS_ERR_UNSUPPORTED_PUBLIC_KEY
+
+ "Unsupported public key type". The public key or certificate
+ type is not supported in this implementation.
+
+ 56 SILC_STATUS_ERR_OPERATION_ALLOWED
+
+ "Operation is not allowed". A operation, for example a command,
+ is not allowed or it's execution is not allowed.
+
+.in 3
+
+
+
+.ti 0
+4 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
+5 References
+
+[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
+ Protocol Specification", Internet Draft, May 2002.
+
+[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ May 2002.
+
+[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
+ Protocols", Internet Draft, May 2002.
+
+[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.
+
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+[ATTRS] Riikonen, P., "User Online Presence and Information
+ Attributes", Internet Draft, May 2002.
+
+
+.ti 0
+6 Author's Address
+
+.nf
+Pekka Riikonen
+Snellmaninkatu 34 A 15
+70100 Kuopio
+Finland
+
+EMail: priikone@iki.fi
+
+
+.ti 0
+Appendix A
+
+This appendix defines the usage of the <Requested Attributes> argument in
+the SILC_COMMAND_WHOIS command. The attributes are defined in [ATTRS],
+and may be used to request additional information about the user. Since
+the information that may be requested using the attributes is something
+that server cannot deliver to the sender, it is possible to send the WHOIS
+command directly to the destination client whom will then provide the
+requested attributes. This requires the servers to relay the WHOIS
+command to the client, and it requires capability for handling the WHOIS
+command in the client end.
+
+The <Requested Attributes> MAY include several attributes that are
+requested. The format and encoding of the <Requested Attributes> is as
+defined in [ATTRS]. When <Requested Attributes> argument is set the
+server MAY process the attributes to see whether it can narrow down
+the WHOIS search, for example when searching with a nickname. The
+normal servers MUST process the WHOIS command as normal WHOIS command,
+that is to send the command directly to the router. The router MAY
+process the attributes, but it MUST send the command to the server
+that owns the requested client.
+
+The server that owns the client and receives the command MUST check
+whether the client is detached from the network. If it is detached,
+that is the user mode has the SILC_UMODE_DETACHED mode set, it SHOULD
+process the attributes and provide as many of the requested attributes
+as possible and then send reply back to the sender. If the client is
+active in the network it MUST send the command to the client for
+processing.
+
+The client receiving WHOIS command SHOULD check whether the
+<Requested Attributes> argument is set. If it is not set then the
+WHOIS command SHOULD be discarded. The client processes the requested
+attributes and SHOULD reply to each of the requested attribute with
+either valid value, or with an indication that the requested attribute
+is not known or supported. This is to be done as defined in [ATTRS].
+The client always MUST send a reply to the command when some attributes
+were requested. The client MAY also add additional attributes to the
+reply even if they were not requested. The client MAY also digitally
+sign the attributes with ATTRIBUTE_USER_DIGITAL_SIGNATURE as defined
+in [ATTRS]. Then the client sends the reply back to the sender of
+the command. The command reply that client assembles does not need
+to include any other argument but the <Status Payload> (1), and the
+<Attributes> (11). The server receiving reply from client MUST allow
+this sort of command reply for WHOIS command.
+
+The information received from the client MAY be cached in the
+server's end. The caching may be desired for example if the client
+can be detached from the network. This way the server is then able
+to provide at least partial information for a requester. The
+server MAY also process the command reply and verify whether the
+attributes provided in the reply are actually valid. If it can do
+this, and verify that they indeed are valid values it MAY append
+a digital signature at the end of the attributes with the
+ATTRIBUTE_SERVER_DIGITAL_SIGNATURE as defined in [ATTRS]. The
+server then MUST provide valid WHOIS command reply to the sender
+of the command. Other servers and routers that receive the command
+reply en route to the original sender MAY also cache the information.
+
+The client which receives the command reply to the WHOIS command
+SHOULD verify the ATTRIBUTE_USER_DIGITAL_SIGNATURE and the
+ATTRIBUTE_SERVER_DIGITAL_SIGNATURE if they are provided.
+
+
+.ti 0
+Full Copyright Statement
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--- /dev/null
+.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 11 August 2003
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-pp-08.txt 11 August 2003
+Expires: 11 February 2004
+
+.in 3
+
+.ce 2
+SILC Packet Protocol
+<draft-riikonen-silc-pp-08.txt>
+
+.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 [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 ................................ 15
+ 2.3.2 Generic payloads .................................... 15
+ 2.3.2.1 ID Payload .................................. 15
+ 2.3.2.2 Argument Payload ............................ 16
+ 2.3.2.3 Argument List Payload ....................... 17
+ 2.3.2.4 Channel Payload ............................. 18
+ 2.3.2.5 Public Key Payload .......................... 19
+ 2.3.2.6 Message Payload ............................. 19
+ 2.3.3 Disconnect Payload .................................. 23
+ 2.3.4 Success Payload ..................................... 23
+ 2.3.5 Failure Payload ..................................... 24
+ 2.3.6 Reject Payload ...................................... 24
+ 2.3.7 Notify Payload ...................................... 25
+ 2.3.8 Error Payload ....................................... 34
+ 2.3.9 Channel Message Payload ............................. 34
+ 2.3.10 Channel Key Payload ................................ 35
+ 2.3.11 Private Message Payload ............................ 37
+ 2.3.12 Private Message Key Payload ........................ 37
+ 2.3.13 Command Payload .................................... 39
+ 2.3.14 Command Reply Payload .............................. 40
+ 2.3.15 Connection Auth Request Payload .................... 40
+ 2.3.16 New ID Payload ..................................... 41
+ 2.3.17 New Client Payload ................................. 42
+ 2.3.18 New Server Payload ................................. 43
+ 2.3.19 New Channel Payload ................................ 44
+ 2.3.20 Key Agreement Payload .............................. 45
+ 2.3.21 Resume Router Payload .............................. 46
+ 2.3.22 File Transfer Payload .............................. 46
+ 2.3.23 Resume Client Payload .............................. 48
+ 2.4 SILC ID Types ............................................. 49
+ 2.5 Packet Encryption And Decryption .......................... 49
+ 2.5.1 Normal Packet Encryption And Decryption ............. 50
+ 2.5.2 Channel Message Encryption And Decryption ........... 50
+ 2.5.3 Private Message Encryption And Decryption ........... 51
+ 2.6 Packet MAC Generation ..................................... 52
+ 2.7 Packet Padding Generation ................................. 52
+ 2.8 Packet Compression ........................................ 53
+ 2.9 Packet Sending ............................................ 53
+ 2.10 Packet Reception ......................................... 54
+ 2.11 Packet Routing ........................................... 54
+ 2.12 Packet Broadcasting ...................................... 55
+3 Security Considerations ....................................... 56
+4 References .................................................... 56
+5 Author's Address .............................................. 58
+6 Full Copyright Statement ...................................... 58
+
+.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: Argument List Payload
+Figure 6: Channel Payload
+Figure 7: Public Key Payload
+Figure 8: Message Payload
+Figure 9: Disconnect Payload
+Figure 10: Success Payload
+Figure 11: Failure Payload
+Figure 12: Reject Payload
+Figure 13: Notify Payload
+Figure 14: Error Payload
+Figure 15: Channel Key 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: Resume Router Payload
+Figure 23: File Transfer Payload
+Figure 24: Resume Client 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 [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 packet protocol is designed to be compact to avoid unnecessary
+overhead as much as possible. This makes the SILC suitable also in
+environment of low bandwidth requirements such as mobile networks. All
+packet payloads can also be compressed to further reduce the size of
+the packets.
+
+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 and the 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. 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 128 bytes. The padding is always
+encrypted. The padding is applied always, even if the packet is
+not encrypted. See the section 2.7 Padding Generation for more
+detailed information.
+
+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. See the section 2.6 Packet MAC Generation
+for more information. If compression is used the compression 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.
+
+.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 |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Pad Length | RESERVED | Source ID Len | Dest ID Len |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| 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) - Indicates the length of the
+ packet not including the padding of the packet.
+
+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 data MUST include private
+ message that is encrypted using private key set by
+ client. Servers does not know this key and cannot
+ handle the packet, but passes it 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 and normal
+ server cannot send broadcast packets. 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.
+
+
+ Compressed 0x08
+
+ Marks that the payload of the packet is compressed.
+ The sender of the packet marks this flag when it
+ compresses the payload, and any server or router
+ en route to the recipient MUST NOT unset this flag.
+ See section 2.8 Packet Compression for description of
+ packet compressing.
+
+.in 3
+
+o Packet Type (1 byte) - Indicates 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 Pad Length (1 byte) - Indicates the length of the padding
+ applied after the SILC Packet header. Maximum length for
+ padding is 128 bytes.
+
+o RESERVED (1 byte) - Reserved field and must include a
+ zero (0) value.
+
+o Source ID Length (1 byte) - Indicates the length of the
+ Source ID field in the header, not including this or any
+ other fields.
+
+o Destination ID Length (1 byte) - 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 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 the following packet types.
+
+The below list of the SILC Packet types includes reference to the packet
+payload as well. Packet payloads are the actual packet data area. 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 a
+router to send SILC_PACKET_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 does not have
+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. The following packet
+desription list will define it separately if a packet is allowed to be
+sent to indirectly connected entity. Other packets MUST NOT be sent or
+accepted, if sent, to indirectly connected entities.
+
+Some packets MAY be sent as lists by adding the List flag to the Packet
+Header and constructing multiple packet payloads one after the other.
+When this is allowed it is separately defined in the following list.
+Other packets MUST NOT be sent as list and the List flag MUST NOT be set.
+
+
+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.
+
+ Payload of the packet: See section 2.3.3 Disconnect Payload
+
+
+ 2 SILC_PACKET_SUCCESS
+
+ This packet is sent upon successful execution of a protocol.
+ The status of the success is sent in the packet payload.
+
+ Payload of the packet: See section 2.3.4 Success Payload
+
+
+ 3 SILC_PACKET_FAILURE
+
+ This packet is sent upon failure of a protocol. The status
+ of the failure is sent in the packet payload.
+
+ Payload of the packet: See section 2.3.5 Failure Payload
+
+
+ 4 SILC_PACKET_REJECT
+
+ This packet MAY be sent upon rejection of a protocol. The
+ status of the rejection is sent in the packet payload.
+
+ Payload of the packet: See section 2.3.6 Reject Payload
+
+
+ 5 SILC_PACKET_NOTIFY
+
+ This packet is used to send notify message. The packet is
+ usually sent between server and client, but also between
+ server and router. Client MUST NOT send this packet. Server
+ MAY destine this packet to channel as well when the packet is
+ distributed to all clients on the channel. This packet MAY
+ be sent as list.
+
+ 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.
+
+ 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. This packet MAY be sent to entity
+ that is indirectly connected to the sender.
+
+ 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 when server generates it. Each channel has their own
+ independent keys that is used to protect the traffic on the
+ channel. It is also possible to use channel private keys that
+ are not server generated. In this case this packet is not used.
+ 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.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. See [SILC1] for private message key generation.
+ This packet MAY be sent to entity that is indirectly connected
+ to the sender.
+
+ Payload of the packet: See section 2.3.11 Private Message
+ Payload
+
+
+ 10 SILC_PACKET_PRIVATE_MESSAGE_KEY
+
+ This packet can be used to agree about a key to be used to
+ protect private messages between two clients. This packet
+ is sent inside the SILC network and protected with session
+ keys. There are other means of agreeing to use private message
+ keys as well, than sending this packet which may not be
+ desirable on all situations. See the [SILC1] for private
+ message key generation. This packet MAY be sent to entity
+ that is indirectly connected to the sender.
+
+ 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.
+
+ 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 MAY be sent as list.
+
+ 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].
+
+ 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.
+
+ 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.
+
+ 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 an 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 SHOULD respond with the same
+ packet including the mandatory authentication method.
+
+ 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].
+
+ 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 IDs from server to
+ router and from router to all other routers in SILC network.
+ This is used when for example new client is registered to
+ SILC network. The newly created IDs 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. This packet MAY be sent as list.
+
+ 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 to the server.
+
+ 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.
+
+ 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. This packet MAY be sent as list.
+
+ 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.
+
+
+ 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 does not have a
+ payload.
+
+
+ 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.
+
+
+ 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.
+
+ Payload of the packet: See section 2.3.20 Key Agreement Payload
+
+
+ 26 SILC_PACKET_RESUME_ROUTER
+
+ This packet is used during backup router protocol when the
+ original primary router of the cell comes back online and wishes
+ to resume the position as being the primary router of the cell.
+
+ Payload of the packet: See section 2.3.21 Resume Router Payload
+
+
+ 27 SILC_PACKET_FTP
+
+ This packet is used to perform an file transfer protocol in the
+ SILC session with some entity in the network. The packet is
+ multi purpose. The packet is used to tell other entity in the
+ network that the sender wishes to perform an file transfer
+ protocol. The packet is also used to actually tunnel the
+ file transfer protocol stream. The file transfer protocol
+ stream is always protected with the SILC binary packet protocol.
+
+ Payload of the packet: See section 2.3.22 File Transfer Payload
+
+
+ 28 SILC_PACKET_RESUME_CLIENT
+
+ This packet is used to resume a client back to the network
+ after it has been detached. A client is able to detach from
+ the network but the client is still valid client in the network.
+ The client may then later resume its session back by sending
+ this packet to a server. Routers also use this packet to notify
+ other routers in the network that the detached client has resumed.
+
+ Payload of the packet: See section 2.3.23 Resume Client Payload
+
+
+ 29 - 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. Most of the payloads may only be sent with specific
+packet type which is defined in the description of the payload.
+
+There are some other payloads in 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 payload.
+
+
+.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.
+
+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. The encoding
+ of the ID data is defined in section 2.4 SILC ID Types.
+.in 3
+
+
+.ti 0
+2.3.2.2 Argument Payload
+
+Argument Payload is used to set arguments for any packet payload that
+need and support arguments, such as commands. Number of arguments
+associated with a packet MUST be indicated by the packet payload which
+need 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.
+
+.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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Data Length | Argument Type | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Argument Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 4: Argument Payload
+
+
+.in 6
+o Data Length (2 bytes) - Length of the Argument Data field
+ not including the length of any other field in the payload.
+
+o Argument Type (1 byte) - Indicates the type of the argument.
+ Every argument can have a specific type that are defined
+ by the packet payload needing the argument. For example
+ every command specify a number for each argument that may be
+ 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) value.
+
+o Argument Data (variable length) - Argument data.
+.in 3
+
+
+.ti 0
+2.3.2.3 Argument List Payload
+
+Argument List Payload is a list of Argument Payloads appended one
+after the other. The number of arguments is indicated in the
+payload.
+
+The following diagram represents the Argument List 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Argument Nums | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Argument Payloads ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 5: Argument List Payload
+
+
+.in 6
+o Argument Nums (2 bytes) - Indicates the number of Argument
+ Payloads. If zero (0) value is found in this field no
+ arguments are present.
+
+o Argument Payloads (variable length) - The Argument Payloads
+ appended one after the other. The payloads can be decoded
+ since the length of the payload is indicated in each of
+ the Argument Payload.
+.in 3
+
+
+
+
+.ti 0
+2.3.2.4 Channel Payload
+
+Generic Channel Payload may be used to send information about a 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 6: 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 encoded 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 a 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.5 Public Key Payload
+
+Generic Public Key Payload may be used to send different type 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 (or certificate) ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 7: 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
+ encoded public key or certificate data.
+.in 3
+
+
+.ti 0
+2.3.2.6 Message Payload
+
+Generic Message Payload can be used to send messages in SILC. It
+is used to send channel messages and private messages.
+
+The following diagram represents the 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Message Flags | Message Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Message Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Padding Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Padding ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Initial Vector * ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ MAC * ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 8: Message Payload
+
+
+.in 6
+o Message Flags (2 bytes) - Includes the Message Flags of the
+ message. The flags can indicate a reason or a purpose for
+ the message. The following Message 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
+ for this flag.
+
+ 0x0040 SILC_MESSAGE_FLAG_REPLY
+
+ This is a generic reply flag to send a reply to
+ previously received request. A separate document
+ should define any payloads associated to this flag.
+
+ 0x0080 SILC_MESSAGE_FLAG_DATA
+
+ This is a generic data flag, indicating that the
+ message includes some data which can be interpreted
+ in a specific way. Using this flag any kind of data
+ can be delivered inside message payload. A separate
+ document should define how this flag is interpreted
+ and define any associated payloads.
+
+ 0x0100 SILC_MESSAGE_FLAG_UTF8
+
+ This flag indicates that the message is UTF-8 encoded
+ textual message. When sending text messages in SILC
+ this flag SHOULD be used. When this flag is used the
+ text sent as message MUST be UTF-8 encoded.
+
+ 0x0200 - 0x0800 RESERVED
+
+ Reserved for future flags.
+
+ 0x1000 - 0x8000 PRIVATE RANGE
+
+ Private range for free use.
+
+o Message Length (2 bytes) - Indicates the length of the
+ Message Data field in the payload, not including any
+ other field.
+
+o Message Data (variable length) - The actual message data.
+
+o Padding Length (2 bytes) - Indicates the length of the
+ Padding field in the payload, not including any other
+ field.
+
+o Padding (variable length) - If this payload is used as
+ channel messages, the padding MUST be applied because
+ this payload is encrypted separately from other parts
+ of the packet. If this payload is used as private
+ messages, the padding is present only when the payload
+ is encrypted with private message key. If encrypted
+ with session keys this field MUST NOT be present and the
+ Padding Length field includes a zero (0) value. The
+ padding SHOULD be random data.
+
+o Initial Vector (variable length) - This field MUST be
+ present when this payload is used as channel messages.
+ The IV SHOULD be random data for each channel message.
+
+ When encrypting private messages with session keys this
+ field MUST NOT be present. For private messages this
+ field is present only when encrypting with a static
+ private message key (pre-shared key). If randomly
+ generated key material is used this field MUST NOT be
+ present. Also, If Key Agreement (SKE) was used to
+ negotiate fresh key material for private message key
+ this field MUST NOT be present. See the section 4.6
+ in [SILC1] for more information about IVs when
+ encrypting private messages.
+
+ This field includes the initial vector used in message
+ encryption. It need to be used in the packet decryption
+ as well. Contents of this field depends on the encryption
+ algorithm and encryption mode. This field is not encrypted,
+ is not included in padding calculation and its length
+ equals to cipher's block size. This field is authenticated
+ by the message MAC.
+
+o MAC (variable length) - The MAC computed from the
+ Message Flags, Message Length, Message Data, Padding Length,
+ Padding and Initial Vector fields in that order. The MAC
+ is computed after the payload is encrypted. This is so
+ called Encrypt-Then-MAC order; first encrypt, then compute
+ MAC from ciphertext. The MAC protects the integrity of
+ the Message Payload. Also, when used as channel messages
+ it is possible to have multiple private channel keys set,
+ and receiver can use the MAC to verify which of the keys
+ must be used in decryption. This field is not present
+ when encrypting private messages with session key. This
+ field is not encrypted. This field is authenticated by
+ the SILC packet MAC.
+.in 3
+
+
+.ti 0
+2.3.3 Disconnect Payload
+
+Disconnect payload is sent upon disconnection. Reason of the
+disconnection is sent to the disconnected party in the payload.
+
+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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Status | |
++-+-+-+-+-+-+-+-+ +
+| |
+~ Disconnect Message ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 9: Disconnect Payload
+
+.in 6
+o Status (1 byte) - Indicates the Status Type, defined in [SILC3]
+ for the reason of disconnection.
+
+o Disconnect Message (variable length) - Human readable UTF-8
+ encoded string indicating reason of the disconnection. This
+ field MAY be omitted.
+.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, and
+it is protocol dependent.
+
+.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 10: 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 11: 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 and is protocol dependent.
+
+
+.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 12: 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 and from server to router. It is also used
+by routers to notify other routers in the network. This payload MAY also
+be sent to a channel. Client MUST NOT send this payload. When this
+packet is received by client it SHOULD process it. Servers and routers
+MUST process notify packets.
+
+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 13: 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 (1 byte) - Indicates the number of Argument
+ Payloads associated to this payload. Notify types may define
+ arguments to be sent 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].
+Note that all IDs sent in arguments are sent inside ID Payload. Also
+note that all passphrases that may be sent inside arguments MUST be
+UTF-8 [RFC2279] encoded. Also note that all public keys or certificates
+sent inside arguments are actually Public Key Payloads.
+
+
+.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) <message>
+
+ The <message> is implementation specific free UTF-8 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) <Channel ID> (2) <channel name>
+ (3) [<sender Client ID>] (4) [<add | del>]
+ (5) [<invite list>]
+
+ The <Channel ID> is the channel. The <channel name> 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 <Channel ID>. The <sender Client ID> is the
+ Client ID which invited the client to the channel. The
+ <add | del> is an argument of size of 1 byte where 0x00 means
+ adding a client to invite list, and 0x01 means deleting a client
+ from invite list. The <invite list>, if present, indicates the
+ information to be added to or removed from the invite list.
+ The <invite list> format is defined in [SILC4] with
+ SILC_COMMAND_INVITE command. When this notify is destined to
+ a client the <add | del> and <invite list> MUST NOT be sent.
+
+
+2 SILC_NOTIFY_TYPE_JOIN
+
+ Sent when client has joined to a channel. The server MUST
+ distribute this type to the local clients on the channel and then
+ send it to its primary router. Note that, when router is joining
+ the client on behalf of normal server then router MUST send this
+ notify type locally and globally. The router or server receiving
+ the packet distributes this type to the local clients on the
+ channel and broadcast it to the network. This notify is sent
+ also to the client that joined the channel.
+
+ Max Arguments: 2
+ Arguments: (1) [<Client ID>] (2) <Channel ID>
+
+ The <Client ID> is the client that joined to the channel
+ indicated by the <Channel ID>.
+
+
+3 SILC_NOTIFY_TYPE_LEAVE
+
+ Sent when client has left a channel. The server must distribute
+ this type 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. This notify MUST NOT be sent to
+ the leaving client.
+
+ Max Arguments: 1
+ Arguments: (1) <Client ID>
+
+ The <Client ID> 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 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. This notify
+ MUST NOT be sent to the quitting client.
+
+ Max Arguments: 2
+ Arguments: (1) <Client ID> (2) <message>
+
+ The <Client ID> is the client which left SILC network. The
+ <message> 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 may be
+ sent only to the clients which are joined on the channel which
+ topic was just set or changed. The packet is destined to the
+ channel.
+
+ Max Arguments: 2
+ Arguments: (1) <ID Payload> (2) <topic>
+
+ The <ID Payload> is the ID of the entity who set the topic.
+ It usually is Client ID but it can be Server ID and Channel ID
+ as well.
+
+
+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. This packet is
+ destined directly to the sent entity. This MUST be sent to those
+ clients that are joined on same channels as the client that
+ changed the nickname. This notify MUST NOT be sent multiple
+ times to the same recipient. This notify MUST be sent also to
+ the client that changed the nickname.
+
+ Max Arguments: 3
+ Arguments: (1) <Old Client ID> (2) <New Client ID>
+ (3) <nickname>
+
+ The <Old Client ID> is the old ID of the client which changed
+ the nickname. The <New Client ID> is the new ID generated by
+ the change of the nickname. The <nickname> is the new nickname.
+ Note that it is possible to send this notify even if the
+ nickname has not changed, but client ID was changed.
+
+
+7 SILC_NOTIFY_TYPE_CMODE_CHANGE
+
+ Sent when channel mode has changed. This type MUST be sent only
+ to the clients which are joined on the channel which mode was
+ changed. This packet is destined to the channel.
+
+ Max Arguments: 7
+ Arguments: (1) <ID Payload> (2) <mode mask>
+ (3) [<cipher>] (4) <[hmac>]
+ (5) [<passphrase>] (6) [<founder public key>]
+ (7) [<channel pubkey>]
+
+ The <ID Payload> 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 <mode mask>
+ is the new mode mask of the channel. The client can safely
+ ignore the <cipher> argument since the SILC_PACKET_CHANNEL_KEY
+ packet will force the new channel key change anyway. The <hmac>
+ argument is important since the client is responsible of setting
+ the new HMAC and the hmac key into use. The <passphrase> is
+ the passphrase of the channel, if it was now set. The <founder
+ public key> argument is sent when the founder mode on the
+ channel was set. All routers and servers that receive the packet
+ MUST save the founder's public key so that the founder can
+ reclaim the channel founder rights back for the channel on any
+ server in the network.
+
+ The <channel pubkey> is an Argument List Payload and it is used
+ to add and/or remove channel public keys from the channel. Also,
+ when announcing channel information between servers and routers
+ during connecting phase this argument includes the list of channel
+ public keys. To add a public key to channel public key list the
+ SILC_CMODE_CHANNEL_AUTH mode is set and the argument type is 0x00,
+ and the argument is the public key. To remove a public key from
+ the channel public key list the argument type is 0x01, and the
+ argument is the public key to be removed. If the mode
+ SILC_CMODE_CHANNEL_AUTH is unset (and was set earlier) all public
+ keys are removed at once. Implementation MAY add and remove
+ multiple public keys at the same time by including multiple
+ arguments to the <channel pubkey> Argument List Payload where each
+ argument is one Public Key Payload. When <channel pubkey> is used
+ to announce information during server connecting phase the
+ argument type MUST be 0x03. See section 4.2.1 in [SILC1] for
+ more information.
+
+
+8 SILC_NOTIFY_TYPE_CUMODE_CHANGE
+
+ Sent when user mode on channel has changed. This type MUST be
+ sent only to the clients which are joined on the channel where
+ the target client is on. This packet is destined to the channel.
+
+ Max Arguments: 4
+ Arguments: (1) <ID Payload> (2) <mode mask>
+ (3) <Target Client ID> (4) [<founder pubkey>]
+
+ The <ID Payload> 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 <mode mask>
+ is the new mode mask of the channel. The <Target Client ID>
+ is the client which mode was changed. The <founder pubkey>
+ is the public key of the channel founder and may be sent only
+ when first time setting the channel founder mode using the
+ SILC_COMMAND_CUMODE command, and when sending this notify.
+
+
+9 SILC_NOTIFY_TYPE_MOTD
+
+ Sent when Message of the Day (motd) is sent to a client.
+
+ Max Arguments: 1
+ Arguments: (1) <motd>
+
+ The <motd> is the Message of the Day. This notify MAY be
+ ignored.
+
+
+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 are
+ joined on the channel. This packet is destined to the sent
+ entity.
+
+ Max Arguments: 2
+ Arguments: (1) <Old Channel ID> (2) <New Channel ID>
+
+ The <Old Channel ID> is the channel's old ID and the <New
+ Channel ID> is the new one that MUST replace the old one.
+ Server which receives this from router MUST re-announce the
+ channel to the router by sending SILC_PACKET_NEW_CHANNEL packet
+ with the new Channel ID.
+
+
+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.
+ This packet is destined to the sent entity.
+
+ Max Arguments: 256
+ Arguments: (1) <Server ID> (n) [<Client ID>] [...]
+
+ The <Server ID> is the server's ID. The rest of the arguments
+ are the Client IDs of the clients 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. Server receiving the Client ID's in the payload
+ may use them directly to remove the client.
+
+
+12 SILC_NOTIFY_TYPE_KICKED
+
+ Sent when a client has been kicked from a channel. This MUST
+ also be sent to the client which was kicked from the channel.
+ The client which was kicked from the channel MUST be removed
+ from the channel. The client MUST also be removed from channel's
+ invite list if it is explicitly added in the list. This packet
+ is 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: 3
+ Arguments: (1) <Client ID> (2) [<comment>]
+ (3) <Kicker's Client ID>
+
+ The <Client ID> is the client which was kicked from the channel.
+ The kicker may have set the <comment> to indicate the reason for
+ the kicking. The <Kicker's Client ID> is the kicker.
+
+
+13 SILC_NOTIFY_TYPE_KILLED
+
+ Sent when a client has been killed from the network. This MUST
+ also be sent to the client which was killed from the network.
+ This notify MUST be sent to those clients which are joined on
+ same channels as the killed client. The client which was killed
+ MUST be removed from the network. This packet is destined
+ directly to the sent entity. The router or server receiving
+ the packet distributes this type to the local clients on the
+ channel and broadcast it to the network. The client MUST also
+ be removed from joined channels invite list if it is explicitly
+ added in the lists. This notify MUST NOT be sent multiple
+ times to same recipient.
+
+ Max Arguments: 3
+ Arguments: (1) <Client ID> (2) [<comment>]
+ (3) <Killer's ID>
+
+ The <Client ID> is the client which was killed from the network.
+ The killer may have set the <comment> to indicate the reason for
+ the killing. The <Killer's ID> is the killer, which may be
+ client but also router server.
+
+
+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) <Client ID> (2) <mode mask>
+
+ The <Client ID> is the client which mode was changed. The
+ <mode mask> 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) <Channel ID> (2) [<add | del>]
+ (3) [<ban list>]
+
+ The <Channel ID> is the channel which ban list was changed.
+ The <add | del> is an argument of size of 1 byte where 0x00 means
+ adding a client to ban list, and 0x01 means deleting a client
+ from ban list. The <ban list> indicates the information to be
+ added to or removed from the ban list. The <ban list> format
+ format is defined in [SILC4] with SILC_COMMAND_BAN command.
+
+
+16 SILC_NOTIFY_TYPE_ERROR
+
+ Sent when an error occurs during processing some SILC procedure.
+ This is not used when error occurs during command processing, see
+ [SILC4] for more information about commands and command replies.
+ This type is sent directly to the sender of the packet whose
+ packet caused the error. See [SILC1] for definition when this
+ type can be sent.
+
+ Max Arguments: 256
+ Arguments: (1) <Status Type> (n) [...]
+
+ The <Status Type> is the error type defined in [SILC4]. Note
+ that same types are also used with command replies to indicate
+ the status of a command. Both commands and this notify type
+ share same status types. Rest of the arguments are status type
+ dependent and are specified with those status types that can be
+ sent currently inside this notify type in [SILC4]. The <Status
+ Type> is size of 1 byte.
+
+
+17 SILC_NOTIFY_TYPE_WATCH
+
+ Sent to indicate change in a watched user. Client can set
+ nicknames to be watched with SILC_COMMAND_WATCH command, and
+ receive notifications when they login to network, signoff from
+ the network or their user mode is changed. This notify type
+ is used to deliver these notifications. The notify type is
+ sent directly to the watching client.
+
+ Max Arguments: 4
+ Arguments: (1) <Client ID> (2) [<nickname>]
+ (3) <user mode> (4) [<Notify Type>]
+
+ The <Client ID> is the user's Client ID which is being watched,
+ and the <nickname> is its nickname. If the client just
+ changed the nickname, then <nickname> is the new nickname, but
+ the <Client ID> is the old client ID. The <user mode> is the
+ user's current user mode. The <Notify Type> can be same as the
+ Notify Payload's Notify Type, and is 16 bit MSB first order
+ value. If provided it may indicate the notify that occurred
+ for the client. If client logged in to the network the
+ <Notify Type> MUST NOT be present.
+.in 3
+
+Notify types starting from 16384 are reserved for private notify
+message types.
+
+Router server which receives SILC_NOTIFY_TYPE_SIGNOFF,
+SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED,
+SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE
+MUST check whether someone in the local cell is watching the nickname
+the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the
+watcher, unless the watched client in case has the user mode
+SILC_UMODE_REJECT_WATCHING set. If the watcher client and the client
+that was watched is same the notify SHOULD NOT be sent.
+
+
+
+
+
+.ti 0
+2.3.8 Error Payload
+
+Error payload is sent upon error in protocol. 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 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 14: Error Payload
+
+
+.in 6
+o Error Message (variable length) - Human readable error
+ message as UTF-8 string.
+.in 3
+
+
+.ti 0
+2.3.9 Channel Message Payload
+
+Channel Message Payload is used to send message to channels, a group
+of users. These messages can only be sent if client has joined to
+some channel. Even though this packet is very 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 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.
+
+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 Destination ID MUST be Channel ID in the SILC
+Packet header.
+
+This packet use generic Message Payload as Channel Message Payload.
+See section 2.3.2.6 for generic Message Payload.
+
+
+.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 MUST start 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.
+
+Note that, this packet is not used if SILC_CMODE_PRIVKEY mode is set
+on channel. This means that channel uses channel private keys which
+are not server generated. For this reason server cannot send this
+packet as it does not know the key.
+
+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 15: 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.
+
+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. The messages are sent only to the specified user
+and no other user inside SILC network is able to see the message.
+
+The message can be 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. It is
+for example possible to perform Key Agreement between two clients.
+See section 2.3.20 Key Agreement Payload how to perform key
+agreement. See also section 2.3.12 Private Message Key Payload
+for another way of using private keys with private messages. See
+[SILC1] section 4.6 for detailed description for private message
+key generation procedure.
+
+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 the private message key is used, and the Private Message Key
+flag was set in the SILC Packet header no server or router en route
+is able to decrypt or re-encrypt the packet. In this case only the
+SILC Packet header is processed by the servers and routers en route.
+Section Client To Client in [SILC1] gives example of this scheme.
+
+This packet use generic Message Payload as Private Message Payload.
+See section 2.3.2.6 for generic Message Payload.
+
+
+.ti 0
+2.3.12 Private Message Key Payload
+
+This payload is OPTIONAL and can be used to send private message
+key between two clients in the network. The packet is secured with
+normal session keys. By default private messages are encrypted
+with session keys, and with this payload it is possible to set
+private key for private message encryption between two clients.
+
+The receiver of this payload SHOULD verify for example from user
+whether user want to receive private message key. Note that there
+are other, more secure ways of exchanging private message keys in
+the SILC network. Instead of sending this payload it is possible to
+negotiate the private message key with SKE protocol using the Key
+Agreement payload directly peer to peer, see section 2.3.20.
+
+This payload may only be sent by client to another client. Server
+MUST NOT send this payload. 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 ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| HMAC Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ HMAC 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.
+
+o HMAC Name Length (2 bytes) - Indicates the length of the
+ HMAC Name field in the payload, not including any other
+ field.
+
+o HMAC Name (variable length) - Name of the HMAC to use
+ in the private message MAC computation. If this field does
+ not exist then the default HMAC of the SILC protocol is used.
+ See the [SILC1] for defined HMACs.
+.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.
+.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 2.3.13 section for the 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 SHOULD 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 use 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.
+
+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. Client MUST NOT send this payload.
+Both client and server (and router) MAY receive this payload.
+
+The packet use 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 nickname sent in this payload.
+
+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 encoded Server ID
+ data.
+
+o Server Name Length (2 bytes) - Length of the server name
+ field.
+
+o Server Name (variable length) - The server name string.
+.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. Server MAY send this packet to a router when it is
+announcing its existing channels to the router after it has connected
+to the router.
+
+The packet use 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 clients agree
+about the key without any server interaction. The protocol is executed
+peer to peer. 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.
+
+This payload may be sent with SILC_PACKET_KEY_AGREEMENT and
+SILC_PACKET_FTP packet types. It MUST NOT be sent in any other packet
+types. 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] in section 4.6 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 Resume Router Payload
+
+See the [SILC1] for Resume Router protocol where this payload is
+used. The payload may only be sent with SILC_PACKET_RESUME_ROUTER
+packet. It MUST NOT be sent in any other packet type. The following
+diagram represents the Resume Router Payload.
+
+
+.in 21
+.nf
+ 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Type | Session ID |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 22: Resume Router Payload
+
+
+.in 6
+o Type (1 byte) - Indicates the type of the backup resume
+ protocol packet. The type values are defined in [SILC1].
+
+o Session ID (1 bytes) - Indicates the session ID for the
+ backup resume protocol. The sender of the packet sets this
+ value and the receiver MUST set the same value in subsequent
+ reply packet.
+.in 3
+
+
+.ti 0
+2.3.22 File Transfer Payload
+
+File Transfer Payload is used to perform file transfer protocol between
+two entities in the network. The actual file transfer protocol is always
+encapsulated inside the SILC Packet. The actual data stream is also sent
+peer to peer outside SILC network.
+
+When an entity, usually a client wishes to perform file transfer protocol
+with another client in the network, they perform Key Agreement protocol
+as described in the section 2.3.20 Key Agreement Payload and in [SILC3],
+inside File Transfer Payload. After the Key Agreement protocol has been
+performed the subsequent packets in the data stream will be protected
+using the new key material. The actual file transfer protocol is also
+initialized in this stage. All file transfer protocol packets are always
+encapsulated in the File Transfer Payload and protected with the
+negotiated key material.
+
+The payload may only be sent with SILC_PACKET_FTP packet. It MUST NOT
+be sent in any other packet type. The following diagram represents the
+File Transfer 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Type | |
++-+-+-+-+-+-+-+-+ +
+| |
+~ Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 23: File Transfer Payload
+
+
+.in 6
+o Type (1 byte) - Indicates the type of the file transfer
+ protocol. The following file transfer protocols has been
+ defined:
+
+ 1 Secure File Transfer Protocol (SFTP) (mandatory)
+
+ If zero (0) value or any unsupported file transfer protocol
+ type is found in this field the packet MUST be discarded.
+ The currently mandatory file transfer protocol is SFTP.
+ The SFTP protocol is defined in [SFTP].
+
+o Data (variable length) - Arbitrary file transfer data. The
+ contents and encoding of this field is dependent of the usage
+ of this payload and the type of the file transfer protocol.
+ When this payload is used to perform the Key Agreement
+ protocol, this field include the Key Agreement Payload,
+ as defined in the section 2.3.20 Key Agreement Payload.
+ When this payload is used to send the actual file transfer
+ protocol data, the encoding is defined in the corresponding
+ file transfer protocol.
+.in 3
+
+
+.ti 0
+2.3.23 Resume Client Payload
+
+This payload is used by client to resume its detached session in the
+SILC Network. A client is able to detach itself from the network by
+sending SILC_COMMAND_DETACH command to its server. The network
+connection to the client is lost but the client remains as valid
+client in the network. The client is able to resume the session back
+by sending this packet and including the old Client ID, and an
+Authentication Payload [SILC1] which the server use to verify with
+the detached client's public key. This also implies that the
+mandatory authentication method is public key authentication.
+
+Server or router that receives this from the client also sends this,
+without the Authentication Payload, to routers in the network so that
+they know the detached client has resumed. Refer to the [SILC1] for
+detailed description how the detaching and resuming procedure is
+performed.
+
+The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the Resume 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Client ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Client ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Authentication Payload ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 24: Resume Client Payload
+
+
+.in 6
+o Client ID Length (1 byte) - The length of the Client ID
+ field not including any other field.
+
+o Client ID (variable length) - The detached client's Client
+ ID. The client that sends this payload must know the Client
+ ID.
+
+o Authentication Payload (variable length) - The authentication
+ payload that the server will verify with the detached client's
+ public key. If the server doesn't know the public key, it must
+ retrieve it for example with SILC_COMMAND_GETKEY command.
+.in 3
+
+
+
+.ti 0
+2.4 SILC ID Types
+
+ID's are 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
+
+ This is used when other ID type is available at the time.
+
+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
+
+When encoding different IDs into the ID Payload, all fields are always
+in MSB first order. The IP address, port, and/or the random number
+are encoded in the MSB first order.
+
+
+.ti 0
+2.5 Packet Encryption And Decryption
+
+SILC packets are encrypted almost entirely. Only the MAC at the end
+of the packet is never encrypted. 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 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.
+At this point the receiver is also able to determine the length of the
+packet.
+
+With out a doubt, this sort of decryption processing causes some
+overhead to packet decryption, but never the less, is required.
+
+The MAC of the packet is also verified at this point. The MAC is
+computed from the ciphertext of the packet so it can be verified
+at this stage. The length of the packet need to be known to be able
+to verify the MAC from the ciphertext so the first 16 bytes need to
+be decrypted to determine the packet length. However, the MAC MUST
+be verified from the entire ciphertext.
+
+
+.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. 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 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 too. 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 before. This
+different processing of channel messages with router to router
+connection is because channel keys are cell specific. All cells have
+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 and is not re-encrypted.
+
+The true receiver of the private message 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, from packet sequence number, and from the encrypted packet
+data. The MAC is always computed after packet is encrypted. This is
+so called Encrypt-Then-MAC order; packet is first encrypted, then MAC
+is computed from the encrypted data.
+
+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.
+
+Hence, packet's MAC generation is as follows:
+
+ mac = MAC(key, sequence number | Encrypted SILC packet)
+
+The MAC key is negotiated during the SKE protocol. The sequence number
+is a 32 bit MSB first value starting from zero for first packet and
+increasing for subsequent packets, finally wrapping after 2^32 packets.
+The value is never reset, not even after rekey has been performed.
+However, rekey MUST be performed before the sequence number wraps
+and repeats from zero. Note that the sequence number is incremented only
+when MAC is computed for a packet. If packet is not encrypted and MAC is
+not computed then the sequence number is not incremented. Hence, the
+sequence number is zero for the very first encrypted packet.
+
+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
+always MUST 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
+may be calculated as follows:
+
+.in 6
+padding_length = 16 - (packet_length mod block_size)
+if (padding_length < 8)
+ padding_length += block_size
+.in 3
+
+The `block_size' is the block size of the cipher. The maximum padding
+length is 128 bytes, and minimum is 8 bytes. For example, packets that
+include a passphrase or a password for authentication purposes SHOULD
+pad the packet up to the maximum padding length. The maximum padding
+is calculated as follows:
+
+.in 6
+padding_length = 128 - (packet_length mod block_size)
+.in 3
+
+For special packets the padding calculation is 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.
+
+The padding MUST be random data, preferably, generated by
+cryptographically strong random number generator for each packet
+separately.
+
+
+.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 SHOULD 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 encrypt the packet as has been
+described in above sections according whether the packet is normal
+packet or special packet. Then sender MUST compute the MAC of the
+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).
+
+However, there are some issues when routing channel messages to group
+of users. Routers are responsible of routing the channel message to
+other routers, local servers and local clients as well. Routers MUST
+send the channel message to only one router in the network, preferably
+to the shortest route to reach the channel users. The message can be
+routed into either upstream or downstream. After the message is sent
+to a router in the network it MUST NOT be sent to any other router in
+either same route or other route. The message MUST NOT be routed to
+the router it came from.
+
+When routing for example private messages they should be routed to the
+shortest route always to reach the destination client as fast as possible.
+
+For server which receives a packet to be routed to an entity that is
+indirectly connected to the sender, the server MUST check whether that
+particular packet type is allowed to be routed to that destination. Not
+all packets may be sent by some odd entity to for example a local client,
+or to some remote server or router, 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. That section defines the
+packets that may be sent to indirectly connected entities. When a server
+or a router receives a packet that may be sent to indirectly connected
+entity and it is destined to other entity except that server, it MUST
+route it further either to shortest route or to the primary route to reach
+that destination.
+
+Routers form a ring in the SILC network. However, routers may have other
+direct connections to other routers in the network too. This can cause
+interesting routing problems in the network. Since the network is a ring,
+the packets usually should be routed into clock-wise direction, or if it
+cannot be used then always counter clock-wise (primary route) direction.
+Problems may arise when a faster direct route exists and router is routing
+a channel message. Currently channel messages must be routed either
+in upstream or downstream, they cannot be routed to other direct routes.
+The SILC protocol should have a shortest path discovery protocol, and some
+existing routing protocol, that can handle a ring network with other
+direct routes inside the ring (so called hybrid ring-mesh topology),
+MAY be defined to be used with the SILC protocol. Additional
+specifications MAY be written on the subject to permeate this
+specification.
+
+
+.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, May 2002.
+
+[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
+ Protocols", Internet Draft, May 2002.
+
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
+
+[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.
+
+[SFTP] Ylonen T., and Lehtinen S., "Secure Shell File Transfer
+ Protocol", Internet Draft, March 2001.
+
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+.ti 0
+5 Author's Address
+
+.nf
+Pekka Riikonen
+Snellmaninkatu 34 A 15
+70100 Kuopio
+Finland
+
+EMail: priikone@iki.fi
+
+
+.ti 0
+6 Full Copyright Statement
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--- /dev/null
+.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 11 August 2003
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-spec-08.txt 11 August 2003
+Expires: 11 February 2004
+
+.in 3
+
+.ce 3
+Secure Internet Live Conferencing (SILC),
+Protocol Specification
+<draft-riikonen-silc-spec-08.txt>
+
+.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 provides advanced and feature rich conferencing
+services with security as main design principal. Strong cryptographic
+methods are used to protect SILC packets inside the SILC network.
+Three other specifications 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 ............................... 6
+ 2.3 Communication in the Network .............................. 7
+ 2.4 Channel Communication ..................................... 7
+ 2.5 Router Connections ........................................ 8
+3 SILC Specification ............................................ 9
+ 3.1 Client .................................................... 9
+ 3.1.1 Client ID ........................................... 9
+ 3.2 Server .................................................... 10
+ 3.2.1 Server's Local ID List .............................. 11
+ 3.2.2 Server ID ........................................... 12
+ 3.2.3 SILC Server Ports ................................... 12
+ 3.3 Router .................................................... 13
+ 3.3.1 Router's Local ID List .............................. 13
+ 3.3.2 Router's Global ID List ............................. 14
+ 3.3.3 Router's Server ID .................................. 14
+ 3.4 Channels .................................................. 14
+ 3.4.1 Channel ID .......................................... 16
+ 3.5 Operators ................................................. 16
+ 3.6 SILC Commands ............................................. 17
+ 3.7 SILC Packets .............................................. 17
+ 3.8 Packet Encryption ......................................... 17
+ 3.8.1 Determination of the Source and the Destination ..... 18
+ 3.8.2 Client To Client .................................... 19
+ 3.8.3 Client To Channel ................................... 20
+ 3.8.4 Server To Server .................................... 21
+ 3.9 Key Exchange And Authentication ........................... 21
+ 3.9.1 Authentication Payload .............................. 21
+ 3.10 Algorithms ............................................... 23
+ 3.10.1 Ciphers ............................................ 23
+ 3.10.1.1 CBC Mode .................................. 24
+ 3.10.1.2 CTR Mode .................................. 24
+ 3.10.1.3 Randomized CBC Mode ....................... 26
+ 3.10.2 Public Key Algorithms .............................. 26
+ 3.10.2.1 Multi-Precision Integers .................. 27
+ 3.10.3 Hash Functions ..................................... 27
+ 3.10.4 MAC Algorithms ..................................... 27
+ 3.10.5 Compression Algorithms ............................. 28
+ 3.11 SILC Public Key .......................................... 29
+ 3.12 SILC Version Detection ................................... 31
+ 3.13 Backup Routers ........................................... 31
+ 3.13.1 Switching to Backup Router ......................... 33
+ 3.13.2 Resuming Primary Router ............................ 34
+4 SILC Procedures ............................................... 36
+ 4.1 Creating Client Connection ................................ 37
+ 4.2 Creating Server Connection ................................ 38
+ 4.2.1 Announcing Clients, Channels and Servers ............ 39
+ 4.3 Joining to a Channel ...................................... 40
+ 4.4 Channel Key Generation .................................... 41
+ 4.5 Private Message Sending and Reception ..................... 42
+ 4.6 Private Message Key Generation ............................ 42
+ 4.7 Channel Message Sending and Reception ..................... 43
+ 4.8 Session Key Regeneration .................................. 44
+ 4.9 Command Sending and Reception ............................. 44
+ 4.10 Closing Connection ....................................... 45
+ 4.11 Detaching and Resuming a Session ......................... 46
+5 Security Considerations ....................................... 47
+6 References .................................................... 48
+7 Author's Address .............................................. 50
+8 Full Copyright Statement ...................................... 50
+
+.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
+Figure 6: Counter Block
+
+
+.ti 0
+1. Introduction
+
+This document describes a Secure Internet Live Conferencing (SILC)
+protocol which provides secure conferencing services over insecure
+network channel. SILC can be used as a secure conferencing service
+that provides rich conferencing features. Some of the SILC features
+are found in traditional chat protocols such as IRC [IRC] but many
+of the SILC features can also be found in Instant Message (IM) style
+protocols. SILC combines features from both of these chat protocol
+styles, and can be implemented as either IRC-like system or IM-like
+system. Some of the more advanced and secure features of the
+protocol are new to all conferencing protocols. SILC also supports
+multimedia messages and can also be implemented as a video and audio
+conferencing system.
+
+Strong cryptographic methods are used to protect SILC packets inside
+the SILC network. Three other specifications 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 SILC Packet Protocol provides secured
+and authenticated packets, and the protocol is designed to be compact.
+This makes SILC also suitable in environment of low bandwidth
+requirements such as mobile networks. All packet payloads in SILC
+can be also compressed.
+
+The security of SILC protocol sessions are 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 forms a ring as opposed to tree style network topology that
+conferencing protocols usually have. The network has a cells which are
+constructed from a router and zero or more servers. The servers are
+connected to the router in a star like network topology. Routers in the
+network are connected to each other forming a ring. 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 router servers.
+
+A difference between normal server and router server is that routers
+knows all global information and keep the global network state up to date.
+They also do the actual routing of the messages to the correct receiver
+between other cells. Normal servers knows only local information and
+receive global information only when it is needed. They do not need to
+keep the global network state up to date. This makes the network faster
+and scalable as there are less servers that needs to maintain global
+network state.
+
+This, on the other hand, leads into a 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 able to act
+as 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. Other direct routes between
+other routers is also possible in addition of the mandatory ring
+connections. This leads into a hybrid ring-mesh network topology.
+
+There are many issues in this network topology that needs to be careful
+about. Issues like routing, 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 client that does not belong to local cell
+the message is routed to the router server to which the destination
+client 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 ring.
+
+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. This sort of ring network, with
+ability to have other direct routes in the network can cause interesting
+routing problems. The [SILC2] discusses the routing of packets in this
+sort of network in more detail.
+
+
+.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 user's IP address and nickname. User use logical nicknames
+in communication which are then mapped to the corresponding Client ID.
+Client IDs are low level identifications and should 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 typically causes the server names or client's
+host names to be used along with the nicknames on user interface 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. Also, any kind
+of nickname registering service becomes obsolete. The maximum length of
+nickname is 128 bytes.
+
+
+.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 IDs,
+and IDs based on IPv6 addresses extends this to 2^224 different Client
+IDs. 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 the client is 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 lowercase 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. Note that the nickname MUST be in
+ lowercase format.
+
+.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 serious 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.
+
+
+.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 IDs, 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 do not have to worry about global clients. Server is also responsible
+of creating the Client IDs for their clients.
+
+Normal server also keeps information about locally created channels and
+their Channel IDs.
+
+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 IDs 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 IDs also provide
+information for Client IDs, 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 and keeps the global state.
+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.
+
+
+.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 IDs 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. Router MAY also cache same detailed information for other clients
+if needed.
+
+
+.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 IDs, all created channels
+and their Channel IDs and all servers and routers on SILC and their
+Server IDs. 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 IDs on channel
+ o Client ID modes on channel
+.in 3
+
+
+
+.ti 0
+3.3.3 Router's Server ID
+
+Router's Server ID is equivalent to normal Server ID. As routers are
+normal servers same types of IDs applies for routers as well. 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 Channel ID of the channel. If the channel has
+a founder mode set and last client leaves the channel the channel does
+not cease to exist. The founder mode can be used to make permanent
+channels in the network. The founder of the channel can regain the
+channel founder privileges on the channel later when he joins 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 bytes. Channel names MUST NOT contain any
+whitespaces (` '), 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 to 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 or counter
+
+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 or counter
+
+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 or counter - To further randomize the Channel ID.
+ Another choice is to use a counter starting from zero (0).
+ This makes sure that there are no collisions. This also means
+ that in a cell there can be 2^16 different 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
+channels, to gain access to the contents of 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 any normal user 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. Usually server cannot send commands to
+clients, however there MAY be commands that allow the server to send
+commands to client. By default servers MAY send commands only to other
+servers and routers.
+
+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 misused 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 misuse 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. It is not possible to send a packet in SILC network without
+encryption. 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
+gives generic description of 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 have a channel 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 have 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 beforehand to be able to talk on the
+channel. In this case, no server or router knows the key for the 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 router. However, every packet passed
+from router to other router, including packets for channels, are
+encrypted with the shared session key. Every router connection MUST
+have 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 of whom is the 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 IDs attached to the header. The IDs 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 however, that some
+packets such as commands may be resent by a server to serve the client's
+original command. In this case the command packet sent by the server
+includes the server's IDs as it is a different packet. When server
+or router receives a packet it MUST verify that the Source ID is
+valid and correct ID for that sender.
+
+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 have established a 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 header
+ is encrypted with the session key shared between the client and
+ server, and the private message 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. Header is encrypted with the session key.
+
+o Router determines the destination of the packet and sends the
+ packet to the server. Header is encrypted with the session key.
+
+o Server determines the client to which the packet is destined
+ to and sends the packet to the client. Header is encrypted with
+ the session key.
+
+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 entire packet.
+The packet header however is always encrypted with session key and
+is decrypted and re-encrypted with the session key of next recipient.
+
+The process for clients on same server is much simpler as there is
+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.
+ Packet header is encrypted with the session key, message
+ data is encrypted with channel key.
+
+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 it.
+
+
+.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 another router connect
+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, clients MAY be accepted
+to connect to server without explicit authentication. Servers are
+REQUIRED to use authentication protocol when connecting. The
+authentication may be based on passphrase (pre-shared secret) or public
+key based on digital signatures. All passphrases sent in SILC protocol
+MUST be UTF-8 [RFC2279] encoded. 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 protocols. It can be used during the session to
+authenticate with a remote. For example, a client can authenticate
+itself to a 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 bytes) - 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 MAY include random data for padding purposes.
+ However, in this case the field MUST be ignored by the
+ receiver.
+
+ 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. If zero (0)
+ value is found in this field the payload MUST be
+ discarded.
+
+o Authentication Data (variable length) - Authentication
+ method dependent authentication data.
+.in 3
+
+
+If the authentication method is passphrase-based, the Authentication
+Data field includes the plaintext UTF-8 encoded passphrase. It is safe
+to send plaintext passphrase since the entire payload is encrypted. In
+this case the Public Data Length is set to zero (0), but MAY also include
+random data for padding purposes. It is also RECOMMENDED that maximum
+amount of padding is applied to SILC packet when using passphrase-based
+authentication. This way it is not possible to approximate the length
+of the passphrase from the encrypted packet.
+
+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, unless otherwise
+stated in the context where this payload is used. 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 encoding is described in [SILC2]. 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. Also in case of public key
+authentication this 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] for 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:
+
+aes-256-cbc AES in CBC mode, 256 bit key (REQUIRED)
+aes-256-ctr AES in CTR mode, 256 bit key (RECOMMENDED)
+aes-256-rcbc AES in randomized CBC mode, 256 bit key (OPTIONAL)
+aes-192-<mode> AES in <mode> mode, 192 bit key (OPTIONAL)
+aes-128-<mode> AES in <mode> mode, 128 bit key (RECOMMENDED)
+twofish-256-<mode> Twofish in <mode> mode, 256 bit key (OPTIONAL)
+twofish-192-<mode> Twofish in <mode> mode, 192 bit key (OPTIONAL)
+twofish-128-<mode> Twofish in <mode> mode, 128 bit key (OPTIONAL)
+cast-256-<mode> CAST-256 in <mode> mode, 256 bit key (OPTIONAL)
+cast-192-<mode> CAST-256 in <mode> mode, 192 bit key (OPTIONAL)
+cast-128-<mode> CAST-256 in <mode> mode, 128 bit key (OPTIONAL)
+serpent-<len>-<mode> Serpent in <mode> mode, <len> bit key (OPTIONAL)
+rc6-<len>-<mode> RC6 in <mode> mode, <len> bit key (OPTIONAL)
+mars-<len>-<mode> MARS in <mode> mode, <len> bit key (OPTIONAL)
+none No encryption (OPTIONAL)
+
+The <mode> is either "cbc", "ctr" or "rcbc". Other encryption modes MAY
+be defined to be used in SILC using the same name format. The <len> is
+either 256, 192 or 128 bit key length. Also, additional ciphers MAY be
+defined to be used in SILC by using the same name format as above.
+
+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 algorithm except in special
+debugging mode.
+
+
+.ti 0
+3.10.1.1 CBC Mode
+
+The "cbc" encryption mode is CBC mode with inter-packet chaining. This
+means that the Initialization Vector (IV) for the next encryption block
+is the previous ciphertext block. The very first IV MUST be random and
+is generated as described in [SILC3].
+
+
+.ti 0
+3.10.1.2 CTR Mode
+
+The "ctr" encryption mode is Counter Mode (CTR). The CTR mode in SILC is
+stateful in encryption and decryption. Both sender and receiver maintain
+the counter for the CTR mode and thus can precompute the key stream for
+encryption and decryption. By default, CTR mode does not require
+plaintext padding, however implementations MAY apply padding to the
+packets. If the last key block is larger than the last plaintext block
+the resulted value is truncated to the size of the plaintext block and
+the most significant bits are used. When sending authentication data
+inside packets the maximum amount of padding SHOULD be applied with
+CTR mode as well.
+
+In CTR mode only the encryption operation of the cipher is used. The
+decryption operation is not needed since both encryption and decryption
+process is simple XOR with the plaintext block and the key stream block.
+
+The counter block is used to create the key for the CTR mode. When
+SILC specifications refer to Initialization Vector (IV) in general cases,
+in case of CTR mode it refers to the counter block. The format of the
+128 bit counter block 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Truncated HASH from SKE |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Sending/Receiving IV from SKE |
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Block Counter |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 6: Counter Block
+
+.in 6
+o Truncated HASH from SKE (4 bytes) - This value is the first 4
+ bytes from the HASH value that was computed as a result of SKE
+ protocol. This acts as session identifier and each rekey MUST
+ produce a new HASH value.
+
+o Sending/Receiving IV from SKE (8 bytes) - This value is the
+ first 8 bytes from the Sending IV or Receiving IV generated in
+ the SKE protocol. When this mode is used to encrypt sending
+ traffic the Sending IV is used, when used to decrypt receiving
+ traffic the Receiving IV is used. This assures that two parties
+ of the protocol use different IV for sending traffic. Each rekey
+ MUST produce a new value.
+
+o Block Counter (4 bytes) - This is the counter value for the
+ counter block and is MSB ordered number starting from one (1)
+ value for first block and incrementing for subsequent blocks.
+ The same value MUST NOT be used twice. The rekey MUST be
+ performed before this counter value wraps.
+.in 3
+
+CTR mode MUST NOT be used with "none" MAC. Implementations also MUST
+assure that the same counter block is not used to encrypt more than
+one block. Also, the key material used with CTR mode MUST be fresh
+key material. Static keys (pre-shared keys) MUST NOT be used with
+CTR mode. For this reason using CTR mode to encrypt for example
+channel messages or private messages with a pre-shared key is
+inappropriate. For private messages, the Key Agreement could be
+performed to produce fresh key material.
+
+If the IV Included flag was negotiated in SKE, or CTR mode is used to
+protect channel messages where the counter block will be included in the
+Message Payload, implementations SHOULD still use the same counter block
+format as defined above. However, implementations are RECOMMENDED to
+replace the Truncated HASH field with a 32 bit random value for each IV
+(counter block) per encrypted SILC packet. Also note, that in this case
+the decryption process is not stateful and receiver cannot precompute the
+key stream.
+
+
+.ti 0
+3.10.1.3 Randomized CBC Mode
+
+The "rcbc" encryption mode is CBC mode with randomized IV. This means
+that each IV for each packet MUST be chosen randomly. When encrypting
+more than one block the normal inter-packet chaining is used, but for
+the first block new random IV is selected in each packet. In this mode
+the IV is appended at the end of the last ciphertext block and thus
+delivered to the recipient. This mode increases the ciphertext size by
+one ciphertext block. Note also that some data payloads in SILC are
+capable of delivering the IV to the recipient. When explicitly
+encrypting these payloads with randomized CBC the IV MUST NOT be appended
+at the end of the ciphertext, but is placed at the specified location
+in the payload. However, Message Payload for example has the IV at
+the location which is equivalent to placing it after the last ciphertext
+block. When using CBC mode with such payloads it is actually equivalent
+to using randomized CBC since the IV is selected in random and included
+in the ciphertext.
+
+
+.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.
+
+When signatures are computed in SILC the computing of the signature is
+represented as sign(). The signature computing procedure is dependent
+of the public key algorithm, and the public key or certificate encoding.
+When using SILC public key the signature is computed as described in
+previous paragraph for RSA and DSS keys. If the hash function is not
+specified separately for signing process SHA-1 MUST be used. When using
+SSH2 public keys the signature is computed as described in [SSH-TRANS].
+When using X.509 version 3 certificates the signature is computed as
+described in [PKCS7]. When using OpenPGP certificates the signature is
+computed as described in [PGP].
+
+
+.ti 0
+3.10.2.1 Multi-Precision Integers
+
+Multi-Precision (MP) integers in SILC are encoded and decoded as defined
+in PKCS #1 [PKCS1]. MP integers are unsigned, encoded with desired octet
+length. This means that if the octet length is more than the actual
+length of the integer one or more leading zero octets will appear at the
+start of the encoding. The actual length of the integer is the bit size
+of the integer not counting any leading zero bits.
+
+
+.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 (RECOMMENDED)
+.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 for a packet.
+
+The following MAC algorithms are defined in SILC protocol:
+
+.in 6
+hmac-sha1-96 HMAC-SHA1, length = 12 bytes (REQUIRED)
+hmac-md5-96 HMAC-MD5, length = 12 bytes (OPTIONAL)
+hmac-sha1 HMAC-SHA1, length = 20 bytes (OPTIONAL)
+hmac-md5 HMAC-MD5, length = 16 bytes (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]. The hash algorithms used
+in HMACs, the SHA-1 is described in [RFC3174] and MD5 is described
+in [RFC1321].
+
+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 SILC 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 escaped as `\\,',
+ for example, `O=Company XYZ\\, Inc.'. Other characters that
+ require escaping are listed in [RFC2253] and are to be escaped
+ as defined therein.
+
+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. All strings in the public key MUST be UTF-8 encoded.
+
+If an external protocol needs to refer to SILC Public Key by name, the
+names "silc-rsa" and "silc-dss" for SILC Public Key based on RSA algorithm
+and SILC Public Key based on DSS algorithm, respectively, are to be used.
+However, this SILC specification does not use these names directly, and
+they are defined here for external protocols (protocols that may like
+to use SILC Public Key).
+
+
+.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-<protocol version>-<software version>
+.in 3
+
+The version strings are of the following format:
+
+.in 6
+protocol version = <major>.<minor>
+software version = <major>[.<minor>[.<build or vendor string>]]
+.in 3
+
+Protocol version MUST provide both major and minor version. Currently
+implementations MUST set the protocol version and accept at least the
+protocol version as SILC-1.2-<software version>. If new protocol version
+causes incompatibilities with older version the <minor> version number
+MUST be incremented. The <major> is incremented if new protocol version
+is fully incompatible.
+
+Software version MAY provide major, minor and build (vendor) version.
+The software version MAY be freely set and accepted. The version string
+MUST consist of printable US-ASCII characters.
+
+Thus, the version strings could be, for example:
+
+.in 6
+SILC-1.1-2.0.2
+SILC-1.0-1.2
+SILC-1.2-1.0.VendorXYZ
+SILC-1.2-2.4.5 Vendor Limited
+.in 3
+
+
+.ti 0
+3.13 Backup Routers
+
+Backup routers may exist in the cell in addition to the primary router.
+However, they must not be active routers or 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 one of the backup routers becomes 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. When the backup router connects to the primary router
+of the cell it MUST present itself as router server in the Connection
+Authentication protocol, even though it is normal server as long as the
+primary router is available. Reason for this is that the configuration
+needed in the responder end requires usually router connection level
+configuration. The responder, however must understand and treat the
+connection as normal server (except when feeding router level data 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 an actual router server when it feeds the data
+to it.
+
+In addition to having direct connection to the primary router of the
+cell, the backup router must also have connection to the same router
+to which the primary router of the cell is connected. However, it must
+not be the 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 to as being a passive connection. Some keepalive actions may
+be needed by the router to keep the connection alive.
+
+It is required that other normal servers have 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.
+
+Also, if any other router in the network is using the cell's primary
+router as its own primary router, it must also have passive connection
+to the cell's backup router. It too is prepared to switch to use the
+backup router as its new primary router as soon as the original primary
+router becomes unresponsive.
+
+All of the parties of this protocol know which one is the backup router
+of the cell from their local configuration. Each of the entities must
+be configured accordingly and care must be taken when configuring the
+backup routers, servers and other routers in the network.
+
+It must be noted that some of the channel messages and private messages
+may be lost during the switch to the backup router. The announcements
+assure that the state of the network is not lost during the switch.
+
+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 local configuration
+phase. All the parties of this protocol must be configured accordingly to
+understand the order of the backup routers. It is not required that the
+backup server is actually an active server in the cell. The backup router
+may be a redundant server in the cell that does not accept normal client
+connections at all. It may be reserved purely for the backup purposes.
+
+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.13.1 Switching to Backup Router
+
+When the primary router of the cell becomes unresponsive, for example
+by sending EOF to the connection, all the parties of this protocol MUST
+replace the old connection to the primary router with first configured
+backup router. The backup router usually needs to do local modifications
+to its database in order to update all the information needed to maintain
+working routes. The backup router must understand that clients that
+were originated from the primary router are now originated from some of
+the existing server connections and must update them accordingly. It
+must also remove those clients that were owned by the primary router
+since those connections were lost when the primary router became
+unresponsive.
+
+All the other parties of the protocol must also update their local
+database to understand that the route to the primary router will now go
+to the backup router.
+
+Servers connected to the backup router MUST send SILC_PACKET_RESUME_ROUTER
+packet with type value 21, to indicate that the server will start using
+the backup router as primary router. The backup router MUST NOT allow
+this action if it detects that primary is still up and running. If
+backup router knows that primary is up and running it MUST send
+SILC_PACKET_FAILURE with type value 21 (4 bytes, MSB first order) back
+to the server. The server then MUST NOT use the backup as primary
+router, but must try to establish connection back to the primary router.
+If the action is allowed type value 21 is sent back to the server from
+the backup router. It is RECOMMENDED that implementations use the
+SILC_COMMAND_PING command to detect whether primary router is responsive.
+
+The servers connected to the backup router must then announce their
+clients, channels, channel users, channel user modes, channel modes,
+topics and other information to the backup router. This is to assure
+that none of the important notify packets were lost during the switch
+to the backup router. The backup router must check which of these
+announced entities it already has and distribute the new ones to the
+primary router.
+
+The backup router too must announce its servers, clients, channels
+and other information to the new primary router. The primary router
+of the backup router too must announce its information to the backup
+router. Both must process only the ones they do not know about. If
+any of the announced modes do not match then they are enforced in
+normal manner as defined in section 4.2.1 Announcing Clients, Channels
+and Servers.
+
+
+.ti 0
+3.13.2 Resuming Primary Router
+
+Usually the primary router is unresponsive only a short period of time
+and it is intended that the original router of the cell will resume
+its position as primary router when it comes back online. The backup
+router that is now acting as primary router of the cell must constantly
+try to connect to the original primary router of the cell. It is
+RECOMMENDED that it would try to reconnect in 30 second intervals to
+the primary router.
+
+When the connection is established to the primary router the backup
+resuming protocol is executed. The protocol is advanced as follows:
+
+ 1. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+ value 1 to the primary router that came back online. The packet
+ will indicate the primary router has been replaced by the backup
+ router. After sending the packet the backup router will announce
+ all of its channels, channel users, modes etc. to the primary
+ router.
+
+ If the primary knows that it has not been replaced (for example
+ the backup itself disconnected from the primary router and thinks
+ that it is now primary in the cell) the primary router send
+ SILC_PACKET_FAILURE with the type value 1 (4 bytes, MSB first
+ order) back to the backup router. If backup receives this it
+ MUST NOT continue with the backup resuming protocol.
+
+ 2. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+ value 1 to its current primary router to indicate that it will
+ resign as being primary router. Then, backup router sends the
+ SILC_PACKET_RESUME_ROUTER packet with type value 1 to all
+ connected servers to also indicate that it will resign as being
+ primary router.
+
+ 3. Backup router also send SILC_PACKET_RESUME_ROUTER packet with
+ type value 1 to the router that is using the backup router
+ currently as its primary router.
+
+ 4. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+ with type value 1 must reconnect immediately to the primary
+ router of the cell that came back online. After they have created
+ the connection they MUST NOT use that connection as active primary
+ route but still route all packets to the backup router. After
+ the connection is created they MUST send SILC_PACKET_RESUME_ROUTER
+ with type value 2 back to the backup router. The session ID value
+ found in the first packet MUST be set in this packet.
+
+ 5. Backup router MUST wait for all packets with type value 2 before
+ it continues with the protocol. It knows from the session ID values
+ set in the packet when it has received all packets. The session
+ value should be different in all packets it has sent earlier.
+ After the packets are received the backup router sends the
+ SILC_PACKET_RESUME_ROUTER packet with type value 3 to the
+ primary router that came back online. This packet will indicate
+ that the backup router is now ready to resign as being primary
+ router. The session ID value in this packet MUST be the same as
+ in the first packet sent to the primary router. During this time
+ the backup router must still route all packets it is receiving
+ from server connections.
+
+ 6. The primary router receives the packet and send the packet
+ SILC_PACKET_RESUME_ROUTER with type value 4 to all connected servers
+ including the backup router. It also sends the packet with type
+ value 4 to its primary router, and to the router that is using
+ it as its primary router. The Session ID value in these packets
+ SHOULD be zero (0).
+
+ 7. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+ packet with type value 4 must switch their primary route to the new
+ primary router and remove the route for the backup router, since
+ it is no longer the primary router of the cell. They must also
+ update their local database to understand that the clients are
+ not originated from the backup router but from the locally connected
+ servers. After that they MUST announce their channels, channel
+ users, modes etc. to the primary router. They MUST NOT use the
+ backup router connection after this and the connection is considered
+ to be a passive connection. The implementation SHOULD be able
+ to disable the connection without closing the actual link.
+
+After this protocol is executed the backup router is now again a normal
+server in the cell that has the backup link to the primary router. The
+primary router feeds the router specific data again to the backup router.
+All server connections to the backup router are considered passive
+connections.
+
+When the primary router of the cell comes back online and connects
+to its remote primary router, the remote primary router MUST send the
+SILC_PACKET_RESUME_ROUTER packet with type value 20 indicating that the
+connection is not allowed since the router has been replaced by an
+backup router in the cell. The session ID value in this packet SHOULD be
+zero (0). When the primary router receives this packet it MUST NOT use
+the connection as active connection but must understand that it cannot
+act as primary router in the cell, until the backup resuming protocol has
+been executed.
+
+The following type values has been defined for SILC_PACKET_RESUME_ROUTER
+packet:
+
+ 1 SILC_SERVER_BACKUP_START
+ 2 SILC_SERVER_BACKUP_START_CONNECTED
+ 3 SILC_SERVER_BACKUP_START_ENDING
+ 4 SILC_SERVER_BACKUP_START_RESUMED
+ 20 SILC_SERVER_BACKUP_START_REPLACED
+ 21 SILC_SERVER_BACKUP_START_USE
+
+If any other value is found in the type field the packet MUST be
+discarded. The SILC_PACKET_RESUME_ROUTER packet and its payload
+is defined in [SILC2].
+
+
+.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 references [SILC2], [SILC3] and [SILC4] permeate this
+section's definitions.
+
+
+
+
+.ti 0
+4.1 Creating Client Connection
+
+This section describes the procedure when a 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, a 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. The 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 perform
+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
+MUST register itself by sending SILC_PACKET_NEW_CLIENT packet to the
+server. This packet includes various information about the client
+that the server uses to register the client. Server registers 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 that
+information rather than what it received from client. This is a 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 may set the nickname to something
+more desirable 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].
+
+Router server MUST also check whether some client in the local cell
+is watching for the nickname this new client has, and send the
+SILC_NOTIFY_TYPE_WATCH to the watcher.
+
+
+.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 to when a 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 authentication or public key authentication based on
+digital signatures.
+
+After server and router have successfully performed the key exchange
+and connection authentication protocol, the server MUST 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. The router receiving the
+ID MUST verify that the IP address in the Server ID is same as the
+server's real IP address.
+
+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 is in [SILC2].
+
+As the 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.
+Channels' mode, founder public key, channel public keys, and other
+channel mode specific data is announced by sending the
+SILC_NOTIFY_TYPE_CMODE_CHANGE notify list.
+
+The channel public keys that are announced are compiled in Argument
+List Payload where the argument type is 0x03, and each argument is
+Public Key Payload containing one public key or certificate.
+
+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.
+
+Also, clients' modes (user modes in SILC) MUST be announced. This is
+done by compiling a list of Notify Payloads with SILC_NOTIFY_UMODE_CHANGE
+notify type into the SILC_PACKET_NOTIFY packet. Also, channels' topics
+MUST be announced by compiling a list of Notify Payloads with the
+SILC_NOTIFY_TOPIC_SET notify type into the SILC_PACKET_NOTIFY packet.
+
+The router which receives these lists MUST process them and broadcast
+the packets to its primary router. 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 a channel founder already 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 on the server.
+
+If the channel public keys are already set on the on router, the router
+MUST ignore the received channel public key list and send the notify
+type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server which includes the
+channel public key list that is on router. The server MUST change the
+list to the one it receives from router.
+
+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 the 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 have 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 have 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 are set for the client.
+
+If the router created the channel in the process, information about the
+new channel MUST be broadcast 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 or distributed 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 client MUST start
+using the new key. If server creates the new key the server MUST also
+send the new key to its router. See [SILC2] for more information about
+how channel messages must be encrypted and decrypted when router is
+processing them.
+
+If the key changes very often due to joining traffic on the channel it
+is RECOMMENDED that client implementation would cache some of the old
+channel keys for short period of time so that it is able to decrypt all
+channel messages it receives. It is possible that on a heavy traffic
+channel a message encrypted with channel key that was just changed
+is received by client after the new key was set into use. This is
+possible because not all clients may receive the new key at the same
+time, and may still be sending messages encrypted with the old key.
+
+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 also MUST save the channel key.
+
+
+.ti 0
+4.5 Private Message Sending and Reception
+
+Private messages are sent point to point. Client explicitly destine
+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 in any
+other packet as well. The Source ID in the SILC Packet Header MUST be
+the ID of the sender of the message.
+
+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.
+
+If server receives a private message packet which includes invalid
+destination Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+notify to the client with error status indicating that such Client ID
+does not exist.
+
+See [SILC2] for description of private message encryption and decryption
+process.
+
+
+.ti 0
+4.6 Private Message Key Generation
+
+Private message MAY be protected with a 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.
+The key sent inside the payload SHOULD be randomly generated. This
+packet MUST NOT be used to send pre-shared keys.
+
+Another choice is to entirely use keys that are not sent through
+the SILC network at all. This significantly adds security. This key
+could be a pre-shared key that is known by both of the clients. Both
+agree about using the key and start sending packets that indicate
+that the private message is secured using private message key. In
+case of pre-shared keys (static keys) the IV used in encryption SHOULD
+be chosen randomly.
+
+It is also possible to negotiate fresh key material by performing
+Key Agreement. The SILC_PACKET_KEY_AGREEMENT packet MAY be used to
+negotiate the fresh key material. In this case the resulting key
+material is used to secure the private messages. Also, the IV used
+in encryption is used as defined in [SILC3], unless otherwise stated
+by the encryption mode used. By performing Key Agreement the clients
+may negotiate the cipher and HMAC to be used in the private message
+encryption and to negotiate additional security parameters.
+
+If the key is pre-shared key or other key material not generated by
+Key Agreement, then the key material SHOULD be processed as defined
+in [SILC3]. The hash function to be used SHOULD be SHA1. 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].
+In this case also, implementations SHOULD use the SILC protocol's
+mandatory cipher and HMAC in private message encryption.
+
+
+.ti 0
+4.7 Channel Message Sending and Reception
+
+Channel messages are delivered to a group of users. The group forms a
+channel and all clients on the channel receives messages sent to the
+channel. The Source ID in the SILC Packet Header MUST be the ID
+of the sender of the message.
+
+Channel messages are destined to a channel by specifying the Channel ID
+as Destination ID in the SILC Packet Header. The server MUST then
+distribute the message to all clients, except to the original sender,
+on the channel by sending the channel message destined explicitly to a
+client on the channel. However, the Destination ID MUST still remain
+as the Channel ID.
+
+If server receives a channel message packet which includes invalid
+destination Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+notify to the sender with error status indicating that such Channel ID
+does not exist.
+
+See the [SILC2] for description of channel message routing for router
+servers, and 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 have 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. See the [SILC4]
+for detailed description of all commands.
+
+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 [SILC4]. 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 servers. 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.
+
+Router server MUST also check whether some client in the local cell
+is watching for the nickname this client has, and send the
+SILC_NOTIFY_TYPE_WATCH to the watcher, unless the client which left
+the network has the SILC_UMODE_REJECT_WATCHING user mode set.
+
+
+
+
+.ti 0
+4.11 Detaching and Resuming a Session
+
+SILC protocol provides a possibility for a client to detach itself from
+the network without actually signing off from the network. The client
+connection to the server is closed but the client remains as valid client
+in the network. The client may then later resume its session back from
+any server in the network.
+
+When client wishes to detach from the network it MUST send the
+SILC_COMMAND_DETACH command to its server. The server then MUST set
+SILC_UMODE_DETACHED mode to the client and send SILC_NOTIFY_UMODE_CHANGE
+notify to its primary router, which then MUST broadcast it further
+to other routers in the network. This user mode indicates that the
+client is detached from the network. Implementations MUST NOT use
+the SILC_UMODE_DETACHED flag to determine whether a packet can be sent
+to the client. All packets MUST still be sent to the client even if
+client is detached from the network. Only the server that originally
+had the active client connection is able to make the decision after it
+notices that the network connection is not active. In this case the
+default case is to discard the packet.
+
+The SILC_UMODE_DETACHED flag cannot be set by client itself directly
+with SILC_COMMAND_UMODE command, but only implicitly by sending the
+SILC_COMMAND_DETACH command. The flag also cannot be unset by the
+client, server or router with SILC_COMMAND_UMODE command, but only
+implicitly by sending and receiving the SILC_PACKET_RESUME_CLIENT
+packet.
+
+When the client wishes to resume its session in the SILC Network it
+connects to a server in the network, which MAY also be a different
+from the original server, and performs normal procedures regarding
+creating a connection as described in section 4.1. After the SKE
+and the Connection Authentication protocols has been successfully
+completed the client MUST NOT send SILC_PACKET_NEW_CLIENT packet, but
+MUST send SILC_PACKET_RESUME_CLIENT packet. This packet is used to
+perform the resuming procedure. The packet MUST include the detached
+client's Client ID, which the client must know. It also includes
+Authentication Payload which includes signature computed with the
+client's private key. The signature is computed as defined in the
+section 3.9.1. Thus, the authentication method MUST be based in
+public key authentication.
+
+When server receive the SILC_PACKET_RESUME_CLIENT packet it MUST
+do the following: Server checks that the Client ID is valid client
+and that it has the SILC_UMODE_DETACHED mode set. Then it verifies
+the Authentication Payload with the detached client's public key.
+If it does not have the public key it retrieves it by sending
+SILC_COMMAND_GETKEY command to the server that has the public key from
+the original client connection. The server MUST NOT use the public
+key received in the SKE protocol for this connection. If the
+signature is valid the server unsets the SILC_UMODE_DETACHED flag,
+and sends the SILC_PACKET_RESUME_CLIENT packet to its primary router.
+The routers MUST broadcast the packet and unset the SILC_UMODE_DETACHED
+flag when the packet is received. If the server is router server it
+also MUST send the SILC_PACKET_RESUME_CLIENT packet to the original
+server whom owned the detached client.
+
+The servers and routers that receives the SILC_PACKET_RESUME_CLIENT
+packet MUST know whether the packet already has been received for
+the client. It is a protocol error to attempt to resume the client
+session from more than one server. The implementations could set
+internal flag that indicates that the client is resumed. If router
+receive SILC_PACKET_RESUME_CLIENT packet for client that is already
+resumed the client MUST be killed from the network. This would
+indicate that the client is attempting to resume the session more
+than once which is a protocol error. In this case the router sends
+SILC_NOTIFY_TYPE_KILLED to the client. All routers that detect
+the same situation MUST also send the notify for the client.
+
+The servers and routers that receive the SILC_PACKET_RESUME_CLIENT
+must also understand that the client may not be found behind the
+same server that it originally came from. They must update their
+caches according to this. The server that now owns the client session
+MUST check whether the Client ID of the resumed client is based
+on the server's Server ID. If it is not it creates a new Client
+ID and send SILC_NOTIFY_TYPE_NICK_CHANGE to the network. It MUST
+also send the channel keys of all channels that the client has
+joined to the client since it does not have them. Whether the
+Client ID was changed or not the server MUST send SILC_PACKET_NEW_ID
+packet to the client. Only after this is the client resumed back
+to the network and may start sending packets and messages.
+
+It is also possible that the server did not know about the global
+channels before the client resumed. In this case it joins the client
+to the channels, generates new channel keys and distributes the keys
+to the channels as described in section 4.4.
+
+It is an implementation issue for how long servers keep detached client
+sessions. It is RECOMMENDED that the detached sessions would be
+persistent as long as the server is running.
+
+
+.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 to 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 to acceptance to
+the SILC Network. Even though the SILC protocol is secure in a network
+of mutual distrust between clients, servers, routers and administrators
+of the servers, the client should be able to trust the servers they are
+using if they wish to do so.
+
+It however must be noted that if the client requires absolute security
+by not trusting any of the servers or routers in the SILC Network, it can
+be accomplished by negotiating private keys outside the SILC Network,
+either using SKE or some other key exchange 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 a foolproof system; the SILC servers and routers could very well be
+compromised. However, to provide an acceptable level of security and
+usability for end users, the protocol uses many times session keys or
+other keys generated by the servers to secure the messages. This is an
+intentional design feature to allow ease of use for end users. This way
+the network is still usable, and remains encrypted even if the external
+means of distributing the keys is not working. The implementation,
+however, may like to not follow this design feature, and may always
+negotiate the keys outside SILC network. This is an acceptable solution
+and many times recommended. The implementation still must be able to
+work with the server generated keys.
+
+If this is unacceptable for the client or end user, the private keys
+negotiated outside the SILC Network should always be used. In the end
+it is the 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,
+ May 2002.
+
+[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
+ Protocols", Internet Draft, May 2002.
+
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
+
+[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.
+
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+[RFC1321] Rivest R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+[RFC3174] Eastlake, F., et al., "US Secure Hash Algorithm 1 (SHA1)",
+ RFC 3174, September 2001.
+
+[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
+ Version 1.5", RFC 2315, March 1998.
+
+[RFC2253] Wahl, M., et al., "Lightweight Directory Access Protocol
+ (v3): UTF-8 String Representation of Distinguished Names",
+ RFC 2253, December 1997.
+
+
+.ti 0
+7 Author's Address
+
+.nf
+Pekka Riikonen
+Snellmaninkatu 34 A 15
+70100 Kuopio
+Finland
+
+EMail: priikone@iki.fi
+
+
+.ti 0
+8 Full Copyright Statement
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
projects / silc.git / commitdiff