+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
+ 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.
+
+ * Trimmed the silc_hash_fingerprint function to remove extra
+ whitespaces from the end of the fingerprint. The affected
+ file is lib/silccrypt/silchash.c.
+
+ * Updated TODO.
+
+ * Added silc_cipher_register_default function to register all
+ default ciphers. It can be used when configuration files
+ does not exist and the application does not want any specific
+ ciphers in any specific order.
+
+ The SilcDList is now used as silc_cipher_list dynamically
+ allocated cipher list. Removed the static list all together
+ and now all ciphers must be allocated to the dynamic list.
+ The silc_cipher_alloc routine was changed to check only the
+ dynamic list.
+
+ All silc_cipher_* routines that used to return int returns
+ now bool.
+
+ The affected files lib/silccrypt/silccrypt.[ch].
+
+ * The same thing was done to silc_hash_* as for silc_cipher_*
+ routines. Affected files lib/silccrypt/silchash.[ch].
+
+ * The same thing was done to silc_pkcs_* as for silc_cipher_*
+ routines. Affected files lib/silccrypt/silcpkcs.[ch].
+ Added also silc_pkcs_[un]register[_default] functions.
+ Removed the data_context from the PKCS API.
+
+ * Added silc_hmac_register_default function to register default
+ hmacs. Affected files lib/silccrypt/silchmac.[ch]. Added also
+ SILC_ALL_HMACS macro that can be used with silc_hmac_unregister
+ to unregister all hmacs at once.
+
+ * Register the default ciphers, hash functions, PKCSs and HMACs
+ if client's configuration file does not exist. The affected
+ file silc/silc.c.
+
+ * The client did not load the hash functions from the SIM
+ modules at all. Added support for this. Affected file is
+ silc/clientconfig.c.
+
+ * When decoding public key with silc_pkcs_public_key_decode, check
+ the supported algorithm only if PKCS are registered. Affected
+ file lib/silccrypt/silcpkcs.c. The same was done with the
+ silc_pkcs_private_key_decode.
+
+ * Fixed the SILC List routines to keep the list always in order.
+ It used to change the list's order when traversing the list but
+ not it preserves the order. Affected file lib/trq/silclist.h.
+
+Mon Apr 30 17:29:03 EEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
+
+ * Added the client library to use the SilcSocketConnection's
+ reference counter (by silc_socket_dup) to prevent the bug that
+ the socket object may be freed underneath async operation.
+
+ * The name resolv library checking fixes in the configure.in.pre.
+ The patch by salo.
+
+ * Created new version of the protocol drafts for future
+ development. The -03 drafts are the ones that will be changed
+ in the trunk now and the -02 will remain as they are.
+
+ * Send list of CUMODE notifys to the router when announcing
+ the channel users to the router. Affected file silcd/server.c.
+ If the router receiving channel founder CUMODE for a channel
+ that already has channel founder it will send CUMODE notify
+ to the sender to remove the channel founder rights from the
+ announced client. Affected file silcd/packet_receive.c.
+
+ * The CUMODE notify may now use Server ID as well as the entity
+ who changes the mode. Updated protocool specs.
+
+ * Updated INSTALL and README files.
+
Sun Apr 29 23:17:50 EEST 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* New web pages in the http://silc.pspt.fi. The pages was
-Installing SILC Developer's Version
-===================================
+Quick Installation
+==================
-./configure
-./make
+To configure and compile SILC package give the comands:
-You should not install the SILC into your system, instead, you should
-run it from the current directory.
+ ./configure
+ make
+ make install
-To see different compilation options, give,
+This will install the SILC binaries and configuration files into the
+/usr/local/silc/ directory. System wide configuration files are installed
+into the /etc/silc/ directory.
-./configure --help
+Basic Installation
+==================
+ These are generic installation instructions.
-Generally, developers wants to compile with debugging, in this case,
-give,
+ The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation. It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions. Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, a file
+`config.cache' that saves the results of its tests to speed up
+reconfiguring, and a file `config.log' containing compiler output
+(useful mainly for debugging `configure').
-./configure --enable-debug
+ If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release. If at some point `config.cache'
+contains results you don't want to keep, you may remove or edit it.
-WARNING: The debugging is very very heavy and you currently cannot turn
-it off if you have compiled it with this option. However, if you're
-going to develop or debug SILC you should compile with this option.
+ The file `configure.in' is used to create `configure' by a program
+called `autoconf'. You only need `configure.in' if you want to change
+it or regenerate `configure' using a newer version of `autoconf'.
+The simplest way to compile this package is:
+
+ 1. `cd' to the directory containing the package's source code and type
+ `./configure' to configure the package for your system. If you're
+ using `csh' on an old version of System V, you might need to type
+ `sh ./configure' instead to prevent `csh' from trying to execute
+ `configure' itself.
+
+ Running `configure' takes awhile. While running, it prints some
+ messages telling which features it is checking for.
+
+ 2. Type `make' to compile the package.
+
+ 3. Optionally, type `make check' to run any self-tests that come with
+ the package.
+
+ 4. Type `make install' to install the programs and any data files and
+ documentation.
+
+ 5. You can remove the program binaries and object files from the
+ source code directory by typing `make clean'. To also remove the
+ files that `configure' created (so you can compile the package for
+ a different kind of computer), type `make distclean'. There is
+ also a `make maintainer-clean' target, but that is intended mainly
+ for the package's developers. If you use it, you may have to get
+ all sorts of other programs in order to regenerate files that came
+ with the distribution.
+
+Compilers and Options
+=====================
+
+ Some systems require unusual options for compilation or linking that
+the `configure' script does not know about. You can give `configure'
+initial values for variables by setting them in the environment. Using
+a Bourne-compatible shell, you can do that on the command line like
+this:
+ CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
+
+Or on systems that have the `env' program, you can do it like this:
+ env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
+
+Compiling For Multiple Architectures
+====================================
+
+ You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory. To do this, you must use a version of `make' that
+supports the `VPATH' variable, such as GNU `make'. `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script. `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'.
+
+ If you have to use a `make' that does not supports the `VPATH'
+variable, you have to compile the package for one architecture at a time
+in the source code directory. After you have installed the package for
+one architecture, use `make distclean' before reconfiguring for another
+architecture.
+
+Installation Names
+==================
+
+ By default, `make install' will install the package's files in
+`/usr/local/bin', `/usr/local/man', etc. You can specify an
+installation prefix other than `/usr/local' by giving `configure' the
+option `--prefix=PATH'.
+
+ You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files. If you
+give `configure' the option `--exec-prefix=PATH', the package will use
+PATH as the prefix for installing programs and libraries.
+Documentation and other data files will still use the regular prefix.
+
+ In addition, if you use an unusual directory layout you can give
+options like `--bindir=PATH' to specify different values for particular
+kinds of files. Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them.
+
+ If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+Optional Features
+=================
+
+ Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System). The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+ For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+Specifying the System Type
+==========================
+
+ There may be some features `configure' can not figure out
+automatically, but needs to determine by the type of host the package
+will run on. Usually `configure' can figure that out, but if it prints
+a message saying it can not guess the host type, give it the
+`--host=TYPE' option. TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name with three fields:
+ CPU-COMPANY-SYSTEM
+
+See the file `config.sub' for the possible values of each field. If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the host type.
+
+ If you are building compiler tools for cross-compiling, you can also
+use the `--target=TYPE' option to select the type of system they will
+produce code for and the `--build=TYPE' option to select the type of
+system on which you are compiling the package.
+
+Operation Controls
+==================
+
+ `configure' recognizes the following options to control how it
+operates.
+
+`--cache-file=FILE'
+ Use and save the results of the tests in FILE instead of
+ `./config.cache'. Set FILE to `/dev/null' to disable caching, for
+ debugging `configure'.
+
+`--help'
+ Print a summary of the options to `configure', and exit.
+
+`--quiet'
+`--silent'
+`-q'
+ Do not print messages saying which checks are being made. To
+ suppress all normal output, redirect it to `/dev/null' (any error
+ messages will still be shown).
+
+`--srcdir=DIR'
+ Look for the package's source code in directory DIR. Usually
+ `configure' can determine that directory automatically.
+
+`--version'
+ Print the version of Autoconf used to generate the `configure'
+ script, and exit.
+
+`configure' also accepts some other, not widely useful, options.
History
=======
-Even though SILC were just released to the public the idea and the protocol
-itself is quite old. I got the idea about SILC in its current form in
-the year 1996 and first lines of codes were written in early 1997. This
-release is now third rewrite of the SILC. The very first version were
-written in 1997 and it included SILC client and very very preliminary
-SILC server. The server actually weren't usable but the client looked
-pretty much the same as it does now. At that time the SILC also included
-RSA implementation and 3DES implementation. The random number generator
-that exists in this current release is actually based on the RNG written
-in 1997. The RNG written in 1997, on the other hand, were based on
-the SSH's random number generator. The RNG has been rewritten twice
-since the first version.
-
-I stopped writing the SILC later in 1997 when I got busy at school and
-in work. The pause lasted several months. The development resumed in
-1998 when my friend (Juha Räsänen) and I implemented ElGamal algorithm.
-I rewrote some other parts as well. However, for the same reasons as
-previously the development stopped again. I resumed the development
-later in 1998 by doing rewrite of the SILC in C++. This was obviously
-a mistake but at that time it seemed like a good idea. Again, in the
-winter 1999 I got very busy writing my thesis and was forced to stop the
-development again. I also, started a new job in the spring.
-
-Later, in 1999, I decided that this time I'm going to make it the right
-way. C++ was obviously a bad choice so I decided to fall back to plain
-C language. I also decided to do complete rewrite and started doing
-more thorough planning of what the SILC actually should include. I also
+Even though SILC were released in summer 2000 to the public the idea and
+the protocol itself is quite old. I got the idea about SILC in its
+current form in the year 1996 and first lines of codes were written in
+early 1997. This release is now third rewrite of the SILC. The very first
+version were written in 1997 and it included SILC client and very very
+preliminary SILC server. The server actually weren't usable but the
+client looked pretty much the same as it does now. At that time the SILC
+also included RSA implementation and 3DES implementation. The random
+number generator that exists in this current release is actually based on
+the RNG written in 1997. The RNG written in 1997, on the other hand, were
+based on the SSH's random number generator. The RNG has been rewritten
+twice since the first version.
+
+I stopped writing the SILC later in 1997 when I got busy at school and in
+work. The pause lasted several months. The development resumed in 1998
+when my friend (Juha Räsänen) and I implemented ElGamal algorithm. I
+rewrote some other parts as well. However, for the same reasons as
+previously the development stopped again. I resumed the development later
+in 1998 by doing rewrite of the SILC in C++. This was obviously a mistake
+but at that time it seemed like a good idea. Again, in the winter 1999 I
+got very busy writing my thesis and was forced to stop the development
+again. I also, started a new job in the spring.
+
+Later, in 1999, I decided that this time I'm going to make it the right
+way. C++ was obviously a bad choice so I decided to fall back to plain C
+language. I also decided to do complete rewrite and started doing more
+thorough planning of what the SILC actually should include. I also
decided that this time it is going to kill me before I stop the
-development. I started writing SILC in the weekends and actually
-everytime I had some spare time. I also started a new job but I didn't
-let that get to my way. The result of this development effort is the
-release now in public.
-
-I've learned a lot by doing the SILC. I guess, when I started it I wasn't
-that good of a C programmer. That alone was a reason why SILC hasn't
-seen the day of light before now. My programming style has also changed
-dramatically during these years. Actually, it has changed couple times
-since this last rewrite as well. However, the code style of current SILC
+development. I started writing SILC in the weekends and actually
+everytime I had some spare time. I also started a new job but I didn't
+let that get to my way. The result of this development effort is the
+release now in public.
+
+I've learned a lot by doing the SILC. I guess, when I started it I wasn't
+that good of a C programmer. That alone was a reason why SILC hasn't seen
+the day of light before now. My programming style has also changed
+dramatically during these years. Actually, it has changed couple times
+since this last rewrite as well. However, the code style of current SILC
release is quite consistent (actually the coding style SILC has been
written now I've learned in my current job).
-There is probably over 85% of new code in this third rewrite. Rest has
-just been copied from the old versions and only minor changes has been
-made (like changed function names and overall coding style). I've
+There is probably over 85% of new code in this third rewrite. Rest has
+just been copied from the old versions and only minor changes has been
+made (like changed function names and overall coding style). I've
preserved the dates of the old files (dating back to 1997) that has
-existed in some forms in the old versions. There is a lot of new code but
-already I see a lot that needs rewriting. The development continues.
+existed in some forms in the old versions. There is a lot of new code but
+already I see a lot that needs rewriting. The development continues.
Contact
=======
-Feedback and comments are welcome. You can reach me in the following
-Address.
+Feedback and comments are welcome. Bug reports should be sent to the
+development mailing list.
-Official SILC project web site is : http://silc.pspt.fi
-FTP archive for SILC project is : ftp://silc.pspt.fi/pub/silc/
-Development mailing list address is : silc-devel@lists.sourceforge.net
+Official SILC project web site : http://silcnet.org/
+FTP archive for SILC project : ftp://silc.pspt.fi/pub/silc/
+Development mailing list address : silc-devel@lists.sourceforge.net
Pekka Riikonen <priikone@poseidon.pspt.fi>
==============================
After checkout from CVS the SILC source tree must be prepared for
-configuration and compilation. To compile the source three, give,
+configuration and compilation. To compile the source tree, give,
./prepare
./configure --enable-debug
TODO/bugs In SILC Client Library
================================
- o Client library crashes if for example server timeouts protocol
- execution and disconnects the client. The client, on the other hand
- may still assume that the connection is active, even after receiving
- the EOF. Reason for this is that the clien library does not handle
- the SilcSocketConnection reference counter at all. This must be
- fixed.
-
- o When receiving client's public key with GETKEY or in key agreement
- protoocl it probably should be saved using the nickname and the real
- name of the client instead of the host name of the client.
+ o Add local commands to list the current server and client public keys
+ that the user has. And a local command to dump the contents of the
+ public key to the screen.
o Add client library parameters or options that handle what kind of
messages the library should print out (using `say' client operation,
TODO/bugs In SILC Server
========================
- o Send SILC_NOTIFY_TYPE_CUMODE_CHANGE when received announced channels
- and channel users and we (router) already has a channel founder on the
- channel.
-
o When server quits and all clients of that server are removed from all
channels the channel keys are re-generated for all clients. This is
a bug and should be done only once per channel after all clients of
hash tables should replace the lists. Thus, the ID cache should be
rewritten to use hash tables internally.
+ o New configuration file format must be added. The new one will be
+ done using the dotconf config library.
+
o The backup router support described in the protocol specification
should be done at some point.
TODO/bugs In SILC Libraries
===========================
- o Remove the static lists from SILC ciphers, PKCS and hash functions
- in the crypto library. The currently acceptable code is used in the
- HMAC library, look from there. The config file must decide the order
- of the algorithms, not the static lists, as they are doing now.
- Actually the way to do this is to keep the static lists, but register
- the algorithms to the dynamic list and make the alloc routines to
- check only the dynamic list. Also, replace the lists used by these
- routines with SilcList. Also, for applications it might be nice
- to export a function that registers default algorithms, if application
- does not want to register them one by one (if for example SILC client
- is run without config files at all).
+ o Some of the ciphers in lib/silccrypt does not implement the SILC
+ Crypto API correctly.
o Compression routines are missing. The protocol supports packet
compression thus it must be implemented. SILC Comp API must be
not in distribution), but it is not used yet, and it requires some
tweaking on the Makefiles (we want static lib not shared).
- o Some of the ciphers in lib/silccrypt does not implement the SILC
- Crypto API correctly.
-
o IPv6 support for ID's and into the code.
- o SIM support for SILC PKCS API needs to made so that they could be
- used as SIM's. At the same time some work is required on prime
- generation as the way it is done now sucks. Read from code for
- more (silcpkcs.h).
-
TODO After 1.0
==============
unsigned char *pk, uint32 pk_len,
SilcSKEPKType pk_type)
{
- SilcSocketConnection sock = conn->sock;
+ int i;
char filename[256];
char file[256];
- char *hostname, *fingerprint;
+ char *fingerprint;
struct passwd *pw;
struct stat st;
char *entity = ((conn_type == SILC_SOCKET_TYPE_SERVER ||
conn_type == SILC_SOCKET_TYPE_ROUTER) ?
"server" : "client");
- hostname = sock->hostname ? sock->hostname : sock->ip;
-
if (pk_type != SILC_SKE_PK_TYPE_SILC) {
- silc_say(client, conn, "We don't support %s %s key type",
- entity, hostname);
+ silc_say(client, conn, "We don't support %s key type %d",
+ entity, pk_type);
return FALSE;
}
if (!pw)
return FALSE;
+ /* Replace all whitespaces with `_'. */
+ fingerprint = silc_hash_fingerprint(NULL, pk, pk_len);
+ for (i = 0; i < strlen(fingerprint); i++)
+ if (fingerprint[i] == ' ')
+ fingerprint[i] = '_';
+
memset(filename, 0, sizeof(filename));
memset(file, 0, sizeof(file));
- snprintf(file, sizeof(file) - 1, "%skey_%s_%d.pub", entity, hostname,
- sock->port);
+ snprintf(file, sizeof(file) - 1, "%skey_%s.pub", entity, fingerprint);
snprintf(filename, sizeof(filename) - 1, "%s/.silc/%skeys/%s",
pw->pw_dir, entity, file);
+ silc_free(fingerprint);
+
+ fingerprint = silc_hash_fingerprint(NULL, pk, pk_len);
/* Check whether this key already exists */
if (stat(filename, &st) < 0) {
- fingerprint = silc_hash_fingerprint(NULL, pk, pk_len);
- silc_say(client, conn, "Received %s %s public key", entity, hostname);
- silc_say(client, conn, "Fingerprint for the %s %s key is", entity,
- hostname);
+ silc_say(client, conn, "Received %s public key", entity);
+ silc_say(client, conn, "Fingerprint for the %s key is", entity);
silc_say(client, conn, "%s", fingerprint);
- silc_free(fingerprint);
/* Ask user to verify the key and save it */
if (silc_client_ask_yes_no(client,
/* Save the key for future checking */
silc_pkcs_save_public_key_data(filename, pk, pk_len,
SILC_PKCS_FILE_PEM);
+ silc_free(fingerprint);
return TRUE;
}
} else {
SILC_PKCS_FILE_PEM))
if (!silc_pkcs_load_public_key(filename, &public_key,
SILC_PKCS_FILE_BIN)) {
- fingerprint = silc_hash_fingerprint(NULL, pk, pk_len);
- silc_say(client, conn, "Received %s %s public key", entity, hostname);
- silc_say(client, conn, "Fingerprint for the %s %s key is",
- entity, hostname);
+ silc_say(client, conn, "Received %s public key", entity);
+ silc_say(client, conn, "Fingerprint for the %s key is", entity);
silc_say(client, conn, "%s", fingerprint);
- silc_free(fingerprint);
- silc_say(client, conn, "Could not load your local copy of the %s %s key",
- entity, hostname);
+ silc_say(client, conn, "Could not load your local copy of the %s key",
+ entity);
if (silc_client_ask_yes_no(client,
"Would you like to accept the key anyway (y/n)? "))
{
unlink(filename);
silc_pkcs_save_public_key_data(filename, pk, pk_len,
SILC_PKCS_FILE_PEM);
+ silc_free(fingerprint);
return TRUE;
}
+ silc_free(fingerprint);
return FALSE;
}
/* Encode the key data */
encpk = silc_pkcs_public_key_encode(public_key, &encpk_len);
if (!encpk) {
- fingerprint = silc_hash_fingerprint(NULL, pk, pk_len);
- silc_say(client, conn, "Received %s %s public key", entity, hostname);
- silc_say(client, conn, "Fingerprint for the %s %s key is",
- entity, hostname);
+ silc_say(client, conn, "Received %s public key", entity);
+ silc_say(client, conn, "Fingerprint for the %s key is", entity);
silc_say(client, conn, "%s", fingerprint);
- silc_free(fingerprint);
- silc_say(client, conn, "Your local copy of the %s %s key is malformed",
- entity, hostname);
+ silc_say(client, conn, "Your local copy of the %s key is malformed",
+ entity);
if (silc_client_ask_yes_no(client,
"Would you like to accept the key anyway (y/n)? "))
{
unlink(filename);
silc_pkcs_save_public_key_data(filename, pk, pk_len,
SILC_PKCS_FILE_PEM);
+ silc_free(fingerprint);
return TRUE;
}
+ silc_free(fingerprint);
return FALSE;
}
if (memcmp(encpk, pk, encpk_len)) {
- fingerprint = silc_hash_fingerprint(NULL, pk, pk_len);
- silc_say(client, conn, "Received %s %s public key", entity, hostname);
- silc_say(client, conn, "Fingerprint for the %s %s key is",
- entity, hostname);
+ silc_say(client, conn, "Received %s public key", entity);
+ silc_say(client, conn, "Fingerprint for the %s key is", entity);
silc_say(client, conn, "%s", fingerprint);
- silc_free(fingerprint);
- silc_say(client, conn, "%s %s key does not match with your local copy",
- entity, hostname);
- silc_say(client, conn, "It is possible that the key has expired or changed");
+ silc_say(client, conn, "%s key does not match with your local copy",
+ entity);
+ silc_say(client, conn,
+ "It is possible that the key has expired or changed");
silc_say(client, conn, "It is also possible that some one is performing "
"man-in-the-middle attack");
unlink(filename);
silc_pkcs_save_public_key_data(filename, pk, pk_len,
SILC_PKCS_FILE_PEM);
+ silc_free(fingerprint);
return TRUE;
}
- silc_say(client, conn, "Will not accept %s %s key", entity, hostname);
+ silc_say(client, conn, "Will not accept the %s key", entity);
+ silc_free(fingerprint);
return FALSE;
}
/* Local copy matched */
+ silc_free(fingerprint);
return TRUE;
}
- silc_say(client, conn, "Will not accept %s %s key", entity, hostname);
+ silc_say(client, conn, "Will not accept the %s key", entity);
+ silc_free(fingerprint);
return FALSE;
}
{
SilcClientInternal app = (SilcClientInternal)client->application;
- if (app->config->conns) {
+ if (app->config && app->config->conns) {
SilcClientConfigSectionConnection *conn = NULL;
/* Check if we find a match from user configured connections */
{ "[cipher]",
SILC_CLIENT_CONFIG_SECTION_TYPE_CIPHER, 4 },
{ "[pkcs]",
- SILC_CLIENT_CONFIG_SECTION_TYPE_PKCS, 2 },
+ SILC_CLIENT_CONFIG_SECTION_TYPE_PKCS, 1 },
{ "[hash]",
SILC_CLIENT_CONFIG_SECTION_TYPE_HASH_FUNCTION, 4 },
{ "[hmac]",
SilcClientConfigParse *return_config)
{
int i, begin;
- uint32 linenum;
+ int linenum;
char line[1024], *cp;
SilcClientConfigSection *cptr = NULL;
SilcClientConfigParse parse = *return_config, first = NULL;
break;
}
- /* Get key length */
- ret = silc_config_get_token(line, &tmp);
- if (ret < 0)
- break;
- if (ret == 0) {
- fprintf(stderr, "%s:%d: PKCS key length not defined\n",
- config->filename, pc->linenum);
- break;
- }
- config->pkcs->key_len = atoi(tmp);
- silc_free(tmp);
-
check = TRUE;
break;
/* Registers configured ciphers. These can then be allocated by the
client when needed. */
-void silc_client_config_register_ciphers(SilcClientConfig config)
+bool silc_client_config_register_ciphers(SilcClientConfig config)
{
SilcClientConfigSectionAlg *alg;
SilcClientInternal app = (SilcClientInternal)config->client;
SILC_LOG_DEBUG(("Registering configured ciphers"));
+ if (!config->cipher)
+ return FALSE;
+
alg = config->cipher;
while(alg) {
if (!alg->sim_name) {
- /* Crypto module is supposed to be built in. Nothing to be done
- here except to test that the cipher really is built in. */
- SilcCipher tmp = NULL;
+ /* Crypto module is supposed to be built in. Get the pointer to the
+ built in cipher and register it. */
+ int i;
+
+ for (i = 0; silc_default_ciphers[i].name; i++)
+ if (!strcmp(silc_default_ciphers[i].name, alg->alg_name)) {
+ silc_cipher_register(&silc_default_ciphers[i]);
+ break;
+ }
- if (silc_cipher_alloc(alg->alg_name, &tmp) == FALSE) {
- SILC_LOG_ERROR(("Unsupported cipher `%s'", alg->alg_name));
+ if (!silc_cipher_is_supported(alg->alg_name)) {
+ SILC_LOG_ERROR(("Unknown cipher `%s'", alg->alg_name));
silc_client_stop(client);
exit(1);
}
- silc_cipher_free(tmp);
#ifdef SILC_SIM
} else {
SILC_LOG_DEBUG(("set_key=%p", cipher.set_key));
cipher.set_key_with_string =
silc_sim_getsym(sim, silc_sim_symname(alg_name,
- SILC_CIPHER_SIM_SET_KEY_WITH_STRING));
+ SILC_CIPHER_SIM_SET_KEY_WITH_STRING));
SILC_LOG_DEBUG(("set_key_with_string=%p", cipher.set_key_with_string));
cipher.encrypt =
silc_sim_getsym(sim, silc_sim_symname(alg_name,
alg = alg->next;
}
+
+ return TRUE;
}
/* Registers configured PKCS's. */
-/* XXX: This really doesn't do anything now since we have statically
- registered our PKCS's. This should be implemented when PKCS works
- as SIM's. This checks now only that the PKCS user requested is
- really out there. */
-void silc_client_config_register_pkcs(SilcClientConfig config)
+bool silc_client_config_register_pkcs(SilcClientConfig config)
{
SilcClientConfigSectionAlg *alg = config->pkcs;
SilcClientInternal app = (SilcClientInternal)config->client;
SilcClient client = app->client;
- SilcPKCS tmp = NULL;
SILC_LOG_DEBUG(("Registering configured PKCS"));
- while(alg) {
+ if (!alg)
+ return FALSE;
- if (silc_pkcs_alloc(alg->alg_name, &tmp) == FALSE) {
- SILC_LOG_ERROR(("Unsupported PKCS `%s'", alg->alg_name));
+ while(alg) {
+ int i;
+
+ for (i = 0; silc_default_pkcs[i].name; i++)
+ if (!strcmp(silc_default_pkcs[i].name, alg->alg_name)) {
+ silc_pkcs_register(&silc_default_pkcs[i]);
+ break;
+ }
+
+ if (!silc_pkcs_is_supported(alg->alg_name)) {
+ SILC_LOG_ERROR(("Unknown PKCS `%s'", alg->alg_name));
silc_client_stop(client);
exit(1);
}
- silc_free(tmp);
alg = alg->next;
}
+
+ return TRUE;
}
/* Registers configured hash funtions. These can then be allocated by the
client when needed. */
-void silc_client_config_register_hashfuncs(SilcClientConfig config)
+bool silc_client_config_register_hashfuncs(SilcClientConfig config)
{
SilcClientConfigSectionAlg *alg;
SilcClientInternal app = (SilcClientInternal)config->client;
SILC_LOG_DEBUG(("Registering configured hash functions"));
+ if (!config->hash_func)
+ return FALSE;
+
alg = config->hash_func;
while(alg) {
if (!alg->sim_name) {
+ int i;
+
+ for (i = 0; silc_default_hash[i].name; i++)
+ if (!strcmp(silc_default_hash[i].name, alg->alg_name)) {
+ silc_hash_register(&silc_default_hash[i]);
+ break;
+ }
+
if (!silc_hash_is_supported(alg->alg_name)) {
- SILC_LOG_ERROR(("Unsupported hash function `%s'",
- alg->alg_name));
+ SILC_LOG_ERROR(("Unknown hash function `%s'", alg->alg_name));
+ silc_client_stop(client);
+ exit(1);
+ }
+#ifdef SILC_SIM
+ } else {
+ /* Load (try at least) the hash SIM module */
+ SilcHashObject hash;
+ SilcSimContext *sim;
+
+ memset(&hash, 0, sizeof(hash));
+ hash.name = alg->alg_name;
+ hash.block_len = alg->block_len;
+ hash.hash_len = alg->key_len;
+
+ sim = silc_sim_alloc();
+ sim->type = SILC_SIM_HASH;
+ sim->libname = alg->sim_name;
+
+ if ((silc_sim_load(sim))) {
+ hash.init =
+ silc_sim_getsym(sim, silc_sim_symname(alg->alg_name,
+ SILC_HASH_SIM_INIT));
+ SILC_LOG_DEBUG(("init=%p", hash.init));
+ hash.update =
+ silc_sim_getsym(sim, silc_sim_symname(alg->alg_name,
+ SILC_HASH_SIM_UPDATE));
+ SILC_LOG_DEBUG(("update=%p", hash.update));
+ hash.final =
+ silc_sim_getsym(sim, silc_sim_symname(alg->alg_name,
+ SILC_HASH_SIM_FINAL));
+ SILC_LOG_DEBUG(("final=%p", hash.final));
+ hash.context_len =
+ silc_sim_getsym(sim, silc_sim_symname(alg->alg_name,
+ SILC_HASH_SIM_CONTEXT_LEN));
+ SILC_LOG_DEBUG(("context_len=%p", hash.context_len));
+
+ /* Put the SIM to the table of all SIM's in client */
+ app->sim = silc_realloc(app->sim,
+ sizeof(*app->sim) *
+ (app->sim_count + 1));
+ app->sim[app->sim_count] = sim;
+ app->sim_count++;
+ } else {
+ SILC_LOG_ERROR(("Error configuring hash functions"));
silc_client_stop(client);
exit(1);
}
+
+ /* Register the hash function */
+ silc_hash_register(&hash);
+#endif
}
alg = alg->next;
}
+
+ return TRUE;
}
/* Registers configured HMACs. These can then be allocated by the
client when needed. */
-void silc_client_config_register_hmacs(SilcClientConfig config)
+bool silc_client_config_register_hmacs(SilcClientConfig config)
{
SilcClientConfigSectionAlg *alg;
SilcClientInternal app = (SilcClientInternal)config->client;
SILC_LOG_DEBUG(("Registering configured HMACs"));
- if (!config->hmac) {
- SILC_LOG_ERROR(("HMACs are not configured. SILC cannot work without "
- "HMACs"));
- silc_client_stop(client);
- exit(1);
- }
+ if (!config->hmac)
+ return FALSE;
alg = config->hmac;
while(alg) {
SilcHmacObject hmac;
if (!silc_hash_is_supported(alg->sim_name)) {
- SILC_LOG_ERROR(("Unsupported hash function `%s'",
- alg->sim_name));
+ SILC_LOG_ERROR(("Unknown hash function `%s' for HMAC `%s'",
+ alg->sim_name, alg->alg_name));
silc_client_stop(client);
exit(1);
}
alg = alg->next;
}
+
+ return TRUE;
}
SilcClientConfigSectionConnection *
SilcClientConfigParse parse_config);
int silc_client_config_check_sections(uint32 checkmask);
void silc_client_config_setlogfiles(SilcClientConfig config);
-void silc_client_config_register_ciphers(SilcClientConfig config);
-void silc_client_config_register_pkcs(SilcClientConfig config);
-void silc_client_config_register_hashfuncs(SilcClientConfig config);
-void silc_client_config_register_hmacs(SilcClientConfig config);
+bool silc_client_config_register_ciphers(SilcClientConfig config);
+bool silc_client_config_register_pkcs(SilcClientConfig config);
+bool silc_client_config_register_hashfuncs(SilcClientConfig config);
+bool silc_client_config_register_hmacs(SilcClientConfig config);
SilcClientConfigSectionConnection *
silc_client_config_find_connection(SilcClientConfig config,
char *host, int port);
/* Read global configuration file. */
app->config = silc_client_config_alloc(opt_config_file);
- if (app->config == NULL)
- goto fail;
/* XXX Read local configuration file */
silc->realname = silc_get_real_name();
/* Register all configured ciphers, PKCS and hash functions. */
- app->config->client = (void *)app;
- silc_client_config_register_ciphers(app->config);
- silc_client_config_register_pkcs(app->config);
- silc_client_config_register_hashfuncs(app->config);
- silc_client_config_register_hmacs(app->config);
+ if (app->config) {
+ app->config->client = (void *)app;
+ if (!silc_client_config_register_ciphers(app->config))
+ silc_cipher_register_default();
+ if (!silc_client_config_register_pkcs(app->config))
+ silc_pkcs_register_default();
+ if (!silc_client_config_register_hashfuncs(app->config))
+ silc_hash_register_default();
+ if (!silc_client_config_register_hmacs(app->config))
+ silc_hmac_register_default();
+ } else {
+ /* Register default ciphers, pkcs, hash funtions and hmacs. */
+ silc_cipher_register_default();
+ silc_pkcs_register_default();
+ silc_hash_register_default();
+ silc_hmac_register_default();
+ }
/* Load public and private key */
if (silc_client_load_keys(silc) == FALSE)
SILC_TASK_TIMEOUT,
SILC_TASK_PRI_LOW);
- if (app->config->commands) {
+ if (app->config && app->config->commands) {
/* Run user configured commands with timeout */
silc_task_register(silc->timeout_queue, 0,
silc_client_run_commands,
#
# NOTE: <module path> must be omitted as PKCS cannot be modules currently.
#
-#[pkcs]
-#rsa::1024
-#dss::1024
+[pkcs]
+rsa
#
# Configured connections to servers.
serverid.c \
silcd.c \
server_version.c
-
silcd_DEPENDENCIES = ../lib/libsilc.a
if SILC_BUILD_GMP
server->server_type == SILC_ROUTER ?
TRUE : FALSE, channel,
target_mask, client->id,
- SILC_ID_CLIENT_LEN,
+ SILC_ID_CLIENT, SILC_ID_CLIENT_LEN,
target_client->id,
SILC_ID_CLIENT_LEN);
}
/* Get entry to the channel user list */
silc_list_start(channel->user_list);
- while ((chl = silc_list_get(channel->user_list)) != SILC_LIST_END)
+ while ((chl = silc_list_get(channel->user_list)) != SILC_LIST_END) {
+ SilcChannelClientEntry chl2 = NULL;
+
+ /* If the mode is channel founder and we already find a client
+ to have that mode on the channel we will enforce the sender
+ to change the channel founder mode away. There can be only one
+ channel founder on the channel. */
+ if (server->server_type == SILC_ROUTER &&
+ mode & SILC_CHANNEL_UMODE_CHANFO &&
+ chl->mode & SILC_CHANNEL_UMODE_CHANFO) {
+ silc_server_send_notify_cumode(server, sock, FALSE, channel,
+ (mode & (~SILC_CHANNEL_UMODE_CHANFO)),
+ server->id, SILC_ID_SERVER,
+ SILC_ID_SERVER_LEN,
+ client->id, SILC_ID_CLIENT_LEN);
+ silc_free(channel_id);
+
+ /* Change the mode back if we changed it */
+ if (chl2)
+ chl2->mode &= ~SILC_CHANNEL_UMODE_CHANFO;
+ goto out;
+ }
+
if (chl->client == client) {
/* Change the mode */
chl->mode = mode;
- break;
+ if (!(mode & SILC_CHANNEL_UMODE_CHANFO))
+ break;
+
+ chl2 = chl;
}
+ }
/* Send the same notify to the channel */
silc_server_packet_send_to_channel(server, sock, channel, packet->type,
}
if (channel_id2) {
- SilcBuffer users = NULL;
+ SilcBuffer users = NULL, users_modes = NULL;
/* Re-announce our clients on the channel as the ID has changed now */
- silc_server_announce_get_channel_users(server, channel, &users);
+ silc_server_announce_get_channel_users(server, channel, &users,
+ &users_modes);
if (users) {
silc_buffer_push(users, users->data - users->head);
silc_server_packet_send(server, sock,
users->data, users->len, FALSE);
silc_buffer_free(users);
}
+ if (users_modes) {
+ silc_buffer_push(users_modes, users_modes->data - users_modes->head);
+ silc_server_packet_send(server, sock,
+ SILC_PACKET_NOTIFY, SILC_PACKET_FLAG_LIST,
+ users_modes->data, users_modes->len, FALSE);
+ silc_buffer_free(users_modes);
+ }
}
silc_free(channel_id);
/* The channel exist by that name, check whether the ID's match.
If they don't then we'll force the server to use the ID we have.
We also create a new key for the channel. */
- SilcBuffer users = NULL;
+ SilcBuffer users = NULL, users_modes = NULL;
if (!channel->id)
channel_id = silc_id_dup(channel_id, SILC_ID_CHANNEL);
/* Since the channel is coming from server and we also know about it
then send the JOIN notify to the server so that it see's our
users on the channel "joining" the channel. */
- silc_server_announce_get_channel_users(server, channel, &users);
+ silc_server_announce_get_channel_users(server, channel, &users,
+ &users_modes);
if (users) {
silc_buffer_push(users, users->data - users->head);
silc_server_packet_send(server, sock,
users->data, users->len, FALSE);
silc_buffer_free(users);
}
+ if (users_modes) {
+ silc_buffer_push(users_modes, users_modes->data - users_modes->head);
+ silc_server_packet_send(server, sock,
+ SILC_PACKET_NOTIFY, SILC_PACKET_FLAG_LIST,
+ users_modes->data, users_modes->len, FALSE);
+ silc_buffer_free(users_modes);
+ }
}
}
int broadcast,
SilcChannelEntry channel,
uint32 mode_mask,
- SilcClientID *client_id,
- uint32 client_id_len,
+ void *id, SilcIdType id_type,
+ uint32 id_len,
SilcClientID *target,
uint32 target_len)
{
SilcBuffer idp1, idp2;
unsigned char mode[4];
- idp1 = silc_id_payload_encode((void *)client_id, SILC_ID_CLIENT);
+ idp1 = silc_id_payload_encode((void *)id, id_type);
idp2 = silc_id_payload_encode((void *)target, SILC_ID_CLIENT);
SILC_PUT32_MSB(mode_mask, mode);
int broadcast,
SilcChannelEntry channel,
uint32 mode_mask,
- SilcClientID *client_id,
- uint32 client_id_len,
+ void *id, SilcIdType id_type,
+ uint32 id_len,
SilcClientID *target,
uint32 target_len);
void silc_server_send_notify_signoff(SilcServer server,
}
static SilcBuffer
-silc_server_announce_encode_join(uint32 argc, ...)
+silc_server_announce_encode_notify(SilcNotifyType notify, uint32 argc, ...)
{
va_list ap;
va_start(ap, argc);
- return silc_notify_payload_encode(SILC_NOTIFY_TYPE_JOIN, argc, ap);
+ return silc_notify_payload_encode(notify, argc, ap);
}
/* Returns assembled packets for channel users of the `channel'. */
void silc_server_announce_get_channel_users(SilcServer server,
SilcChannelEntry channel,
- SilcBuffer *channel_users)
+ SilcBuffer *channel_users,
+ SilcBuffer *channel_users_modes)
{
SilcChannelClientEntry chl;
SilcBuffer chidp, clidp;
SilcBuffer tmp;
int len;
+ unsigned char mode[4];
SILC_LOG_DEBUG(("Start"));
silc_list_start(channel->user_list);
while ((chl = silc_list_get(channel->user_list)) != SILC_LIST_END) {
clidp = silc_id_payload_encode(chl->client->id, SILC_ID_CLIENT);
- tmp = silc_server_announce_encode_join(2, clidp->data, clidp->len,
- chidp->data, chidp->len);
+
+ /* JOIN Notify */
+ tmp = silc_server_announce_encode_notify(SILC_NOTIFY_TYPE_JOIN, 2,
+ clidp->data, clidp->len,
+ chidp->data, chidp->len);
len = tmp->len;
*channel_users =
silc_buffer_realloc(*channel_users,
silc_buffer_put(*channel_users, tmp->data, tmp->len);
silc_buffer_pull(*channel_users, len);
- silc_buffer_free(clidp);
silc_buffer_free(tmp);
+
+ /* CUMODE notify for mode change on the channel */
+ SILC_PUT32_MSB(chl->mode, mode);
+ tmp = silc_server_announce_encode_notify(SILC_NOTIFY_TYPE_CUMODE_CHANGE,
+ 3, clidp->data, clidp->len,
+ mode, 4,
+ clidp->data, clidp->len);
+ len = tmp->len;
+ *channel_users_modes =
+ silc_buffer_realloc(*channel_users_modes,
+ (*channel_users_modes ?
+ (*channel_users_modes)->truelen + len : len));
+ silc_buffer_pull_tail(*channel_users_modes,
+ ((*channel_users_modes)->end -
+ (*channel_users_modes)->data));
+
+ silc_buffer_put(*channel_users_modes, tmp->data, tmp->len);
+ silc_buffer_pull(*channel_users_modes, len);
+ silc_buffer_free(tmp);
+
+ silc_buffer_free(clidp);
}
silc_buffer_free(chidp);
}
void silc_server_announce_get_channels(SilcServer server,
SilcIDList id_list,
SilcBuffer *channels,
- SilcBuffer *channel_users)
+ SilcBuffer *channel_users,
+ SilcBuffer *channel_users_modes)
{
SilcIDCacheList list;
SilcIDCacheEntry id_cache;
silc_buffer_pull(*channels, len);
silc_server_announce_get_channel_users(server, channel,
- channel_users);
+ channel_users,
+ channel_users_modes);
silc_free(cid);
void silc_server_announce_channels(SilcServer server)
{
- SilcBuffer channels = NULL, channel_users = NULL;
+ SilcBuffer channels = NULL, channel_users = NULL, channel_users_modes = NULL;
SILC_LOG_DEBUG(("Announcing channels and channel users"));
/* Get channels and channel users in local list */
silc_server_announce_get_channels(server, server->local_list,
- &channels, &channel_users);
+ &channels, &channel_users,
+ &channel_users_modes);
/* Get channels and channel users in global list */
silc_server_announce_get_channels(server, server->global_list,
- &channels, &channel_users);
+ &channels, &channel_users,
+ &channel_users_modes);
if (channels) {
silc_buffer_push(channels, channels->data - channels->head);
silc_buffer_free(channel_users);
}
+
+ if (channel_users_modes) {
+ silc_buffer_push(channel_users_modes,
+ channel_users_modes->data - channel_users_modes->head);
+ SILC_LOG_HEXDUMP(("channel users modes"), channel_users_modes->data,
+ channel_users_modes->len);
+
+ /* Send the packet */
+ silc_server_packet_send(server, server->router->connection,
+ SILC_PACKET_NOTIFY, SILC_PACKET_FLAG_LIST,
+ channel_users_modes->data,
+ channel_users_modes->len,
+ FALSE);
+
+ silc_buffer_free(channel_users_modes);
+ }
}
/* Failure timeout callback. If this is called then we will immediately
void *hb_context);
void silc_server_announce_get_channel_users(SilcServer server,
SilcChannelEntry channel,
- SilcBuffer *channel_users);
+ SilcBuffer *channel_users,
+ SilcBuffer *channel_users_modes);
void silc_server_announce_get_channels(SilcServer server,
SilcIDList id_list,
SilcBuffer *channels,
- SilcBuffer *channel_users);
+ SilcBuffer *channel_users,
+ SilcBuffer *channel_users_modes);
void silc_server_announce_servers(SilcServer server);
void silc_server_announce_clients(SilcServer server);
void silc_server_announce_channels(SilcServer server);
{ "[Cipher]",
SILC_CONFIG_SERVER_SECTION_TYPE_CIPHER, 4 },
{ "[PKCS]",
- SILC_CONFIG_SERVER_SECTION_TYPE_PKCS, 2 },
+ SILC_CONFIG_SERVER_SECTION_TYPE_PKCS, 1 },
{ "[Hash]",
SILC_CONFIG_SERVER_SECTION_TYPE_HASH_FUNCTION, 4 },
{ "[hmac]",
break;
}
- /* Get key length */
- ret = silc_config_get_token(line, &tmp);
- if (ret < 0)
- break;
- if (ret == 0) {
- fprintf(stderr, "%s:%d: PKCS key length not defined\n",
- config->filename, pc->linenum);
- break;
- }
- config->pkcs->key_len = atoi(tmp);
- silc_free(tmp);
-
check = TRUE;
checkmask |= (1L << pc->section->type);
break;
while(alg) {
if (!alg->sim_name) {
- /* Crypto module is supposed to be built in. Nothing to be done
- here except to test that the cipher really is built in. */
- SilcCipher tmp = NULL;
-
- if (silc_cipher_alloc(alg->alg_name, &tmp) == FALSE) {
- SILC_LOG_ERROR(("Unsupported cipher `%s'", alg->alg_name));
+ int i;
+
+ for (i = 0; silc_default_ciphers[i].name; i++)
+ if (!strcmp(silc_default_ciphers[i].name, alg->alg_name)) {
+ silc_cipher_register(&silc_default_ciphers[i]);
+ break;
+ }
+
+ if (!silc_cipher_is_supported(alg->alg_name)) {
+ SILC_LOG_ERROR(("Unknown cipher `%s'", alg->alg_name));
silc_server_stop(server);
exit(1);
}
- silc_cipher_free(tmp);
-
#ifdef SILC_SIM
} else {
/* Load (try at least) the crypto SIM module */
}
/* Registers configured PKCS's. */
-/* XXX: This really doesn't do anything now since we have statically
- registered our PKCS's. This should be implemented when PKCS works
- as SIM's. This checks now only that the PKCS user requested is
- really out there. */
void silc_server_config_register_pkcs(SilcServerConfig config)
{
SilcServerConfigSectionAlg *alg = config->pkcs;
SilcServer server = (SilcServer)config->server;
- SilcPKCS tmp = NULL;
SILC_LOG_DEBUG(("Registering configured PKCS"));
while(alg) {
-
- if (silc_pkcs_alloc(alg->alg_name, &tmp) == FALSE) {
- SILC_LOG_ERROR(("Unsupported PKCS `%s'", alg->alg_name));
+ int i;
+
+ for (i = 0; silc_default_pkcs[i].name; i++)
+ if (!strcmp(silc_default_pkcs[i].name, alg->alg_name)) {
+ silc_pkcs_register(&silc_default_pkcs[i]);
+ break;
+ }
+
+ if (!silc_pkcs_is_supported(alg->alg_name)) {
+ SILC_LOG_ERROR(("Unknown PKCS `%s'", alg->alg_name));
silc_server_stop(server);
exit(1);
}
- silc_free(tmp);
alg = alg->next;
}
while(alg) {
if (!alg->sim_name) {
- /* Hash module is supposed to be built in. Nothing to be done
- here except to test that the hash function really is built in. */
- SilcHash tmp = NULL;
-
- if (silc_hash_alloc(alg->alg_name, &tmp) == FALSE) {
- SILC_LOG_ERROR(("Unsupported hash function `%s'", alg->alg_name));
+ int i;
+
+ for (i = 0; silc_default_hash[i].name; i++)
+ if (!strcmp(silc_default_hash[i].name, alg->alg_name)) {
+ silc_hash_register(&silc_default_hash[i]);
+ break;
+ }
+
+ if (!silc_hash_is_supported(alg->alg_name)) {
+ SILC_LOG_ERROR(("Unknown hash funtion `%s'", alg->alg_name));
silc_server_stop(server);
exit(1);
}
- silc_hash_free(tmp);
#ifdef SILC_SIM
} else {
SilcHmacObject hmac;
if (!silc_hash_is_supported(alg->sim_name)) {
- SILC_LOG_ERROR(("Unsupported hash function `%s'", alg->sim_name));
+ SILC_LOG_ERROR(("Unknown hash function `%s'", alg->sim_name));
silc_server_stop(server);
exit(1);
}
AC_DEFINE_UNQUOTED(SILC_SIZEOF_VOID_P, $ac_cv_sizeof_void_p)
# Function and library checking
-AC_CHECK_FUNCS(initscr)
-AC_CHECK_LIB(ncurses, initscr, LIBS="$LIBS -lncurses")
-AC_CHECK_FUNCS(gethostbyname)
-#AC_CHECK_LIB(nsl, gethostbyname, LIBS="$LIBS -lnsl -lresolv")
-AC_CHECK_FUNCS(socket)
-AC_CHECK_LIB(socket, socket, LIBS="$LIBS -lsocket")
+AC_CHECK_FUNC(initscr, ac_initscr_found=1, ac_initscr_found=0)
+if test x$ac_initscr_found = x0; then
+ AC_CHECK_LIB(ncurses, initscr, LIBS="$LIBS -lncurses")
+fi
+AC_CHECK_FUNC(gethostbyname, ac_gethostbyname_found=1,
+ac_gethostbyname_found=0)
+if test x$ac_gethostbyname_found = x0; then
+ AC_CHECK_LIB(nsl, gethostbyname, LIBS="$LIBS -lnsl")
+ AC_CHECK_FUNC(res_gethostbyname, ac_res_ghbn_found=1, ac_res_ghbn_found=0)
+ if test x$ac_res_ghbn_found = x0; then
+ AC_CHECK_LIB(resolv, res_gethostbyname, LIBS="$LIBS -lresolv")
+ fi
+fi
+AC_CHECK_FUNC(socket, ac_socket_found=1, ac_socket_found=0)
+if test x$ac_socket_found = x0; then
+ AC_CHECK_LIB(socket, socket, LIBS="$LIBS -lsocket")
+fi
AC_CHECK_FUNCS(gethostname gethostbyaddr getservbyname getservbyport)
AC_CHECK_FUNCS(select listen bind shutdown close connect)
AC_CHECK_FUNCS(fcntl setsockopt)
--- /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 25 April 2001
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-commands-00.txt 25 April 2001
+Expires: 25 October 2001
+
+.in 3
+
+.ce 2
+SILC Commands
+<draft-riikonen-silc-commands-00.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 Internet Draft [SILC1]. The
+SILC Commands are very important part of the SILC protocol. Usually
+the commands are used by SILC clients to manage the SILC session, but
+also SILC servers may use the commands. This memo specifies detailed
+command messages and command reply messages.
+
+
+
+
+
+
+
+
+.ti 0
+Table of Contents
+
+.nf
+1 Introduction .................................................. 2
+ 1.1 Requirements Terminology .................................. 2
+2 SILC Commands ................................................. 2
+ 2.1 SILC Commands Syntax ...................................... 2
+ 2.2 SILC Commands List ........................................ 4
+ 2.3 SILC Command Status Types ................................. 32
+ 2.3.1 SILC Command Status Payload ......................... 32
+ 2.3.2 SILC Command Status List ............................ 32
+3 Security Considerations ....................................... 37
+4 References .................................................... 37
+5 Author's Address .............................................. 39
+
+
+.ti 0
+1. Introduction
+
+This document describes the commands used in the Secure Internet Live
+Conferencing (SILC) protocol, specified in the Secure Internet Live
+Conferencing, Protocol Specification Internet Draft [SILC1]. This
+document specifies detailed command messages and command reply messages.
+
+Commands are very important part on SILC network especially for client
+which uses commands to operate on the SILC network. Commands are used
+to set nickname, join to channel, change modes and many other things.
+
+See the [SILC1] for the requirements and the restrictions for the usage
+of the SILC commands. The [SILC2] defines the command packet type and
+the Command Payload which is actually used to deliver the commands and
+command reply messages.
+
+
+.ti 0
+1.1 Requirements Terminology
+
+The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+MAY, and OPTIONAL, when they appear in this document, are to be
+interpreted as described in [RFC2119].
+
+
+.ti 0
+2 SILC Commands
+
+.ti 0
+2.1 SILC Commands Syntax
+
+This section briefly describes the syntax of the command notions
+in this document. Every field in command is separated from each
+other by whitespaces (` ') indicating that each field is independent
+argument and each argument MUST have own Command Argument Payload.
+The number of maximum arguments are defined with each command
+separately. The Command Argument Payload is described in [SILC2].
+
+Every command defines specific number for each argument. Currently,
+they are defined in ascending order; first argument has number one
+(1), second has number two (2) and so on. This number is set into the
+Argument Type field in the Command Argument Payload. This makes it
+possible to send the arguments in free order as the number MUST be
+used to identify the type of the argument. This makes is it also
+possible to have multiple optional arguments in commands and in
+command replies. The number of argument is marked in parentheses
+before the actual argument.
+
+
+
+.in 6
+Example: Arguments: (1) <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_TOO_MANY_TARGETS
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_NICK
+
+Every command reply also defines set of status message that it
+may return inside the <Status Payload>. All status messages
+are defined in the section 2.3 SILC Command Status Types.
+
+.in 3
+Every command that has some kind of ID as argument (for example
+<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.
+
+
+.ti 0
+2.2 SILC Commands List
+
+This section lists all SILC commands, however, it is expected that a
+implementation and especially client implementation has many more
+commands that has only local affect. These commands are official
+SILC commands that has both client and server sides and cannot be
+characterized as local commands.
+
+List of all defined commands in SILC follows.
+
+.in 0
+ 0 SILC_COMMAND_NONE
+
+ None. This is reserved command and MUST NOT be sent.
+
+
+ 1 SILC_COMMAND_WHOIS
+
+ Max Arguments: 3328
+ Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
+ (3) [<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.
+
+ 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. The server replies
+ in this case with only one reply message for all requested users.
+
+ To prevent miss-use of this command wildcards in the nickname
+ or in the server name are not permitted. It is not allowed
+ to request all users on some server. The WHOIS requests MUST
+ be based on specific nickname request.
+
+ The WHOIS request MUST be always sent to the router by server
+ so that all users are searched. However, the server still MUST
+ search its locally connected clients. The router MUST send
+ this command to the server which owns the requested client. That
+ server MUST reply to the command. Server MUST NOT send whois
+ replies to the client until it has received the reply from its
+ router.
+
+ Reply messages to the command:
+
+ Max Arguments: 8
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) <nickname>[@<server>] (4) <username@host>
+ (5) <real name> (6) [<Channel Payload
+ list>]
+ (7) [<user mode>] (8) [<idle time>]
+
+
+ This command may reply with several command reply messages to
+ form a list of results. In this case the status payload will
+ include STATUS_LIST_START status in the first reply and
+ STATUS_LIST_END in the last reply to indicate the end of the
+ list. If there are only one reply the status is set to normal
+ STATUS_OK.
+
+ The command replies include the Client ID of the nickname,
+ nickname and server name, user name and host name and user's real
+ name. Client SHOULD process these replies only after the last
+ reply has been received with the STATUS_LIST_END status. If the
+ <count> option were defined in the query there will be only
+ <count> many replies from the server.
+
+ The server MAY return the list of channel the client has joined.
+ In this case the list is list of Channel Payloads. The Mode Mask
+ in the Channel Payload (see [SILC2] and section 2.3.2.3 for the
+ Channel Payload) is the client's mode on the channel. The list
+ is encoded by adding the Channel Payloads one after the other.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_LIST_START
+ SILC_STATUS_LIST_END
+ SILC_STATUS_ERR_NO_SUCH_NICK
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+ SILC_STATUS_ERR_WILDCARDS
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
+ 2 SILC_COMMAND_WHOWAS
+
+ Max Arguments: 2
+ 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.
+
+ 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: 3328
+ Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
+ (3) [<Client ID>] (n) [...]
+
+ Identify. Identify command is almost analogous to WHOIS command,
+ except that it does not return as much information. Only relevant
+ information such as Client ID is returned. This is usually used
+ to get the Client ID of a client used in the communication with
+ the client.
+
+ 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.
+
+ 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 IDENTIFY command. In this case
+ the Client ID's are appended as normal arguments. The server
+ replies in this case with only one reply message for all requested
+ users.
+
+ To prevent miss-use of this 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 IDENTIFY requests MUST
+ be based on specific nickname request.
+
+ Implementations may not want to give interface access to this
+ command as it is hardly a command that would be used by an end user.
+ However, it must be implemented as it is used with private message
+ sending.
+
+ The IDENTIFY MUST be always sent to the router by server so that
+ all users are searched. However, server MUST still search its
+ locally connected clients.
+
+ Reply messages to the command:
+
+ Max Arguments: 4
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) [<nickname>[@<server>]] (4) [<username@host>]
+
+ 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 Client ID of the nickname and if more
+ information is available it MAY reply with nickname and user name
+ and host name. 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_CLIENT_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 spaces (` '), non-printable
+ characters, commas (`,') and any wildcard characters. Note that
+ nicknames in SILC are case-sensitive which must be taken into
+ account when searching clients by nickname.
+
+ When nickname is changed new Client ID is generated. Server MUST
+ distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
+ channels (if any) the client is joined on. Then it MUST send
+ SILC_PACKET_REPLACE_ID to its primary route to replace the old
+ Client ID with the new one.
+
+ Reply messages to the command:
+
+ Max Arguments: 2
+ Arguments: (1) <Status Payload> (2) <New ID Payload>
+
+ This command is replied always with New ID Payload that is
+ generated by the server every time user changes their nickname.
+ Client receiving this payload MUST start using the received
+ Client ID as its current valid Client ID. The New ID Payload
+ is described in [SILC2].
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_WILDCARDS
+ SILC_STATUS_ERR_NICKNAME_IN_USE
+ SILC_STATUS_ERR_BAD_NICKNAME
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
+ 5 SILC_COMMAND_LIST
+
+ Max Arguments: 1
+ Arguments: (1) [<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) [<adding client>] (4) [<removing client>]
+
+ This command is used to invite other clients to join to the
+ channel. The <Client ID> argument is the target client's ID that
+ is being invited. The <Channel ID> is the Channel ID of the
+ requested channel. The sender of this command MUST be on the
+ channel. The server MUST also send the notify type
+ SILC_NOTIFY_TYPE_INVITE to its primary router and then to the
+ client indicated by the <Client ID>.
+
+ The <adding client> and <removing client> can be used to add to
+ and remove from the invite list. The format of the <adding client>
+ and <removing client> is as follows:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
+
+ When adding to or removing from the invite list the server MUST
+ send the notify type SILC_NOTIFY_TYPE_INVITE to its primary router
+ and MUST NOT send it to the client which was added to the list.
+ The client which executes this command MUST have at least channel
+ operator privileges to be able to add to or remove from the invite
+ list. The wildcards MAY be used with this command. If adding or
+ removing more than one client then the lists are an comma (`,')
+ separated.
+
+ Note that the <Client ID> provided MUST be resolved into correct
+ nickname and host name and add to the invite list before sending
+ the notify packet.
+
+ When this command is given with only <Channel ID> argument then
+ the command merely returns the invite list of the channel. This
+ command MUST fail if the requested channel does not exist, the
+ requested <Client ID> is already on the channel or if the channel
+ is invite only channel and the caller of this command does not
+ have at least channel operator privileges.
+
+ Reply messages to the command:
+
+ Max Arguments: 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
+
+
+ 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: 2
+ Arguments: (1) <Client ID> (2) [<comment>]
+
+ This command is used by SILC operators to remove a client from
+ SILC network. The removing has temporary effects and client may
+ reconnect to SILC network. The <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.
+
+ When killing a client the router MUST first send notify type
+ SILC_NOTIFY_TYPE_KILLED to all channels the client has joined.
+ The packet MUST NOT be sent to the killed client on the channels.
+ Then, the router MUST send the same notify type to its primary
+ router. Finally, the router MUST send the same notify type
+ directly to the client which was killed.
+
+ Reply messages to the command:
+
+ Max Arguments: 1
+ Arguments: (1) <Status Payload>
+
+ This command replies only with Status Payload.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_WILDCARDS
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+ SILC_STATUS_ERR_NO_CLIENT_ID
+ SILC_STATUS_ERR_NO_ROUTER_PRIV
+
+
+ 10 SILC_COMMAND_INFO
+
+ Max Arguments: 2
+ Arguments: (1) [<server>] (2) [<Server ID>]
+
+ This command is used to fetch various information about a server.
+ If <server> argument is specified the command MUST be sent to
+ the requested server.
+
+ If the <Server ID> is specified the server information if fetched
+ by the provided Server ID.
+
+ Reply messages to the command:
+
+ Max Arguments: 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_CONNECT
+
+ Max Arguments: 2
+ Arguments: (1) <remote server/router> (2) [<port>]
+
+ This command is used by operators to force a server to try to
+ establish a new connection to remote server or router. The
+ Operator MUST specify the server/router to be connected by
+ setting <remote server> argument. The port is 32 bit MSB value.
+
+ Reply messages to the command:
+
+ Max Arguments: 1
+ Arguments: (1) <Status Payload>
+
+ This command replies only with Status Payload.
+
+
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_WILDCARDS
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NO_SERVER_PRIV
+ SILC_STATUS_ERR_NO_ROUTER_PRIV
+
+
+ 12 SILC_COMMAND_PING
+
+ Max Arguments: 1
+ Arguments: (1) <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 or certificate
+ authentication data (data signed with private key).
+
+ 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: 5
+ Arguments: (1) <channel> (2) <Client ID>
+ (3) [<passphrase>] (4) [<cipher>]
+ (5) [<hmac>]
+
+ Join to channel/create new channel. This command is used to
+ join to a channel. If the channel does not exist the channel is
+ created. If server is normal server this command MUST be 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 server MUST check whether the user is allowed to join to
+ the requested channel. Various modes set to the channel affect
+ the ability of the user to join the channel. These conditions
+ are:
+
+ o The user MUST be invited to the channel if the channel
+ is invite-only channel.
+
+ o The Client ID/nickname/username/host name MUST NOT match
+ any active bans.
+
+ o The correct passphrase MUST be provided if passphrase
+ is set to the channel.
+
+ o The user count limit, if set, MUST NOT be reached.
+
+ Reply messages to the command:
+
+ Max Arguments: 14
+ Arguments: (1) <Status Payload> (2) <channel>
+ (3) <Channel ID> (4) <Client ID>
+ (5) <channel mode mask> (6) <created>
+ (7) [<Channel Key Payload>] (8) [<ban list>]
+ (9) [<invite list>] (10) [<topic>]
+ (11) [<hmac>] (12) <list count>
+ (13) <Client ID list> (14) <client mode list>
+
+ This command replies with the channel name requested by the
+ client, channel ID of the channel and topic of the channel
+ if it exists. The <Client ID> is the Client ID which was joined
+ to the channel. It also replies with the channel mode mask
+ which tells all the modes set on the channel. If the
+ channel is created the mode mask is zero (0). If ban mask
+ and/or invite list is set they are sent as well.
+
+ The <list count>, <Client ID list> and <client mode list> are
+ the clients currently on the channel and their modes on the
+ channel. The <Client ID list> is formed by adding the ID Payloads
+ one after the other. The <client mode list> is formed by adding
+ 32 bit MSB first order values one after the other.
+
+ Client receives the channel key in the reply message as well
+ inside <Channel Key Payload>.
+
+ Status messages:
+
+ 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:
+
+ 0x0000 SILC_UMODE_NONE
+
+ No specific mode for client. This is the initial
+ setting when new client is created. The client is
+ normal client now.
+
+
+ 0x0001 SILC_UMODE_SERVER_OPERATOR
+
+ Marks the user as server operator. Client MUST NOT
+ set this mode itself. Server sets this mode to the
+ client when client attains the server operator
+ privileges by SILC_COMMAND_OPER command. Client
+ MAY unset the mode itself.
+
+
+ 0x0002 SILC_UMODE_ROUTER_OPERATOR
+
+ Marks the user as router (SILC) operator. Client
+ MUST NOT this mode itself. Router sets this mode to
+ the client when client attains the router operator
+ privileges by SILC_COMMAND_SILCOPER command. Client
+ MAY unset the mode itself.
+
+
+ 0x0004 SILC_UMODE_GONE
+
+ Marks that the user is not currently present in the
+ SILC Network. Client MAY set and unset this mode.
+
+ Reply messages to the command:
+
+ Max Arguments: 2
+ Arguments: (1) <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: 7
+ Arguments: (1) <Channel ID> (2) <channel mode mask>
+ (3) [<user limit>] (4) [<passphrase>]
+ (5) [<cipher>] (6) [<hmac>]
+ (7) [<auth payload>]
+
+ 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 poses sufficient privileges to be able to
+ change the mode.
+
+ When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
+ type MUST be distributed to the channel.
+
+ The following channel modes are defined:
+
+ 0x0000 SILC_CMODE_NONE
+
+ No specific mode on channel. This is the default when
+ channel is created. This means that channel is just plain
+ normal channel.
+
+
+ 0x0001 SILC_CMODE_PRIVATE
+
+ Channel is private channel. Private channels are shown
+ in the channel list listed with SILC_COMMAND_LIST command
+ with indication that the channel is private. Also,
+ client on private channel will no be detected to be on
+ the channel as the channel is not shown in the client's
+ currently joined channel list. Channel founder and
+ channel operator MAY set/unset this mode.
+
+ Typical implementation would use [+|-]p on user interface
+ to set/unset this mode.
+
+
+ 0x0002 SILC_CMODE_SECRET
+
+ Channel is secret channel. Secret channels are not shown
+ in the list listed with SILC_COMMAND_LIST command. Secret
+ channels can be considered to be invisible channels.
+ Channel founder and channel operator MAY set/unset this
+ mode.
+
+ Typical implementation would use [+|-]s on user interface
+ to set/unset this mode.
+
+
+ 0x0004 SILC_CMODE_PRIVKEY
+
+ Channel uses private channel key to protect the traffic
+ on the channel. When this mode is set the client will be
+ responsible to set the key it wants to use to encrypt and
+ decrypt the traffic on channel. Server generated channel
+ keys are not used at all. This mode provides additional
+ security as clients on channel may agree to use private
+ channel key that even servers do not know. Naturally,
+ this requires that every client on the channel knows
+ the key before hand (it is considered to be pre-shared-
+ key). The key material is RECOMMENDED to be processed
+ as stated in the [SILC3] in the section Processing the
+ Key Material.
+
+ As it is local setting it is possible to have several
+ private channel keys on one channel. In this case several
+ clients can talk on same channel but only those clients
+ that share the key with the message sender will be able
+ to hear the talking. Client SHOULD NOT display those
+ message for the end user that it is not able to decrypt
+ when this mode is set.
+
+ Only channel founder MAY set/unset this mode. If this
+ mode is unset the server will distribute new channel
+ key to all clients on the channel which will be used
+ thereafter.
+
+ Typical implementation would use [+|-]k on user interface
+ to set/unset this mode.
+
+
+ 0x0008 SILC_CMODE_INVITE
+
+ Channel is invite only channel. Client may join to this
+ channel only if it is invited to the channel. Channel
+ founder and channel operator MAY set/unset this mode.
+
+ Typical implementation would use [+|-]i on user interface
+ to set/unset this mode.
+
+
+ 0x0010 SILC_CMODE_TOPIC
+
+ The topic of the channel may only be set by client that
+ is channel founder or channel operator. Normal clients
+ on channel will not be able to set topic when this mode
+ is set. Channel founder and channel operator MAY set/
+ unset this mode.
+
+ Typical implementation would use [+|-]t on user interface
+ to set/unset this mode.
+
+
+ 0x0020 SILC_CMODE_ULIMIT
+
+ User limit has been set to the channel. New clients
+ may not join to the channel when the limit set is
+ reached. Channel founder and channel operator MAY set/
+ unset the limit. The <user limit> argument is the
+ number of limited users.
+
+ Typical implementation would use [+|-]l on user interface
+ to set/unset this mode.
+
+
+ 0x0040 SILC_CMODE_PASSPHRASE
+
+ Passphrase has been set to the channel. Client may
+ join to the channel only if it is able to provide the
+ correct passphrase. Setting passphrases to channel
+ is entirely safe as all commands are protected in the
+ SILC network. Only channel founder MAY set/unset
+ the passphrase. The <passphrase> argument is the
+ set passphrase.
+
+ Typical implementation would use [+|-]a on user interface
+ to set/unset this mode.
+
+
+ 0x0080 SILC_CMODE_CIPHER
+
+ Sets specific cipher to be used to protect channel
+ traffic. The <cipher> argument is the requested cipher.
+ When set or unset the server must re-generate new
+ channel key. Only channel founder MAY set the cipher of
+ the channel. When unset the new key is generated using
+ default cipher for the channel.
+
+ Typical implementation would use [+|-]c on user interface
+ to set/unset this mode.
+
+
+ 0x0100 SILC_CMODE_HMAC
+
+ Sets specific hmac to be used to compute the MACs of the
+ channel message. The <hmac> argument is the requested hmac.
+ Only channel founder may set the hmac of the channel.
+
+ Typical implementation would use [+|-]h on user interface
+ to set/unset this mode.
+
+
+ 0x0200 SILC_CMODE_FOUNDER_AUTH
+
+ Channel founder may set this mode to be able to regain
+ channel founder rights even if the client leaves the
+ channel. The <auth payload> is the Authentication Payload
+ consisting of the authentication method and authentication
+ data to be used in the authentication. The server MUST
+ NOT accept NONE authentication method. Also, if the
+ method is public key authentication the server MUST NOT
+ save the authentication data from the payload as the
+ data is different on all authentications. In this case the
+ server only saves the authentication method.
+
+ Note that this mode is effective only in the current server.
+ The client MUST connect to the same server later to be able
+ to regain the channel founder rights. The server MUST save
+ the public key of the channel founder and use that to identify
+ the client which is claiming the channel founder rights.
+ The rights may be claimed by the SILC_CUMODE_FOUNDER
+ channel user mode using SILC_COMMAND_CUMODE command. The
+ set authentication data remains valid as long as the channel
+ exists or until the founder unsets this mode.
+
+ Typical implementation would use [+|-]f on user interface
+ to set/unset this mode.
+
+ To make the mode system work, client MUST keep the channel mode
+ mask locally so that the mode setting and unsetting would work
+ without problems. The client receives the initial channel mode
+ mask when it joins to the channel. When the mode changes on
+ channel the server MUST distribute the changed channel mode mask
+ to all clients on the channel by sending the notify type
+ SILC_NOTIFY_TYPE_CMODE_CHANGE. The notify type MUST also be sent
+ to the server's primary router.
+
+ Reply messages to the command:
+
+ Max Arguments: 2
+ Arguments: (1) <Status Payload> (2) <channel mode mask>
+
+ This command replies with the changed channel mode mask that
+ client MUST keep locally.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_BAD_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ SILC_STATUS_ERR_UNKNOWN_MODE
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+
+
+ 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 poses sufficient privileges to be able to
+ change the mode.
+
+ When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
+ type is distributed to the channel.
+
+ The following channel modes are defined:
+
+ 0x0000 SILC_CUMODE_NONE
+
+ No specific mode. This is the normal situation for client.
+ Also, this is the mode set when removing all modes from
+ the target client.
+
+
+ 0x0001 SILC_CUMODE_FOUNDER
+
+ The client is channel founder of the channel. Usually this
+ mode is set only by the server when the channel was created.
+ However, if the SILC_CMODE_FOUNDER_AUTH channel mode has
+ been set, the client can claim channel founder privileges
+ by providing the <auth payload> that the server will use
+ to authenticate the client. The client MAY remove this
+ mode at any time.
+
+
+ 0x0002 SILC_CUMODE_OPERATOR
+
+ Sets channel operator privileges on the channel for a
+ client on the channel. Channel founder and channel operator
+ MAY set/unset this mode.
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <channel user mode mask>
+ (3) <Client ID>
+
+ This command replies with the changed channel user mode mask that
+ client MUST keep locally. The <Client ID> is the target client.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_BAD_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ SILC_STATUS_ERR_UNKNOWN_MODE
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+ 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 channel key MUST also be re-generated after kicking, unless
+ the SILC_CMODE_PRIVKEY mode is set.
+
+ Reply messages to the command:
+
+ Max Arguments: 1
+ Arguments: (1) <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_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) [<adding client>]
+ (3) [<removing client>]
+
+ This command is used to manage the ban list of the channel
+ indicated by the <Channel ID>. A client that is banned from
+ channel is no longer able to join the channel. The client which
+ is executing this command MUST have at least channel operator
+ privileges on the channel.
+
+ The <adding client> and <removing client> are used to add to and
+ remove from the ban list. The format of the <adding client> and
+ the <removing client> is of following format:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
+
+ The server MUST send the notify type SILC_NOTIFY_TYPE_BAN to its
+ primary router after adding to or removing from the ban list.
+ The wildcards MAY be used with this command. If adding or removing
+ from than one clients then the lists are an comma (`,') separated.
+
+ 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
+
+
+ 21 SILC_COMMAND_CLOSE
+
+ Max Arguments: 2
+ Arguments: (1) <remote server/router> (2) [<port>]
+
+ This command is used only by operator to close connection to a
+ remote site.
+
+ 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_NO_SUCH_SERVER
+ SILC_STATUS_ERR_NO_SERVER_PRIV
+ SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+
+
+ 22 SILC_COMMAND_SHUTDOWN
+
+ Max Arguments: 0
+ Arguments: None
+
+ This command is used only by operator to shutdown the server.
+ All connections to the server will be closed and the server is
+ shutdown.
+
+ Reply messages to the command:
+
+ Max Arguments: 1
+ Arguments: (1) <Status Payload>
+
+ This command replies only with Status Payload.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NO_SERVER_PRIV
+
+
+ 23 SILC_COMMAND_SILCOPER
+
+ Max Arguments: 2
+ Arguments: (1) <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).
+
+ 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: 1
+ Arguments: (1) <Status Payload>
+
+ This command replies only with Status Payload.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_BAD_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+
+
+ 25 SILC_COMMAND_USERS
+
+ Max Arguments: 1
+ Arguments: (1) <Channel ID>
+
+ This command is used to list user names currently on the requested
+ channel; argument <Channel ID>. The server MUST resolve the
+ user names and send a comma (`,') separated list of user names
+ on the channel. Server or router MAY resolve the names by sending
+ SILC_COMMAND_WHOIS or SILC_COMMAND_IDENTIFY commands.
+
+ If the requested channel is a private or secret channel, this
+ command MUST NOT send the list of users, as private and secret
+ channels cannot be seen by outside. In this case the returned
+ name list MAY include a indication that the server could not
+ resolve the names of the users on the channel. Also, in this case
+ Client ID's or client modes are not sent either.
+
+ Reply messages to the command:
+
+ Max Arguments: 5
+ Arguments: (1) <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 - 199
+
+ Currently undefined commands.
+
+
+ 200 - 254
+
+ These commands are reserved for private use and will not be defined
+ in this document.
+
+
+ 255 SILC_COMMAND_MAX
+
+ Reserved command. This must not be sent.
+.in 3
+
+
+.ti 0
+2.3 SILC Command Status Types
+
+.ti 0
+2.3.1 SILC Command Status Payload
+
+Command Status Payload is sent in command reply messages to indicate
+the status of the command. The payload is one of argument in the
+command thus this is the data area in Command Argument Payload described
+in [SILC2]. The payload is only 2 bytes of length. The following diagram
+represents the Command Status Payload (field is always in MSB order).
+
+
+.in 21
+.nf
+ 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Status Message |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 6: SILC Command Status Payload
+
+
+.in 6
+o Status Message (2 bytes) - Indicates the status message.
+ All Status messages are described in the next section.
+.in 3
+
+
+.ti 0
+2.3.2 SILC Command Status List
+
+Command Status messages are returned in the command reply messages
+to indicate whether the command were executed without errors. If error
+has occurred the status indicates which error occurred. Status payload
+only sends numeric reply about the status. Receiver of the payload must
+convert the numeric values into human readable error messages. The
+list of status messages below has an example human readable error
+messages that client may display for the user.
+
+List of all defined command status messages following.
+
+.in 0
+ Generic status messages:
+
+ 0 SILC_STATUS_OK
+
+ Ok status. Everything went Ok. The status payload maybe
+ safely ignored in this case.
+
+ 1 SILC_STATUS_LIST_START
+
+ Start of the list. There will be several command replies and
+ this reply is the start of the list.
+
+ 2 SILC_STATUS_LIST_ITEM
+
+ Item in the list. This is one of the item in the list but not the
+ first or last one.
+
+ 3 SILC_STATUS_LIST_END
+
+ End of the list. There were several command replies and this
+ reply is the last of the list. There won't be other replies
+ belonging to this list after this one.
+
+ 4 - 9
+
+ Currently undefined and has been reserved for the future.
+
+
+ Error status message:
+
+
+
+ 10 SILC_STATUS_ERR_NO_SUCH_NICK
+
+ "No such nickname". Requested nickname does not exist.
+
+ 11 SILC_STATUS_ERR_NO_SUCH_CHANNEL
+
+ "No such channel". Requested channel name does not exist.
+
+ 12 SILC_STATUS_ERR_NO_SUCH_SERVER
+
+ "No such server". Requested server name does not exist.
+
+ 13 SILC_STATUS_ERR_TOO_MANY_TARGETS
+
+ "Duplicate recipients. No message delivered". Message were
+ tried to be sent to recipient which has several occurrences in
+ the recipient list.
+
+ 14 SILC_STATUS_ERR_NO_RECIPIENT
+
+ "No recipient given". Command required recipient which was
+ not provided.
+
+ 15 SILC_STATUS_ERR_UNKNOWN_COMMAND
+
+ "Unknown command". Command sent to server is unknown by the
+ server.
+
+ 16 SILC_STATUS_ERR_WILDCARDS
+
+ "Wildcards cannot be used". Wildcards were provided but they
+ weren't permitted.
+
+ 17 SILC_STATUS_ERR_NO_CLIENT_ID
+
+ "No Client ID given". Client ID were expected as command
+ parameter but were not found.
+
+ 18 SILC_STATUS_ERR_NO_CHANNEL_ID
+
+ "No Channel ID given". Channel ID were expected as command
+ parameter but were not found.
+
+ 19 SILC_STATUS_ERR_NO_SERVER_ID
+
+ "No Serve ID given". Server ID were expected as command
+ parameter but were not found.
+
+ 20 SILC_STATUS_ERR_BAD_CLIENT_ID
+
+ "Bad Client ID". Client ID provided were erroneous.
+
+ 21 SILC_STATUS_ERR_BAD_CHANNEL_ID
+
+ "Bad Channel ID". Channel ID provided were erroneous.
+
+ 22 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+
+ "No such Client ID". Client ID provided does not exist.
+
+ 23 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+
+ "No such Channel ID". Channel ID provided does not exist.
+
+ 24 SILC_STATUS_ERR_NICKNAME_IN_USE
+
+ "Nickname already exists". Nickname created could not be
+ registered because number of same nicknames were already set to
+ maximum. This is not expected to happen in real life but is
+ possible to occur.
+
+ 25 SILC_STATUS_ERR_NOT_ON_CHANNEL
+
+ "You are not on that channel". The command were specified for
+ channel user is not currently on.
+
+ 26 SILC_STATUS_ERR_USER_NOT_ON_CHANNEL
+
+ "They are not on channel". The requested target client is not
+ on requested channel.
+
+ 27 SILC_STATUS_ERR_USER_ON_CHANNEL
+
+ "User already on channel". User were invited on channel they
+ already are on.
+
+ 28 SILC_STATUS_ERR_NOT_REGISTERED
+
+ "You have not registered". User executed command that requires
+ the client to be registered on the server before it may be
+ executed.
+
+ 29 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+
+ "Not enough parameters". Command requires more parameters
+ than provided.
+
+ 30 SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+ "Too many parameters". Too many parameters were provided
+ for the command.
+
+ 31 SILC_STATUS_ERR_PERM_DENIED
+
+ "Permission denied". Generic permission denied error status
+ to indicate disallowed access.
+
+ 32 SILC_STATUS_ERR_BANNED_FROM_SERVER
+
+ "You are banned from this server". The client tried to register
+ on server that has explicitly denied this host to connect.
+
+ 33 SILC_STATUS_ERR_BAD_PASSWORD
+
+ "Cannot join channel. Incorrect password". Password provided for
+ channel were not accepted.
+
+ 34 SILC_STATUS_ERR_CHANNEL_IS_FULL
+
+ "Cannot join channel. Channel is full". The channel is full
+ and client cannot be joined to it.
+
+ 35 SILC_STATUS_ERR_NOT_INVITED
+
+ "Cannot join channel. You have not been invited". The channel
+ is invite only channel and client has not been invited.
+
+ 36 SILC_STATUS_ERR_BANNED_FROM_CHANNEL
+
+ "Cannot join channel. You have been banned". The client has
+ been banned from the channel.
+
+ 37 SILC_STATUS_ERR_UNKNOWN_MODE
+
+ "Unknown mode". Mode provided by the client were unknown to
+ the server.
+
+ 38 SILC_STATUS_ERR_NOT_YOU
+
+ "Cannot change mode for other users". User tried to change
+ someone else's mode.
+
+ 39 SILC_STATUS_ERR_NO_CHANNEL_PRIV
+
+ "Permission denied. You are not channel operator". Command may
+ be executed only by channel operator.
+
+ 40 SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+
+ "Permission denied. You are not channel founder". Command may
+ be executed only by channel operator.
+
+ 41 SILC_STATUS_ERR_NO_SERVER_PRIV
+
+ "Permission denied. You are not server operator". Command may
+ be executed only by server operator.
+
+ 42 SILC_STATUS_ERR_NO_ROUTER_PRIV
+
+ "Permission denied. You are not SILC operator". Command may be
+ executed only by router (SILC) operator.
+
+ 43 SILC_STATUS_ERR_BAD_NICKNAME
+
+ "Bad nickname". Nickname requested contained illegal characters
+ or were malformed.
+
+ 44 SILC_STATUS_ERR_BAD_CHANNEL
+
+ "Bad channel name". Channel requested contained illegal characters
+ or were malformed.
+
+ 45 SILC_STATUS_ERR_AUTH_FAILED
+
+ "Authentication failed". The authentication data sent as
+ argument were wrong and thus authentication failed.
+
+ 46 SILC_STATUS_ERR_UNKOWN_ALGORITHM
+
+ "The algorithm was not supported." The server does not support the
+ requested algorithm.
+
+ 47 SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+
+ "No such Server ID". Server ID provided does not exist.
+
+.in 3
+
+
+.ti 0
+3 Security Considerations
+
+Security is central to the design of this protocol, and these security
+considerations permeate the specification. Common security considerations
+such as keeping private keys truly private and using adequate lengths for
+symmetric and asymmetric keys must be followed in order to maintain the
+security of this protocol.
+
+
+.ti 0
+4 References
+
+[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
+ Protocol Specification", Internet Draft, April 2001.
+
+[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ April 2001.
+
+[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
+ Protocols", Internet Draft, April 2001.
+
+[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+[Schneier] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996.
+
+[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
+ CRC Press 1997.
+
+[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+[ISAKMP] Maughan D., et al, "Internet Security Association and
+ Key Management Protocol (ISAKMP)", RFC 2408, November
+ 1998.
+
+[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
+ Authentication", RFC 2104, February 1997.
+
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+.ti 0
+5 Author's Address
+
+.nf
+Pekka Riikonen
+Kasarmikatu 11 A4
+70110 Kuopio
+Finland
+
+EMail: priikone@poseidon.pspt.fi
+
+This Internet-Draft expires 25 October 2001
--- /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 25 April 2001
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-ke-auth-02.txt 25 April 2001
+Expires: 25 October 2001
+
+.in 3
+
+.ce 2
+SILC Key Exchange and Authentication Protocols
+<draft-riikonen-silc-ke-auth-02.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 two protocols used in the Secure Internet Live
+Conferencing (SILC) protocol, specified in the Secure Internet Live
+Conferencing, Protocol Specification internet-draft [SILC1]. The
+SILC Key Exchange (SKE) protocol provides secure key exchange between
+two parties resulting into shared secret key material. The protocol
+is based on Diffie-Hellman key exchange algorithm and its functionality
+is derived from several key exchange protocols. SKE uses best parts
+of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
+and the OAKLEY Key Determination protocol [OAKLEY].
+
+The SILC Connection Authentication protocol provides user level
+authentication used when creating connections in SILC network. The
+protocol is transparent to the authentication data which means that it
+can be used to authenticate the user with, for example, passphrase
+(pre-shared-secret) or public key (and certificate).
+
+
+
+.ti 0
+Table of Contents
+
+.nf
+1 Introduction .................................................. 2
+ 1.1 Requirements Terminology .................................. 3
+2 SILC Key Exchange Protocol .................................... 3
+ 2.1 Key Exchange Payloads ..................................... 4
+ 2.1.1 Key Exchange Start Payload .......................... 4
+ 2.1.2 Key Exchange Payload ................................ 8
+ 2.2 Key Exchange Procedure .................................... 10
+ 2.3 Processing the Key Material ............................... 12
+ 2.4 SILC Key Exchange Groups .................................. 13
+ 2.4.1 diffie-hellman-group1 ............................... 14
+ 2.4.2 diffie-hellman-group2 ............................... 14
+ 2.5 Key Exchange Status Types ................................. 15
+3 SILC Connection Authentication Protocol ....................... 16
+ 3.1 Connection Auth Payload ................................... 17
+ 3.2 Connection Authentication Types ........................... 18
+ 3.2.1 Passphrase Authentication ........................... 18
+ 3.2.2 Public Key Authentication ........................... 19
+ 3.3 Connection Authentication Status Types .................... 19
+4 Security Considerations ....................................... 20
+5 References .................................................... 20
+6 Author's Address .............................................. 21
+
+
+.ti 0
+List of Figures
+
+.nf
+Figure 1: Key Exchange Start Payload
+Figure 2: Key Exchange Payload
+Figure 3: Connection Auth Payload
+
+
+.ti 0
+1 Introduction
+
+This memo describes two protocols used in the Secure Internet Live
+Conferencing (SILC) protocol specified in the Secure Internet Live
+Conferencing, Protocol Specification Internet-Draft [SILC1]. The
+SILC Key Exchange (SKE) protocol provides secure key exchange between
+two parties resulting into shared secret key material. The protocol
+is based on Diffie-Hellman key exchange algorithm and its functionality
+is derived from several key exchange protocols. SKE uses best parts
+of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
+and the OAKLEY Key Determination protocol.
+
+The SILC Connection Authentication protocol provides user level
+authentication used when creating connections in SILC network. The
+protocol is transparent to the authentication data which means that it
+can be used to authenticate the user with, for example, pass phrase
+(pre-shared- secret) or public key (and certificate).
+
+The basis of secure SILC session requires strong and secure key exchange
+protocol and authentication. The authentication protocol is entirely
+secured and no authentication data is ever sent in the network without
+encrypting and authenticating it first. Thus, authentication protocol
+may be used only after the key exchange protocol has been successfully
+completed.
+
+This document refers constantly to other SILC protocol specification
+Internet Drafts that are a must read for those who wants to understand
+the function of these protocols. The most important references are
+the Secure Internet Live Conferencing, Protocol Specification [SILC1]
+and the SILC Packet Protocol [SILC2] Internet Drafts.
+
+The protocol is intended to be used with the SILC protocol thus it
+does not define own framework that could be used. The framework is
+provided by the SILC protocol.
+
+
+.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 Key Exchange Protocol
+
+SILC Key Exchange Protocol (SKE) is used to exchange shared secret
+between connecting entities. The result of this protocol is a key
+material used to secure the communication channel. The protocol uses
+Diffie-Hellman key exchange algorithm and its functionality is derived
+from several key exchange protocols. SKE uses best parts of the SSH2
+Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY
+Key Determination protocol. The protocol does not claim any conformance
+to any of these protocols, they were merely used as a reference when
+designing this protocol.
+
+The purpose of SILC Key Exchange protocol is to create session keys to
+be used in current SILC session. The keys are valid only for some period
+of time (usually an hour) or at most until the session ends. These keys
+are used to protect packets like commands, command replies and other
+communication between two entities. If connection is server to router
+connection, the keys are used to protect all traffic between those
+servers. In client connections usually all the packets are protected
+with this key except channel messages; channels has their own keys and
+they are not exchanged with this protocol.
+
+The Diffie-Hellman implementation used in the SILC SHOULD be compliant
+to the PKCS #3.
+
+
+.ti 0
+2.1 Key Exchange Payloads
+
+During the key exchange procedure public data is sent between initiator
+and responder. This data is later used in the key exchange procedure.
+There are several payloads used in the key exchange. As for all SILC
+packets, SILC Packet Header, described in [SILC2], is at the start of
+all packets. The same is done with these payloads as well. All the
+fields in the payloads are always in MSB (most significant byte first)
+order. Following descriptions of these payloads.
+
+
+.ti 0
+2.1.1 Key Exchange Start Payload
+
+The key exchange between two entities MUST be started by sending the
+SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
+Initiator sends the Key Exchange Start Payload to the responder filled
+with all security properties it supports. The responder then checks
+whether it supports the security properties.
+
+It then sends a Key Exchange Start Payload to the initiator filled with
+security properties it selected from the original payload. The payload
+sent by responder MUST include only one chosen property per list.
+
+The Key Exchange Start Payload is used to tell connecting entities what
+security properties and algorithms should be used in the communication.
+The Key Exchange Start Payload is sent only once per session. Even if
+the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
+Payload is not re-sent. When PFS is desired the Key Exchange Payloads
+are sent to negotiate new key material. The procedure is equivalent to
+the very first negotiation except that the Key Exchange Start Payload
+is not sent.
+
+As this payload is used only with the very first key exchange the payload
+is never encrypted, as there are no keys to encrypt it with.
+
+A cookie is also sent in this payload. A cookie is used to randomize the
+payload so that none of the key exchange parties can determine this
+payload before the key exchange procedure starts. The cookie MUST be
+returned to the original sender by the responder.
+
+Following diagram represents the Key Exchange Start Payload. The lists
+mentioned below are always comma (`,') separated and the list MUST
+not include spaces (` ').
+
+
+.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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| RESERVED | Flags | Payload Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
++ +
+| |
++ Cookie +
+| |
++ +
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Version String Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Version String ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Key Exchange Grp Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Key Exchange Groups ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| PKCS Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ PKCS Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Encryption Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Encryption Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Hash Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Hash Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| HMAC Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ HMACs ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Compression Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Compression Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 1: Key Exchange Start Payload
+
+
+
+.in 6
+o RESERVED (1 byte) - Reserved field. Sender fills this with
+ zero (0) value.
+
+o Flags (1 byte) - Indicates flags to be used in the key
+ exchange. Several flags can be set at once by ORing the
+ flags together. The following flags are reserved for this
+ field:
+
+ No flags 0x00
+
+ In this case the field is ignored.
+
+ No Reply 0x01
+
+ If set the receiver of the payload does not reply to
+ the packet.
+
+ PFS 0x02
+
+ Perfect Forward Secrecy (PFS) to be used in the
+ key exchange protocol. If not set, re-keying
+ is performed using the old key. See the [SILC1]
+ for more information on this issue. When PFS is
+ used, re-keying and creating new keys for any
+ particular purpose MUST cause new key exchange.
+ In this key exchange only the Key Exchange Payload
+ is sent and the Key Exchange Start Payload MUST
+ NOT be sent. When doing PFS the Key Exchange
+ Payloads are encrypted with the old keys. With
+ the PFS, the Mutual Authentication flag MUST be
+ ignored.
+
+ Mutual Authentication 0x04
+
+ Both of the parties will perform authentication
+ by providing signed data for the other party to
+ verify. By default, only responder will provide
+ the signature data. If this is set then the
+ initiator must also provide it. Initiator MAY
+ set this but also responder MAY set this even if
+ initiator did not set it.
+
+ Rest of the flags are reserved for the future and
+ MUST NOT be set.
+
+o Payload Length (2 bytes) - Length of the entire Key Exchange
+ Start payload, not including any other field.
+
+o Cookie (16 bytes) - Cookie that randomize this payload so
+ that each of the party cannot determine the payload before
+ hand.
+
+o Version String Length (2 bytes) - The length of the Version
+ String field, not including any other field.
+
+o Version String (variable length) - Indicates the version of
+ the sender of this payload. Initiator sets this when sending
+ the payload and responder sets this when it replies by sending
+ this payload. See [SILC1] for definition of the version
+ string format.
+
+o Key Exchange Grp Length (2 bytes) - The length of the
+ key exchange group list, not including any other field.
+
+o Key Exchange Group (variable length) - The list of
+ key exchange groups. See the section 2.4 SILC Key Exchange
+ Groups for definitions of these groups.
+
+o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
+ list, not including any other field.
+
+o PKCS Algorithms (variable length) - The list of PKCS
+ algorithms.
+
+o Encryption Alg Length (2 bytes) - The length of the encryption
+ algorithms list, not including any other field.
+
+o Encryption Algorithms (variable length) - The list of
+ encryption algorithms.
+
+o Hash Alg Length (2 bytes) - The length of the Hash algorithm
+ list, not including any other field.
+
+o Hash Algorithms (variable length) - The list of Hash
+ algorithms. The hash algorithms are mainly used in the
+ SKE protocol.
+
+o HMAC Length (2 bytes) - The length of the HMAC list, not
+ including any other field.
+
+o HMACs (variable length) - The list of HMACs. The HMAC's
+ are used to compute the Message Authentication Codes (MAC)
+ of the SILC packets.
+
+o Compression Alg Length (2 bytes) - The length of the
+ compression algorithms list, not including any other field.
+
+o Compression Algorithms (variable length) - The list of
+ compression algorithms.
+.in 3
+
+
+.ti 0
+2.1.2 Key Exchange Payload
+
+Key Exchange payload is used to deliver the public key (or certificate),
+the computed Diffie-Hellman public value and possibly signature data
+from one party to the other. When initiator is using this payload
+and the Mutual Authentication flag is not set then the initiator MUST
+NOT provide the signature data. If the flag is set then the initiator
+MUST provide the signature data so that the responder can verify it.
+
+The Mutual Authentication flag is usually used only if a separate
+authentication protocol will not be executed for the initiator of the
+protocol. This is case for example when the SKE is performed between
+two SILC clients. In normal case, where client is connecting to the
+server, or server is connecting to the router the Mutual Authentication
+flag is not necessary.
+
+When performing re-key with PFS selected this is the only payload that
+is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
+be sent at all. However, this payload does not have all the fields
+present. In the re-key with PFS the public key and a possible signature
+data SHOULD NOT be present. If they are present they MUST be ignored.
+The only field that is present is the Public Data that is used to create
+the new key material. In the re-key the Mutual Authentication flag MUST
+also be ignored.
+
+This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
+SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
+SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
+
+The following diagram represent the Key Exchange Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Key Length | Public Key Type |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Public Key of the party (or certificate) ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Public Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Signature Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Signature Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 2: Key Exchange 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. Following types are defined:
+
+ 1 SILC style public key (mandatory)
+ 2 SSH2 style public key (optional)
+ 3 X.509 Version 3 certificate (optional)
+ 4 OpenPGP certificate (optional)
+ 5 SPKI certificate (optional)
+
+ The only required type to support is type number 1. See
+ [SILC1] for the SILC public key specification. See
+ SSH public key specification in [SSH-TRANS]. See X.509v3
+ certificate specification in [PKIX-Part1]. See OpenPGP
+ certificate specification in [PGP]. See SPKI certificate
+ specification in [SPKI]. If this field includes zero (0)
+ or unsupported type number the protocol MUST be aborted
+ sending SILC_PACKET_FAILURE message and the connection SHOULD
+ be closed immediately.
+
+o Public Key (or certificate) (variable length) - The
+ public key or certificate.
+
+o Public Data Length (2 bytes) - The length of the Public Data
+ field, not including any other field.
+
+o Public Data (variable length) - The public data to be
+ sent to the receiver. See section 2.2 Key Exchange
+ Procedure for detailed description how this field is
+ computed. This value is binary encoded.
+
+o Signature Length (2 bytes) - The length of the signature,
+ not including any other field.
+
+o Signature Data (variable length) - The signature signed
+ by the sender. The receiver of this signature MUST
+ verify it. The verification is done using the sender's
+ public key. See section 2.2 Key Exchange Procedure for
+ detailed description how to produce the signature. If
+ the Mutual Authentication flag is not set then initiator
+ MUST NOT provide this field and the Signature Length field
+ MUST be set to zero (0) value. If the flag is set then
+ also the initiator MUST provide this field. The responder
+ MUST always provide this field.
+.in 3
+
+
+.ti 0
+2.2 Key Exchange Procedure
+
+The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
+Key Exchange Start Payload to select the security properties to be used
+in the key exchange and later in the communication.
+
+After Key Exchange Start Payload has been processed by both of the
+parties the protocol proceeds as follows:
+
+
+Setup: p is a large and public safe prime. This is one of the
+ Diffie Hellman groups. q is order of subgroup (largest
+ prime factor of p). g is a generator and is defined
+ along with the Diffie Hellman group.
+
+ 1. Initiator generates a random number x, where 1 < x < q,
+ and computes e = g ^ x mod p. The result e is then
+ encoded into Key Exchange Payload and sent to the
+ responder.
+
+ If the Mutual Authentication flag is set then initiator
+ MUST also produce signature data SIGN_i which the responder
+ will verify. The initiator MUST compute a hash value
+ HASH_i = hash(Key Exchange Start Payload | public key
+ (or certificate) | e). It then signs the HASH_i value with
+ its private key resulting a signature SIGN_i.
+
+ 2. Responder generates a random number y, where 1 < y < q,
+ and computes f = g ^ y mod p. It then computes the
+ shared secret KEY = e ^ y mod p, and, a hash value
+ HASH = hash(Key Exchange Start Payload data | public
+ key (or certificate) | e | f | KEY). It then signs
+ the HASH value with its private key resulting a signature
+ SIGN.
+
+ It then encodes its public key (or certificate), f and
+ SIGN into Key Exchange Payload and sends it to the
+ initiator.
+
+ If the Mutual Authentication flag is set then the responder
+ SHOULD verify that the public key provided in the payload
+ is authentic, or if certificates are used it verifies the
+ certificate. The responder MAY accept the public key without
+ verifying it, however, doing so may result to insecure key
+ exchange (accepting the public key without verifying may be
+ desirable for practical reasons on many environments. For
+ long term use this is never desirable, in which case
+ certificates would be the preferred method to use). It then
+ computes the HASH_i value the same way initiator did in the
+ phase 1. It then verifies the signature SIGN_i from the
+ payload with the hash value HASH_i using the received public
+ key.
+
+ 3. Initiator verifies that the public key provided in
+ the payload is authentic, or if certificates are used
+ it verifies the certificate. The initiator MAY accept
+ the public key without verifying it, however, doing
+ so may result to insecure key exchange (accepting the
+ public key without verifying may be desirable for
+ practical reasons on many environments. For long term
+ use this is never desirable, in which case certificates
+ would be the preferred method to use).
+
+ Initiator then computes the shared secret KEY =
+ f ^ x mod p, and, a hash value HASH in the same way as
+ responder did in phase 2. It then verifies the
+ signature SIGN from the payload with the hash value
+ HASH using the received public key.
+
+
+If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
+to indicate that the key exchange protocol has failed, and the connection
+SHOULD be closed immediately. Any other packets MUST NOT be sent or
+accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
+SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
+
+The result of this protocol is a shared secret key material KEY and
+a hash value HASH. The key material itself is not fit to be used as
+a key, it needs to be processed further to derive the actual keys to be
+used. The key material is also used to produce other security parameters
+later used in the communication. See section 2.3 Processing the Key
+Material for detailed description how to process the key material.
+
+If the Mutual Authentication flag was set the protocol produces also
+a hash value HASH_i. This value, however, must be discarded.
+
+After the keys are processed the protocol is ended by sending the
+SILC_PACKET_SUCCESS packet. Both entities send this packet to
+each other. After this both parties will start using the new keys.
+
+
+.ti 0
+2.3 Processing the Key Material
+
+Key Exchange protocol produces secret shared key material KEY. This
+key material is used to derive the actual keys used in the encryption
+of the communication channel. The key material is also used to derive
+other security parameters used in the communication. Key Exchange
+protocol produces a hash value HASH as well.
+
+The keys MUST be derived from the key material as follows:
+
+.in 6
+Sending Initial Vector (IV) = hash(0 | KEY | HASH)
+Receiving Initial Vector (IV) = hash(1 | KEY | HASH)
+Sending Encryption Key = hash(2 | KEY | HASH)
+Receiving Encryption Key = hash(3 | KEY | HASH)
+HMAC Key = hash(4 | KEY | HASH)
+.in 3
+
+
+The Initial Vector (IV) is used in the encryption when doing for
+example CBC mode. As many bytes as needed are taken from the start of
+the hash output for IV. Sending IV is for sending key and receiving IV
+is for receiving key. For receiving party, the receiving IV is actually
+sender's sending IV, and, the sending IV is actually sender's receiving
+IV. Initiator uses IV's as they are (sending IV for sending and
+receiving IV for receiving).
+
+The Encryption Keys are derived as well from the hash(). If the hash()
+output is too short for the encryption algorithm more key material MUST
+be produced in the following manner:
+
+.in 6
+K1 = hash(2 | KEY | HASH)
+K2 = hash(KEY | K1)
+K3 = hash(KEY | K1 | K2) ...
+
+Sending Encryption Key = K1 | K2 | K3 ...
+
+
+K1 = hash(3 | KEY | HASH)
+K2 = hash(KEY | K1)
+K3 = hash(KEY | K1 | K2) ...
+
+Receiving Encryption Key = K1 | K2 | K3 ...
+.in 3
+
+
+The key is distributed by hashing the previous hash with the original
+key material. The final key is a concatenation of the hash values.
+For Receiving Encryption Key the procedure is equivalent. Sending key
+is used only for encrypting data to be sent. The receiving key is used
+only to decrypt received data. For receiving party, the receive key is
+actually sender's sending key, and, the sending key is actually sender's
+receiving key. Initiator uses generated keys as they are (sending key
+for sending and receiving key for receiving).
+
+The HMAC key is used to create MAC values to packets in the communication
+channel. As many bytes as needed are taken from the start of the hash
+output.
+
+These procedures are performed by all parties of the key exchange
+protocol. This MUST be done before the protocol has been ended by
+sending the SILC_PACKET_SUCCESS packet.
+
+This same procedure is used in the SILC in some other circumstances
+as well. Any changes to this procedure is mentioned separately when
+this procedure is needed. See the [SILC1] and the [SILC2] for these
+circumstances.
+
+
+.ti 0
+2.4 SILC Key Exchange Groups
+
+The Following groups may be used in the SILC Key Exchange protocol.
+The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
+negotiated to be used in the connection with Key Exchange Start Payload
+and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
+proposed in the Key Exchange Start Payload regardless of any other
+requested group (however, it does not have to be the first in the list).
+
+
+.ti 0
+2.4.1 diffie-hellman-group1
+
+The length of this group is 1024 bits. This is REQUIRED group.
+The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+
+Its decimal value is
+
+.in 6
+179769313486231590770839156793787453197860296048756011706444
+423684197180216158519368947833795864925541502180565485980503
+646440548199239100050792877003355816639229553136239076508735
+759914822574862575007425302077447712589550957937778424442426
+617334727629299387668709205606050270810842907692932019128194
+467627007
+.in 3
+
+Its hexadecimal value is
+
+.in 6
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+FFFFFFFF FFFFFFFF
+.in 3
+
+
+The generator used with this prime is g = 2. The group order q is
+(p - 1) / 2.
+
+This group was taken from the OAKLEY specification.
+
+
+.ti 0
+2.4.2 diffie-hellman-group2
+
+The length of this group is 1536 bits. This is OPTIONAL group.
+The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
+
+Its decimal value is
+
+.in 6
+241031242692103258855207602219756607485695054850245994265411
+694195810883168261222889009385826134161467322714147790401219
+650364895705058263194273070680500922306273474534107340669624
+601458936165977404102716924945320037872943417032584377865919
+814376319377685986952408894019557734611984354530154704374720
+774996976375008430892633929555996888245787241299381012913029
+459299994792636526405928464720973038494721168143446471443848
+8520940127459844288859336526896320919633919
+.in 3
+
+Its hexadecimal value is
+
+.in 6
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+.in 3
+
+The generator used with this prime is g = 2. The group order q is
+(p - 1) / 2.
+
+This group was taken from the OAKLEY specification.
+
+
+.ti 0
+2.5 Key Exchange Status Types
+
+This section defines all key exchange protocol status types that may
+be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+to indicate the status of the protocol. Implementations may map the
+status types to human readable error message. All types except the
+SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+The length of status is 32 bits (4 bytes). The following status types
+are defined:
+
+.in 6
+0 SILC_SKE_STATUS_OK
+
+ Protocol were executed successfully.
+
+
+1 SILC_SKE_STATUS_ERROR
+
+ Unknown error occurred. No specific error type is defined.
+
+
+2 SILC_SKE_STATUS_BAD_PAYLOAD
+
+ Provided KE payload were malformed or included bad fields.
+
+
+3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
+
+ None of the provided groups were supported.
+
+
+4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
+
+ None of the provided ciphers were supported.
+
+
+5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
+
+ None of the provided public key algorithms were supported.
+
+
+6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
+
+ None of the provided hash functions were supported.
+
+
+7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
+
+ None of the provided HMACs were supported.
+
+
+8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
+
+ Provided public key type is not supported.
+
+
+9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
+
+ Provided signature was incorrect.
+
+
+10 SILC_SKE_STATUS_BAD_VERSION
+
+ Provided version string was not acceptable.
+.in 3
+
+
+.ti 0
+3 SILC Connection Authentication Protocol
+
+Purpose of Connection Authentication protocol is to authenticate the
+connecting party with server. Usually connecting party is client but
+server may connect to router server as well. Its other purpose is to
+provide information for the server about which type of connection this
+is. The type defines whether this is client, server or router
+connection. Server uses this information to create the ID for the
+connection.
+
+After the authentication protocol has been successfully completed
+SILC_PACKET_NEW_ID must be sent to the connecting client by the server.
+See the [SILC1] for the details of the connecting procedure.
+
+Server MUST verify the authentication data received and if it is to fail
+the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+If everything checks out fine the protocol is ended by server by sending
+SILC_PACKET_SUCCESS packet.
+
+The protocol is executed after the SILC Key Exchange protocol. It MUST
+NOT be executed in any other time. As it is performed after key exchange
+protocol all traffic in the connection authentication protocol is
+encrypted with the exchanged keys.
+
+The protocol MUST be started by the connecting party by sending the
+SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
+described in the next section. This payload MUST include the
+authentication data. The authentication data is set according
+authentication method that MUST be known by both parties. If connecting
+party does not know what is the mandatory authentication method it MAY
+request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
+packet. This packet is not part of this protocol and is described in
+section Connection Auth Request Payload in [SILC2]. However, if
+connecting party already knows the mandatory authentication method
+sending the request is not necessary.
+
+See [SILC1] and section Connection Auth Request Payload in [SILC2] also
+for the list of different authentication methods. Authentication method
+MAY also be NONE, in which case the server does not require
+authentication at all. However, in this case the protocol still MUST be
+executed; the authentication data just is empty indicating no
+authentication is required.
+
+If authentication method is passphrase the authentication data is
+plaintext passphrase. As the payload is entirely encrypted it is safe
+to have plaintext passphrase. See the section 3.2.1 Passphrase
+Authentication for more information.
+
+If authentication method is public key authentication the authentication
+data is signature of the hash value HASH plus Key Exchange Start Payload,
+established by the SILC Key Exchange protocol. This signature MUST then
+be verified by the server. See the section 3.2.2 Public Key
+Authentication for more information.
+
+The connecting client of this protocol MUST wait after successful execution
+of this protocol for the SILC_PACKET_NEW_ID packet where it will receive
+the ID it will be using in the SILC network. The connecting client cannot
+start normal SILC session (sending messages or commands) until it has
+received its ID. The ID's are always created by the server except
+for server to router connection where servers create their own ID's.
+
+
+.ti 0
+3.1 Connection Auth Payload
+
+Client sends this payload to authenticate itself to the server. Server
+connecting to another server also sends this payload. Server receiving
+this payload MUST verify all the data in it and if something is to fail
+the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+
+The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
+It MUST NOT be sent in any other packet type. The following diagram
+represent the Connection Auth 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 | Connection Type |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Authentication Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 3: Connection Auth Payload
+
+
+.in 6
+o Payload Length (2 bytes) - Length of the entire Connection
+ Auth Payload.
+
+o Connection Type (2 bytes) - Indicates the type of the
+ connection. See section Connection Auth Request Payload
+ in [SILC2] for the list of connection types. This field MUST
+ include valid connection type or the packet MUST be discarded
+ and authentication MUST be failed.
+
+o Authentication Data (variable length) - The actual
+ authentication data. Contents of this depends on the
+ authentication method known by both parties. If no
+ authentication is required this field does not exist.
+.in 3
+
+
+.ti 0
+3.2 Connection Authentication Types
+
+SILC supports two authentication types to be used in the connection
+authentication protocol; passphrase or public key based authentication.
+The following sections defines the authentication methods. See [SILC2]
+for defined numerical authentication method types.
+
+
+.ti 0
+3.2.1 Passphrase Authentication
+
+Passphrase authentication or pre-shared-key based authentication is
+simply an authentication where the party that wants to authenticate
+itself to the other end sends the passphrase that is required by
+the other end, for example server.
+
+If the passphrase matches with the one in the server's end the
+authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
+sent to the sender and the protocol execution fails.
+
+This is REQUIRED authentication method to be supported by all SILC
+implementations.
+
+
+.ti 0
+3.2.2 Public Key Authentication
+
+Public key authentication may be used if passphrase based authentication
+is not desired. The public key authentication works by sending a
+signature as authentication data to the other end, say, server. The
+server MUST then verify the signature by the public key of the sender,
+which the server has received earlier in SKE protocol.
+
+The signature is computed using the private key of the sender by signing
+the HASH value provided by the SKE protocol previously, and the Key
+Exchange Start Payload from SKE protocol that was sent to the server.
+The server MUST verify the data, thus it must keep the HASH and the
+Key Exchange Start Payload saved during SKE and authentication protocols.
+
+If the verified signature matches the sent signature, the authentication
+were successful and SILC_PACKET_SUCCESS is sent. If it failed the protocol
+execution is stopped and SILC_PACKET_FAILURE is sent.
+
+This is REQUIRED authentication method to be supported by all SILC
+implementations.
+
+
+.ti 0
+3.3 Connection Authentication Status Types
+
+This section defines all connection authentication status types that
+may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+to indicate the status of the protocol. Implementations may map the
+status types to human readable error message. All types except the
+SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+The length of status is 32 bits (4 bytes). The following status types
+are defined:
+
+0 SILC_AUTH_OK
+
+ Protocol was executed successfully.
+
+
+1 SILC_AUTH_FAILED
+
+ Authentication failed.
+
+
+.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, April 2001.
+
+[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ April 2001.
+
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001.
+
+[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+[Schneier] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996.
+
+[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
+ CRC Press 1997.
+
+[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+[ISAKMP] Maughan D., et al, "Internet Security Association and
+ Key Management Protocol (ISAKMP)", RFC 2408, November
+ 1998.
+
+[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
+ Authentication", RFC 2104, February 1997.
+
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+.ti 0
+6 Author's Address
+
+.nf
+Pekka Riikonen
+Kasarmikatu 11 A4
+70110 Kuopio
+Finland
+
+EMail: priikone@poseidon.pspt.fi
+
+This Internet-Draft expires 25 October 2001
--- /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 XXX
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-pp-03.txt XXX
+Expires: XXX
+
+.in 3
+
+.ce 2
+SILC Packet Protocol
+<draft-riikonen-silc-pp-03.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 Internet Draft [SILC1]. This
+protocol describes the packet types and packet payloads which defines
+the contents of the packets. The protocol provides secure binary packet
+protocol that assures that the contents of the packets are secured and
+authenticated.
+
+
+
+
+
+
+
+
+
+.ti 0
+Table of Contents
+
+.nf
+1 Introduction .................................................. 3
+ 1.1 Requirements Terminology .................................. 4
+2 SILC Packet Protocol .......................................... 4
+ 2.1 SILC Packet ............................................... 4
+ 2.2 SILC Packet Header ........................................ 5
+ 2.3 SILC Packet Types ......................................... 7
+ 2.3.1 SILC Packet Payloads ................................ 16
+ 2.3.2 Generic payloads .................................... 16
+ 2.3.2.1 ID Payload .................................. 16
+ 2.3.2.2 Argument Payload ............................ 17
+ 2.3.2.3 Channel Payload ............................. 18
+ 2.3.2.4 Public Key Payload .......................... 19
+ 2.3.3 Disconnect Payload .................................. 19
+ 2.3.4 Success Payload ..................................... 19
+ 2.3.5 Failure Payload ..................................... 20
+ 2.3.6 Reject Payload ...................................... 21
+ 2.3.7 Notify Payload ...................................... 22
+ 2.3.8 Error Payload ....................................... 21
+ 2.3.9 Channel Message Payload ............................. 28
+ 2.3.10 Channel Key Payload ................................ 31
+ 2.3.11 Private Message Payload ............................ 33
+ 2.3.12 Private Message Key Payload ........................ 34
+ 2.3.13 Command Payload .................................... 36
+ 2.3.14 Command Reply Payload .............................. 37
+ 2.3.15 Connection Auth Request Payload .................... 37
+ 2.3.16 New ID Payload ..................................... 38
+ 2.3.17 New Client Payload ................................. 39
+ 2.3.18 New Server Payload ................................. 40
+ 2.3.19 New Channel Payload ................................ 41
+ 2.3.20 Key Agreement Payload .............................. 42
+ 2.3.21 Cell Routers Payload ............................... 43
+ 2.4 SILC ID Types ............................................. 44
+ 2.5 Packet Encryption And Decryption .......................... 44
+ 2.5.1 Normal Packet Encryption And Decryption ............. 45
+ 2.5.2 Channel Message Encryption And Decryption ........... 45
+ 2.5.3 Private Message Encryption And Decryption ........... 46
+ 2.6 Packet MAC Generation ..................................... 47
+ 2.7 Packet Padding Generation ................................. 47
+ 2.8 Packet Compression ........................................ 48
+ 2.9 Packet Sending ............................................ 48
+ 2.10 Packet Reception ......................................... 49
+ 2.11 Packet Routing ........................................... 49
+ 2.12 Packet Broadcasting ...................................... 50
+3 Security Considerations ....................................... 50
+4 References .................................................... 50
+5 Author's Address .............................................. 52
+
+.ti 0
+List of Figures
+
+.nf
+Figure 1: Typical SILC Packet
+Figure 2: SILC Packet Header
+Figure 3: ID Payload
+Figure 4: Argument Payload
+Figure 5: Channel Payload
+Figure 6: Public Key Payload
+Figure 7: Disconnect Payload
+Figure 8: Success Payload
+Figure 9: Failure Payload
+Figure 10: Reject Payload
+Figure 11: Notify Payload
+Figure 12: Error Payload
+Figure 13: Channel Message Payload
+Figure 14: Channel Key Payload
+Figure 15: Private Message Payload
+Figure 16: Private Message Key Payload
+Figure 17: Command Payload
+Figure 18: Connection Auth Request Payload
+Figure 19: New Client Payload
+Figure 20: New Server Payload
+Figure 21: Key Agreement Payload
+Figure 22: Cell Routers Payload
+
+
+.ti 0
+1. Introduction
+
+This document describes a Packet Protocol used in the Secure Internet
+Live Conferencing (SILC) protocol specified in the Secure Internet Live
+Conferencing, Protocol Specification Internet Draft [SILC1]. This
+protocol describes the packet types and packet payloads which defines
+the contents of the packets. The protocol provides secure binary packet
+protocol that assures that the contents of the packets are secured and
+authenticated.
+
+The basis of SILC protocol relies in the SILC packets and it is with
+out a doubt the most important part of the protocol. It is also probably
+the most complicated part of the protocol. Packets are used all the
+time in the SILC network to send messages, commands and other information.
+All packets in SILC network are always encrypted and their integrity
+is assured by computed MACs. The protocol defines several packet types
+and packet payloads. Each packet type usually has a specific packet
+payload that actually defines the contents of the packet. Each packet
+also includes a default SILC Packet Header that provides sufficient
+information about the origin of the packet and destination of the
+packet.
+
+
+.ti 0
+1.1 Requirements Terminology
+
+The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+MAY, and OPTIONAL, when they appear in this document, are to be
+interpreted as described in [RFC2119].
+
+
+.ti 0
+2 SILC Packet Protocol
+
+.ti 0
+2.1 SILC Packet
+
+SILC packets deliver messages from sender to receiver securely by
+encrypting important fields of the packet. The packet consists of
+default SILC Packet Header, Padding, Packet Payload data, and, packet
+MAC.
+
+The following diagram illustrates typical SILC packet.
+
+
+.in 5
+.nf
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+| n bytes | 1 - n bytes | n bytes | n bytes
+| SILC Header | Padding | Data Payload | MAC
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+.in 3
+
+.ce
+Figure 1: Typical SILC Packet
+
+
+SILC Header is always the first part of the packet and its purpose
+is to provide information about the packet. It provides for example
+the packet type, origin of the packet and the destination of the packet.
+The header is variable in length and first two (2) bytes of the
+header (thus first two bytes of the packet) are not encrypted. The
+first two (2) bytes are the length of the packet which is not encrypted.
+See the following section for description of SILC Packet header. Packets
+without SILC header or with malformed SILC header MUST be dropped.
+
+Padding follows the packet header. The purpose of the padding is to
+make the packet multiple by eight (8) or by the block size of the
+cipher used in the encryption, which ever is larger. The maximum
+length of padding is currently 16 bytes. The padding is always
+encrypted.
+
+Data payload area follows padding and it is the actual data of the
+packet. The packet data is the packet payloads defined in this
+protocol. The data payload area is always encrypted.
+
+The last part of SILC packet is the packet MAC that assures the
+integrity of the packet. The MAC is always computed from the packet
+before the encryption is applied to the packet. If compression is used
+in the packet the MAC is computed after the compression has been
+applied. The compression, on the other hand, is always applied before
+encryption.
+
+All fields in all packet payloads are always in MSB (most significant
+byte first) order.
+
+
+.ti 0
+2.2 SILC Packet Header
+
+The SILC packet header is applied to all SILC packets and it is
+variable in length. The purpose of SILC Packet header is to provide
+detailed information about the packet. The receiver of the packet
+uses the packet header to parse the packet and gain other relevant
+parameters of the packet.
+
+The following diagram represents the SILC packet header. (*) indicates
+that this field is never encrypted. Other fields are always encrypted.
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Payload Length * | Flags | Packet Type |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Source ID Length | Destination ID Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Src ID Type | |
++-+-+-+-+-+-+-+-+ +
+| |
+~ Source ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Dst ID Type | |
++-+-+-+-+-+-+-+-+ +
+| |
+~ Destination ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 2: SILC Packet Header
+
+
+.in 6
+o Payload Length (2 bytes) - Is the length of the packet
+ not including the padding of the packet. This field must
+ not be encrypted but must always be authenticated.
+
+o Flags (1 byte) - Indicates flags to be used in packet
+ processing. Several flags may be set by ORing the flags
+ together.
+
+ The following flags are reserved for this field:
+
+
+ No flags 0x00
+
+ In this case the field is ignored.
+
+
+ Private Message Key 0x01
+
+ Indicates that the packet must include private
+ message that is encrypted using private key set by
+ client. Servers does not know anything about this
+ key and this causes that the private message is
+ not handled by the server at all, it is just
+ passed along. See section 2.5.3 Private Message
+ Encryption And Decryption for more information.
+
+
+ List 0x02
+
+ Indicates that the packet consists of list of
+ packet payloads indicated by the Packet Type field.
+ The payloads are added one after the other. Note that
+ there are packet types that must not be used as
+ list. Parsing of list packet is done by calculating
+ the length of each payload and parsing them one by
+ one.
+
+
+ Broadcast 0x04
+
+ Marks the packet to be broadcasted. Client cannot
+ send broadcast packet and normal server cannot send
+ broadcast packet. Only router server may send broadcast
+ packet. The router receiving of packet with this flag
+ set MUST send (broadcast) the packet to its primary
+ route. If router has several router connections the
+ packet may be sent only to the primary route. See
+ section 2.12 Packet Broadcasting for description of
+ packet broadcasting.
+
+.in 3
+
+
+
+
+o Packet Type (1 byte) - Is the type of the packet. Receiver
+ uses this field to parse the packet. See section 2.3
+ SILC Packets for list of defined packet types.
+
+o Source ID Length (2 bytes) - Indicates the length of the
+ Source ID field in the header, not including this or any
+ other fields.
+
+o Destination ID Length (2 bytes) - Indicates the length of the
+ Destination ID field in the header, not including this or
+ any other fields.
+
+o Src ID Type (1 byte) - Indicates the type of ID in the
+ Source ID field. See section 2.4 SILC ID Types for
+ defined ID types.
+
+o Source ID (variable length) - The actual source ID that
+ indicates which is the original sender of the packet.
+
+o Dst ID Type (1 byte) - Indicates the type of ID in the
+ Destination ID field. See section 2.4 SILC ID Types for
+ defined ID types.
+
+o Destination ID (variable length) - The actual destination
+ ID that indicates which is the end receiver of the packet.
+
+
+.ti 0
+2.3 SILC Packet Types
+
+SILC packet types defines the contents of the packet and it is used by
+the receiver to parse the packet. The packet type is 8 bits, as a one
+byte, in length. The range for the packet types are from 0 - 255,
+where 0 is never sent and 255 is currently reserved for future
+extensions and MUST NOT be defined to any other purpose. Every SILC
+specification compliant implementation SHOULD support all of these packet
+types.
+
+The below list of the SILC Packet types includes reference to the packet
+payload as well. Packet payloads are the actual packet, that is, the data
+that the packet consists of. Each packet type defines packet payload
+which usually may only be sent with the specific packet type.
+
+Most of the packets are packets that must be destined directly to entity
+that is connected to the sender. It is not allowed, for example, for
+router to send disconnect packet to client that is not directly connected
+to the router. However, there are some special packet types that may
+be destined to some entity that the sender has not direct connection
+with. These packets are for example private message packets, channel
+message packets, command packets and some other packets that may be
+broadcasted in the SILC network. If the packet is allowed to be sent to
+indirectly connected entity it is mentioned separately in the packet
+description (unless it is obvious as in private and channel message
+packets). Other packets MUST NOT be sent or accepted, if sent, to
+indirectly connected entities.
+
+List of SILC Packet types are defined as follows.
+
+.in 1
+ 0 SILC_PACKET_NONE
+
+ This type is reserved and it is never sent.
+
+
+ 1 SILC_PACKET_DISCONNECT
+
+ This packet is sent to disconnect the remote end. Reason of
+ the disconnection is sent inside the packet payload. Client
+ usually does not send this packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.3 Disconnect Payload
+
+
+ 2 SILC_PACKET_SUCCESS
+
+ This packet is sent upon successful execution of some protocol.
+ The status of the success is sent in the packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.4 Success Payload
+
+
+ 3 SILC_PACKET_FAILURE
+
+ This packet is sent upon failure of some protocol. The status
+ of the failure is sent in the packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.5 Failure Payload
+
+
+ 4 SILC_PACKET_REJECT
+
+ This packet MAY be sent upon rejection of some protocol.
+ The status of the rejection is sent in the packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.6 Reject Payload
+
+
+ 5 SILC_PACKET_NOTIFY
+
+ This packet is used to send notify message, usually from
+ server to client, although it MAY be sent from server to another
+ server as well. Client MUST NOT send this packet. Server MAY
+ send this packet to channel as well when the packet is
+ distributed to all clients on the channel.
+
+ Payload of the packet: See section 2.3.7 Notify Payload.
+
+
+ 6 SILC_PACKET_ERROR
+
+ This packet is sent when an error occurs. Server MAY
+ send this packet. Client MUST NOT send this packet. The
+ client MAY entirely ignore the packet, however, server is
+ most likely to take action anyway. This packet MAY be sent
+ to entity that is indirectly connected to the sender.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.8 Error Payload.
+
+
+ 7 SILC_PACKET_CHANNEL_MESSAGE
+
+ This packet is used to send messages to channels. The packet
+ includes Channel ID of the channel and the actual message to
+ the channel. Messages sent to the channel are always protected
+ by channel specific keys. Channel Keys are distributed by
+ SILC_PACKET_CHANNEL_KEY packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.9 Channel Message
+ Payload
+
+
+ 8 SILC_PACKET_CHANNEL_KEY
+
+ This packet is used to distribute new key for particular
+ channel. Each channel has their own independent keys that
+ is used to protect the traffic on the channel. Only server
+ may send this packet. This packet MAY be sent to entity
+ that is indirectly connected to the sender.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.10 Channel Key Payload
+
+
+ 9 SILC_PACKET_PRIVATE_MESSAGE
+
+ This packet is used to send private messages from client
+ to another client. By default, private messages are protected
+ by session keys established by normal key exchange protocol.
+ However, it is possible to use specific key to protect private
+ messages. SILC_PACKET_PRIVATE_MESSAGE_KEY packet is used to
+ agree the key with the remote client. Pre-shared key MAY be
+ used as well if both of the client knows it, however, it needs
+ to be agreed outside SILC. See more of this in [SILC1].
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.11 Private Message
+ Payload
+
+
+ 10 SILC_PACKET_PRIVATE_MESSAGE_KEY
+
+ This packet is used to agree about a key to be used to protect
+ the private messages between two clients. If this is not sent
+ the normal session key is used to protect the private messages
+ inside SILC network. Agreeing to use specific key to protect
+ private messages adds security, as no server between the two
+ clients will be able to decrypt the private message. However,
+ servers inside SILC network are considered to be trusted, thus
+ using normal session key to protect private messages does not
+ degrade security. Whether to agree to use specific keys by
+ default or to use normal session keys by default, is
+ implementation specific issue. See more of this in [SILC1].
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.12 Private Message
+ Key Payload
+
+
+ 11 SILC_PACKET_COMMAND
+
+ This packet is used to send commands from client to server.
+ Server MAY send this packet to other servers as well. All
+ commands are listed in their own section SILC Command Types
+ in [SILC4]. The contents of this packet is command specific.
+ This packet MAY be sent to entity that is indirectly connected
+ to the sender.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.13 Command Payload
+
+
+ 12 SILC_PACKET_COMMAND_REPLY
+
+ This packet is sent as reply to the SILC_PACKET_COMMAND packet.
+ The contents of this packet is command specific. This packet
+ MAY be sent to entity that is indirectly connected to the
+ sender.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.14 Command Reply
+ Payload and section 2.3.13 Command
+ Payload
+
+
+ 13 SILC_PACKET_KEY_EXCHANGE
+
+ This packet is used to start SILC Key Exchange Protocol,
+ described in detail in [SILC3].
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: Payload of this packet is described
+ in the section SILC Key Exchange
+ Protocol and its sub sections in
+ [SILC3].
+
+
+ 14 SILC_PACKET_KEY_EXCHANGE_1
+
+ This packet is used as part of the SILC Key Exchange Protocol.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: Payload of this packet is described
+ in the section SILC Key Exchange
+ Protocol and its sub sections in
+ [SILC3].
+
+
+ 15 SILC_PACKET_KEY_EXCHANGE_2
+
+ This packet is used as part of the SILC Key Exchange Protocol.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: Payload of this packet is described
+ in the section SILC Key Exchange
+ Protocol and its sub sections in
+ [SILC3].
+
+
+ 16 SILC_PACKET_CONNECTION_AUTH_REQUEST
+
+ This packet is used to request the authentication method to
+ be used in the SILC Connection Authentication Protocol. If
+ initiator of the protocol does not know the mandatory
+ authentication method this packet MAY be used to determine it.
+
+ The party receiving this payload MUST respond with the same
+ packet including the mandatory authentication method.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.15 Connection Auth
+ Request Payload
+
+
+
+
+ 17 SILC_PACKET_CONNECTION_AUTH
+
+ This packet is used to start and perform the SILC Connection
+ Authentication Protocol. This protocol is used to authenticate
+ the connecting party. The protocol is described in detail in
+ [SILC3].
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: Payload of this packet is described
+ in the section SILC Authentication
+ Protocol and it sub sections in [SILC].
+
+
+ 18 SILC_PACKET_NEW_ID
+
+ This packet is used to distribute new ID's from server to
+ router and from router to all routers in the SILC network.
+ This is used when for example new client is registered to
+ SILC network. The newly created ID's of these operations are
+ distributed by this packet. Only server may send this packet,
+ however, client MUST be able to receive this packet. This
+ packet MAY be sent to entity that is indirectly connected
+ to the sender.
+
+ Payload of the packet: See section 2.3.16 New ID Payload
+
+
+ 19 SILC_PACKET_NEW_CLIENT
+
+ This packet is used by client to register itself to the
+ SILC network. This is sent after key exchange and
+ authentication protocols has been completed. Client sends
+ various information about itself in this packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.17 New Client Payload
+
+
+ 20 SILC_PACKET_NEW_SERVER
+
+ This packet is used by server to register itself to the
+ SILC network. This is sent after key exchange and
+ authentication protocols has been completed. Server sends
+ this to the router it connected to, or, if router was
+ connecting, to the connected router. Server sends its
+ Server ID and other information in this packet. The client
+ MUST NOT send or receive this packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.18 New Server Payload
+
+
+ 21 SILC_PACKET_NEW_CHANNEL
+
+ This packet is used to notify routers about newly created
+ channel. Channels are always created by the router and it MUST
+ notify other routers about the created channel. Router sends
+ this packet to its primary route. Client MUST NOT send this
+ packet. This packet MAY be sent to entity that is indirectly
+ connected to the sender.
+
+ Payload of the packet: See section 2.3.19 New Channel Payload
+
+
+ 22 SILC_PACKET_REKEY
+
+ This packet is used to indicate that re-key must be performed
+ for session keys. See section Session Key Regeneration in
+ [SILC1] for more information. This packet does not have
+ a payload.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+
+ 23 SILC_PACKET_REKEY_DONE
+
+ This packet is used to indicate that re-key is performed and
+ new keys must be used hereafter.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+
+ 24 SILC_PACKET_HEARTBEAT
+
+ This packet is used by clients, servers and routers to keep the
+ connection alive. It is recommended that all servers implement
+ keepalive actions and perform it to both direction in a link.
+ This packet does not have a payload.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+
+ 25 SILC_PACKET_KEY_AGREEMENT
+
+ This packet is used by clients to request key negotiation
+ between another client in the SILC network. If the negotiation
+ is started it is performed using the SKE protocol. The result of
+ the negotiation, the secret key material, can be used for
+ example as private message key. The server and router MUST NOT
+ send this packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.20 Key Agreement Payload
+
+
+ 26 SILC_PACKET_CELL_ROUTERS
+
+ This packet is used by primary router in the cell to notify its
+ primary router what other routers (backup routers) exist in the
+ cell. In case of failure of the primary router in the cell the
+ first router in the list will act as primary router of the cell.
+ This packet MAY be sent at anytime after connection has been
+ registered to the primary router. The client MUST NOT send this
+ packet.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.21 Cell Routers Payload
+
+
+ 27 - 199
+
+ Currently undefined commands.
+
+
+ 200 - 254
+
+ These packet types are reserved for private use and they will
+ not be defined by this document.
+
+
+
+
+ 255 SILC_PACKET_MAX
+
+ This type is reserved for future extensions and currently it
+ MUST NOT be sent.
+.in 3
+
+
+.ti 0
+2.3.1 SILC Packet Payloads
+
+All payloads resides in the main data area of the SILC packet. However
+all payloads MUST be at the start of the data area after the SILC
+packet header and padding. All fields in the packet payload are always
+encrypted, as they reside in the data area of the packet which is
+always encrypted.
+
+Payloads described in this section are common payloads that MUST be
+accepted anytime during SILC session. Most of the payloads may only
+be sent with specific packet type which is defined in the description
+of the payload.
+
+There are a lot of other payloads in the SILC as well. However, they
+are not common in the sense that they could be sent at any time.
+These payloads are not described in this section. These are payloads
+such as SILC Key Exchange payloads and so on. These are described
+in [SILC1], [SILC3] and [SILC4].
+
+
+.ti 0
+2.3.2 Generic payloads
+
+This section describes generic payloads that are not associated to any
+specific packet type. They can be used for example inside some other
+packet payloads.
+
+
+.ti 0
+2.3.2.1 ID Payload
+
+This payload can be used to send an ID. ID's are variable in length
+thus this payload provides a way to send variable length ID's.
+
+
+
+
+
+
+
+
+
+
+
+
+The following diagram represents the ID Payload.
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| ID Type | ID Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ ID Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 3: ID Payload
+
+
+.in 6
+o ID Type (2 bytes) - Indicates the type of the ID. See
+ section 2.4 SILC ID Types for list of defined ID types.
+
+o ID Length (2 bytes) - Length of the ID Data area not
+ including the length of any other fields in the payload.
+
+o ID Data (variable length) - The actual ID data.
+.in 3
+
+
+.ti 0
+2.3.2.2 Argument Payload
+
+Argument Payload is used to set arguments for any packet payload that
+needs and supports arguments, such as commands. Number of arguments
+associated with a packet MUST be indicated by the packet payload which
+needs the arguments. Argument Payloads MUST always reside right after
+the packet payload needing the arguments. Incorrect amount of argument
+payloads MUST cause rejection of the packet. The following diagram
+represents the Argument Payload.
+
+The following diagram represents the Argument Payload.
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Payload Length | Argument Type | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Argument Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 4: Argument Payload
+
+
+.in 6
+o Payload Length (2 bytes) - Length of the argument payload data
+ area not including the length of any other fields in the
+ payload.
+
+o Argument Type (1 byte) - Indicates the type of the argument.
+ Every argument may have a specific type that MUST be defined
+ by the packet payload needing the argument. For example
+ every command specify a number for each argument that maybe
+ associated with the command. By using this number the receiver
+ of the packet knows what type of argument this is. If there is
+ no specific argument type this field is set to zero (0).
+
+o Argument Data (variable length) - Argument data.
+.in 3
+
+
+.ti 0
+2.3.2.3 Channel Payload
+
+Generic Channel Payload may be used to send information about channel,
+its name, the Channel ID and a mode.
+
+The following diagram represents the Channel Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Channel Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Channel Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Channel ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Channel ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Mode Mask |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 5: New Channel Payload
+
+
+.in 6
+o Channel Name Length (2 bytes) - Length of the channel name
+ field.
+
+o Channel Name (variable length) - The name of the channel.
+
+o Channel ID Length (2 bytes) - Length of the Channel ID field.
+
+o Channel ID (variable length) - The Channel ID.
+
+o Mode Mask (4 bytes) - A mode. This can be the mode of the
+ channel but it can also be the mode of the client on the
+ channel. The contents of this field is dependent of the
+ usage of this payload. The usage is defined separately
+ when this payload is used. This is a 32 bit MSB first value.
+.in 3
+
+
+.ti 0
+2.3.2.4 Public Key Payload
+
+Generic Public Key Payload may be used to send different types of
+public keys and certificates.
+
+The following diagram represents the Public Key Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Key Length | Public Key Type |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Public Key of the party (or certificate) ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 6: Public Key Payload
+
+
+.in 6
+o Public Key Length (2 bytes) - The length of the Public Key
+ (or certificate) field, not including any other field.
+
+o Public Key Type (2 bytes) - The public key (or certificate)
+ type. This field indicates the type of the public key in
+ the packet. See the [SILC3] for defined public key types.
+
+o Public Key (or certificate) (variable length) - The
+ public key or certificate.
+.in 3
+
+
+.ti 0
+2.3.3 Disconnect Payload
+
+Disconnect payload is sent upon disconnection. The payload is simple;
+reason of disconnection is sent to the disconnected party.
+
+The payload may only be sent with SILC_PACKET_DISCONNECT packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the Disconnect Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Disconnect Message ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 7: Disconnect Payload
+
+
+
+
+.in 6
+o Disconnect Message (variable length) - Human readable
+ reason of the disconnection.
+.in 3
+
+
+.ti 0
+2.3.4 Success Payload
+
+Success payload is sent when some protocol execution is successfully
+completed. The payload is simple; indication of the success is sent.
+This may be any data, including binary or human readable data.
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Success Indication ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 8: Success Payload
+
+
+.in 6
+o Success Indication (variable length) - Indication of
+ the success. This may be for example some flag that
+ indicates the protocol and the success status or human
+ readable success message. The true length of this
+ payload is available by calculating it from the SILC
+ Packet Header.
+.in 3
+
+
+
+.ti 0
+2.3.5 Failure Payload
+
+This is opposite of Success Payload. Indication of failure of
+some protocol is sent in the payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Failure Indication ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 9: Failure Payload
+
+
+.in 6
+o Failure Indication (variable length) - Indication of
+ the failure. This may be for example some flag that
+ indicates the protocol and the failure status or human
+ readable failure message. The true length of this
+ payload is available by calculating it from the SILC
+ Packet Header.
+.in 3
+
+
+.ti 0
+2.3.6 Reject Payload
+
+This payload is sent when some protocol is rejected to be executed.
+Other operations MAY send this as well that was rejected. The
+indication of the rejection is sent in the payload. The indication
+may be binary or human readable data.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Reject Indication ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 10: Reject Payload
+
+
+.in 6
+o Reject Indication (variable length) - Indication of
+ the rejection. This maybe for example some flag that
+ indicates the protocol and the rejection status or human
+ readable rejection message. The true length of this
+ payload is available by calculating it from the SILC
+ Packet Header.
+.in 3
+
+
+.ti 0
+2.3.7 Notify Payload
+
+Notify payload is used to send notify messages. The payload is usually
+sent from server to client, however, server MAY send it to another
+server as well. This payload MAY also be sent to a channel. Client
+MUST NOT send this payload. The receiver of this payload MAY ignore
+the contents of the payload, however, notify message SHOULD be audited.
+
+The payload may only be sent with SILC_PACKET_NOTIFY packet. It MUST
+not be sent in any other packet type. The following diagram represents
+the Notify Payload.
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Notify Type | Payload Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Argument Nums |
++-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 11: Notify Payload
+
+
+.in 6
+o Notify Type (2 bytes) - Indicates the type of the notify
+ message.
+
+o Payload Length (2 bytes) - Length of the entire Notify Payload
+ including any associated Argument Payloads.
+
+o Argument Nums (2 bytes) - Indicates the number of Argument
+ Payloads associated to this payload. Notify types may define
+ arguments to be send along the notify message.
+.in 3
+
+The following list of currently defined notify types. The format for
+notify arguments is same as in SILC commands described in [SILC4].
+Also, all ID's sent in arguments are sent inside ID Payload.
+
+.in 6
+0 SILC_NOTIFY_TYPE_NONE
+
+ If no specific notify type apply for the notify message this type
+ MAY be used.
+
+ Max Arguments: 1
+ Arguments: (1) <message>
+
+ The <message> is implementation specific free text string.
+ Receiver MAY ignore this message.
+
+
+1 SILC_NOTIFY_TYPE_INVITE
+
+ Sent when an client is invited to a channel. This is also sent
+ when the invite list of the channel is changed. This notify type
+ is sent between routers and if an client was invited, to the
+ client as well. In this case the packet is destined to the client.
+
+ Max Arguments: 5
+ Arguments: (1) <Channel ID> (2) <channel name>
+ (3) [<sender Client ID>] (4) [<adding client>]
+ (5) [<removing client>]
+
+ 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 <adding
+ client> and the <removing client> indicates the added or removed
+ client from the channel's invite list. The format of the <adding
+ client> and the <removing client> is defined in the [SILC4] with
+ SILC_COMMAND_INVITE command.
+
+ The <adding client> and <removing client> MUST NOT be sent when
+ the packet is destined to a client.
+
+
+2 SILC_NOTIFY_TYPE_JOIN
+
+ Sent when client has joined to a channel. The server MUST
+ distribute this type only to the local clients on the channel
+ and then send it to its primary router. The router or server
+ receiving the packet distributes this type to the local clients
+ on the channel and broadcast it to the network.
+
+ Max Arguments: 2
+ Arguments: (1) [<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 only to the local clients on the channel and then send
+ it to its primary router. The router or server receiving the
+ packet distributes this type to the local clients on the channel
+ and broadcast it to the network.
+
+ Max Arguments: 1
+ Arguments: (1) <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 only to the local clients on the channel and
+ then send it to its primary router. The router or server receiving
+ the packet distributes this type to the local clients on the
+ channel and broadcast it to the network.
+
+ Max Arguments: 2
+ Arguments: (1) <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 must be
+ sent only to the clients which is joined on the channel which
+ topic was set or changed.
+
+ Max Arguments: 2
+ Arguments: (1) <Client ID> (2) <topic>
+
+ The <Client ID> is the client which set or changed the <topic>.
+
+
+6 SILC_NOTIFY_TYPE_NICK_CHANGE
+
+ Sent when client changes nick on a channel. The server MUST
+ distribute this type only to the local clients on the channel
+ and then send it to its primary router. The router or server
+ receiving the packet distributes this type to the local clients
+ on the channel and broadcast it to the network.
+
+ Max Arguments: 2
+ Arguments: (1) <Old Client ID> (2) <New Client ID>
+
+ 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.
+
+
+7 SILC_NOTIFY_TYPE_CMODE_CHANGE
+
+ Sent when channel mode has changed. This type MUST be sent only
+ to the clients which is joined on the channel which mode was
+ changed.
+
+ Max Arguments: 4
+ Arguments: (1) <ID Payload> (2) <mode mask>
+ (3) [<cipher>] (4) <[hmac>]
+
+ 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.
+
+
+8 SILC_NOTIFY_TYPE_CUMODE_CHANGE
+
+ Sent when user mode on channel has changed. This type MUST be
+ sent only to the clients which is joined on the channel where
+ the target client is on.
+
+ Max Arguments: 3
+ Arguments: (1) <ID Payload> (2) <mode mask>
+ (3) <Target Client ID>
+
+ 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.
+
+
+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.
+
+
+10 SILC_NOTIFY_TYPE_CHANNEL_CHANGE
+
+ Sent when channel's ID has changed for a reason or another.
+ This is sent by normal server to the client. This can also be
+ sent by router to other server to force the Channel ID change.
+ The Channel ID MUST be changed to use the new one. When sent
+ to clients, this type MUST be sent only to the clients which is
+ joined on the channel.
+
+ Max Arguments: 2
+ Arguments: (1) <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.
+
+
+11 SILC_NOTIFY_TYPE_SERVER_SIGNOFF
+
+ Sent when server quits SILC network. Those clients from this
+ server that are on channels must be removed from the channel.
+
+ Max Arguments: 2000
+ Arguments: (1) <Server ID> (n) [<Client ID> [...]
+
+ The <Server ID> is the server's ID. The rest of the arguments
+ are the Client ID's of the client's which are coming from this
+ server and are thus quitting the SILC network also. If the
+ maximum number of arguments are reached another
+ SILC_NOTIFY_TYPE_SERVER_SIGNOFF notify packet MUST be sent.
+ When this notify packet is sent between routers the Client ID's
+ MAY be omitted.
+
+
+12 SILC_NOTIFY_TYPE_KICKED
+
+ Sent when a client has been kicked from a channel. This is
+ sent also to the client which was kicked from the channel.
+ The client which was kicked from the channel MUST be removed
+ from the channel. This notify type is always destined to the
+ channel. The router or server receiving the packet distributes
+ this type to the local clients on the channel and broadcast it
+ to the network.
+
+ Max Arguments: 2
+ Arguments: (1) <Client ID> (2) [<comment>]
+
+ 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.
+
+
+13 SILC_NOTIFY_TYPE_KILLED
+
+ Sent when a client has been killed from the network. This is sent
+ also to the client which was killed from the network. The client
+ which was killed from the network MUST be removed from the network.
+ This notify type is destined directly to the client which was
+ killed and to channel if the client is on any channel. The router
+ or server receiving the packet distributes this type to the local
+ clients on the channel and broadcast it to the network.
+
+ Max Arguments: 2
+ Arguments: (1) <Client ID> (2) [<comment>]
+
+ 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.
+
+
+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) [<adding client>]
+ (3) [<removing client>]
+
+ The <Channel ID> is the channel which ban list was changed. The
+ <adding client> is used to indicate that a ban was added and the
+ <removing client> is used to indicate that a ban was removed from
+ the ban list. The format of the <adding client> and the
+ <removing client> is defined in the [SILC4] with SILC_COMMAND_BAN
+ command.
+
+.in 3
+
+Notify types starting from 16384 are reserved for private notify
+message types.
+
+
+.ti 0
+2.3.8 Error Payload
+
+Error payload is sent upon error. Error may occur in various
+conditions when server sends this packet. Client MUST NOT send this
+payload but MUST be able to accept it. However, client MAY
+totally ignore the contents of the packet as server is going to
+take action on the error anyway. However, it is recommended
+that the client takes error packet seriously.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Error Message ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 12: Error Payload
+
+
+.in 6
+o Error Message (variable length) - Human readable error
+ message.
+.in 3
+
+
+.ti 0
+2.3.9 Channel Message Payload
+
+Channel messages are the most common messages sent in the SILC.
+Channel Message Payload is used to send message to channels. These
+messages can only be sent if client has joined to some channel.
+Even though this packet is the most common in SILC it is still
+special packet. Some special handling on sending and reception
+of channel message is required.
+
+Padding MUST be applied into this payload since the payload is
+encrypted separately from other parts of the packet with the
+channel specific key. Hence the requirement of the padding.
+The padding SHOULD be random data. The packet MUST be made
+multiple by eight (8) or by the block size of the cipher, which
+ever is larger.
+
+The SILC header in this packet is encrypted with the session key
+of the next receiver of the packet. Nothing else is encrypted
+with that key. Thus, the actual packet and padding to be
+encrypted with the session key is SILC Header plus padding to it
+to make it multiple by eight (8) or multiple by the block size
+of the cipher, which ever is larger.
+
+Receiver of the the channel message packet is able to determine
+the channel the message is destined to by checking the destination
+ID from the SILC Packet header which tells the destination channel.
+The original sender of the packet is also determined by checking
+the source ID from the header which tells the client which sent
+the message.
+
+The payload may only be sent with SILC_PACKET_CHANNEL_MESSAGE packet.
+It MUST NOT be sent in any other packet type. The following diagram
+represents the Channel Message Payload.
+
+(*) indicates that the field is not encrypted.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Flags | Message Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Message Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Padding Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Padding ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ MAC ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Initial Vector * ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 13: Channel Message Payload
+
+
+.in 6
+o Flags (2 bytes) - Includes the flags of the channel
+ messages. The flags can indicate a reason or purpose
+ for the channel message. Note that the Private Message
+ Payload use these same flags for the same purpose. The
+ following flags are defined:
+
+ 0x0000 SILC_MESSAGE_FLAG_NONE
+
+ No specific flags set.
+
+ 0x0001 SILC_MESSAGE_FLAG_AUTREPLY
+
+ 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.
+
+ 0x0020 - 0x0200 RESERVED
+
+ Reserved for future flags
+
+ 0x0400 - 0x8000 PRIVATE RANGE
+
+ Private range for free use.
+
+o Message Length (2 bytes) - Indicates the length of the
+ the Message Data field in the payload, not including any
+ other field.
+
+o Message Data (variable length) - The actual message to
+ the channel.
+
+o Padding Length (2 bytes) - Indicates the length of the
+ Padding field in the payload, not including any other
+ field.
+
+o Padding (variable length) - The padding that MUST be
+ applied because this payload is encrypted separately from
+ other parts of the packet.
+
+o MAC (variable length) - The MAC computed from the
+ Message Length, Message Data, Padding Length and Padding
+ fields. This protects the integrity of the plaintext
+ channel message. The receiver can verify from the MAC
+ whether the message decrypted correctly. Also, if more than
+ one private key has been set for the channel, the receiver
+ can verify which of the keys decrypted the message
+ correctly. Note that, this field is encrypted and MUST
+ be added to the padding calculation.
+
+o Initial Vector (variable length) - The initial vector
+ that has been used in packet encryption. It needs to be
+ used in the packet decryption as well. What this field
+ includes is implementation issue. However, it is
+ RECOMMENDED that it would be random data or, perhaps,
+ a timestamp. It is NOT RECOMMENDED to use zero (0) as an
+ initial vector. This field is not encrypted. This field
+ is not included into the padding calculation. Length
+ of this field equals the cipher's block size. This field
+ is, however, authenticated.
+.in 3
+
+
+.ti 0
+2.3.10 Channel Key Payload
+
+All traffic in channels are protected by channel specific keys.
+Channel Key Payload is used to distribute channel keys to all
+clients on the particular channel. Channel keys are sent when
+the channel is created, when new user joins to the channel and
+whenever a user has left a channel. Server creates the new
+channel key and distributes it to the clients by encrypting this
+payload with the session key shared between the server and
+the client. After that, client starts using the key received
+in this payload to protect the traffic on the channel.
+
+The client which is joining to the channel receives its key in the
+SILC_COMMAND_JOIN command reply message thus it is not necessary to
+send this payload to the entity which sent the SILC_COMMAND_JOIN
+command.
+
+Channel keys are cell specific thus every router in the cell have
+to create a channel key and distribute it if any client in the
+cell has joined to a channel. Channel traffic between cell's
+are not encrypted using channel keys, they are encrypted using
+normal session keys between two routers. Inside a cell, all
+channel traffic is encrypted with the specified channel key.
+Channel key should expire periodically, say, in one hour, in
+which case new channel key is created and distributed.
+
+The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet.
+It MUST NOT be sent in any other packet type. The following diagram
+represents the Channel Key Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Channel ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Channel ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Cipher Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Cipher Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Channel Key Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Channel Key ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 14: Channel Key Payload
+
+
+
+.in 6
+o Channel ID Length (2 bytes) - Indicates the length of the
+ Channel ID field in the payload, not including any other
+ field.
+
+o Channel ID (variable length) - The Channel ID of the
+ channel this key is meant for.
+
+o Cipher Name Length (2 bytes) - Indicates the length of the
+ Cipher name field in the payload, not including any other
+ field.
+
+o Cipher Name (variable length) - Name of the cipher used
+ in the protection of channel traffic. This name is
+ initially decided by the creator of the channel but it
+ MAY change during the life time of the channel as well.
+
+o Channel Key Length (2 bytes) - Indicates the length of the
+ Channel Key field in the payload, not including any other
+ field.
+
+o Channel Key (variable length) - The actual channel key
+ material.
+.in 3
+
+
+.ti 0
+2.3.11 Private Message Payload
+
+Private Message Payload is used to send private message between
+two clients (or users for that matter). The messages are sent only
+to the specified user and no other user inside SILC network is
+able to see the message. The message is protected by the session
+key established by the SILC Key Exchange Protocol. However,
+it is also possible to agree to use a private key to protect
+just the private messages. See section 2.3.11 Private Message
+Key Payload for detailed description of how to agree to use
+specific key.
+
+If normal session key is used to protect the message, every server
+between the sender client and the receiving client MUST decrypt the
+packet and always re-encrypt it with the session key of the next
+receiver of the packet. See section Client To Client in [SILC1].
+
+When private key is used to protect the message, servers between
+the sender and the receiver needs not to decrypt/re-encrypt the
+packet. Section Client To Client in [SILC1] gives example of this
+scheme as well.
+
+The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE
+packet. It MUST NOT be sent in any other packet type. The following
+diagram represents the Private Message Payload.
+
+
+
+
+
+
+
+
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Flags | Message Data Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Message Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Padding ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 15: Private Message Payload
+
+
+.in 6
+o Flags (2 bytes) - This field includes the flags of the
+ private message. They can indicate a different reason or
+ purpose for the private message. See the section 2.3.9
+ Channel Message Payload for defined flags. Note that
+ the Channel Message Payload use the same flags for the
+ same purpose.
+
+o Message Data Length (2 bytes) - Indicates the length of the
+ Message Data field, not includes any other field.
+
+o Message Data (variable length) - The actual message to
+ the client. Rest of the packet is reserved for the message
+ data.
+
+o Padding (variable length) - This field is present only
+ when the private message payload is encrypted with private
+ message key. In this case the padding is applied to make
+ the payload multiple by eight (8), or by the block size of
+ the cipher, which ever is larger. When encrypted with
+ normal session keys, this field MUST NOT be included.
+.in 3
+
+
+.ti 0
+2.3.12 Private Message Key Payload
+
+This payload is used to send key from client to another client that
+is going to be used to protect the private messages between these
+two clients. If this payload is not sent normal session key
+established by the SILC Key Exchange Protocol is used to protect
+the private messages.
+
+This payload may only be sent by client to another client. Server
+MUST NOT send this payload at any time. After sending this payload
+the sender of private messages must set the Private Message Key
+flag into SILC Packet Header.
+
+The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY
+packet. It MUST NOT be sent in any other packet type. The following
+diagram represents the Private Message Key Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Private Message Key Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Private Message Key ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Cipher Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Cipher Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 16: Private Message Key Payload
+
+
+
+
+.in 6
+o Private Message Key Length (2 bytes) - Indicates the length
+ of the Private Message Key field in the payload, not including
+ any other field.
+
+o Private Message Key (variable length) - The actual private
+ message key material.
+
+o Cipher Name Length (2 bytes) - Indicates the length of the
+ Cipher Name field in the payload, not including any other
+ field.
+
+o Cipher Name (variable length) - Name of the cipher to use
+ in the private message encryption. If this field does not
+ exist then the default cipher of the SILC protocol is used.
+ See the [SILC1] for defined ciphers.
+.in 3
+
+
+
+.ti 0
+2.3.13 Command Payload
+
+Command Payload is used to send SILC commands from client to server.
+Also server MAY send commands to other servers. The following diagram
+represents the Command Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Payload Length | SILC Command | Arguments Num |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Command Identifier |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 17: Command Payload
+
+
+.in 6
+o Payload Length (2 bytes) - Length of the entire command
+ payload including any command argument payloads associated
+ with this payload.
+
+o SILC Command (1 byte) - Indicates the SILC command. This MUST
+ be set to non-zero value. If zero (0) value is found in this
+ field the packet MUST be discarded.
+
+o Arguments Num (1 byte) - Indicates the number of arguments
+ associated with the command. If there are no arguments this
+ field is set to zero (0). The arguments MUST follow the
+ command payload. See section 2.3.2.2 for definition of the
+ Argument Payload.
+
+o Command Identifier (2 bytes) - Identifies this command at the
+ sender's end. The entity which replies to this command MUST
+ set the value found from this field into the Command Payload
+ used to send the reply to the sender. This way the sender
+ can identify which command reply belongs to which originally
+ sent command. What this field includes is implementation
+ issue but it is RECOMMENDED that wrapping counter value is
+ used in the field. Value zero (0) in this field means that
+ no specific value is set.
+.in 3
+
+See [SILC4] for detailed description of different SILC commands,
+their arguments and their reply messages.
+
+
+
+
+.ti 0
+2.3.14 Command Reply Payload
+
+Command Reply Payload is used to send replies to the commands. The
+Command Reply Payload is identical to the Command Payload thus see
+the upper section for the Command Payload specification.
+
+The entity which sends the reply packet MUST set the Command Identifier
+field in the reply packet's Command Payload to the value it received
+in the original command packet.
+
+See SILC Commands in [SILC4] for detailed description of different
+SILC commands, their arguments and their reply messages.
+
+
+.ti 0
+2.3.15 Connection Auth Request Payload
+
+Client MAY send this payload to server to request the authentication
+method that must be used in authentication protocol. If client knows
+this information beforehand this payload is not necessary to be sent.
+Server performing authentication with another server MAY also send
+this payload to request the authentication method. If the connecting
+server already knows this information this payload is not necessary
+to be sent.
+
+Server receiving this request MUST reply with same payload sending
+the mandatory authentication method. Algorithms that may be required
+to be used by the authentication method are the ones already
+established by the SILC Key Exchange protocol. See section Key
+Exchange Start Payload in [SILC3] for detailed information.
+
+The payload may only be sent with SILC_PACKET_CONNECTION_AUTH_REQUEST
+packet. It MUST NOT be sent in any other packet type. The following
+diagram represents the Connection Auth Request Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Connection Type | Authentication Method |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 18: Connection Auth Request Payload
+
+
+.in 6
+o Connection Type (2 bytes) - Indicates the type of the
+ connection. The following connection types are defined:
+
+
+ 1 Client connection
+ 2 Server connection
+ 3 Router connection
+
+ If any other type is found in this field the packet MUST be
+ discarded and the authentication MUST be failed.
+
+o Authentication Method (2 bytes) - Indicates the authentication
+ method to be used in the authentication protocol. The following
+ authentication methods are defined:
+
+ 0 NONE (mandatory)
+ 1 password (mandatory)
+ 2 public key (mandatory)
+
+ If any other type is found in this field the packet MUST be
+ discarded and the authentication MUST be failed. If this
+ payload is sent as request to receive the mandatory
+ authentication method this field MUST be set to zero (0),
+ indicating that receiver should send the mandatory
+ authentication method. The receiver sending this payload
+ to the requesting party, MAY also set this field to zero (0)
+ to indicate that authentication is not required. In this
+ case authentication protocol still MUST be started but
+ server is most likely to respond with SILC_PACKET_SUCCESS
+ immediately.
+.in 3
+
+
+.ti 0
+2.3.16 New ID Payload
+
+New ID Payload is a multipurpose payload. It is used to send newly
+created ID's from clients and servers. When client connects to server
+and registers itself to the server by sending SILC_PACKET_NEW_CLIENT
+packet, server replies with this packet by sending the created ID for
+the client. Server always creates the ID for the client.
+
+This payload is also used when server tells its router that new client
+has registered to the SILC network. In this case the server sends
+the Client ID of the client to the router. Similarly when router
+distributes information to other routers about the client in the SILC
+network this payload is used.
+
+Also, when server connects to router, router uses this payload to inform
+other routers about new server in the SILC network. However, every
+server (or router) creates their own ID's thus the ID distributed by
+this payload is not created by the distributor in this case. Servers
+create their own ID's. Server registers itself to the network by sending
+SILC_PACKET_NEW_SERVER to the router it connected to. The case is same
+when router connects to another router.
+
+However, this payload MUST NOT be used to send information about new
+channels. New channels are always distributed by sending the dedicated
+SILC_PACKET_NEW_CHANNEL packet.
+
+Thus, this payload is very important and used every time when some
+new entity is registered to the SILC network. Client MUST NOT send this
+payload. Both client and server (and router) MAY receive this payload.
+
+The packet uses generic ID Payload as New ID Payload. See section
+2.3.2.1 for generic ID Payload.
+
+
+.ti 0
+2.3.17 New Client Payload
+
+When client is connected to the server, keys has been exchanged and
+connection has been authenticated client MUST register itself to the
+server. Client's first packet after key exchange and authentication
+protocols must be SILC_PACKET_NEW_CLIENT. This payload tells server all
+the relevant information about the connected user. Server creates a new
+client ID for the client when received this payload and sends it to the
+client in New ID Payload.
+
+This payload sends username and real name of the user on the remote host
+which is connected to the SILC server with SILC client. The server
+creates the client ID according the information sent in this payload.
+The nickname of the user becomes the username sent in this payload.
+However, client should call NICK command after sending this payload to
+set the real nickname of the user which is then used to create new
+client ID.
+
+The payload may only be sent with SILC_PACKET_NEW_CLIENT packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the New Client Payload.
+
+
+
+
+
+
+
+
+
+
+
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Username Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Username ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Real Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Real Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 19: New Client Payload
+
+
+.in 6
+o Username Length (2 bytes) - Length of the Username field.
+
+o Username (variable length) - The username of the user on
+ the host where connecting to the SILC server.
+
+o Real Name Length (2 bytes) - Length of the Real Name field.
+
+o Real Name (variable length) - The real name of the user
+ on the host where connecting to the SILC server.
+.in 3
+
+
+.ti 0
+2.3.18 New Server Payload
+
+This payload is sent by server when it has completed successfully both
+key exchange and connection authentication protocols. The server
+MUST register itself to the SILC Network by sending this payload.
+The first packet after these key exchange and authentication protocols
+is SILC_PACKET_NEW_SERVER packet. The payload includes the Server ID
+of the server that it has created by itself. It also includes a
+name of the server that is associated to the Server ID.
+
+The payload may only be sent with SILC_PACKET_NEW_SERVER packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the New Server Payload.
+
+
+
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Server ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Server ID Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Server Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Server Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 20: New Server Payload
+
+
+.in 6
+o Server ID Length (2 bytes) - Length of the Server ID Data
+ field.
+
+o Server ID Data (variable length) - The actual Server ID
+ data.
+
+o Server Name Length (2 bytes) - Length of the server name
+ field.
+
+o Server Name (variable length) - The server name.
+.in 3
+
+
+.ti 0
+2.3.19 New Channel Payload
+
+Information about newly created channel is broadcasted to all routers
+in the SILC network by sending this packet payload. Channels are
+created by router of the cell. Server never creates channels unless
+it is a standalone server and it does not have router connection,
+in this case server acts as router. Normal server send JOIN command
+to the router (after it has received JOIN command from client) which
+then processes the command and creates the channel. Client MUST NOT
+send this packet.
+
+The packet uses generic Channel Payload as New Channel Payload. See
+section 2.3.2.3 for generic Channel Payload. The Mode Mask field in the
+Channel Payload is the mode of the channel.
+
+
+
+
+.ti 0
+2.3.20 Key Agreement Payload
+
+This payload is used by clients to request key negotiation between
+another client in the SILC Network. The key agreement protocol used
+is the SKE protocol. The result of the protocol, the secret key
+material, can be used for example as private message key between the
+two clients. This significantly adds security as the key agreement
+is performed outside the SILC network. The server and router MUST NOT
+send this payload.
+
+The sender MAY tell the receiver of this payload the hostname and the
+port where the SKE protocol is running in the sender's end. The
+receiver MAY then initiate the SKE negotiation with the sender. The
+sender MAY also optionally not to include the hostname and the port
+of its SKE protocol. In this case the receiver MAY reply to the
+request by sending the same payload filled with the receiver's hostname
+and the port where the SKE protocol is running. The sender MAY then
+initiate the SKE negotiation with the receiver.
+
+The payload may only be sent with SILC_PACKET_KEY_AGREEMENT packet.
+It MUST NOT be sent in any other packet type. The following diagram
+represents the Key Agreement Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Hostname Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Hostname ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Port |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 21: Key Agreement Payload
+
+
+.in 6
+o Hostname Length (2 bytes) - Indicates the length of the
+ Hostname field.
+
+o Hostname (variable length) - The hostname or IP address where
+ the SKE protocol is running. The sender MAY fill this field
+ when sending the payload. If the receiver sends this payload
+ as reply to the request it MUST fill this field.
+
+o Port (4 bytes) - The port where the SKE protocol is bound.
+ The sender MAY fill this field when sending the payload. If
+ the receiver sends this payload as reply to the request it
+ MUST fill this field. This is a 32 bit MSB first order value.
+.in 3
+
+
+After the key material has been received from the SKE protocol it is
+processed as the [SILC3] describes. If the key material is used as
+channel private key then the Sending Encryption Key, as defined in
+[SILC3] is used as the channel private key. Other key material must
+be discarded. The [SILC1] defines the way to use the key material if
+it is intended to be used as private message keys. Any other use for
+the key material is undefined.
+
+
+.ti 0
+2.3.21 Cell Routers Payload
+
+Cell Routers payload is used by router to notify its primary router what
+other routers exist in the cell. The other routers are considered to be
+backup routers and one of them will come active only in the case of
+failure of the primary router. Normal server MAY send this packet if it
+is acting as backup router. Client MUST NOT send this packet. To send
+more than one backup router set the List flag and assemble the payloads
+as list.
+
+The payload may only be sent with SILC_PACKET_CELL_ROUTERS packet. It
+MUST NOT be sent in any other packet type. The Following diagram
+represents the Cell Routers Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Hostname Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Hostname ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Port |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Server ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Server ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 22: Cell Routers Payload
+
+
+.in 6
+o Hostname Length (2 bytes) - Indicates the length of the Hostname
+ field.
+
+o Hostname (variable length) - The hostname or IP address of
+ the backup router.
+
+o Port (4 bytes) - The port of the backup router it currently uses.
+ This is a 32 bit MSB first order value.
+
+o Server ID Length (2 bytes) - Indicates the length of the Server
+ ID field.
+
+o Server ID (variable length) - Consists of the Server ID of the
+ backup router.
+.in 3
+
+
+.ti 0
+2.4 SILC ID Types
+
+ID's are extensively used in the SILC network to associate different
+entities. The following ID's has been defined to be used in the SILC
+network.
+
+.in 6
+0 No ID
+
+ When ever specific ID cannot be used this is used.
+
+1 Server ID
+
+ Server ID to associate servers. See the format of
+ this ID in [SILC1].
+
+2 Client ID
+
+ Client ID to associate clients. See the format of
+ this ID in [SILC1].
+
+3 Channel ID
+
+ Channel ID to associate channels. See the format of
+ this ID in [SILC1].
+.in 3
+
+
+.ti 0
+2.5 Packet Encryption And Decryption
+
+SILC packets are encrypted almost entirely. Only small part of SILC
+header is not encrypted as described in section 5.2 SILC Packet Header.
+The SILC Packet header is the first part of a packet to be encrypted
+and it is always encrypted with the key of the next receiver of the
+packet. The data payload area of the packet is always entirely
+encrypted and it is usually encrypted with the next receiver's key.
+However, there are some special packet types and packet payloads
+that require special encryption process. These special cases are
+described in the next sections. First is described the normal packet
+encryption process.
+
+
+.ti 0
+2.5.1 Normal Packet Encryption And Decryption
+
+Normal SILC packets are encrypted with the session key of the next
+receiver of the packet. The entire SILC Packet header and the packet
+data payload is is also encrypted with the same key. Padding of the
+packet is also encrypted always with the session key, also in special
+cases. Computed MAC of the packet must not be encrypted.
+
+Decryption process in these cases are straightforward. The receiver
+of the packet MUST first decrypt the SILC Packet header, or some parts
+of it, usually first 16 bytes of it. Then the receiver checks the
+packet type from the decrypted part of the header and can determine
+how the rest of the packet must be decrypted. If the packet type is
+any of the special cases described in the following sections the packet
+decryption is special. If the packet type is not among those special
+packet types rest of the packet can be decrypted with the same key.
+
+Also, note that two bytes of the SILC Packet header are not encrypted
+thus it must be noticed in the decryption process by starting the
+decryption from the second byte of the header. This sets some rules
+to padding generation as well, see the section 2.7 Packet Padding
+Generation.
+
+With out a doubt, this sort of decryption processing causes some
+overhead to packet decryption, but never the less, is required.
+
+
+.ti 0
+2.5.2 Channel Message Encryption And Decryption
+
+Channel Messages (Channel Message Payload) are always encrypted with
+the channel specific key. However, the SILC Packet header is not
+encrypted with that key. As in normal case, the header is encrypted
+with the key of the next receiver of the packet, who ever that might
+be. Note that in this case the encrypted data area is not touched
+at all; it MUST NOT be re-encrypted with the session key.
+
+Receiver of a channel message, who ever that is, is REQUIRED to decrypt
+the SILC Packet header to be able to even recognize the packet to be as
+channel message. This is same procedure as for normal SILC packets.
+As the receiver founds the packet to be channel message, rest of the
+packet processing is special. Rest of the SILC Packet header is
+decrypted with the same session key along with the padding of the
+packet. After that the packet is protected with the channel specific
+key and thus can be decrypted only if the receiver is the client on
+the channel. See section 2.7 Packet Padding Generation for more
+information about padding on special packets.
+
+If the receiver of the channel message is router which is routing the
+message to another router then it MUST decrypt the Channel Message
+payload. Between routers (that is, between cells) channel messages
+are protected with session keys shared between the routers. This
+causes another special packet processing for channel messages. If
+the channel message is received from another router then the entire
+packet, including Channel Message payload, MUST be encrypted with the
+session key shared between the routers. In this case the packet
+decryption process is as with normal SILC packets. Hence, if the
+router is sending channel message to another router the Channel
+Message payload MUST have been decrypted and MUST be re-encrypted
+with the session key shared between the another router. In this
+case the packet encryption is as with any normal SILC packet.
+
+It must be noted that this is only when the channel messages are sent
+from router to another router. In all other cases the channel
+message encryption and decryption is as described above. This
+different processing of channel messages with router to router
+connection is because channel keys are cell specific. All cells has
+their own channel keys thus the channel message traveling from one
+cell to another MUST be protected as it would be any normal SILC
+packet.
+
+If the SILC_CMODE_PRIVKEY channel mode has been set for the channel
+then the router cannot decrypt the packet as it does not know the
+private key. In this case the entire packet MUST be encrypted with
+the session key and sent to the router. The router receiving the
+packet MUST check the channel mode and decrypt the packet accordingly.
+
+
+.ti 0
+2.5.3 Private Message Encryption And Decryption
+
+By default, private message in SILC are protected by session keys.
+In this case the private message encryption and decryption process is
+equivalent to normal packet encryption and decryption.
+
+However, private messages MAY be protected with private message key
+which causes the packet to be special packet. The procedure in this
+case is very much alike to channel packets. The actual private message
+is encrypted with the private message key and other parts of the
+packet is encrypted with the session key. See 2.7 Packet Padding
+Generation for more information about padding on special packets.
+
+The difference from channel message processing is that server or router
+en route never decrypts the actual private message, as it does not
+have the key to do that. Thus, when sending packets between router
+the processing is same as in any other case as well; the packet's header
+and padding is protected by the session key and the data area is not
+touched.
+
+The true receiver of the private message, client, that is, is able
+to decrypt the private message as it shares the key with the sender
+of the message.
+
+
+.ti 0
+2.6 Packet MAC Generation
+
+Data integrity of a packet is protected by including a message
+authentication code (MAC) at the end of the packet. The MAC is computed
+from shared secret MAC key, that is established by the SILC Key Exchange
+protocol, and from the original contents of the packet. The MAC is
+always computed before the packet is encrypted, although after it is
+compressed if compression is used.
+
+The MAC is computed from entire packet. Every bit of data in the packet,
+including SILC Packet Header is used in the MAC computing. This way
+the entire packet becomes authenticated.
+
+If the packet is special packet MAC is computed from the entire packet
+but part of the packet may be encrypted before the MAC is computed.
+This is case, for example, with channel messages where the message data
+is encrypted with key that server may not now. In this case the MAC
+has been computed from the encrypted data.
+
+See [SILC1] for defined and allowed MAC algorithms.
+
+
+.ti 0
+2.7 Packet Padding Generation
+
+Padding is needed in the packet because the packet is encrypted. It
+MUST always be multiple by eight (8) or multiple by the block size
+of the cipher, which ever is larger. The padding is always encrypted.
+
+For normal packets the padding is added after the SILC Packet Header
+and between the Data Payload area. The padding for normal packets
+are calculated as follows:
+
+.in 6
+padding length = 16 - ((packet length - 2) mod 16)
+.in 3
+
+The 16 is the maximum padding allowed in SILC packet. Two (2) is
+subtracted from the true length of the packet because two (2) bytes
+is not encrypted in SILC Packet Header, see section 2.2 SILC Packet
+Header. Those two bytes that are not encrypted MUST NOT be calculated
+to the padding length.
+
+For special packets the padding calculation MAY be different as special
+packets may be encrypted differently. In these cases the encrypted
+data area MUST already be multiple by the block size thus in this case
+the padding is calculated only for SILC Packet Header, not for any
+other area of the packet. The same algorithm works in this case as
+well, except that the `packet length' is now the SILC Packet Header
+length. In this case, as well, two (2) is subtracted from the
+length.
+
+The padding MUST be random data, preferably, generated by
+cryptographically strong random number generator.
+
+
+.ti 0
+2.8 Packet Compression
+
+SILC Packets MAY be compressed. In this case the data payload area
+is compressed and all other areas of the packet MUST remain as they
+are. After compression is performed for the data area, the length
+field of Packet Header MUST be set to the compressed length of the
+data.
+
+The compression MUST always be applied before encryption. When
+the packet is received and decrypted the data area MUST be decompressed.
+Note that the true sender of the packet MUST apply the compression and
+the true receiver of the packet MUST apply the decompression. Any
+server or router en route MUST NOT decompress the packet.
+
+
+.ti 0
+2.9 Packet Sending
+
+The sender of the packet MUST assemble the SILC Packet Header with
+correct values. It MUST set the Source ID of the header as its own
+ID, unless it is forwarding the packet. It MUST also set the Destination
+ID of the header to the true destination. If the destination is client
+it will be Client ID, if it is server it will be Server ID and if it is
+channel it will be Channel ID.
+
+If the sender wants to compress the packet it MUST apply the
+compression now. Sender MUST also compute the padding as described
+in above sections. Then sender MUST compute the MAC of the packet.
+
+Then sender MUST encrypt the packet as has been described in above
+sections according whether the packet is normal packet or special
+packet. The computed MAC MUST NOT be encrypted.
+
+
+.ti 0
+2.10 Packet Reception
+
+On packet reception the receiver MUST check that all fields in the
+SILC Packet Header are valid. It MUST check the flags of the
+header and act accordingly. It MUST also check the MAC of the packet
+and if it is to be failed the packet MUST be discarded. Also if the
+header of the packet includes any bad fields the packet MUST be
+discarded.
+
+See above sections on the decryption process of the received packet.
+
+The receiver MUST also check that the ID's in the header are valid
+ID's. Unsupported ID types or malformed ID's MUST cause packet
+rejection. The padding on the reception is always ignored.
+
+The receiver MUST also check the packet type and start parsing the
+packet according to the type. However, note the above sections on
+special packet types and their parsing.
+
+
+.ti 0
+2.11 Packet Routing
+
+Routers are the primary entities in the SILC network that takes care
+of packet routing. However, normal servers routes packets as well, for
+example, when they are routing channel message to the local clients.
+Routing is quite simple as every packet tells the true origin and the
+true destination of the packet.
+
+It is still RECOMMENDED for routers that has several routing connections
+to create route cache for those destinations that has faster route than
+the router's primary route. This information is available for the router
+when other router connects to the router. The connecting party then
+sends all of its locally connected clients, servers and channels. These
+informations helps to create the route cache. Also, when new channels
+are created to a cell its information is broadcasted to all routers
+in the network. Channel ID's are based on router's ID thus it is easy
+to create route cache based on these informations. If faster route for
+destination does not exist in router's route cache the packet MUST be
+routed to the primary route (default route).
+
+For server which receives a packet to be routed to its locally connected
+client the server MUST check whether the particular packet type is
+allowed to be routed to the client. Not all packets may be sent by
+some odd entity to client that is indirectly connected to the sender.
+See section 2.3 SILC Packet Types and paragraph about indirectly connected
+entities and sending packets to them. The section mentions the packets
+that may be sent to indirectly connected entities. It is clear that some
+server cannot send, for example, disconnect packet to client that is not
+directly connected to the server.
+
+
+.ti 0
+2.12 Packet Broadcasting
+
+SILC packets MAY be broadcasted in SILC network. However, only router
+server may send or receive broadcast packets. Client and normal server
+MUST NOT send broadcast packets and they MUST ignore broadcast packets
+if they receive them. Broadcast packets are sent by setting Broadcast
+flag to the SILC packet header.
+
+Broadcasting packets means that the packet is sent to all routers in
+the SILC network, except to the router that sent the packet. The router
+receiving broadcast packet MUST send the packet to its primary route.
+The fact that SILC routers may have several router connections can
+cause problems, such as race conditions inside the SILC network, if
+care is not taken when broadcasting packets. Router MUST NOT send
+the broadcast packet to any other route except to its primary route.
+
+If the primary route of the router is the original sender of the packet
+the packet MUST NOT be sent to the primary route. This may happen
+if router has several router connections and some other router uses
+the router as its primary route.
+
+Routers use broadcast packets to broadcast for example information
+about newly registered clients, servers, channels etc. so that all the
+routers may keep these informations up to date.
+
+
+.ti 0
+3 Security Considerations
+
+Security is central to the design of this protocol, and these security
+considerations permeate the specification. Common security considerations
+such as keeping private keys truly private and using adequate lengths for
+symmetric and asymmetric keys must be followed in order to maintain the
+security of this protocol.
+
+
+.ti 0
+4 References
+
+[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
+ Protocol Specification", Internet Draft, April 2001.
+
+[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
+ Protocols", Internet Draft, April 2001.
+
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001.
+
+[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+[Schneier] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996.
+
+[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
+ CRC Press 1997.
+
+[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+[ISAKMP] Maughan D., et al, "Internet Security Association and
+ Key Management Protocol (ISAKMP)", RFC 2408, November
+ 1998.
+
+[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
+ Authentication", RFC 2104, February 1997.
+
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+.ti 0
+5 Author's Address
+
+.nf
+Pekka Riikonen
+Kasarmikatu 11 A4
+70110 Kuopio
+Finland
+
+EMail: priikone@poseidon.pspt.fi
+
+This Internet-Draft expires XXX
--- /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 XXX
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-spec-03.txt XXX
+Expires: XXX
+
+.in 3
+
+.ce 3
+Secure Internet Live Conferencing (SILC),
+Protocol Specification
+<draft-riikonen-silc-spec-03.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 is IRC [IRC] like protocol, however, it is
+not equivalent to IRC and does not support IRC. Strong cryptographic
+methods are used to protect SILC packets inside the SILC network.
+Three other Internet Drafts relates very closely to this memo;
+SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication
+Protocols [SILC3] and SILC Commands [SILC4].
+
+
+
+
+
+
+.ti 0
+Table of Contents
+
+.nf
+1 Introduction .................................................. 3
+ 1.1 Requirements Terminology .................................. 4
+2 SILC Concepts ................................................. 4
+ 2.1 SILC Network Topology ..................................... 4
+ 2.2 Communication Inside a Cell ............................... 5
+ 2.3 Communication in the Network .............................. 6
+ 2.4 Channel Communication ..................................... 7
+ 2.5 Router Connections ........................................ 7
+ 2.6 Backup Routers ............................................ 8
+3 SILC Specification ............................................ 10
+ 3.1 Client .................................................... 10
+ 3.1.1 Client ID ........................................... 10
+ 3.2 Server .................................................... 11
+ 3.2.1 Server's Local ID List .............................. 12
+ 3.2.2 Server ID ........................................... 13
+ 3.2.3 SILC Server Ports ................................... 14
+ 3.3 Router .................................................... 14
+ 3.3.1 Router's Local ID List .............................. 14
+ 3.3.2 Router's Global ID List ............................. 15
+ 3.3.3 Router's Server ID .................................. 15
+ 3.4 Channels .................................................. 16
+ 3.4.1 Channel ID .......................................... 17
+ 3.5 Operators ................................................. 17
+ 3.6 SILC Commands ............................................. 18
+ 3.7 SILC Packets .............................................. 18
+ 3.8 Packet Encryption ......................................... 19
+ 3.8.1 Determination of the Source and the Destination ..... 19
+ 3.8.2 Client To Client .................................... 20
+ 3.8.3 Client To Channel ................................... 21
+ 3.8.4 Server To Server .................................... 22
+ 3.9 Key Exchange And Authentication ........................... 22
+ 3.9.1 Authentication Payload .............................. 22
+ 3.10 Algorithms ............................................... 24
+ 3.10.1 Ciphers ............................................ 24
+ 3.10.2 Public Key Algorithms .............................. 25
+ 3.10.3 Hash Functions ..................................... 26
+ 3.10.4 MAC Algorithms ..................................... 26
+ 3.10.5 Compression Algorithms ............................. 26
+ 3.11 SILC Public Key .......................................... 27
+ 3.12 SILC Version Detection ................................... 29
+4 SILC Procedures ............................................... 30
+ 4.1 Creating Client Connection ................................ 30
+ 4.2 Creating Server Connection ................................ 31
+ 4.2.1 Announcing Clients, Channels and Servers ............ 32
+ 4.3 Joining to a Channel ...................................... 33
+ 4.4 Channel Key Generation .................................... 34
+ 4.5 Private Message Sending and Reception ..................... 34
+ 4.6 Private Message Key Generation ............................ 35
+ 4.7 Channel Message Sending and Reception ..................... 35
+ 4.8 Session Key Regeneration .................................. 36
+ 4.9 Command Sending and Reception ............................. 37
+ 4.10 Closing Connection ....................................... 37
+5 Security Considerations ....................................... 38
+6 References .................................................... 38
+7 Author's Address .............................................. 39
+
+
+
+.ti 0
+List of Figures
+
+.nf
+Figure 1: SILC Network Topology
+Figure 2: Communication Inside cell
+Figure 3: Communication Between Cells
+Figure 4: Router Connections
+Figure 5: SILC Public Key
+
+
+.ti 0
+1. Introduction
+
+This document describes a Secure Internet Live Conferencing (SILC)
+protocol which provides secure conferencing services over insecure
+network channel. SILC is IRC [IRC] like protocol, however, it is
+not equivalent to IRC and does not support IRC.
+
+Strong cryptographic methods are used to protect SILC packets inside
+the SILC network. Three other Internet Drafts relates very closely
+to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and
+Authentication Protocols [SILC3] and SILC Commands [SILC4].
+
+The protocol uses extensively packets as conferencing protocol
+requires message and command sending. The SILC Packet Protocol is
+described in [SILC2] and should be read to fully comprehend this
+document and protocol. [SILC2] also describes the packet encryption
+and decryption in detail.
+
+The security of SILC protocol, and for any security protocol for that
+matter, is based on strong and secure key exchange protocol. The SILC
+Key Exchange protocol is described in [SILC3] along with connection
+authentication protocol and should be read to fully comprehend this
+document and protocol.
+
+The SILC protocol has been developed to work on TCP/IP network
+protocol, although it could be made to work on other network protocols
+with only minor changes. However, it is recommended that TCP/IP
+protocol is used under SILC protocol. Typical implementation would
+be made in client-server model.
+
+
+.ti 0
+1.1 Requirements Terminology
+
+The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+MAY, and OPTIONAL, when they appear in this document, are to be
+interpreted as described in [RFC2119].
+
+
+.ti 0
+2. SILC Concepts
+
+This section describes various SILC protocol concepts that forms the
+actual protocol, and in the end, the actual SILC network. The mission
+of the protocol is to deliver messages from clients to other clients
+through routers and servers in secure manner. The messages may also
+be delivered from one client to many clients forming a group, also
+known as a channel.
+
+This section does not focus to security issues. Instead, basic network
+concepts are introduced to make the topology of the SILC network
+clear.
+
+
+.ti 0
+2.1 SILC Network Topology
+
+SILC network is a cellular network as opposed to tree style network
+topology. The rationale for this is to have servers that can perform
+specific kind of tasks what other servers cannot perform. This leads
+to two kinds of servers; normal SILC servers and SILC routers.
+
+A difference between normal server and router server is that routers
+knows everything about everything in the network. They also do the
+actual routing of the messages to the correct receiver. Normal servers
+knows only about local information and nothing about global information.
+This makes the network faster as there are less servers that needs to
+keep global information up to date at all time.
+
+This, on the other hand, leads to cellular like network, where routers
+are in the center of the cell and servers are connected to the router.
+
+
+
+
+
+
+
+The following diagram represents SILC network topology.
+
+.in 8
+.nf
+ ---- ---- ---- ---- ---- ----
+ | S8 | S5 | S4 | | S7 | S5 | S6 |
+ ----- ---- ----- ----- ---- -----
+| S7 | S/R1 | S2 | --- | S8 | S/R2 | S4 |
+ ---- ------ ---- ---- ------ ----
+ | S6 | S3 | S1 | | S1 | S3 | S2 | ---- ----
+ ---- ---- ---- ---- ---- ---- | S3 | S1 |
+ Cell 1. \\ Cell 2. | \\____ ----- -----
+ | | | S4 | S/R4 |
+ ---- ---- ---- ---- ---- ---- ---- ------
+ | S7 | S4 | S2 | | S1 | S3 | S2 | | S2 | S5 |
+ ----- ---- ----- ----- ---- ----- ---- ----
+ | S6 | S/R3 | S1 | --- | S4 | S/R5 | S5 | ____/ Cell 4.
+ ---- ------ ---- ---- ------ ----
+ | S8 | S5 | S3 | | S6 | S7 | S8 | ... etc ...
+ ---- ---- ---- ---- ---- ----
+ Cell 3. Cell 5.
+.in 3
+
+.ce
+Figure 1: SILC Network Topology
+
+
+A cell is formed when a server or servers connect to one router. In
+SILC network normal server cannot directly connect to other normal
+server. Normal server may only connect to SILC router which then
+routes the messages to the other servers in the cell. Router servers
+on the other hand may connect to other routers to form the actual SILC
+network, as seen in above figure. However, router is also normal SILC
+server; clients may connect to it the same way as to normal SILC
+server. Normal server also cannot have active connections to more
+than one router. Normal server cannot be connected to two different
+cells. Router servers, on the other hand, may have as many router to
+router connections as needed.
+
+There are many issues in this network topology that needs to be careful
+about. Issues like the size of the cells, the number of the routers in
+the SILC network and the capacity requirements of the routers. These
+issues should be discussed in the Internet Community and additional
+documents on the issue may be written.
+
+
+.ti 0
+2.2 Communication Inside a Cell
+
+It is always guaranteed that inside a cell message is delivered to the
+recipient with at most two server hops. A client which is connected to
+server in the cell and is talking on channel to other client connected
+to other server in the same cell, will have its messages delivered from
+its local server first to the router of the cell, and from the router
+to the other server in the cell.
+
+The following diagram represents this scenario:
+
+
+.in 25
+.nf
+1 --- S1 S4 --- 5
+ S/R
+ 2 -- S2 S3
+ / |
+ 4 3
+.in 3
+
+
+.ce
+Figure 2: Communication Inside cell
+
+
+Example: Client 1. connected to Server 1. send message to
+ Client 4. connected to Server 2. travels from Server 1.
+ first to Router which routes the message to Server 2.
+ which then sends it to the Client 4. All the other
+ servers in the cell will not see the routed message.
+
+
+If the client is connected directly to the router, as router is also normal
+SILC server, the messages inside the cell are always delivered only with
+one server hop. If clients communicating with each other are connected
+to the same server, no router interaction is needed. This is the optimal
+situation of message delivery in the SILC network.
+
+
+.ti 0
+2.3 Communication in the Network
+
+If the message is destined to server that does not belong to local cell
+the message is routed to the router server to which the destination
+server belongs, if the local router is connected to destination router.
+If there is no direct connection to the destination router, the local
+router routes the message to its primary route. The following diagram
+represents message sending between cells.
+
+
+.in 16
+.nf
+1 --- S1 S4 --- 5 S2 --- 1
+ S/R - - - - - - - - S/R
+ 2 -- S2 S3 S1
+ / | \\
+ 4 3 2
+
+ Cell 1. Cell 2.
+.in 3
+
+
+.ce
+Figure 3: Communication Between Cells
+
+
+Example: Client 5. connected to Server 4. in Cell 1. sends message
+ to Client 2. connected to Server 1. in Cell 2. travels
+ from Server 4. to Router which routes the message to
+ Router in Cell 2, which then routes the message to
+ Server 1. All the other servers and routers in the
+ network will not see the routed message.
+
+
+The optimal case of message delivery from the client point of view is
+when clients are connected directly to the routers and the messages
+are delivered from one router to the other.
+
+
+.ti 0
+2.4 Channel Communication
+
+Messages may be sent to group of clients as well. Sending messages to
+many clients works the same way as sending messages point to point, from
+message delivery point of view. Security issues are another matter
+which are not discussed in this section.
+
+Router server handles the message routing to multiple recipients. If
+any recipient is not in the same cell as the sender the messages are
+routed further.
+
+Server distributes the channel message to its local clients which are
+joined to the channel. Router also distributes the message to its
+local clients on the channel.
+
+
+.ti 0
+2.5 Router Connections
+
+Router connections play very important role in making the SILC like
+network topology to work. For example, sending broadcast packets in
+SILC network require special connections between routers; routers must
+be connected in a specific way.
+
+Every router has their primary route which is a connection to another
+router in the network. Unless there is only two routers in the network
+must not routers use each other as their primary routes. The router
+connections in the network must form a circular.
+
+
+
+
+
+
+
+Example with three routers in the network:
+
+
+.in 16
+.nf
+ S/R1 - > - > - > - > - > - > - S/R2
+ \\ /
+ ^ v
+ \\ - < - < - S/R3 - < - < - /
+.in 3
+
+
+.ce
+Figure 4: Router Connections
+
+
+Example: Network with three routers. Router 1. uses Router 2. as its
+ primary router. Router 2. uses Router 3. as its primary router,
+ and Router 3. uses Router 1. as its primary router. There may
+ be other direct connections between the routers but they must
+ not be used as primary routes.
+
+The above example is applicable to any amount of routers in the network
+except for two routers. If there are only two routers in the network both
+routers must be able to handle situation where they use each other as their
+primary routes.
+
+The issue of router connections are very important especially with SILC
+broadcast packets. Usually all router wide information in the network is
+distributed by SILC broadcast packets.
+
+
+.ti 0
+2.6 Backup Routers
+
+Backup routers may exist in the cell in addition of the primary router.
+However, they must not be active routers and act as routers in the cell.
+Only one router may be acting as primary router in the cell. In the case
+of failure of the primary router may one of the backup routers become
+active. The purpose of backup routers are in case of failure of the
+primary router to maintain working connections inside the cell and outside
+the cell and to avoid netsplits.
+
+Backup routers are normal servers in the cell that are prepared to take
+over the tasks of the primary router if needed. They need to have at
+least one direct and active connection to the primary router of the cell.
+This communication channel is used to send the router information to
+the backup router.
+
+Backup router must know everything that the primary router knows to be
+able to take over the tasks of the primary router. It is the primary
+router's responsibility to feed the data to the backup router. If the
+backup router does not know all the data in the case of failure some
+connections may be lost. The primary router of the cell must consider
+the backup router being normal router server and feed the data
+accordingly.
+
+In addition of having direct connection to the primary router of the
+cell the backup router must also have connection to the same router
+the primary router of the cell is connected. However, it must not be
+active router connection meaning that the backup router must not use
+that channel as its primary route and it must not notify the router
+about having connected servers, channels and clients behind it. It
+merely connects to the router. This sort of connection is later
+referred as being passive connection. Some keepalive actions may be
+needed by the router to keep the connection alive.
+
+The primary router notifies its primary router about having backup
+routers in the cell by sending SILC_PACKET_CELL_ROUTERS packet. If
+and when the primary router of the cell becomes unresponsive, its
+primary router knows that there exists backup routers in the cell.
+After that it will start using the first backup router sent in the
+packet as router of that cell.
+
+In this case the backup router must notify its new primary router about
+the servers, channels and clients it has connected to it. The primary
+router knows that this server has become a router of the cell because
+of failure of the primary router in the cell. It must also cope with
+the fact that the servers, channels and clients that the new backup
+router announces are not really new, since they used to exist in the
+primary router of the cell.
+
+It is required that other normal servers has passive connections to
+the backup router(s) in the cell. Some keepalive actions may be needed
+by the server to keep the connection alive. After they notice the
+failure of the primary router they must start using the connection to
+the first backup router as their primary route.
+
+It is RECOMMENDED that there would be at least one backup router in
+the cell. It is NOT RECOMMENDED to have all servers in the cell acting
+as backup routers as it requires establishing several connections to
+several servers in the cell. Large cells can easily have several
+backup routers in the cell.
+
+The order of the backup routers are decided at the primary router of the
+cell and servers and backup routers in the cell must be configured
+accordingly. It is not required that the backup server is actually
+active server in the cell. Backup router may be a spare server in the
+cell that does not accept normal client connections at all. It may be
+reserved purely for the backup purposes. These, however, are cell
+management issues.
+
+If also the first backup router is down as well and there is another
+backup router in the cell then it will start acting as the primary
+router as described above.
+
+
+.ti 0
+3. SILC Specification
+
+This section describes the SILC protocol. However, [SILC2] and
+[SILC3] describes other important protocols that are part of this SILC
+specification and must be read.
+
+
+.ti 0
+3.1 Client
+
+A client is a piece of software connecting to SILC server. SILC client
+cannot be SILC server. Purpose of clients is to provide the user
+interface of the SILC services for end user. Clients are distinguished
+from other clients by unique Client ID. Client ID is a 128 bit ID that
+is used in the communication in the SILC network. The client ID is
+based on the nickname selected by the user. User uses logical nicknames
+in communication which are then mapped to the corresponding Client ID.
+Client ID's are low level identifications and must not be seen by the
+end user.
+
+Clients provide other information about the end user as well. Information
+such as the nickname of the user, username and the host name of the end
+user and user's real name. See section 3.2 Server for information of
+the requirements of keeping this information.
+
+The nickname selected by the user is not unique in the SILC network.
+There can be 2^8 same nicknames for one IP address. As for comparison
+to IRC [IRC] where nicknames are unique this is a fundamental difference
+between SILC and IRC. This causes the server names or client's host names
+to be used along with the nicknames to identify specific users when sending
+messages. This feature of SILC makes IRC style nickname-wars obsolete as
+no one owns their nickname; there can always be someone else with the same
+nickname. The maximum length of nickname is 128 characters.
+
+
+.ti 0
+3.1.1 Client ID
+
+Client ID is used to identify users in the SILC network. The Client ID
+is unique to the extent that there can be 2^128 different Client ID's,
+and ID's based on IPv6 addresses extends this to 2^224 different Client
+ID's. Collisions are not expected to happen. The Client ID is defined
+as follows.
+
+
+
+.in 6
+128 bit Client ID based on IPv4 addresses:
+
+32 bit Server ID IP address (bits 1-32)
+ 8 bit Random number or counter
+88 bit Truncated MD5 hash value of the nickname
+
+224 bit Client ID based on IPv6 addresses:
+
+128 bit Server ID IP address (bits 1-128)
+ 8 bit Random number or counter
+ 88 bit Truncated MD5 hash value of the nickname
+
+o Server ID IP address - Indicates the server where this
+ client is coming from. The IP address hence equals the
+ server IP address where to the client has connected.
+
+o Random number or counter - Random number to further
+ randomize the Client ID. Another choice is to use
+ a counter starting from the zero (0). This makes it
+ possible to have 2^8 same nicknames from the same
+ server IP address.
+
+o MD5 hash - MD5 hash value of the nickname is truncated
+ taking 88 bits from the start of the hash value. This
+ hash value is used to search the user's Client ID from
+ the ID lists.
+
+.in 3
+Collisions could occur when more than 2^8 clients using same nickname
+from the same server IP address is connected to the SILC network.
+Server MUST be able to handle this situation by refusing to accept
+anymore of that nickname.
+
+Another possible collision may happen with the truncated hash value of
+the nickname. It could be possible to have same truncated hash value for
+two different nicknames. However, this is not expected to happen nor
+cause any problems if it would occur. Nicknames are usually logical and
+it is unlikely to have two distinct logical nicknames produce same
+truncated hash value.
+
+
+.ti 0
+3.2 Server
+
+Servers are the most important parts of the SILC network. They form the
+basis of the SILC, providing a point to which clients may connect to.
+There are two kinds of servers in SILC; normal servers and router servers.
+This section focus on the normal server and router server is described
+in the section 3.3 Router.
+
+Normal servers MUST NOT directly connect to other normal server. Normal
+servers may only directly connect to router server. If the message sent
+by the client is destined outside the local server it is always sent to
+the router server for further routing. Server may only have one active
+connection to router on same port. Normal server MUST NOT connect to other
+cell's router except in situations where its cell's router is unavailable.
+
+Servers and routers in the SILC network are considered to be trusted.
+With out a doubt, servers that are set to work on ports above 1023 are
+not considered to be trusted. Also, the service provider acts important
+role in the server's trustworthy.
+
+
+.ti 0
+3.2.1 Server's Local ID List
+
+Normal server keeps various information about the clients and their end
+users connected to it. Every normal server MUST keep list of all locally
+connected clients, Client ID's, nicknames, usernames and host names and
+user's real name. Normal servers only keeps local information and it
+does not keep any global information. Hence, normal servers knows only
+about their locally connected clients. This makes servers efficient as
+they don't have to worry about global clients. Server is also responsible
+of creating the Client ID's for their clients.
+
+Normal server also keeps information about locally created channels and
+their Channel ID's.
+
+
+Hence, local list for normal server includes:
+
+.in 6
+server list - Router connection
+ o Server name
+ o Server IP address
+ o Server ID
+ o Sending key
+ o Receiving key
+ o Public key
+
+client list - All clients in server
+ o Nickname
+ o Username@host
+ o Real name
+ o Client ID
+ o Sending key
+ o Receiving key
+ o Public key
+
+
+channel list - All channels in server
+ o Channel name
+ o Channel ID
+ o Client ID's on channel
+ o Client ID modes on channel
+ o Channel key
+.in 3
+
+
+.ti 0
+3.2.2 Server ID
+
+Servers are distinguished from other servers by unique 64 bit Server ID
+(for IPv4) or 160 bit Server ID (for IPv6). The Server ID is used in
+the SILC to route messages to correct servers. Server ID's also provide
+information for Client ID's, see section 3.1.1 Client ID. Server ID is
+defined as follows.
+
+.in 6
+64 bit Server ID based on IPv4 addresses:
+
+32 bit IP address of the server
+16 bit Port
+16 bit Random number
+
+160 bit Server ID based on IPv6 addresses:
+
+128 bit IP address of the server
+ 16 bit Port
+ 16 bit Random number
+
+o IP address of the server - This is the real IP address of
+ the server.
+
+o Port - This is the port the server is bound to.
+
+o Random number - This is used to further randomize the Server ID.
+
+.in 3
+Collisions are not expected to happen in any conditions. The Server ID
+is always created by the server itself and server is responsible of
+distributing it to the router.
+
+
+.ti 0
+3.2.3 SILC Server Ports
+
+The following ports has been assigned by IANA for the SILC protocol:
+
+.in 10
+silc 706/tcp SILC
+silc 706/udp SILC
+.in 3
+
+
+If there are needs to create new SILC networks in the future the port
+numbers must be officially assigned by the IANA.
+
+Server on network above privileged ports (>1023) SHOULD NOT be trusted
+as they could have been set up by untrusted party.
+
+
+.ti 0
+3.3 Router
+
+Router server in SILC network is responsible for keeping the cell together
+and routing messages to other servers and to other routers. Router server
+is also a normal server thus clients may connect to it as it would be
+just normal SILC server.
+
+However, router servers has a lot of important tasks that normal servers
+do not have. Router server knows everything about everything in the SILC.
+They know all clients currently on SILC, all servers and routers and all
+channels in SILC. Routers are the only servers in SILC that care about
+global information and keeping them up to date at all time. And, this
+is what they must do.
+
+
+.ti 0
+3.3.1 Router's Local ID List
+
+Router server as well MUST keep local list of connected clients and
+locally created channels. However, this list is extended to include all
+the informations of the entire cell, not just the server itself as for
+normal servers.
+
+However, on router this list is a lot smaller since routers do not need
+to keep information about user's nickname, username and host name and real
+name since these are not needed by the router. The router keeps only
+information that it needs.
+
+
+Hence, local list for router includes:
+
+.in 6
+server list - All servers in the cell
+ o Server name
+ o Server ID
+ o Router's Server ID
+ o Sending key
+ o Receiving key
+
+client list - All clients in the cell
+ o Client ID
+
+
+channel list - All channels in the cell
+ o Channel ID
+ o Client ID's on channel
+ o Client ID modes on channel
+ o Channel key
+.in 3
+
+
+Note that locally connected clients and other information include all the
+same information as defined in section section 3.2.1 Server's Local ID
+List.
+
+
+.ti 0
+3.3.2 Router's Global ID List
+
+Router server MUST also keep global list. Normal servers do not have
+global list as they know only about local information. Global list
+includes all the clients on SILC, their Client ID's, all created channels
+and their Channel ID's and all servers and routers on SILC and their
+Server ID's. That is said, global list is for global information and the
+list must not include the local information already on the router's local
+list.
+
+Note that the global list does not include information like nicknames,
+usernames and host names or user's real names. Router does not need to
+keep these informations as they are not needed by the router. This
+information is available from the client's server which maybe queried
+when needed.
+
+Hence, global list includes:
+
+.in 6
+server list - All servers in SILC
+ o Server name
+ o Server ID
+ o Router's Server ID
+
+client list - All clients in SILC
+ o Client ID
+
+channel list - All channels in SILC
+ o Channel ID
+ o Client ID's on channel
+ o Client ID modes on channel
+.in 3
+
+
+
+
+
+
+
+
+.ti 0
+3.3.3 Router's Server ID
+
+Router's Server ID's are equivalent to normal Server ID's. As routers
+are normal servers as well same types of ID's applies for routers as well.
+Thus, see section 3.2.2 Server ID.
+
+
+.ti 0
+3.4 Channels
+
+A channel is a named group of one or more clients which will all receive
+messages addressed to that channel. The channel is created when first
+client requests JOIN command to the channel, and the channel ceases to
+exist when the last client has left it. When channel exists, any client
+can reference it using the name of the channel.
+
+Channel names are unique although the real uniqueness comes from 64 bit
+Channel ID. However, channel names are still unique and no two global
+channels with same name may exist. The Channel name is a string of
+maximum length of 256 characters. Channel names MUST NOT contain any
+spaces (` '), any non-printable ASCII characters, commas (`,') and
+wildcard characters.
+
+Channels can have operators that can administrate the channel and
+operate all of its modes. The following operators on channel exist on
+the SILC network.
+
+.in 6
+o Channel founder - When channel is created the joining client becomes
+ channel founder. Channel founder is channel operator with some more
+ privileges. Basically, channel founder can fully operate the channel
+ and all of its modes. The privileges are limited only to the
+ particular channel. There can be only one channel founder per
+ channel. Channel founder supersedes channel operator's privileges.
+
+ Channel founder privileges cannot be removed by any other operator on
+ channel. When channel founder leaves the channel there is no channel
+ founder on the channel. However, it is possible to set a mode for
+ the channel which allows the original channel founder to regain the
+ founder privileges even after leaving the channel. Channel founder
+ also cannot be removed by force from the channel.
+
+o Channel operator - When client joins to channel that has not existed
+ previously it will become automatically channel operator (and channel
+ founder discussed above). Channel operator is able administrate the
+ channel, set some modes on channel, remove a badly behaving client
+ from the channel and promote other clients to become channel
+ operator. The privileges are limited only to the particular channel.
+
+ Normal channel user may be promoted (opped) to channel operator
+ gaining channel operator privileges. Channel founder or other
+ channel operator may also demote (deop) channel operator to normal
+ channel user.
+.in 3
+
+
+.ti 0
+3.4.1 Channel ID
+
+Channels are distinguished from other channels by unique Channel ID.
+The Channel ID is a 64 bit ID (for IPv4) or 160 bit ID (for IPv6), and
+collisions are not expected to happen in any conditions. Channel names
+are just for logical use of channels. The Channel ID is created by the
+server where the channel is created. The Channel ID is defined as
+follows.
+
+.in 6
+64 bit Channel ID based on IPv4 addresses:
+
+32 bit Router's Server ID IP address (bits 1-32)
+16 bit Router's Server ID port (bits 33-48)
+16 bit Random number
+
+160 bit Channel ID based on IPv6 addresses:
+
+128 bit Router's Server ID IP address (bits 1-128)
+ 16 bit Router's Server ID port (bits 129-144)
+ 16 bit Random number
+
+o Router's Server ID IP address - Indicates the IP address of
+ the router of the cell where this channel is created. This is
+ taken from the router's Server ID. This way SILC router knows
+ where this channel resides in the SILC network.
+
+o Router's Server ID port - Indicates the port of the channel on
+ the server. This is taken from the router's Server ID.
+
+o Random number - To further randomize the Channel ID. This makes
+ sure that there are no collisions. This also means that
+ in a cell there can be 2^16 channels.
+.in 3
+
+
+.ti 0
+3.5 Operators
+
+Operators are normal users with extra privileges to their server or
+router. Usually these people are SILC server and router administrators
+that take care of their own server and clients on them. The purpose of
+operators is to administrate the SILC server or router. However, even
+an operator with highest privileges is not able to enter invite-only
+channel, to gain access to the contents of a encrypted and authenticated
+packets traveling in the SILC network or to gain channel operator
+privileges on public channels without being promoted. They have the
+same privileges as everyone else except they are able to administrate
+their server or router.
+
+
+.ti 0
+3.6 SILC Commands
+
+Commands are very important part on SILC network especially for client
+which uses commands to operate on the SILC network. Commands are used
+to set nickname, join to channel, change modes and many other things.
+
+Client usually sends the commands and server replies by sending a reply
+packet to the command. Server MAY also send commands usually to serve
+the original client's request. However, server MUST NOT send commands
+to client and there are some commands that server must not send.
+
+Note that the command reply is usually sent only after client has sent
+the command request but server is allowed to send command reply packet
+to client even if client has not requested the command. Client MAY,
+choose to ignore the command reply.
+
+It is expected that some of the commands may be miss-used by clients
+resulting various problems on the server side. Every implementation
+SHOULD assure that commands may not be executed more than once, say,
+in two (2) seconds. However, to keep response rate up, allowing for
+example five (5) commands before limiting is allowed. It is RECOMMENDED
+that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN,
+SILC_COMMAND_LEAVE and SILC_COMMAND_KILL SHOULD be limited in all cases
+as they require heavy operations. This should be sufficient to prevent
+the miss-use of commands.
+
+SILC commands are described in [SILC4].
+
+
+.ti 0
+3.7 SILC Packets
+
+Packets are naturally the most important part of the protocol and the
+packets are what actually makes the protocol. Packets in SILC network
+are always encrypted using, usually the shared secret session key
+or some other key, for example, channel key, when encrypting channel
+messages. The SILC Packet Protocol is a wide protocol and is described
+in [SILC2]. This document does not define or describe details of
+SILC packets.
+
+
+
+
+
+.ti 0
+3.8 Packet Encryption
+
+All packets passed in SILC network MUST be encrypted. This section
+defines how packets must be encrypted in the SILC network. The detailed
+description of the actual encryption process of the packets are
+described in [SILC2].
+
+Client and its server shares secret symmetric session key which is
+established by the SILC Key Exchange Protocol, described in [SILC3].
+Every packet sent from client to server, with exception of packets for
+channels, are encrypted with this session key.
+
+Channels has their own key that are shared by every client on the channel.
+However, the channel keys are cell specific thus one cell does not know
+the channel key of the other cell, even if that key is for same channel.
+Channel key is also known by the routers and all servers that has clients
+on the channel. However, channels MAY have channel private keys that
+are entirely local setting for the client. All clients on the channel
+MUST know the channel private key before hand to be able to talk on the
+channel. In this case, no server or router know the key for channel.
+
+Server shares secret symmetric session key with router which is
+established by the SILC Key Exchange Protocol. Every packet passed from
+server to router, with exception of packets for channels, are encrypted
+with the shared session key. Same way, router server shares secret
+symmetric key with its primary route. However, every packet passed
+from router to other router, including packets for channels, are
+encrypted with the shared session key. Every router connection has
+their own session keys.
+
+
+.ti 0
+3.8.1 Determination of the Source and the Destination
+
+The source and the destination of the packet needs to be determined
+to be able to route the packets to correct receiver. This information
+is available in the SILC Packet Header which is included in all packets
+sent in SILC network. The SILC Packet Header is described in [SILC2].
+
+The header MUST be encrypted with the session key who is next receiver
+of the packet along the route. The receiver of the packet, for example
+a router along the route, is able to determine the sender and the
+destination of the packet by decrypting the SILC Packet Header and
+checking the ID's attached to the header. The ID's in the header will
+tell to where the packet needs to be sent and where it is coming from.
+
+The header in the packet MUST NOT change during the routing of the
+packet. The original sender, for example client, assembles the packet
+and the packet header and server or router between the sender and the
+receiver MUST NOT change the packet header.
+
+Note that the packet and the packet header may be encrypted with
+different keys. For example, packets to channels are encrypted with
+the channel key, however, the header is encrypted with the session key
+as described above. However, the header and the packet may be encrypted
+with same key. This is the case, for example, with command packets.
+
+
+.ti 0
+3.8.2 Client To Client
+
+The process of message delivery and encryption from client to another
+client is as follows.
+
+Example: Private message from client to another client on different
+ servers. Clients do not share private message delivery
+ keys; normal session keys are used.
+
+o Client 1. sends encrypted packet to its server. The packet is
+ encrypted with the session key shared between client and its
+ server.
+
+o Server determines the destination of the packet and decrypts
+ the packet. Server encrypts the packet with session key shared
+ between the server and its router, and sends the packet to the
+ router.
+
+o Router determines the destination of the packet and decrypts
+ the packet. Router encrypts the packet with session key
+ shared between the router and the destination server, and sends
+ the packet to the server.
+
+o Server determines the client to which the packet is destined
+ to and decrypts the packet. Server encrypts the packet with
+ session key shared between the server and the destination client,
+ and sends the packet to the client.
+
+o Client 2. decrypts the packet.
+
+
+Example: Private message from client to another client on different
+ servers. Clients has established secret shared private
+ message delivery key with each other and that is used in
+ the message encryption.
+
+o Client 1. sends encrypted packet to its server. The packet is
+ encrypted with the private message delivery key shared between
+ clients.
+
+o Server determines the destination of the packet and sends the
+ packet to the router.
+
+o Router determines the destination of the packet and sends the
+ packet to the server.
+
+o Server determines the client to which the packet is destined
+ to and sends the packet to the client.
+
+o Client 2. decrypts the packet with the secret shared key.
+
+
+If clients share secret key with each other the private message
+delivery is much simpler since servers and routers between the
+clients do not need to decrypt and re-encrypt the packet.
+
+The process for clients on same server is much simpler as there are
+no need to send the packet to the router. The process for clients
+on different cells is same as above except that the packet is routed
+outside the cell. The router of the destination cell routes the
+packet to the destination same way as described above.
+
+
+.ti 0
+3.8.3 Client To Channel
+
+Process of message delivery from client on channel to all the clients
+on the channel.
+
+Example: Channel of four users; two on same server, other two on
+ different cells. Client sends message to the channel.
+
+o Client 1. encrypts the packet with channel key and sends the
+ packet to its server.
+
+o Server determines local clients on the channel and sends the
+ packet to the Client on the same server. Server then sends
+ the packet to its router for further routing.
+
+o Router determines local clients on the channel, if found
+ sends packet to the local clients. Router determines global
+ clients on the channel and sends the packet to its primary
+ router or fastest route.
+
+o (Other router(s) do the same thing and sends the packet to
+ the server(s))
+
+o Server determines local clients on the channel and sends the
+ packet to the client.
+
+o All clients receiving the packet decrypts the packet.
+
+
+.ti 0
+3.8.4 Server To Server
+
+Server to server packet delivery and encryption is described in above
+examples. Router to router packet delivery is analogous to server to
+server. However, some packets, such as channel packets, are processed
+differently. These cases are described later in this document and
+more in detail in [SILC2].
+
+
+.ti 0
+3.9 Key Exchange And Authentication
+
+Key exchange is done always when for example client connects to server
+but also when server and router, and router and router connects to each
+other. The purpose of key exchange protocol is to provide secure key
+material to be used in the communication. The key material is used to
+derive various security parameters used to secure SILC packets. The
+SILC Key Exchange protocol is described in detail in [SILC3].
+
+Authentication is done after key exchange protocol has been successfully
+completed. The purpose of authentication is to authenticate for example
+client connecting to the server. However, usually clients are accepted
+to connect to server without explicit authentication. Servers are
+required use authentication protocol when connecting. The authentication
+may be based on passphrase (pre-shared-secret) or public key. The
+connection authentication protocol is described in detail in [SILC3].
+
+
+.ti 0
+3.9.1 Authentication Payload
+
+Authentication payload is used separately from the SKE and the Connection
+Authentication protocol. It is used during the session to authenticate
+with the remote. For example, the client can authenticate itself to the
+server to become server operator. In this case, Authentication Payload is
+used.
+
+
+
+
+
+
+
+
+
+
+
+The format of the Authentication Payload is as follows:
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Payload Length | Authentication Method |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Public Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Authentication Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Authentication Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 5: Authentication Payload
+
+
+.in 6
+o Payload Length (2 bytes) - Length of the entire payload.
+
+o Authentication Method (2) - The method of the authentication.
+ The authentication methods are defined in [SILC2] in the
+ Connection Auth Request Payload. The NONE authentication
+ method SHOULD NOT be used.
+
+o Public Data Length (2 bytes) - Indicates the length of
+ the Public Data field.
+
+o Public Data (variable length) - This is defined only if
+ the authentication method is public key. If it is any other
+ this field does not exist and the Public Data Length field
+ is set to zero (0).
+
+ When the authentication method is public key this includes
+ 128 to 4096 bytes of non-zero random data that is used in
+ the signature process, described subsequently.
+
+o Authentication Data Length (2 bytes) - Indicates the
+ length of the Authentication Data field.
+
+o Authentication Data (variable length) - Authentication
+ method dependent authentication data.
+.in 3
+
+
+If the authentication method is password based, the Authentication
+Data field includes the plaintext password. It is safe to send
+plaintext password since the entire payload is encrypted. In this
+case the Public Data Length is set to zero (0).
+
+If the authentication method is public key based (or certificate)
+the Authentication Data is computed as follows:
+
+ HASH = hash(random bytes | ID | public key (or certificate));
+ Authentication Data = sign(HASH);
+
+The hash() and the sign() are the hash function and the public key
+cryptography function selected in the SKE protocol. The public key
+is SILC style public key unless certificates are used. The ID is the
+entity's ID (Client or Server ID) which is authenticating itself. The
+ID is raw ID data. The random bytes are non-zero random bytes of
+length between 128 and 4096 bytes, and will be included into the
+Public Data field as is.
+
+The receiver will compute the signature using the random data received
+in the payload, the ID associated to the connection and the public key
+(or certificate) received in the SKE protocol. After computing the
+receiver MUST verify the signature. In this case also, the entire
+payload is encrypted.
+
+
+.ti 0
+3.10 Algorithms
+
+This section defines all the allowed algorithms that can be used in
+the SILC protocol. This includes mandatory cipher, mandatory public
+key algorithm and MAC algorithms.
+
+
+.ti 0
+3.10.1 Ciphers
+
+Cipher is the encryption algorithm that is used to protect the data
+in the SILC packets. See [SILC2] of the actual encryption process and
+definition of how it must be done. SILC has a mandatory algorithm that
+must be supported in order to be compliant with this protocol.
+
+The following ciphers are defined in SILC protocol:
+
+.in 6
+aes-256-cbc AES in CBC mode, 256 bit key (REQUIRED)
+aes-192-cbc AES in CBC mode, 192 bit key (OPTIONAL)
+aes-128-cbc AES in CBC mode, 128 bit key (OPTIONAL)
+twofish-256-cbc Twofish in CBC mode, 256 bit key (OPTIONAL)
+twofish-192-cbc Twofish in CBC mode, 192 bit key (OPTIONAL)
+twofish-128-cbc Twofish in CBC mode, 128 bit key (OPTIONAL)
+blowfish-128-cbc Blowfish in CBC mode, 128 bit key (OPTIONAL)
+cast-256-cbc CAST-256 in CBC mode, 256 bit key (OPTIONAL)
+cast-192-cbc CAST-256 in CBC mode, 192 bit key (OPTIONAL)
+cast-128-cbc CAST-256 in CBC mode, 128 bit key (OPTIONAL)
+rc6-256-cbc RC6 in CBC mode, 256 bit key (OPTIONAL)
+rc6-192-cbc RC6 in CBC mode, 192 bit key (OPTIONAL)
+rc6-128-cbc RC6 in CBC mode, 128 bit key (OPTIONAL)
+mars-256-cbc Mars in CBC mode, 256 bit key (OPTIONAL)
+mars-192-cbc Mars in CBC mode, 192 bit key (OPTIONAL)
+mars-128-cbc Mars in CBC mode, 128 bit key (OPTIONAL)
+none No encryption (OPTIONAL)
+.in 3
+
+
+Algorithm none does not perform any encryption process at all and
+thus is not recommended to be used. It is recommended that no client
+or server implementation would accept none algorithms except in special
+debugging mode.
+
+Additional ciphers MAY be defined to be used in SILC by using the
+same name format as above.
+
+
+.ti 0
+3.10.2 Public Key Algorithms
+
+Public keys are used in SILC to authenticate entities in SILC network
+and to perform other tasks related to public key cryptography. The
+public keys are also used in the SILC Key Exchange protocol [SILC3].
+
+The following public key algorithms are defined in SILC protocol:
+
+.in 6
+rsa RSA (REQUIRED)
+dss DSS (OPTIONAL)
+.in 3
+
+DSS is described in [Menezes]. The RSA MUST be implemented according
+PKCS #1 [PKCS1]. The mandatory PKCS #1 implementation in SILC MUST be
+compliant to either PKCS #1 version 1.5 or newer with the following
+notes: The signature encoding is always in same format as the encryption
+encoding regardless of the PKCS #1 version. The signature with appendix
+(with hash algorithm OID in the data) MUST NOT be used in the SILC. The
+rationale for this is that there is no binding between the PKCS #1 OIDs
+and the hash algorithms used in the SILC protocol. Hence, the encoding
+is always in PKCS #1 version 1.5 format.
+
+Additional public key algorithms MAY be defined to be used in SILC.
+
+
+
+
+.ti 0
+3.10.3 Hash Functions
+
+Hash functions are used as part of MAC algorithms defined in the next
+section. They are also used in the SILC Key Exchange protocol defined
+in the [SILC3].
+
+The following Hash algorithm are defined in SILC protocol:
+
+.in 6
+sha1 SHA-1, length = 20 (REQUIRED)
+md5 MD5, length = 16 (OPTIONAL)
+.in 3
+
+
+.ti 0
+3.10.4 MAC Algorithms
+
+Data integrity is protected by computing a message authentication code
+(MAC) of the packet data. See [SILC2] for details how to compute the
+MAC.
+
+The following MAC algorithms are defined in SILC protocol:
+
+.in 6
+hmac-sha1-96 HMAC-SHA1, length = 12 (REQUIRED)
+hmac-md5-96 HMAC-MD5, length = 12 (OPTIONAL)
+hmac-sha1 HMAC-SHA1, length = 20 (OPTIONAL)
+hmac-md5 HMAC-MD5, length = 16 (OPTIONAL)
+none No MAC (OPTIONAL)
+.in 3
+
+The none MAC is not recommended to be used as the packet is not
+authenticated when MAC is not computed. It is recommended that no
+client or server would accept none MAC except in special debugging
+mode.
+
+The HMAC algorithm is described in [HMAC] and hash algorithms that
+are used as part of the HMACs are described in [Scheneir] and in
+[Menezes]
+
+Additional MAC algorithms MAY be defined to be used in SILC.
+
+
+.ti 0
+3.10.5 Compression Algorithms
+
+SILC protocol supports compression that may be applied to unencrypted
+data. It is recommended to use compression on slow links as it may
+significantly speed up the data transmission. By default, SILC does not
+use compression which is the mode that must be supported by all SILC
+implementations.
+
+
+
+The following compression algorithms are defined:
+
+.in 6
+none No compression (REQUIRED)
+zlib GNU ZLIB (LZ77) compression (OPTIONAL)
+.in 3
+
+Additional compression algorithms MAY be defined to be used in SILC.
+
+
+.ti 0
+3.11 SILC Public Key
+
+This section defines the type and format of the SILC public key. All
+implementations MUST support this public key type. See [SILC3] for
+other optional public key and certificate types allowed in the SILC
+protocol. Public keys in SILC may be used to authenticate entities
+and to perform other tasks related to public key cryptography.
+
+The format of the SILC Public Key is as follows:
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Key Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Algorithm Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Algorithm Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Identifier Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Identifier ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Public Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 5: SILC Public Key
+
+
+.in 6
+o Public Key Length (4 bytes) - Indicates the full length
+ of the public key, not including this field.
+
+o Algorithm Name Length (2 bytes) - Indicates the length
+ of the Algorithm Length field, not including this field.
+
+o Algorithm name (variable length) - Indicates the name
+ of the public key algorithm that the key is. See the
+ section 3.10.2 Public Key Algorithms for defined names.
+
+o Identifier Length (2 bytes) - Indicates the length of
+ the Identifier field, not including this field.
+
+o Identifier (variable length) - Indicates the identifier
+ of the public key. This data can be used to identify
+ the owner of the key. The identifier is of the following
+ format:
+
+ UN User name
+ HN Host name or IP address
+ RN Real name
+ E EMail address
+ O Organization
+ C Country
+
+
+ Examples of an identifier:
+
+ `UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi'
+
+ `UN=sam, HN=dummy.fi, RN=Sammy Sam, O=Company XYZ, C=Finland'
+
+ At least user name (UN) and host name (HN) MUST be provided as
+ identifier. The fields are separated by commas (`,'). If
+ comma is in the identifier string it must be written as `\\,',
+ for example, `O=Company XYZ\\, Inc.'.
+
+o Public Data (variable length) - Includes the actual
+ public data of the public key.
+
+ The format of this field for RSA algorithm is
+ as follows:
+
+ 4 bytes Length of e
+ variable length e
+ 4 bytes Length of n
+ variable length n
+
+
+ The format of this field for DSS algorithm is
+ as follows:
+
+ 4 bytes Length of p
+ variable length p
+ 4 bytes Length of q
+ variable length q
+ 4 bytes Length of g
+ variable length g
+ 4 bytes Length of y
+ variable length y
+
+ The variable length fields are multiple precession
+ integers encoded as strings in both examples.
+
+ Other algorithms must define their own type of this
+ field if they are used.
+.in 3
+
+All fields in the public key are in MSB (most significant byte first)
+order.
+
+
+.ti 0
+3.12 SILC Version Detection
+
+The version detection of both client and server is performed at the
+connection phase while executing the SILC Key Exchange protocol. The
+version identifier is exchanged between initiator and responder. The
+version identifier is of the following format:
+
+.in 6
+SILC-<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>]]
+.in 3
+
+Protocol version MAY provide both major and minor version. Currently
+implementations MUST set the protocol version and accept the protocol
+version as SILC-1.0-<software version>.
+
+Software version MAY provide major, minor and build version. The
+software version MAY be freely set and accepted.
+
+
+Thus, the version string could be, for example:
+
+.in 6
+SILC-1.0-1.2
+.in 3
+
+
+
+
+.ti 0
+4 SILC Procedures
+
+This section describes various SILC procedures such as how the
+connections are created and registered, how channels are created and
+so on. The section describes the procedures only generally as details
+are described in [SILC2] and [SILC3].
+
+
+.ti 0
+4.1 Creating Client Connection
+
+This section describes the procedure when client connects to SILC server.
+When client connects to server the server MUST perform IP address lookup
+and reverse IP address lookup to assure that the origin host really is
+who it claims to be. Client, host, connecting to server SHOULD have
+both valid IP address and fully qualified domain name (FQDN).
+
+After that the client and server performs SILC Key Exchange protocol
+which will provide the key material used later in the communication.
+The key exchange protocol MUST be completed successfully before the
+connection registration may continue. The SILC Key Exchange protocol
+is described in [SILC3].
+
+Typical server implementation would keep a list of connections that it
+allows to connect to the server. The implementation would check, for
+example, the connecting client's IP address from the connection list
+before the SILC Key Exchange protocol has been started. Reason for
+this is that if the host is not allowed to connect to the server there
+is no reason to perform the key exchange protocol.
+
+After successful key exchange protocol the client and server performs
+connection authentication protocol. The purpose of the protocol is to
+authenticate the client connecting to the server. Flexible
+implementation could also accept the client to connect to the server
+without explicit authentication. However, if authentication is
+desired for a specific client it may be based on passphrase or
+public key authentication. If authentication fails the connection
+MUST be terminated. The connection authentication protocol is described
+in [SILC3].
+
+After successful key exchange and authentication protocol the client
+registers itself by sending SILC_PACKET_NEW_CLIENT packet to the
+server. This packet includes various information about the client
+that the server uses to create the client. Server creates the client
+and sends SILC_PACKET_NEW_ID to the client which includes the created
+Client ID that the client MUST start using after that. After that
+all SILC packets from the client MUST have the Client ID as the
+Source ID in the SILC Packet Header, described in [SILC2].
+
+Client MUST also get the server's Server ID that is to be used as
+Destination ID in the SILC Packet Header when communicating with
+the server (for example when sending commands to the server). The
+ID may be resolved in two ways. Client can take the ID from an
+previously received packet from server that MUST include the ID,
+or to send SILC_COMMAND_INFO command and receive the Server ID as
+command reply.
+
+Server MAY choose not to use the information received in the
+SILC_PACKET_NEW_CLIENT packet. For example, if public key or
+certificate were used in the authentication, server MAY use those
+informations rather than what it received from client. This is suitable
+way to get the true information about client if it is available.
+
+The nickname of client is initially set to the username sent in the
+SILC_PACKET_NEW_CLIENT packet. User should set the nickname to more
+suitable by sending SILC_COMMAND_NICK command. However, this is not
+required as part of registration process.
+
+Server MUST also distribute the information about newly registered
+client to its router (or if the server is router, to all routers in
+the SILC network). More information about this in [SILC2].
+
+
+.ti 0
+4.2 Creating Server Connection
+
+This section describes the procedure when server connects to its
+router (or when router connects to other router, the cases are
+equivalent). The procedure is very much alike when client connects
+to the server thus it is not repeated here.
+
+One difference is that server MUST perform connection authentication
+protocol with proper authentication. A proper authentication is based
+on passphrase or public key authentication.
+
+After server and router has successfully performed the key exchange
+and connection authentication protocol, the server register itself
+to the router by sending SILC_PACKET_NEW_SERVER packet. This packet
+includes the server's Server ID that it has created by itself and
+other relevant information about the server.
+
+After router has received the SILC_PACKET_NEW_SERVER packet it
+distributes the information about newly registered server to all routers
+in the SILC network. More information about this in [SILC2].
+
+As client needed to resolve the destination ID this MUST be done by the
+server that connected to the router, as well. The way to resolve it is
+to get the ID from previously received packet. The server MAY also
+use SILC_COMMAND_INFO command to resolve the ID. Server MUST also start
+using its own Server ID as Source ID in SILC Packet Header and the
+router's Server ID as Destination when communicating with the router.
+
+
+.ti 0
+4.2.1 Announcing Clients, Channels and Servers
+
+After server or router has connected to the remote router, and it already
+has connected clients and channels it MUST announce them to the router.
+If the server is router server, also all the local servers in the cell
+MUST be announced.
+
+All clients are announced by compiling a list of ID Payloads into the
+SILC_PACKET_NEW_ID packet. All channels are announced by compiling a
+list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet. Also,
+the channel users on the channels must be announced by compiling a
+list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into
+the SILC_PACKET_NOTIFY packet. The users' modes on the channel must
+also be announced by compiling list of Notify Payloads with the
+SILC_NOTIFY_TYPE_CUMODE_CHANGE notify type into the SILC_PACKET_NOTIFY
+packet.
+
+The router MUST also announce the local servers by compiling list of
+ID Payloads into the SILC_PACKET_NEW_ID packet.
+
+The router which receives these lists MUST process them and broadcast
+the packets to its primary route.
+
+When processing the announced channels and channel users the router MUST
+check whether a channel exists already with the same name. If channel
+exists with the same name it MUST check whether the Channel ID is
+different. If the Channel ID is different the router MUST send the notify
+type SILC_NOTIFY_TYPE_CHANNEL_CHANGE to the server to force the channel ID
+change to the ID the router has. If the mode of the channel is different
+the router MUST send the notify type SILC_NOTIFY_TYPE_CMODE_CHANGE to the
+server to force the mode change to the mode that the router has.
+
+The router MUST also generate new channel key and distribute it to the
+channel. The key MUST NOT be generated if the SILC_CMODE_PRIVKEY mode
+is set.
+
+If the channel has channel founder on the router the router MUST send
+the notify type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server to force
+the mode change for the channel founder on the server. The channel
+founder privileges MUST be removed.
+
+The router processing the channels MUST also compile a list of
+Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into the
+SILC_PACKET_NOTIFY and send the packet to the server. This way the
+server (or router) will receive the clients on the channel that
+the router has.
+
+
+.ti 0
+4.3 Joining to a Channel
+
+This section describes the procedure when client joins to a channel.
+Client joins to channel by sending command SILC_COMMAND_JOIN to the
+server. If the receiver receiving join command is normal server the
+server MUST check its local list whether this channel already exists
+locally. This would indicate that some client connected to the server
+has already joined to the channel. If this is case the client is
+joined to the channel, new channel key is created and information about
+newly joined channel is sent to the router. The router is informed
+by sending SILC_NOTIFY_TYPE_JOIN notify type. The notify type MUST
+also be sent to the local clients on the channel. The new channel key
+is also sent to the router and to local clients on the channel.
+
+If the channel does not exist in the local list the client's command
+MUST be sent to the router which will then perform the actual joining
+procedure. When server receives the reply to the command from the
+router it MUST be sent to the client which sent the command originally.
+Server will also receive the channel key from the server that it MUST
+send to the client which originally requested the join command. The
+server MUST also save the channel key.
+
+If the receiver of the join command is router it MUST first check its
+local list whether anyone in the cell has already joined to the channel.
+If this is the case the client is joined to the channel and reply is
+sent to the client. If the command was sent by server the command reply
+is sent to the server which sent it. Then the router MUST also create
+new channel key and distribute it to all clients on the channel and
+all servers that has clients on the channel. Router MUST also send
+the SILC_NOTIFY_TYPE_JOIN notify type to local clients on the channel
+and to local servers that has clients on the channel.
+
+If the channel does not exist on the router's local list it MUST
+check the global list whether the channel exists at all. If it does
+the client is joined to the channel as described previously. If
+the channel does not exist the channel is created and the client
+is joined to the channel. The channel key is also created and
+distributed as previously described. The client joining to the created
+channel is made automatically channel founder and both channel founder
+and channel operator privileges is set for the client.
+
+If the router created the channel in the process, information about the
+new channel MUST be broadcasted to all routers. This is done by
+broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary
+route. When the router joins the client to the channel it MUST also
+send information about newly joined client to all routers in the SILC
+network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify
+type to the router's primary route.
+
+It is important to note that new channel key is created always when
+new client joins to channel, whether the channel has existed previously
+or not. This way the new client on the channel is not able to decrypt
+any of the old traffic on the channel. Client which receives the reply to
+the join command MUST start using the received Channel ID in the channel
+message communication thereafter. Client also receives the key for the
+channel in the command reply. Note that the channel key is never
+generated if the SILC_CMODE_PRIVKEY mode is set.
+
+
+.ti 0
+4.4 Channel Key Generation
+
+Channel keys are created by router which creates the channel by taking
+enough randomness from cryptographically strong random number generator.
+The key is generated always when channel is created, when new client
+joins a channel and after the key has expired. Key could expire for
+example in an hour.
+
+The key MUST also be re-generated whenever some client leaves a channel.
+In this case the key is created from scratch by taking enough randomness
+from the random number generator. After that the key is distributed to
+all clients on the channel. However, channel keys are cell specific thus
+the key is created only on the cell where the client, which left the
+channel, exists. While the server or router is creating the new channel
+key, no other client may join to the channel. Messages that are sent
+while creating the new key are still processed with the old key. After
+server has sent the SILC_PACKET_CHANNEL_KEY packet MUST client start
+using the new key. If server creates the new key the server MUST also
+send the new key to its router. See [SILC2] on more information about
+how channel messages must be encrypted and decrypted when router is
+processing them.
+
+When client receives the SILC_PACKET_CHANNEL_KEY packet with the
+Channel Key Payload it MUST process the key data to create encryption
+and decryption key, and to create the HMAC key that is used to compute
+the MACs of the channel messages. The processing is as follows:
+
+ channel_key = raw key data
+ HMAC key = hash(raw key data)
+
+The raw key data is the key data received in the Channel Key Payload.
+The hash() function is the hash function used in the HMAC of the channel.
+Note that the server MUST also save the channel key.
+
+
+.ti 0
+4.5 Private Message Sending and Reception
+
+Private messages are sent point to point. Client explicitly destines
+a private message to specific client that is delivered to only to that
+client. No other client may receive the private message. The receiver
+of the private message is destined in the SILC Packet Header as any
+other packet as well.
+
+If the sender of a private message does not know the receiver's Client
+ID, it MUST resolve it from server. There are two ways to resolve the
+client ID from server; it is RECOMMENDED that client implementations
+send SILC_COMMAND_IDENTIFY command to receive the Client ID. Client
+MAY also send SILC_COMMAND_WHOIS command to receive the Client ID.
+If the sender has received earlier a private message from the receiver
+it should have cached the Client ID from the SILC Packet Header.
+
+See [SILC2] for description of private message encryption and decryption
+process.
+
+
+.ti 0
+4.6 Private Message Key Generation
+
+Private message MAY be protected by the key generated by the client.
+The key may be generated and sent to the other client by sending packet
+SILC_PACKET_PRIVATE_MESSAGE_KEY which travels through the network
+and is secured by session keys. After that the private message key
+is used in the private message communication between those clients.
+
+Other choice is to entirely use keys that are not sent through
+the SILC network at all. This significantly adds security. This key
+would be pre-shared-key that is known by both of the clients. Both
+agree about using the key and starts sending packets that indicate
+that the private message is secured using private message key.
+
+The key material used as private message key is implementation issue.
+However, SILC_PACKET_KEY_AGREEMENT packet MAY be used to negotiate
+the key material. If the key is normal pre-shared-key or randomly
+generated key, and the SILC_PACKET_KEY_AGREEMENT was not used, then
+the key material SHOULD be processed as defined in the [SILC3]. In
+the processing, however, the HASH, as defined in [SILC3] MUST be
+ignored. After processing the key material it is employed as defined
+in [SILC3], however, the HMAC key material MUST be discarded.
+
+If the key is pre-shared-key or randomly generated the implementations
+should use the SILC protocol's mandatory cipher as the cipher. If the
+SKE was used to negotiate key material the cipher was negotiated as well.
+
+.ti 0
+4.7 Channel Message Sending and Reception
+
+Channel messages are delivered to group of users. The group forms a
+channel and all clients on the channel receives messages sent to the
+channel.
+
+Channel messages are destined to channel by specifying the Channel ID
+as Destination ID in the SILC Packet Header. The server MUST then
+distribute the message to all clients on the channel by sending the
+channel message destined explicitly to a client on the channel.
+
+See [SILC2] for description of channel message encryption and decryption
+process.
+
+
+.ti 0
+4.8 Session Key Regeneration
+
+Session keys MUST be regenerated periodically, say, once in an hour.
+The re-key process is started by sending SILC_PACKET_REKEY packet to
+other end, to indicate that re-key must be performed. The initiator
+of the connection SHOULD initiate the re-key.
+
+If perfect forward secrecy (PFS) flag was selected in the SILC Key
+Exchange protocol [SILC3] the re-key MUST cause new key exchange with
+SKE protocol. In this case the protocol is secured with the old key
+and the protocol results to new key material. See [SILC3] for more
+information. After the SILC_PACKET_REKEY packet is sent the sender
+will perform the SKE protocol.
+
+If PFS flag was set the resulted key material is processed as described
+in the section Processing the Key Material in [SILC3]. The difference
+with re-key in the processing is that the initial data for the hash
+function is just the resulted key material and not the HASH as it
+is not computed at all with re-key. Other than that, the key processing
+it equivalent to normal SKE negotiation.
+
+If PFS flag was not set, which is the default case, then re-key is done
+without executing SKE protocol. In this case, the new key is created by
+providing the current sending encryption key to the SKE protocol's key
+processing function. The process is described in the section Processing
+the Key Material in [SILC3]. The difference in the processing is that
+the initial data for the hash function is the current sending encryption
+key and not the SKE's KEY and HASH values. Other than that, the key
+processing is equivalent to normal SKE negotiation.
+
+After both parties has regenerated the session key, both MUST send
+SILC_PACKET_REKEY_DONE packet to each other. These packets are still
+secured with the old key. After these packets, the subsequent packets
+MUST be protected with the new key.
+
+
+
+
+.ti 0
+4.9 Command Sending and Reception
+
+Client usually sends the commands in the SILC network. In this case
+the client simply sends the command packet to server and the server
+processes it and replies with command reply packet.
+
+However, if the server is not able to process the command, it is sent
+to the server's router. This is case for example with commands such
+as, SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there
+are other commands as well. For example, if client sends the WHOIS
+command requesting specific information about some client the server must
+send the WHOIS command to router so that all clients in SILC network
+are searched. The router, on the other hand, sends the WHOIS command
+further to receive the exact information about the requested client.
+The WHOIS command travels all the way to the server which owns the client
+and it replies with command reply packet. Finally, the server which
+sent the command receives the command reply and it must be able to
+determine which client sent the original command. The server then
+sends command reply to the client. Implementations should have some
+kind of cache to handle, for example, WHOIS information. Servers
+and routers along the route could all cache the information for faster
+referencing in the future.
+
+The commands sent by server may be sent hop by hop until someone is able
+to process the command. However, it is preferred to destine the command
+as precisely as it is possible. In this case, other routers en route
+MUST route the command packet by checking the true sender and true
+destination of the packet. However, servers and routers MUST NOT route
+command reply packets to clients coming from other server. Client
+MUST NOT accept command reply packet originated from anyone else but
+from its own server.
+
+
+.ti 0
+4.10 Closing Connection
+
+When remote client connection is closed the server MUST send the notify
+type SILC_NOTIFY_TYPE_SIGNOFF to its primary router and to all channels
+the client was joined. The server MUST also save the client's information
+for a period of time for history purposes.
+
+When remote server or router connection is closed the server or router
+MUST also remove all the clients that was behind the server or router
+from the SILC Network. The server or router MUST also send the notify
+type SILC_NOTIFY_TYPE_SERVER_SIGNOFF to its primary router and to all
+local clients that are joined on the same channels with the remote
+server's or router's clients.
+
+
+.ti 0
+5 Security Considerations
+
+Security is central to the design of this protocol, and these security
+considerations permeate the specification. Common security considerations
+such as keeping private keys truly private and using adequate lengths for
+symmetric and asymmetric keys must be followed in order to maintain the
+security of this protocol.
+
+Special attention must also be paid on the servers and routers that are
+running the SILC service. The SILC protocol's security depends greatly
+on the security and the integrity of the servers and administrators that
+are running the service. It is recommended that some form of registration
+is required by the server and router administrator prior acceptance to
+the SILC Network. The clients must be able to trust the servers they
+are using.
+
+It is also recommended that router operators in the SILC Network would
+form a joint forum to discuss the router and SILC Network management
+issues. Also, router operators along with the cell's server operators
+should have a forum to discuss the cell management issues.
+
+
+.ti 0
+6 References
+
+[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ April 2001.
+
+[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
+ Protocols", Internet Draft, April 2001.
+
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001.
+
+[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+[Schneier] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996.
+
+[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
+ CRC Press 1997.
+
+[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+[ISAKMP] Maughan D., et al, "Internet Security Association and
+ Key Management Protocol (ISAKMP)", RFC 2408, November
+ 1998.
+
+[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
+ Authentication", RFC 2104, February 1997.
+
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+.ti 0
+7 Author's Address
+
+.nf
+Pekka Riikonen
+Kasarmikatu 11 A4
+70110 Kuopio
+Finland
+
+EMail: priikone@poseidon.pspt.fi
+
+This Internet-Draft expires XXX
#
# Configured PKCS.
#
-# Format: <name>:<module path>:<key length>
+# Format: <name>
#
-# NOTE: <module path> must be omitted as PKCS cannot be modules currently.
-#
-#[pkcs]
-#rsa::1024
-#dss::1024
+[pkcs]
+rsa
#
# Configured connections to servers.
#
# Configured PKCS.
#
-# Format: <name>:<module path>:<key length>
+# Format: <name>
#
-# NOTE: <module path> must be omitted as PKCS cannot be modules currently.
-#
-#[PKCS]
-#rsa::1024
-#dss::1024
+[PKCS]
+rsa
#
# Run SILC server as specific user and group. The server must be initially
# Format: <remote host>:<port>:<comment>
#
[DenyConnection]
-#10.2.1.99:0:Your connection has been denied
\ No newline at end of file
+#10.2.1.99:0:Your connection has been denied
if (!client->sockets) {
client->sockets = silc_calloc(1, sizeof(*client->sockets));
- client->sockets[0] = sock;
+ client->sockets[0] = silc_socket_dup(sock);
client->sockets_count = 1;
return;
}
for (i = 0; i < client->sockets_count; i++) {
if (client->sockets[i] == NULL) {
- client->sockets[i] = sock;
+ client->sockets[i] = silc_socket_dup(sock);
return;
}
}
client->sockets = silc_realloc(client->sockets, sizeof(*client->sockets) *
(client->sockets_count + 1));
- client->sockets[client->sockets_count] = sock;
+ client->sockets[client->sockets_count] = silc_socket_dup(sock);
client->sockets_count++;
}
for (i = 0; i < client->sockets_count; i++) {
if (client->sockets[i] == sock) {
+ silc_socket_free(sock);
client->sockets[i] = NULL;
return;
}
protocol as context. */
proto_ctx = silc_calloc(1, sizeof(*proto_ctx));
proto_ctx->client = (void *)client;
- proto_ctx->sock = conn->sock;
+ proto_ctx->sock = silc_socket_dup(conn->sock);
proto_ctx->rng = client->rng;
proto_ctx->responder = FALSE;
proto_ctx->send_packet = silc_client_protocol_ke_send_packet;
if (ctx->dest_id)
silc_free(ctx->dest_id);
ctx->sock->protocol = NULL;
+ silc_socket_free(ctx->sock);
/* Notify application of failure */
client->ops->connect(client, ctx->sock->user_data, FALSE);
if (ctx->dest_id)
silc_free(ctx->dest_id);
conn->sock->protocol = NULL;
+ silc_socket_free(ctx->sock);
/* Notify application of failure */
client->ops->connect(client, ctx->sock->user_data, FALSE);
silc_free(ctx->auth_data);
if (ctx->ske)
silc_ske_free(ctx->ske);
+ silc_socket_free(ctx->sock);
silc_free(ctx);
conn->sock->protocol = NULL;
}
to the protocol. */
proto_ctx = silc_calloc(1, sizeof(*proto_ctx));
proto_ctx->client = (void *)client;
- proto_ctx->sock = sock;
+ proto_ctx->sock = silc_socket_dup(sock);
proto_ctx->responder = FALSE;
proto_ctx->pfs = conn->rekey->pfs;
silc_packet_context_free(ctx->packet);
if (ctx->ske)
silc_ske_free(ctx->ske);
+ silc_socket_free(ctx->sock);
silc_free(ctx);
return;
}
silc_packet_context_free(ctx->packet);
if (ctx->ske)
silc_ske_free(ctx->ske);
+ silc_socket_free(ctx->sock);
silc_free(ctx);
}
{
SilcPacketContext *p = (SilcPacketContext *)context;
silc_client_notify_by_server(p->context, p->sock, p);
+ silc_socket_free(p->sock);
}
/* Destructor for the pending command callback */
SilcBuffer idp = silc_id_payload_encode(client_id, SILC_ID_CLIENT);
p->context = (void *)client;
- p->sock = conn->sock;
+ p->sock = silc_socket_dup(conn->sock);
silc_client_send_command(client, conn, SILC_COMMAND_WHOIS, ++conn->cmd_ident,
1, 3, idp->data, idp->len);
SilcBuffer buffer;
SilcIdType type;
uint16 idlen;
- unsigned char *id_data;
+ unsigned char *id_data = NULL;
int ret;
void *id;
return sizeof(RsaKey);
}
-SILC_PKCS_API_DATA_CONTEXT_LEN(rsa)
-{
- return sizeof(RsaDataContext);
-}
-
-SILC_PKCS_API_SET_ARG(rsa)
-{
- RsaDataContext *data_ctx = (RsaDataContext *)data_context;
-
- switch(argnum) {
- case 1:
- data_ctx->src = val;
- return TRUE;
- break;
- case 2:
- data_ctx->dst = val;
- return TRUE;
- break;
- case 3:
- data_ctx->exp = val;
- return TRUE;
- break;
- case 4:
- data_ctx->mod = val;
- return TRUE;
- break;
- default:
- return FALSE;
- break;
- }
-
- return FALSE;
-}
-
SILC_PKCS_API_ENCRYPT(rsa)
{
RsaKey *key = (RsaKey *)context;
#include "rsa_internal.h"
-/* Data context for RSA */
-typedef struct {
- SilcInt src;
- SilcInt dst;
- SilcInt exp;
- SilcInt mod;
-} RsaDataContext;
-
-RsaDataContext *silc_rsa_data_context;
-
/*
* SILC PKCS API for RSA
*/
SILC_PKCS_API_SET_PUBLIC_KEY(rsa);
SILC_PKCS_API_SET_PRIVATE_KEY(rsa);
SILC_PKCS_API_CONTEXT_LEN(rsa);
-SILC_PKCS_API_DATA_CONTEXT_LEN(rsa);
-SILC_PKCS_API_SET_ARG(rsa);
SILC_PKCS_API_ENCRYPT(rsa);
SILC_PKCS_API_DECRYPT(rsa);
SILC_PKCS_API_SIGN(rsa);
#include "ciphers.h" /* Includes cipher definitions */
-/* List of all ciphers in SILC. You can dynamically add new ciphers
- into the list. At the initialization of SILC this list is filled with
- the configured ciphers. */
-struct SilcCipherListStruct {
- SilcCipherObject *cipher;
- struct SilcCipherListStruct *next;
-};
-
/* Dynamically registered list of ciphers. */
-struct SilcCipherListStruct *silc_cipher_list = NULL;
+SilcDList silc_cipher_list = NULL;
-/* Staticly declared list of ciphers. This is used if system doesn't
- support SIM's. */
-SilcCipherObject silc_cipher_builtin_list[] =
+/* Static list of ciphers for silc_cipher_register_default(). */
+SilcCipherObject silc_default_ciphers[] =
{
{ "aes-256-cbc", 16, 256, silc_aes_set_key,
silc_aes_set_key_with_string, silc_aes_encrypt_cbc,
registered. Therefore, if memory has been allocated for the object sent
as argument it has to be free'd after this function returns succesfully. */
-int silc_cipher_register(SilcCipherObject *cipher)
+bool silc_cipher_register(SilcCipherObject *cipher)
{
- struct SilcCipherListStruct *new, *c;
+ SilcCipherObject *new;
SILC_LOG_DEBUG(("Registering new cipher `%s'", cipher->name));
new = silc_calloc(1, sizeof(*new));
- new->cipher = silc_calloc(1, sizeof(*new->cipher));
-
- /* Set the pointers */
- new->cipher->name = strdup(cipher->name);
- new->cipher->block_len = cipher->block_len;
- new->cipher->key_len = cipher->key_len;
- new->cipher->set_key = cipher->set_key;
- new->cipher->set_key_with_string = cipher->set_key_with_string;
- new->cipher->encrypt = cipher->encrypt;
- new->cipher->decrypt = cipher->decrypt;
- new->cipher->context_len = cipher->context_len;
- new->next = NULL;
-
- /* Add the new cipher to the list */
- if (!silc_cipher_list) {
- silc_cipher_list = new;
- return TRUE;
- }
-
- c = silc_cipher_list;
- while (c) {
- if (!c->next) {
- c->next = new;
- break;
- }
- c = c->next;
- }
+ new->name = strdup(cipher->name);
+ new->block_len = cipher->block_len;
+ new->key_len = cipher->key_len;
+ new->set_key = cipher->set_key;
+ new->set_key_with_string = cipher->set_key_with_string;
+ new->encrypt = cipher->encrypt;
+ new->decrypt = cipher->decrypt;
+ new->context_len = cipher->context_len;
+
+ /* Add to list */
+ if (silc_cipher_list == NULL)
+ silc_cipher_list = silc_dlist_init();
+ silc_dlist_add(silc_cipher_list, new);
return TRUE;
}
/* Unregister a cipher from the SILC. */
-int silc_cipher_unregister(SilcCipherObject *cipher)
+bool silc_cipher_unregister(SilcCipherObject *cipher)
{
- struct SilcCipherListStruct *c, *tmp;
+ SilcCipherObject *entry;
SILC_LOG_DEBUG(("Unregistering cipher"));
- c = silc_cipher_list;
-
- if (cipher == SILC_ALL_CIPHERS) {
- /* Unregister all ciphers */
- while (c) {
- tmp = c->next;
- silc_free(c->cipher->name);
- silc_free(c);
- c = tmp;
- }
-
- return TRUE;
- }
-
- /* Unregister the cipher */
- if (c->cipher == cipher) {
- tmp = c->next;
- silc_free(c->cipher->name);
- silc_free(c);
- silc_cipher_list = tmp;
-
- return TRUE;
- }
+ if (!silc_cipher_list)
+ return FALSE;
- while (c) {
- if (c->next->cipher == cipher) {
+ silc_dlist_start(silc_cipher_list);
+ while ((entry = silc_dlist_get(silc_cipher_list)) != SILC_LIST_END) {
+ if (cipher == SILC_ALL_CIPHERS || entry == cipher) {
+ silc_dlist_del(silc_cipher_list, entry);
- tmp = c->next->next;
- silc_free(c->cipher->name);
- silc_free(c);
- c->next = tmp;
+ if (silc_dlist_count(silc_cipher_list) == 0) {
+ silc_dlist_uninit(silc_cipher_list);
+ silc_cipher_list = NULL;
+ }
return TRUE;
}
-
- c = c->next;
}
return FALSE;
}
+/* Function that registers all the default ciphers (all builtin ciphers).
+ The application may use this to register the default ciphers if specific
+ ciphers in any specific order is not wanted. */
+
+bool silc_cipher_register_default(void)
+{
+ int i;
+
+ for (i = 0; silc_default_ciphers[i].name; i++)
+ silc_cipher_register(&(silc_default_ciphers[i]));
+
+ return TRUE;
+}
+
/* Allocates a new SILC cipher object. Function returns 1 on succes and 0
on error. The allocated cipher is returned in new_cipher argument. The
caller must set the key to the cipher after this function has returned
by calling the ciphers set_key function. */
-int silc_cipher_alloc(const unsigned char *name, SilcCipher *new_cipher)
+bool silc_cipher_alloc(const unsigned char *name, SilcCipher *new_cipher)
{
- struct SilcCipherListStruct *c;
- int i;
+ SilcCipherObject *entry;
SILC_LOG_DEBUG(("Allocating new cipher object"));
-
- /* Allocate the new object */
- *new_cipher = silc_calloc(1, sizeof(**new_cipher));
if (silc_cipher_list) {
-
- c = silc_cipher_list;
- while (c) {
- if (!strcmp(c->cipher->name, name))
- break;
- c = c->next;
+ silc_dlist_start(silc_cipher_list);
+ while ((entry = silc_dlist_get(silc_cipher_list)) != SILC_LIST_END) {
+ if (!strcmp(entry->name, name)) {
+ *new_cipher = silc_calloc(1, sizeof(**new_cipher));
+ (*new_cipher)->cipher = entry;
+ (*new_cipher)->context = silc_calloc(1, entry->context_len());
+ (*new_cipher)->set_iv = silc_cipher_set_iv;
+ (*new_cipher)->get_iv = silc_cipher_get_iv;
+ (*new_cipher)->get_key_len = silc_cipher_get_key_len;
+ (*new_cipher)->get_block_len = silc_cipher_get_block_len;
+ return TRUE;
+ }
}
-
- if (!c || !c->cipher->context_len)
- goto check_builtin;
-
- /* Set the pointers */
- (*new_cipher)->cipher = c->cipher;
- (*new_cipher)->context = silc_calloc(1, c->cipher->context_len());
- (*new_cipher)->set_iv = silc_cipher_set_iv;
- (*new_cipher)->get_iv = silc_cipher_get_iv;
- (*new_cipher)->get_key_len = silc_cipher_get_key_len;
- (*new_cipher)->get_block_len = silc_cipher_get_block_len;
-
- return TRUE;
}
- check_builtin:
-
- for (i = 0; silc_cipher_builtin_list[i].name; i++)
- if (!strcmp(silc_cipher_builtin_list[i].name, name))
- break;
-
- if (silc_cipher_builtin_list[i].name == NULL) {
- silc_free(*new_cipher);
- *new_cipher = NULL;
- return FALSE;
- }
-
- /* Set the pointers */
- (*new_cipher)->cipher = &silc_cipher_builtin_list[i];
- (*new_cipher)->context =
- silc_calloc(1, (*new_cipher)->cipher->context_len());
- (*new_cipher)->set_iv = silc_cipher_set_iv;
- (*new_cipher)->get_iv = silc_cipher_get_iv;
- (*new_cipher)->get_key_len = silc_cipher_get_key_len;
- (*new_cipher)->get_block_len = silc_cipher_get_block_len;
- memset(&(*new_cipher)->iv, 0, sizeof((*new_cipher)->iv));
-
- return TRUE;
+ return FALSE;
}
/* Free's the given cipher. */
/* Returns TRUE if cipher `name' is supported. */
-int silc_cipher_is_supported(const unsigned char *name)
+bool silc_cipher_is_supported(const unsigned char *name)
{
- struct SilcCipherListStruct *c;
- int i;
+ SilcCipherObject *entry;
if (silc_cipher_list) {
- c = silc_cipher_list;
-
- while (c) {
- if (!strcmp(c->cipher->name, name))
+ silc_dlist_start(silc_cipher_list);
+ while ((entry = silc_dlist_get(silc_cipher_list)) != SILC_LIST_END) {
+ if (!strcmp(entry->name, name))
return TRUE;
- c = c->next;
}
}
- for (i = 0; silc_cipher_builtin_list[i].name; i++)
- if (!strcmp(silc_cipher_builtin_list[i].name, name))
- return TRUE;
-
return FALSE;
}
/* Returns comma separated list of supported ciphers. */
-char *silc_cipher_get_supported()
+char *silc_cipher_get_supported(void)
{
+ SilcCipherObject *entry;
char *list = NULL;
- int i, len;
- struct SilcCipherListStruct *c;
+ int len;
len = 0;
if (silc_cipher_list) {
- c = silc_cipher_list;
-
- while (c) {
- len += strlen(c->cipher->name);
+ silc_dlist_start(silc_cipher_list);
+ while ((entry = silc_dlist_get(silc_cipher_list)) != SILC_LIST_END) {
+ len += strlen(entry->name);
list = silc_realloc(list, len + 1);
- memcpy(list + (len - strlen(c->cipher->name)),
- c->cipher->name, strlen(c->cipher->name));
+ memcpy(list + (len - strlen(entry->name)),
+ entry->name, strlen(entry->name));
memcpy(list + len, ",", 1);
len++;
-
- c = c->next;
}
}
- for (i = 0; silc_cipher_builtin_list[i].name; i++) {
- len += strlen(silc_cipher_builtin_list[i].name);
- list = silc_realloc(list, len + 1);
-
- memcpy(list + (len - strlen(silc_cipher_builtin_list[i].name)),
- silc_cipher_builtin_list[i].name,
- strlen(silc_cipher_builtin_list[i].name));
- memcpy(list + len, ",", 1);
- len++;
- }
-
list[len - 1] = 0;
return list;
/* Encrypts */
-int silc_cipher_encrypt(SilcCipher cipher, const unsigned char *src,
- unsigned char *dst, uint32 len,
- unsigned char *iv)
+bool silc_cipher_encrypt(SilcCipher cipher, const unsigned char *src,
+ unsigned char *dst, uint32 len,
+ unsigned char *iv)
{
return cipher->cipher->encrypt(cipher->context, src, dst, len, iv);
}
/* Decrypts */
-int silc_cipher_decrypt(SilcCipher cipher, const unsigned char *src,
- unsigned char *dst, uint32 len,
- unsigned char *iv)
+bool silc_cipher_decrypt(SilcCipher cipher, const unsigned char *src,
+ unsigned char *dst, uint32 len,
+ unsigned char *iv)
{
return cipher->cipher->decrypt(cipher->context, src, dst, len, iv);
}
/* Sets the key for the cipher */
-int silc_cipher_set_key(SilcCipher cipher, const unsigned char *key,
- uint32 keylen)
+bool silc_cipher_set_key(SilcCipher cipher, const unsigned char *key,
+ uint32 keylen)
{
return cipher->cipher->set_key(cipher->context, key, keylen);
}
uint32 block_len;
uint32 key_len;
- int (*set_key)(void *, const unsigned char *, uint32);
- int (*set_key_with_string)(void *, const unsigned char *, uint32);
- int (*encrypt)(void *, const unsigned char *, unsigned char *,
- uint32, unsigned char *);
- int (*decrypt)(void *, const unsigned char *, unsigned char *,
- uint32, unsigned char *);
+ bool (*set_key)(void *, const unsigned char *, uint32);
+ bool (*set_key_with_string)(void *, const unsigned char *, uint32);
+ bool (*encrypt)(void *, const unsigned char *, unsigned char *,
+ uint32, unsigned char *);
+ bool (*decrypt)(void *, const unsigned char *, unsigned char *,
+ uint32, unsigned char *);
uint32 (*context_len)();
} SilcCipherObject;
uint32 (*get_block_len)(struct SilcCipherStruct *);
} *SilcCipher;
-/* List of all registered ciphers. */
-extern struct SilcCipherListStruct *silc_cipher_list;
-
/* Marks for all ciphers in silc. This can be used in silc_cipher_unregister
to unregister all ciphers at once. */
#define SILC_ALL_CIPHERS ((SilcCipherObject *)1)
+/* Static list of ciphers for silc_cipher_register_default(). */
+extern SilcCipherObject silc_default_ciphers[];
+
/* Macros */
/* Function names in SILC Crypto modules. The name of the cipher
/* These macros can be used to implement the SILC Crypto API and to avoid
errors in the API these macros should be used always. */
#define SILC_CIPHER_API_SET_KEY(cipher) \
-int silc_##cipher##_set_key(void *context, \
- const unsigned char *key, \
- uint32 keylen)
+bool silc_##cipher##_set_key(void *context, \
+ const unsigned char *key, \
+ uint32 keylen)
#define SILC_CIPHER_API_SET_KEY_WITH_STRING(cipher) \
-int silc_##cipher##_set_key_with_string(void *context, \
- const unsigned char *string, \
- uint32 stringlen)
+bool silc_##cipher##_set_key_with_string(void *context, \
+ const unsigned char *string, \
+ uint32 stringlen)
#define SILC_CIPHER_API_ENCRYPT_CBC(cipher) \
-int silc_##cipher##_encrypt_cbc(void *context, \
- const unsigned char *src, \
- unsigned char *dst, \
- uint32 len, \
- unsigned char *iv)
+bool silc_##cipher##_encrypt_cbc(void *context, \
+ const unsigned char *src, \
+ unsigned char *dst, \
+ uint32 len, \
+ unsigned char *iv)
#define SILC_CIPHER_API_DECRYPT_CBC(cipher) \
-int silc_##cipher##_decrypt_cbc(void *context, \
- const unsigned char *src, \
- unsigned char *dst, \
- uint32 len, \
- unsigned char *iv)
+bool silc_##cipher##_decrypt_cbc(void *context, \
+ const unsigned char *src, \
+ unsigned char *dst, \
+ uint32 len, \
+ unsigned char *iv)
#define SILC_CIPHER_API_CONTEXT_LEN(cipher) \
uint32 silc_##cipher##_context_len()
/* Prototypes */
-int silc_cipher_register(SilcCipherObject *cipher);
-int silc_cipher_unregister(SilcCipherObject *cipher);
-int silc_cipher_alloc(const unsigned char *name, SilcCipher *new_cipher);
+bool silc_cipher_register(SilcCipherObject *cipher);
+bool silc_cipher_unregister(SilcCipherObject *cipher);
+bool silc_cipher_register_default(void);
+bool silc_cipher_alloc(const unsigned char *name, SilcCipher *new_cipher);
void silc_cipher_free(SilcCipher cipher);
-int silc_cipher_is_supported(const unsigned char *name);
-char *silc_cipher_get_supported();
-int silc_cipher_encrypt(SilcCipher cipher, const unsigned char *src,
- unsigned char *dst, uint32 len,
- unsigned char *iv);
-int silc_cipher_decrypt(SilcCipher cipher, const unsigned char *src,
- unsigned char *dst, uint32 len,
- unsigned char *iv);
-int silc_cipher_set_key(SilcCipher cipher, const unsigned char *key,
- uint32 keylen);
+bool silc_cipher_is_supported(const unsigned char *name);
+char *silc_cipher_get_supported(void);
+bool silc_cipher_encrypt(SilcCipher cipher, const unsigned char *src,
+ unsigned char *dst, uint32 len,
+ unsigned char *iv);
+bool silc_cipher_decrypt(SilcCipher cipher, const unsigned char *src,
+ unsigned char *dst, uint32 len,
+ unsigned char *iv);
+bool silc_cipher_set_key(SilcCipher cipher, const unsigned char *key,
+ uint32 keylen);
void silc_cipher_set_iv(SilcCipher cipher, const unsigned char *iv);
void silc_cipher_get_iv(SilcCipher cipher, unsigned char *iv);
uint32 silc_cipher_get_key_len(SilcCipher cipher);
#include "md5.h"
#include "sha1.h"
-/* List of all hash functions in SILC. You can dynamically add new hash
- functions into the list. At the initialization of SILC this list is
- filled with the configured hash functions. */
-struct SilcHashListStruct {
- SilcHashObject *hash;
- struct SilcHashListStruct *next;
-};
-
/* List of dynamically registered hash functions. */
-struct SilcHashListStruct *silc_hash_list = NULL;
+SilcDList silc_hash_list = NULL;
-/* Statically declared list of hash functions. */
-SilcHashObject silc_hash_builtin_list[] =
+/* Default hash functions for silc_hash_register_default(). */
+SilcHashObject silc_default_hash[] =
{
{ "sha1", 20, 64, silc_sha1_init, silc_sha1_update, silc_sha1_final,
silc_sha1_transform, silc_sha1_context_len },
/* Registers a new hash function into the SILC. This function is used at
the initialization of the SILC. */
-int silc_hash_register(SilcHashObject *hash)
+bool silc_hash_register(SilcHashObject *hash)
{
- struct SilcHashListStruct *new, *h;
+ SilcHashObject *new;
SILC_LOG_DEBUG(("Registering new hash function `%s'", hash->name));
new = silc_calloc(1, sizeof(*new));
- new->hash = silc_calloc(1, sizeof(*new->hash));
-
- /* Set the pointers */
- new->hash->name = strdup(hash->name);
- new->hash->hash_len = hash->hash_len;
- new->hash->block_len = hash->block_len;
- new->hash->init = hash->init;
- new->hash->update = hash->update;
- new->hash->final = hash->final;
- new->hash->context_len = hash->context_len;
- new->next = NULL;
-
- /* Add the new hash function to the list */
- if (!silc_hash_list) {
- silc_hash_list = new;
- return TRUE;
- }
-
- h = silc_hash_list;
- while (h) {
- if (!h->next) {
- h->next = new;
- break;
- }
- h = h->next;
- }
+ new->name = strdup(hash->name);
+ new->hash_len = hash->hash_len;
+ new->block_len = hash->block_len;
+ new->init = hash->init;
+ new->update = hash->update;
+ new->final = hash->final;
+ new->transform = hash->transform;
+ new->context_len = hash->context_len;
+
+ /* Add to list */
+ if (silc_hash_list == NULL)
+ silc_hash_list = silc_dlist_init();
+ silc_dlist_add(silc_hash_list, new);
return TRUE;
}
/* Unregister a hash function from the SILC. */
-int silc_hash_unregister(SilcHashObject *hash)
+bool silc_hash_unregister(SilcHashObject *hash)
{
- struct SilcHashListStruct *h, *tmp;
+ SilcHashObject *entry;
SILC_LOG_DEBUG(("Unregistering hash function"));
- h = silc_hash_list;
-
- /* Unregister all hash functions */
- if (hash == SILC_ALL_HASH_FUNCTIONS) {
- /* Unregister all ciphers */
- while (h) {
- tmp = h->next;
- silc_free(h->hash->name);
- silc_free(h);
- h = tmp;
- }
-
- return TRUE;
- }
+ if (!silc_hash_list)
+ return FALSE;
- /* Unregister the hash function */
- if (h->hash == hash) {
- tmp = h->next;
- silc_free(h->hash->name);
- silc_free(h);
- silc_hash_list = tmp;
+ silc_dlist_start(silc_hash_list);
+ while ((entry = silc_dlist_get(silc_hash_list)) != SILC_LIST_END) {
+ if (hash == SILC_ALL_HASH_FUNCTIONS || entry == hash) {
+ silc_dlist_del(silc_hash_list, entry);
- return TRUE;
- }
+ if (silc_dlist_count(silc_hash_list) == 0) {
+ silc_dlist_uninit(silc_hash_list);
+ silc_hash_list = NULL;
+ }
- while (h) {
- if (h->next->hash == hash) {
- tmp = h->next->next;
- silc_free(h->hash->name);
- silc_free(h);
- h->next = tmp;
return TRUE;
}
-
- h = h->next;
}
return FALSE;
}
+/* Function that registers all the default hash funcs (all builtin ones).
+ The application may use this to register the default hash funcs if
+ specific hash funcs in any specific order is not wanted. */
+
+bool silc_hash_register_default(void)
+{
+ int i;
+
+ for (i = 0; silc_default_hash[i].name; i++)
+ silc_hash_register(&(silc_default_hash[i]));
+
+ return TRUE;
+}
+
/* Allocates a new SilcHash object. New object is returned into new_hash
argument. */
-int silc_hash_alloc(const unsigned char *name, SilcHash *new_hash)
+bool silc_hash_alloc(const unsigned char *name, SilcHash *new_hash)
{
- struct SilcHashListStruct *h;
- int i;
+ SilcHashObject *entry;
SILC_LOG_DEBUG(("Allocating new hash object"));
- /* Allocate the new object */
- *new_hash = silc_calloc(1, sizeof(**new_hash));
-
if (silc_hash_list) {
- h = silc_hash_list;
- while (h) {
- if (!strcmp(h->hash->name, name))
- break;
- h = h->next;
+ silc_dlist_start(silc_hash_list);
+ while ((entry = silc_dlist_get(silc_hash_list)) != SILC_LIST_END) {
+ if (!strcmp(entry->name, name)) {
+ *new_hash = silc_calloc(1, sizeof(**new_hash));
+ (*new_hash)->hash = entry;
+ (*new_hash)->context = silc_calloc(1, entry->context_len());
+ (*new_hash)->make_hash = silc_hash_make;
+ return TRUE;
+ }
}
-
- if (!h || !h->hash->context_len)
- goto check_builtin;
-
- /* Set the pointers */
- (*new_hash)->hash = h->hash;
- (*new_hash)->context = silc_calloc(1, h->hash->context_len());
- (*new_hash)->make_hash = silc_hash_make;
-
- return TRUE;
}
- check_builtin:
- for (i = 0; silc_hash_builtin_list[i].name; i++)
- if (!strcmp(silc_hash_builtin_list[i].name, name))
- break;
-
- if (silc_hash_builtin_list[i].name == NULL) {
- silc_free(*new_hash);
- *new_hash = NULL;
- return FALSE;
- }
-
- /* Set the pointers */
- (*new_hash)->hash = &silc_hash_builtin_list[i];
- (*new_hash)->context = silc_calloc(1, (*new_hash)->hash->context_len());
- (*new_hash)->make_hash = silc_hash_make;
-
- return TRUE;
+ return FALSE;
}
/* Free's the SilcHash object */
/* Returns TRUE if hash algorithm `name' is supported. */
-int silc_hash_is_supported(const unsigned char *name)
+bool silc_hash_is_supported(const unsigned char *name)
{
- struct SilcHashListStruct *h;
- int i;
+ SilcHashObject *entry;
- if (!name)
- return FALSE;
-
if (silc_hash_list) {
- h = silc_hash_list;
-
- while (h) {
- if (!strcmp(h->hash->name, name))
+ silc_dlist_start(silc_hash_list);
+ while ((entry = silc_dlist_get(silc_hash_list)) != SILC_LIST_END) {
+ if (!strcmp(entry->name, name))
return TRUE;
- h = h->next;
}
}
- for (i = 0; silc_hash_builtin_list[i].name; i++)
- if (!strcmp(silc_hash_builtin_list[i].name, name))
- return TRUE;
-
return FALSE;
}
/* Returns comma separated list of supported hash functions. */
-char *silc_hash_get_supported()
+char *silc_hash_get_supported(void)
{
+ SilcHashObject *entry;
char *list = NULL;
- int i, len;
- struct SilcHashListStruct *h;
+ int len;
len = 0;
if (silc_hash_list) {
- h = silc_hash_list;
-
- while (h) {
- len += strlen(h->hash->name);
+ silc_dlist_start(silc_hash_list);
+ while ((entry = silc_dlist_get(silc_hash_list)) != SILC_LIST_END) {
+ len += strlen(entry->name);
list = silc_realloc(list, len + 1);
- memcpy(list + (len - strlen(h->hash->name)),
- h->hash->name, strlen(h->hash->name));
+ memcpy(list + (len - strlen(entry->name)),
+ entry->name, strlen(entry->name));
memcpy(list + len, ",", 1);
len++;
-
- h = h->next;
}
}
- for (i = 0; silc_hash_builtin_list[i].name; i++) {
- len += strlen(silc_hash_builtin_list[i].name);
- list = silc_realloc(list, len + 1);
-
- memcpy(list + (len - strlen(silc_hash_builtin_list[i].name)),
- silc_hash_builtin_list[i].name,
- strlen(silc_hash_builtin_list[i].name));
- memcpy(list + len, ",", 1);
- len++;
- }
-
list[len - 1] = 0;
return list;
if ((i + 1) % 10 == 0)
snprintf(cp++, sizeof(fingerprint), " ");
}
+ i--;
+ if ((i + 1) % 2 == 0)
+ cp[-2] = 0;
+ if ((i + 1) % 10 == 0)
+ cp[-1] = 0;
return strdup(fingerprint);
}
uint32, unsigned char *);
} *SilcHash;
-extern struct SilcHashListStruct *silc_hash_list;
-
/* Marks for all hash functions. This can be used in silc_hash_unregister
to unregister all hash function at once. */
#define SILC_ALL_HASH_FUNCTIONS ((SilcHashObject *)1)
+/* Default hash functions for silc_hash_register_default(). */
+extern SilcHashObject silc_default_hash[];
+
/* Macros */
/* Following macros are used to implement the SILC Hash API. These
uint32 silc_##hash##_context_len()
/* Prototypes */
-int silc_hash_register(SilcHashObject *hash);
-int silc_hash_unregister(SilcHashObject *hash);
-int silc_hash_alloc(const unsigned char *name, SilcHash *new_hash);
+bool silc_hash_register(SilcHashObject *hash);
+bool silc_hash_unregister(SilcHashObject *hash);
+bool silc_hash_register_default(void);
+bool silc_hash_alloc(const unsigned char *name, SilcHash *new_hash);
void silc_hash_free(SilcHash hash);
uint32 silc_hash_len(SilcHash hash);
-int silc_hash_is_supported(const unsigned char *name);
-char *silc_hash_get_supported();
+bool silc_hash_is_supported(const unsigned char *name);
+char *silc_hash_get_supported(void);
void silc_hash_make(SilcHash hash, const unsigned char *data,
uint32 len, unsigned char *return_hash);
char *silc_hash_fingerprint(SilcHash hash, const unsigned char *data,
/* List of dynamically registered HMACs. */
SilcDList silc_hmac_list = NULL;
+/* Default hmacs for silc_hmac_register_default(). */
+SilcHmacObject silc_default_hmacs[] =
+{
+ { "hmac-sha1-96", 12 },
+ { "hmac-md5-96", 12 },
+ { "hmac-sha1", 20 },
+ { "hmac-md5", 16 },
+
+ { NULL, 0 }
+};
+
/* Registers a new HMAC into the SILC. This function is used at the
initialization of the SILC. */
-int silc_hmac_register(SilcHmacObject *hmac)
+bool silc_hmac_register(SilcHmacObject *hmac)
{
SilcHmacObject *new;
/* Unregister a HMAC from the SILC. */
-int silc_hmac_unregister(SilcHmacObject *hmac)
+bool silc_hmac_unregister(SilcHmacObject *hmac)
{
SilcHmacObject *entry;
silc_dlist_start(silc_hmac_list);
while ((entry = silc_dlist_get(silc_hmac_list)) != SILC_LIST_END) {
- if (entry == hmac) {
+ if (hmac == SILC_ALL_HMACS || entry == hmac) {
silc_dlist_del(silc_hmac_list, entry);
if (silc_dlist_count(silc_hmac_list) == 0) {
return FALSE;
}
+/* Function that registers all the default hmacs (all builtin ones).
+ The application may use this to register the default hmacs if
+ specific hmacs in any specific order is not wanted. */
+
+bool silc_hmac_register_default(void)
+{
+ int i;
+
+ for (i = 0; silc_default_hmacs[i].name; i++)
+ silc_hmac_register(&(silc_default_hmacs[i]));
+
+ return TRUE;
+}
+
/* Allocates a new SilcHmac object of name of `name'. The `hash' may
be provided as argument. If provided it is used as the hash function
of the HMAC. If it is NULL then the hash function is allocated and
the name of the hash algorithm is derived from the `name'. */
-int silc_hmac_alloc(char *name, SilcHash hash, SilcHmac *new_hmac)
+bool silc_hmac_alloc(char *name, SilcHash hash, SilcHmac *new_hmac)
{
SilcHmacObject *entry;
/* Returns TRUE if HMAC `name' is supported. */
-int silc_hmac_is_supported(const char *name)
+bool silc_hmac_is_supported(const char *name)
{
SilcHmacObject *entry;
uint32 key_len;
};
+/* Marks for all hmacs. This can be used in silc_hmac_unregister
+ to unregister all hmacs at once. */
+#define SILC_ALL_HMACS ((SilcHmacObject *)1)
+
+/* Default hmacs for silc_hmac_register_default(). */
+extern SilcHmacObject silc_default_hmacs[];
+
/* Prototypes */
-int silc_hmac_register(SilcHmacObject *hmac);
-int silc_hmac_unregister(SilcHmacObject *hmac);
-int silc_hmac_alloc(char *name, SilcHash hash, SilcHmac *new_hmac);
+bool silc_hmac_register(SilcHmacObject *hmac);
+bool silc_hmac_unregister(SilcHmacObject *hmac);
+bool silc_hmac_register_default(void);
+bool silc_hmac_alloc(char *name, SilcHash hash, SilcHmac *new_hmac);
void silc_hmac_free(SilcHmac hmac);
-int silc_hmac_is_supported(const char *name);
-char *silc_hmac_get_supported();
+bool silc_hmac_is_supported(const char *name);
+char *silc_hmac_get_supported(void);
uint32 silc_hmac_len(SilcHmac hmac);
void silc_hmac_set_key(SilcHmac hmac, const unsigned char *key,
uint32 key_len);
#include "rsa.h"
#include "pkcs1.h"
-/* List of all PKCS's in SILC. PKCS's don't support SIM's thus
- only static declarations are possible. XXX: I hope this to change
- real soon. */
-SilcPKCSObject silc_pkcs_list[] =
+/* Dynamically registered list of PKCS. */
+SilcDList silc_pkcs_list = NULL;
+
+/* Static list of PKCS for silc_pkcs_register_default(). */
+SilcPKCSObject silc_default_pkcs[] =
{
/* RSA with PKCS #1 (Uses directly routines from Raw RSA operations) */
- { "rsa", &silc_rsa_data_context,
+ { "rsa",
silc_rsa_init, silc_rsa_clear_keys, silc_rsa_get_public_key,
silc_rsa_get_private_key, silc_rsa_set_public_key,
silc_rsa_set_private_key, silc_rsa_context_len,
- silc_rsa_data_context_len, silc_rsa_set_arg,
silc_pkcs1_encrypt, silc_pkcs1_decrypt,
silc_pkcs1_sign, silc_pkcs1_verify },
/* Raw RSA operations */
- { "rsa-raw", &silc_rsa_data_context,
+ { "rsa-raw",
silc_rsa_init, silc_rsa_clear_keys, silc_rsa_get_public_key,
silc_rsa_get_private_key, silc_rsa_set_public_key,
silc_rsa_set_private_key, silc_rsa_context_len,
- silc_rsa_data_context_len, silc_rsa_set_arg,
silc_rsa_encrypt, silc_rsa_decrypt,
silc_rsa_sign, silc_rsa_verify },
NULL, NULL, NULL, NULL, NULL, NULL }
};
-/* Allocates a new SilcPKCS object. The new allocated object is returned
- to the 'new_pkcs' argument. This function also initializes the data
- context structure. Function returns 1 on success and 0 on error.
+/* Register a new PKCS into SILC. This is used at the initialization of
+ the SILC. */
-*/
-int silc_pkcs_alloc(const unsigned char *name, SilcPKCS *new_pkcs)
+bool silc_pkcs_register(SilcPKCSObject *pkcs)
{
- int i;
+ SilcPKCSObject *new;
+
+ SILC_LOG_DEBUG(("Registering new PKCS `%s'", pkcs->name));
+
+ new = silc_calloc(1, sizeof(*new));
+ new->name = strdup(pkcs->name);
+ new->init = pkcs->init;
+ new->clear_keys = pkcs->clear_keys;
+ new->get_public_key = pkcs->get_public_key;
+ new->get_private_key = pkcs->get_private_key;
+ new->set_public_key = pkcs->set_public_key;
+ new->set_private_key = pkcs->set_private_key;
+ new->context_len = pkcs->context_len;
+ new->encrypt = pkcs->encrypt;
+ new->decrypt = pkcs->decrypt;
+ new->sign = pkcs->sign;
+ new->verify = pkcs->verify;
+
+ /* Add to list */
+ if (silc_pkcs_list == NULL)
+ silc_pkcs_list = silc_dlist_init();
+ silc_dlist_add(silc_pkcs_list, new);
- SILC_LOG_DEBUG(("Allocating new PKCS object"));
+ return TRUE;
+}
- for (i = 0; silc_pkcs_list[i].name; i++) {
- if (!strcmp(silc_pkcs_list[i].name, name))
- break;
- }
+/* Unregister a PKCS from the SILC. */
+
+bool silc_pkcs_unregister(SilcPKCSObject *pkcs)
+{
+ SilcPKCSObject *entry;
+
+ SILC_LOG_DEBUG(("Unregistering PKCS"));
- if (silc_pkcs_list[i].name == NULL)
+ if (!silc_pkcs_list)
return FALSE;
- *new_pkcs = silc_calloc(1, sizeof(**new_pkcs));
+ silc_dlist_start(silc_pkcs_list);
+ while ((entry = silc_dlist_get(silc_pkcs_list)) != SILC_LIST_END) {
+ if (pkcs == SILC_ALL_PKCS || entry == pkcs) {
+ silc_dlist_del(silc_pkcs_list, entry);
+
+ if (silc_dlist_count(silc_pkcs_list) == 0) {
+ silc_dlist_uninit(silc_pkcs_list);
+ silc_pkcs_list = NULL;
+ }
+
+ return TRUE;
+ }
+ }
+
+ return FALSE;
+}
+
+/* Function that registers all the default PKCS (all builtin PKCS).
+ The application may use this to register the default PKCS if specific
+ PKCS in any specific order is not wanted. */
+
+bool silc_pkcs_register_default(void)
+{
+ int i;
- /* Set the pointers */
- (*new_pkcs)->pkcs = &silc_pkcs_list[i];
- (*new_pkcs)->pkcs->data_context =
- silc_calloc(1, (*new_pkcs)->pkcs->data_context_len());
- (*new_pkcs)->context = silc_calloc(1, (*new_pkcs)->pkcs->context_len());
- (*new_pkcs)->get_key_len = silc_pkcs_get_key_len;
+ for (i = 0; silc_default_pkcs[i].name; i++)
+ silc_pkcs_register(&(silc_default_pkcs[i]));
return TRUE;
}
+/* Allocates a new SilcPKCS object. The new allocated object is returned
+ to the 'new_pkcs' argument. */
+
+bool silc_pkcs_alloc(const unsigned char *name, SilcPKCS *new_pkcs)
+{
+ SilcPKCSObject *entry;
+
+ SILC_LOG_DEBUG(("Allocating new PKCS object"));
+
+ if (silc_pkcs_list) {
+ silc_dlist_start(silc_pkcs_list);
+ while ((entry = silc_dlist_get(silc_pkcs_list)) != SILC_LIST_END) {
+ if (!strcmp(entry->name, name)) {
+ *new_pkcs = silc_calloc(1, sizeof(**new_pkcs));
+ (*new_pkcs)->pkcs = entry;
+ (*new_pkcs)->context = silc_calloc(1, entry->context_len());
+ (*new_pkcs)->get_key_len = silc_pkcs_get_key_len;
+ return TRUE;
+ }
+ }
+ }
+
+ return FALSE;
+}
+
/* Free's the PKCS object */
void silc_pkcs_free(SilcPKCS pkcs)
{
if (pkcs)
silc_free(pkcs->context);
+ silc_free(pkcs);
}
/* Return TRUE if PKCS algorithm `name' is supported. */
int silc_pkcs_is_supported(const unsigned char *name)
{
- int i;
-
- if (!name)
- return FALSE;
+ SilcPKCSObject *entry;
- for (i = 0; silc_pkcs_list[i].name; i++) {
- if (!strcmp(silc_pkcs_list[i].name, name))
- return TRUE;
+ if (silc_pkcs_list) {
+ silc_dlist_start(silc_pkcs_list);
+ while ((entry = silc_dlist_get(silc_pkcs_list)) != SILC_LIST_END) {
+ if (!strcmp(entry->name, name))
+ return TRUE;
+ }
}
return FALSE;
/* Returns comma separated list of supported PKCS algorithms */
-char *silc_pkcs_get_supported()
+char *silc_pkcs_get_supported(void)
{
+ SilcPKCSObject *entry;
char *list = NULL;
- int i, len;
+ int len;
len = 0;
- for (i = 0; silc_pkcs_list[i].name; i++) {
- len += strlen(silc_pkcs_list[i].name);
- list = silc_realloc(list, len + 1);
-
- memcpy(list + (len - strlen(silc_pkcs_list[i].name)),
- silc_pkcs_list[i].name, strlen(silc_pkcs_list[i].name));
- memcpy(list + len, ",", 1);
- len++;
+ if (silc_pkcs_list) {
+ silc_dlist_start(silc_pkcs_list);
+ while ((entry = silc_dlist_get(silc_pkcs_list)) != SILC_LIST_END) {
+ len += strlen(entry->name);
+ list = silc_realloc(list, len + 1);
+
+ memcpy(list + (len - strlen(entry->name)),
+ entry->name, strlen(entry->name));
+ memcpy(list + len, ",", 1);
+ len++;
+ }
}
list[len - 1] = 0;
pkcs_len + identifier_len > totlen)
goto err;
- /* See if we support this algorithm */
- if (!silc_pkcs_is_supported(pkcs_name)) {
- SILC_LOG_DEBUG(("Unsupported PKCS %s", pkcs_name));
+ /* See if we support this algorithm (check only if PKCS are registered) */
+ if (silc_pkcs_list && !silc_pkcs_is_supported(pkcs_name)) {
+ SILC_LOG_DEBUG(("Unknown PKCS %s", pkcs_name));
goto err;
}
goto err;
/* Try to set the key. If this fails the key must be malformed. This
- code assumes that the PKCS routine checks the format of the key. */
- silc_pkcs_alloc(pkcs_name, &alg);
- if (!alg->pkcs->set_public_key(alg->context, key_data, key_len))
- goto err;
- silc_pkcs_free(alg);
+ code assumes that the PKCS routine checks the format of the key.
+ (check only if PKCS are registered) */
+ if (silc_pkcs_list) {
+ silc_pkcs_alloc(pkcs_name, &alg);
+ if (!alg->pkcs->set_public_key(alg->context, key_data, key_len))
+ goto err;
+ silc_pkcs_free(alg);
+ }
if (public_key) {
*public_key = silc_calloc(1, sizeof(**public_key));
if (pkcs_len < 1 || pkcs_len > buf->truelen)
goto err;
- /* See if we support this algorithm */
- if (!silc_pkcs_is_supported(pkcs_name))
+ /* See if we support this algorithm (check only if PKCS are registered). */
+ if (silc_pkcs_list && !silc_pkcs_is_supported(pkcs_name)) {
+ SILC_LOG_DEBUG(("Unknown PKCS `%s'", pkcs_name));
goto err;
+ }
/* Get key data. We assume that rest of the buffer is key data. */
silc_buffer_pull(buf, 2 + pkcs_len);
goto err;
/* Try to set the key. If this fails the key must be malformed. This
- code assumes that the PKCS routine checks the format of the key. */
- silc_pkcs_alloc(pkcs_name, &alg);
- if (!alg->pkcs->set_private_key(alg->context, key_data, key_len))
- goto err;
- silc_pkcs_free(alg);
+ code assumes that the PKCS routine checks the format of the key.
+ (check only if PKCS are registered) */
+ if (silc_pkcs_list) {
+ silc_pkcs_alloc(pkcs_name, &alg);
+ if (!alg->pkcs->set_private_key(alg->context, key_data, key_len))
+ goto err;
+ silc_pkcs_free(alg);
+ }
if (private_key) {
*private_key = silc_calloc(1, sizeof(**private_key));
any PKCS in SILC. */
typedef struct SilcPKCSObjectStruct {
char *name;
- void *data_context;
-
int (*init)(void *, uint32, SilcRng);
void (*clear_keys)(void *);
unsigned char *(*get_public_key)(void *, uint32 *);
uint32 (*set_public_key)(void *, unsigned char *, uint32);
int (*set_private_key)(void *, unsigned char *, uint32);
uint32 (*context_len)();
- uint32 (*data_context_len)();
- int (*set_arg)(void *, void *, int, SilcInt);
int (*encrypt)(void *, unsigned char *, uint32,
unsigned char *, uint32 *);
int (*decrypt)(void *, unsigned char *, uint32,
uint32 (*get_key_len)(struct SilcPKCSStruct *);
} *SilcPKCS;
-/* List of all PKCS in SILC. */
-extern SilcPKCSObject silc_pkcs_list[];
-
/* SILC style public key object. Public key is read from file to this
object. Public keys received from network must be in this format as
well. */
#define SILC_PKCS_FILE_BIN 0
#define SILC_PKCS_FILE_PEM 1
+/* Marks for all PKCS in silc. This can be used in silc_pkcs_unregister
+ to unregister all PKCS at once. */
+#define SILC_ALL_PKCS ((SilcPKCSObject *)1)
+
+/* Static list of PKCS for silc_pkcs_register_default(). */
+extern SilcPKCSObject silc_default_pkcs[];
+
/* Macros */
/* Macros used to implement the SILC PKCS API */
uint32 key_len)
#define SILC_PKCS_API_CONTEXT_LEN(pkcs) \
uint32 silc_##pkcs##_context_len()
-#define SILC_PKCS_API_DATA_CONTEXT_LEN(pkcs) \
-uint32 silc_##pkcs##_data_context_len()
-#define SILC_PKCS_API_SET_ARG(pkcs) \
-int silc_##pkcs##_set_arg(void *context, \
- void *data_context, \
- int argnum, \
- SilcInt val)
#define SILC_PKCS_API_ENCRYPT(pkcs) \
int silc_##pkcs##_encrypt(void *context, \
unsigned char *src, \
uint32 data_len)
/* Prototypes */
-int silc_pkcs_alloc(const unsigned char *name, SilcPKCS *new_pkcs);
+bool silc_pkcs_register(SilcPKCSObject *pkcs);
+bool silc_pkcs_unregister(SilcPKCSObject *pkcs);
+bool silc_pkcs_register_default(void);
+bool silc_pkcs_alloc(const unsigned char *name, SilcPKCS *new_pkcs);
void silc_pkcs_free(SilcPKCS pkcs);
int silc_pkcs_is_supported(const unsigned char *name);
-char *silc_pkcs_get_supported();
+char *silc_pkcs_get_supported(void);
uint32 silc_pkcs_get_key_len(SilcPKCS self);
unsigned char *silc_pkcs_get_public_key(SilcPKCS pkcs, uint32 *len);
unsigned char *silc_pkcs_get_private_key(SilcPKCS pkcs, uint32 *len);
SILC_LOG_DEBUG(("Start"));
+ if (!req_iv_len || !req_enc_key_len || !req_hmac_key_len)
+ return SILC_SKE_STATUS_ERROR;
+
buf = silc_buffer_alloc(1 + data_len);
silc_buffer_pull_tail(buf, SILC_BUFFER_END(buf));
silc_buffer_format(buf,
# temporary files (including these prepare* scripts) are removed.
#
-SILC_VERSION=0.1.1
+SILC_VERSION=0.2
version=$1
if test "$version" = ""; then
projects / silc.git / commitdiff