Contact

@@ -37,5 +50,4 @@ priikone@poseidon.pspt.fi - - + \ No newline at end of file diff --git a/public_html/copying.html b/public_html/copying.html index 1fc18fed..98380651 100644 --- a/public_html/copying.html +++ b/public_html/copying.html @@ -1,4 +1,5 @@ +

diff --git a/public_html/docs.html b/public_html/docs.html new file mode 100644 index 00000000..d5038ad8 --- /dev/null +++ b/public_html/docs.html @@ -0,0 +1,92 @@ + + + +

+ + + + +

+ +

SILC Documentation

+Currently the SILC documentation is under work and the software does not +have that much of a documentation. +

+[Coming later: Software manual, SILC Library Reference manual] + +

SILC Protocol Internet Drafts

+SILC Protocol is documented and three Internet Drafts exists. These +Internet Drafts has been submitted, also, to the +IETF. +

Secure Internet Live Conferencing (SILC), Protocol Specification +

+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 SILC network. Two +other Internet Drafts relates very closely to this memo; SILC Packet +Protocol [SILC2] and SILC Key Exchange and Authentication Protocols +[SILC3]. +

+ +draft-riikonen-silc-spec-00.txt +

+ +

SILC Packet Protocol +

+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. +

+ +draft-riikonen-silc-pp-00.txt +

+ +

SILC Key Exchange and Authentication Protocols +

+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). +

+ +draft-riikonen-silc-ke-auth-00.txt +

+ +

+ + \ No newline at end of file diff --git a/public_html/docs/CodingStyle b/public_html/docs/CodingStyle new file mode 100644 index 00000000..e6033530 --- /dev/null +++ b/public_html/docs/CodingStyle @@ -0,0 +1,575 @@ +Coding Style in SILC source tree +================================ + +This documents describes the coding style and coding conventions used +in the SILC source tree. The purpose of the document is to describe the +common way to program for SILC and thus should be learned when programming +new code. The document describes various conventions regarding variable +naming, function naming, indentation, overall appearance of a piece of +code and how some of the technical issues has been done in the SILC and +should be done in the future. + + +Naming +====== + +Generic naming + +All identifiers, whether they defines, functions or something else, with +execption of variables, has a common naming convention. Usually all +identifiers use `silc' prefix to indicate that the identifier is part of +SILC distribution. For example, silc_server_init(), SILC_PACKET_TYPE_ERROR, +etc. As mentioned however, variables, local or global, does not use this +naming convention. + +Lower lever routines, usually some library routines, may use their +own naming convention if generic API is defined over them. The API uses +the common naming convention while the lower level routines uses what +ever they want. For example, ciphers are implemented currently in this +way. They define common SILC Cipher API but the actual implementation +of algorithms uses their own naming convention. Another example is +the GMP math library that uses its own function naming but we have our +own SILC MP API over it that has been defined using common SILC naming +convention. + + +Variables + +Variable names are always in lowercase and any mixed-case or totally +uppercase variable names should be avoided. Variable names may include +underscore if it is necessary. For example, `unsigned char *id_string;'. + +The same name convention is used in structure field names. All fields +in structures should be in lowercase. Global variables should have some +sort of prefix to indicate that the variable is global. Although, global +variables should be avoided if possible. + +Local variable names should be as short as possible without losing +meaning of the name. For example there is no reason to call loop +counter as `loop_counter' when `i' is commonly used instead. Using +variable name `tmp' is also ok and should be used when some temporary +value is used. + + +#define's and Macros + +All #define's should always be in uppercase to indicate that it is +a define, for example, `#define SILC_PACKET_TYPE_NONE 0'. As mentioned +previously #define's and macros always use the `SILC' prefix. The +names also uses always underscores. + +Names of #define's and macros should be self explanatory. This may +lead to long names but it is better than having some `#define SILC_KE1_SX' +which does not tell you anything. + + +Type definitions + +Type definitions (typedefs) uses some what different naming convention +from variables and macros. Typedefs has mixed-case names and they +never use underscores. For example, `SilcSomeStruct', `SilcServerObject'. +Like in any other case the names should be self explanatory which may +lead to long names but that is not a problem. + +The names should tell what the typedef is about. If it is a typedef +of a structure it should tell what the structure is for in the first +place. For example `SilcClientStruct', `SilcCipherObject', +`SilcConfigSection´, etc. + + +Structures + +Same naming convention used in typedefs applies to names of structures as +well. Same as with typedef, structure names should be self explanatory +and should tell what the structure is made for. + +Structures are used a lot in SILC. They are used as simple structures +and as objects as well. When normal structures are needed they are +defined as follows, + + struct SilcDummyStruct { + unsigned char *dummy; + }; + +And used as `struct SilcDummyStruct *dummy'. However, this is quite +rarely used in the SILC, instead structures are typedef'd as following +later. When structure is used as object they are defined as follows, + + typedef struct SilcDummyStruct { + unsigned char *dummy; + unsigned int flags; + void (*callback)(void *, unsigned int); + } SilcDummyObject; + +If the SilcDummyStruct is not needed it may be omitted (which is very +common in SILC code), leaving, + + typedef struct { + unsigned char *dummy; + unsigned int flags; + void (*callback)(void *, unsigned int); + } SilcDummyObject; + +Finally, it is common that structures are typedef'd pointers as they +are very flexible to use, + + typedef SilcDummyObject *SilcDummy; + +It is common in SILC to typedef structures instead of defining name +for the structure. In this case the structure may be used without +defining `struct' to the code, For example, + + SilcDummyObject dummy_obj; + SilcDummyObject *dummy; + +If the structure has a pointer typedef then they are defined as normal +variables but for real they are pointers, For example, + + SilcDummy dummy; + dummy = silc_calloc(1, sizeof(*dummy)); + dummy->flags = 0; + +This convention is very common in SILC code and has been used consistently +throughout the code. The pattern here is that all structures are named +as `SilcXxxStruct', all objects are named as `SilcXxxObject' and when +they are typedef'd pointers they are named as `SilcXxx'. + + +Functions + +Function naming uses the common naming convention used in the SILC. All +functions are always lowercase and they use underscores. The name of +the function always starts with prefix `silc_'. The name of the function +should be self explanatory which may lead to long names. The name of +a function is constructed from following parts, + + silc___ + +The is for example or , however, it is +always omitted (and must be omitted) when programming library code. + +The is the module you are programming currently. You should +have a pretty good idea what you are programming and what the module +does. For example, , , , , etc. + +The is the describtion of the functionality of the function +you are writing. Naturally it should be self explanatory and weird +short names should be avoided. It is better to have long function +names than some odd name that does not tell what it is about. Function +naming could be for example, , , , , +etc. + +So, it is common in SILC to have function names, such as, + + silc_server_packet_send + silc_server_packet_send_to_channel + silc_client_packet_process + silc_idcache_del_by_id + silc_task_unregister_by_fd + silc_protocol_excute_final + silc_buffer_alloc + +When function registers something the name of the function should +generally be `silc_function_register' and unregistering should happen +with `silc_function_unregister'. When function allocates something it +should be called `silc_function_alloc' and when freeing it should be +called `silc_function_free'. Respectively, with init/uninit functions. + +When this naming convention is used consistently it is easy to remember +what the name of the function is. For example, if you need buffer it +is easy to figure out that the routines are most likely called +`silc_buffer_*', and if you need to allocate buffer it is most likely +called `silc_buffer_alloc'. This sort of naming makes the programming, +in the long run, much cleaner, simpler and faster. + + +Inline functions + +SILC uses quite a bit inline functions to optimize the code. The +naming of inline functions must follow same convention as any normal +function. All inline functions in SILC are defined and written into +header files. Inline functions must be defined in following manner +in the header file, + +extern inline void silc_dummy_inline(unsigned int flags) +{ + doing_little_dummy_things; +} + +Because the function is defined as extern they can be included into +public header files. Do not forget to define inline function as extern. +There are no any explicit prototype definitions for inline functions. + + +Indentation +=========== + +SILC has been coded with Emacs so standard indentation of Emacs is used +in the SILC code. The indentation is always 2 characters, not a +tabulator. If you use Emacs then this should not be a problem. So, +if you code for SILC be sure to format the code to the standard way +used in the SILC before submitting the code. + +A tip for those who think that these long function names etc are just +too long to type, consider using dynamic abbreviation found in Emacs. +With this cool feature you only have type some part of the string and +then use the dabbrev to find the rest of the string. I guess, by +default it is M-/ in Emacs but I have binded it into Shift-TAB so it +is fast to use when typing. + + +Placing Braces +============== + +The common fight about how the braces should be placed in the C code +is probably going on in the SILC code as well. However, SILC code +is consistent about this. The placing uses K&R style thus the opening +of the brace is put to the last on the line and the closing brace is +on first on its own line, + + if (condition) { + silc_something(); + silc_something_more(); + } + +The function's braces are as follows, + + int silc_client_function() + { + return 0; + } + +More examples, + + if (condition) { + something; + silc_something_more(); + } else { + something_else; + } + + if (condition) { + something; + silc_something_more(); + } else if (other_condition) { + something; + silc_something_more(); + } else { + something_else; + } + + +Commenting +========== + +SILC code is usually pretty well commented and this should be the way +in the future as well. However, the comments should not tell how the +code works, it should be apparent by looking at the code. Instead the +commenting should tell what the function does. All functions should +be commented. If nothing more a line of comment telling what the function +is about helps a lot when you go back to it after six months. Static +functions should be commented as well. + +The commenting of functions in SILC has been made into the source files, +and not in the header files where the function prototypes reside. Header +files usually includes structure comments, macro comments and perhaps +some other relevant commenting but usually not function comments. +It is also Ok to comment the code inside function when it is needed. + +Comments should use normal C-language comments /* */ and not C++ comments. + + +General Appearance +================== + +The code should be clean and good to eye, although the function of it +must always supersede the appearance. However, it is nice to read code +that looks good. Here are some issues on general appearance. + + o Use empty lines when appropriate but not too much. There + should not be excess empty lines at the end of file. However, + using some empty lines in the code makes the code better + looking. + + o The line is 79 characters long and not one character longer. + Longer lines must be cut in two, or three, or ... + + o Use spaces very much. Do not write things like `if(!k)', + instead write `if (!k)'. Same with `for', `while', etc. + Spaces should be put around all binary operators like `*', + `==', `+', etc. Also, when setting a value to variable be + sure to set spaces around `='. When writing argument list + to a function, space should follow each of the comma in the + list. However, do not use spaces with parenthesis, for + example, `if ( !k )' is not accepted. + + o If you are not sure about how something should be done or + the code you've done is not finished, it should be commented + with XXX plus explanation what is going on. + + +Source Files + +All source files starts with header that includes the name of the author, +copyright notice and the copyright policy, usually part of GNU GPL licence. +Now, this really isn't that important but some sort of header should be in +all source files. + +In the start of the source files should include the #include's that are +needed. All library source files must include `silcincludes.h', this is +a must. Client source file must include at least `clientincludes.h' and +server source file must include `serverincludes.h'. Additional include's +may be added as well, however, system specific includes should not be +added directly (unless it is really a special case). Go see any source +file as an example. + + +Header Files + +As with source files, header files should include same file header at +the start of the file. + +Header files are usually divided in three parts in SILC. At the start +of header files should include all definitions, typedefs, structure +definitions etc. After definitions should include macros and inline +functions if any of those exist. After macros should include the +public prototypes of the functions. Go see any header file as an example. + + +Debug Messages +============== + +When writing new code it is recommended that the code produces some sort +of debug messages. SILC has own debug logging system that must be used +in the generic SILC code. Few macros exist, + + SILC_LOG_DEBUG + SILC_LOG_HEXDUMP + SILC_LOG_INFO + SILC_LOG_WARNING + SILC_LOG_ERROR + SILC_LOG_FATAL + +When doing debugging the most used macros are SILC_LOG_DEBUG and +SILC_LOG_HEXDUMP. With first macro you can print out any sort of debug +messages with variable argument list, for example, + + SILC_LOG_DEBUG(("Start")); + SILC_LOG_DEBUG(("Packet length %d", packet_len)); + +Note the extra parenthesis that are required for the macro so that the +variable argument list formatting would work correctly. + +When you need to dump some data into screen you should use SILC_LOG_HEXDUMP +macro. For example, + + SILC_LOG_HEXDUMP(("Packet"), packet->data, packet->len); + SILC_LOG_HEXDUMP(("Packet, size %d", size), packet->data, packet->len); + +In SILC_LOG_HEXDUMP the data to be dumped are set between the second last +and last parenthesis in order that the data is first and the length of the +data is next. If arguments are used they are used the same way as in +SILC_LOG_DEBUG and the data to be dumped are set after the argument list +is closed with the parenthesis. + + +Memory Allocation +================= + +Naturally, memory allocation is a big part of SILC. However, there are +few things that must be noted on the issue. SILC has defined its own +memory allocation functions that must be used. System specific functions +must not be used directly. There are functions like, + + silc_malloc + silc_calloc + silc_realloc + silc_free + +You should always use silc_calloc instead of silc_malloc because +silc_calloc automatically zeroes the allocated memory area. This is +important especially with structures because generally we want that all +fields, by default, are zero. + +So, instead of doing + + SilcStruct *ptr; + + ptr = silc_malloc(sizeof(*ptr)); + +You should do + + SilcStruct *ptr + + ptr = silc_calloc(1, sizeof(*ptr)); + + +When freeing memory it should be zero'ed when appropriate. All memory +allocations that handle sensitive data such as keys should be zero'ed +by memset() before freeing the memory. Common way to do is, + + memset(ptr, 'F', sizeof(*ptr)); + silc_free(ptr); + +Where 'F' indicates free'd memory if you ever check it with debugger. +Other choice is to use 0 instead of 'F'. The pointer after freeing +should be set to NULL if appropriate, ptr = NULL. + +Note that some functions in the SILC library handles the zeroing of +the memory area automatically, like for example, silc_buffer_free. + + +Callback Programming +==================== + +SILC uses pretty much programming convention called callback programming. +This is a programming style that extensively uses function pointers +which are usually called inside some other function. + +Typical scenario is this; You are performing some task that most likely +is asynchronous. You need to be able get some structure context when +the operation finishes. Most common way in this case is to pass the +structure context to the operation function with a callback function +that is called when the operation has finished. Following code explains +probaly better. + + +/* Prototypes */ +static silc_callback(void *context); +void silc_start(); +void silc_async_operation_register(int fd, SilcAsyncCb callback, + void *context); +void silc_async_operation(int fd, SilcAsyncCb callback, void *context); + +/* Type definition of the callback function */ +typedef (*SilcAsyncCb)(void *context); + +/* Registers async operation and passes callback function and context + to it as arguments. */ + +void silc_start() +{ + SilcDummyStruct *ctx; + + ctx = silc_calloc(1, sizeof(*ctx)); + ctx->fd = 30; + + silc_async_operation_register(30, silc_callback, (void *)ctx); +} + +/* The callblack function that is called from the operation function */ + +static void silc_callback(void *context) +{ + SilcDummyStruct *ctx = (SilcDummyStruct *)context; + + ctx->fd = 10; +} + +/* Register async operation */ + +void silc_async_operation_register(int fd, SilcAsyncCb callback, + void *context) +{ + /* Register and return immediately */ + silc_register_async_operation_internal(fd, callback, context); +} + +/* Operation function that will call the callback function after it + has finished. */ + +void silc_async_operation(int fd, SilcAsyncCb callback, void *context) +{ + here_this_function_does_what_ever_it_wants; + + here_something_more; + + /* We are finished, call the callback */ + if (callback) + (*callback)(context); +} + + +Now, after the registeration of the async operation in this dumb example +the silc_start returns immediately. Lets say, 10 seconds later the +async operation is executed (it would have been better to call it just +timeout) by calling silc_async_operation which on the other hand will +call the callback function after it has finished. The context that +was passed to the registeration function is now passed back to the +callback function. Thus, you will get the context you wanted. This is +the typical scenario where callback functions come in very handy. This +is also the best way to pass context's that are needed later without +making them global context's. And as long as the context's are defined +as void * they can be what ever contexts making the functions, that +takes in the context, generic. Like in above example, you could pass +what ever context to the registeration function if you'd want to. + +Callback programming is also used when making generic API's of some +operation. For example, if you want generic hooks to the API so that +something could be done while doing the operation (maybe to collect +statistics or something else) just get the functions accept a callback +function and context and call them when appropriate, then continue +as normally. + +Callback functions has been used a lot in SILC code. The scheduler +and task system implemented in core library uses extensively callback +functions. Timeout's uses callbacks as well. SILC Key Exchange protocol +uses callback functions too. The callback function in SKE provides +packet sending without defining into the SKE code how the packets +should be sent thus making it generic for both client and server +(and actually to any application for that matter). + +There are some technical issues on callback programming that are +common in SILC code. + + o Callback functions are usually defined as void functions + as the routine that calls them usually don't care about + what the callback function does. Many times it doesn't + actually know what it does nor would it be interested to + know that. It doesn't care about return values. + + o Many times the callback functions are static functions + because they are not wanted to be called in anyway else + than as callback functions. + + o Callback function names usually have the `_cb' or `_callback' + at the end of function name, eg. silc_client_cb. + + o Type of callback functions should be typedef'd instead of + defining them directly to the function. See above example. + This makes the code much cleaner. + + o Callback function types has usually the suffix `Cb' or + ´Callback' in the type name, eg. SilcAsyncCallback. + + o You must explicitly cast the void * context's to correct + type in the callback function. Of course you must be careful + to cast them to the correct type as they are void * they + could be anything. Many times this causes problems when you + forget what was the type you passed to it. Callback + programming may get very complex. + + o You cannot use inline functions as callback functions, + naturally. + +Callback programming may be hard to understand from first standing if +you haven't done these before, and debugging them may be pain in the +ass sometimes. But after the grand idea behind callback functions +becomes clear they are a wonderful tool. + + +Copyrights of the Code +====================== + +The original code in SILC is GPL licensed. GMP is GPL licensed as well +and zlib is with free license as well. New code will be accepted to +the official SILC source tree if it is coded in GPL or similiar free +license as GPL is, and of course if it is public domain. Code with +restricting licenses will not be accepted to the SILC source tree. +SILC is free software, open source, what ever, project and will remain +as such. + +Also, about authoring; If you write code to SILC don't forget to add +yourself as author at the start of the file. The reason for this is +of course that everybody should get the credits they deserve but also +if problems occur we know who to blame. :) diff --git a/public_html/docs/draft-riikonen-silc-ke-auth-00.txt b/public_html/docs/draft-riikonen-silc-ke-auth-00.txt new file mode 100644 index 00000000..d180a985 --- /dev/null +++ b/public_html/docs/draft-riikonen-silc-ke-auth-00.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-ke-auth-00.txt 28 June 2000 +Expires: 28 Jan 2001 + + + SILC Key Exchange and Authentication Protocols + +Status of this Memo + + This document is an Internet-Draft. 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.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), + munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or + ftp.isi.edu (US West Coast). + + The distribution of this memo is unlimited. + + +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). + + + + +Riikonen [Page 1] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + +Table of Contents + + 1 Introduction .................................................. 2 + 2 SILC Key Exchange Protocol .................................... 3 + 2.1 Key Exchange Payloads ..................................... 3 + 2.1.1 Key Exchange Start Payload .......................... 4 + 2.1.2 Key Exchange 1 Payload .............................. 7 + 2.1.3 Key Exchange 2 Payload .............................. 9 + 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 ............................... 13 + 2.4.2 diffie-hellman-group2 ............................... 14 + 2.5 Key Exchange Status Types ................................. 14 + 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 ........................... 18 + 3.3 Connection Authentication Status Types .................... 19 + 4 Security Considerations ....................................... 19 + 5 References .................................................... 19 + 6 Author's Address .............................................. 20 + + +List of Figures + + Figure 1: Key Exchange Start Payload + Figure 2: Key Exchange 1 Payload + Figure 3: Key Exchange 2 Payload + Figure 4: Connection Auth Payload + + +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 + + + +Riikonen [Page 2] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + can be used to authenticate the user with, for example, passphrase + (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 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. + + +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 server + 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. + + +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. + + + +Riikonen [Page 3] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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 fields in + all payloads are always in MSB (most significant byte first) order. + Following descriptions of these payloads. + + +2.1.1 Key Exchange Start Payload + + Key exchange between two entities always begins with a + SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload. + When performing key exchange between client and server, the client sends + Key Exchange Start Payload to server filled with all security properties + that the client supports. Server then checks if it supports the security + properties. + + It then sends a Key Exchange Start Payload to client filled with security + properties it selected from the payload client originally sent. The + payload sent by server must include only one chosen property per list. + + When performing key exchange between server and server, the server who + is contacting sends the Key Exchange Start Payload with security property + list it supports to the other server. The contacted party then chooses + the preferred properties same way as previously described. It then + replies with the properties it wanted same way as previously described. + + The Key Exchange Start Payload is used to tell connecting entities what + security properties and algorithms should be used in the communication. + If perfect forward secrecy (PFS) is not desired (PFS is undefined by + default) Key Exchange Start Payload is sent only once per session, thus, + for example, re-keying will not cause sending of a new payload. If PFS + is desired, re-keying will always cause new key exchange thus causes + sending of a new Key Exchange Start Payload. + + When performing first key exchange this payload is never encrypted, as + there are no existing keys to encrypt it with. If performing re-keying + (PFS was selected) this payload is encrypted with the existing key and + encryption algorithm. + + Cookie is also send in this payload. Cookie is used to uniform the + payload so that none of the key exchange parties cannot determine this + payload before hand. 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 (` '). + + + + +Riikonen [Page 4] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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 + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Exchange Grp Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Key Exchange Groups ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PKCS Alg Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ PKCS Algorithms ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encryption Alg Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Encryption Algorithms ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash Alg Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Hash Algorithms ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Compression Alg Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Compression Algorithms ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Key Exchange Start Payload + + + + + + +Riikonen [Page 5] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + o RESERVED (1 byte) - Reserved field. Sender fills this with + zeroes (0). + + 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. 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. When PFS is used, + re-keying and creating new keys for any particular + purpose will cause new key exchange. + + 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. + + o Cookie (16 bytes) - Cookie that uniforms this payload so + that each of the party cannot determine the payload before + hand. + + o Key Exchange Grp Length (2 bytes) - The length of the + key exchange group list, including this field as well. + + o Key Exchange Group (variable length) - The list of + key exchange groups. See the section 2.1.2 SILC Key Exchange + Groups for definitions of these groups. + + o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms + list, including this field as well. + + o PKCS Algorithms (variable length) - The list of PKCS + algorithms. + + o Encryption Alg Length (2 bytes) - The length of the encryption + + + +Riikonen [Page 6] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + algorithms list, including this field as well. + + o Encryption Algorithms (variable length) - The list of + encryption algorithms. + + o Hash Alg Length (2 bytes) - The length of the Hash algorithms + list, including this field as well. + + o Hash Algorithms (variable length) - The list of Hash algorithms. + + o Compression Alg Length (2 bytes) - The length of the + compression algorithms list, including this field as well. + + o Compression Algorithms (variable length) - The list of + compression algorithms. + + +2.1.2 Key Exchange 1 Payload + + Key Exchange 1 Payload is used to deliver computed public data from + initiator to responder. This data is used to compute the shared secret, + later by all parties. Key Exchange 1 Payload is only sent after the + SILC_PACKET_KEY_EXCHANGE packet and the Key Exchange Start Payload has + been processed by all the parties. + + This payload sends the initiator's public key to the responder. Responder + may need the public key in which case it should be checked to be trusted + by the responder. + + The payload may only be sent with SILC_PACKET_KEY_EXCHANGE_1 packet. + It must not be sent in any other packet type. Following diagram + represent the Key Exchange 1 Payload. + + + + + + + + + + + + + + + + + + + +Riikonen [Page 7] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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 Host (or certificate) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Public Data Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Public Data (e = g ^ x mod p) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Key Exchange 1 Payload + + + o Public Key Length (2 bytes) - The length of the public key + (or certificate), including this field and public key type + field as well. + + 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. + + o Public Data Length (2 bytes) - The length of the public + data computed by the responder, including this field + as well. + + o Public Data (variable length) - The public data to be + sent to the responder. See section 2.2 Key Exchange + + + +Riikonen [Page 8] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + Procedure for detailed description how this field is + computed. This value is binary encoded. + + +2.1.3 Key Exchange 2 Payload + + Key Exchange 2 Payload is used to deliver public key, computed public + data and signature from responder to initiator. Initiator uses these + public parts of the key exchange protocol to compute the shared secret. + + The payload may only be sent with SILC_PACKET_KEY_EXCHANGE_2 packet. + It must not be sent in any other packet type. Following diagram + represent the Key Exchange 2 Payload. + + + + 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 Host (or certificate) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Public Data Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Public Data (f = g ^ y mod p) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Signature Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Key Exchange 2 Payload + + + + o Public Key Length (2 bytes) - The length of the public key + (or certificate), including this field and public key type + field as well. + + o Public Key Type (2 bytes) - The public key (or certificate) + type. This field indicates the type of the public key in + + + +Riikonen [Page 9] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + the packet. See previous sections for defined public key + types. + + o Public Key of the host (variable length) - The public + key of the sender (or its certificate). This is verified + by the receiver of the packet. The type of this field + is indicated by previous Public Key Type field. + + o Public Data Length (2 bytes) - The length of the public + data computed by the responder, including this field + as well. + + o Public Data (variable length) - The public data computed + by the responder. 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, + including the length of this field as well. + + o Signature Data (variable length) - The signature signed + by the responder. The receiver of this signature must + verify it. The verification is done using the public + key received in this same payload. See section 2.2 + Key Exchange Procedure for detailed description how + to produce the signature. + + +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 1 Payload and sent + to the responder. + + + + +Riikonen [Page 10] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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 | Host 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 2 Payload and sends it to the + initiator. + + + 3. Initiator verifies that the public key provided in + the payload is authentic, or if certificates are used + it verifies the certificate. 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 SILC_PACKET_FAILURE is sent to + indicate that the key exchange protocol failed. Any other packets must + not be sent or accepted during the key exchange except the + SILC_PACKET_KEY_EXCHANGE_*, SILC_PACKET_DISCONNECT, SILC_PACKET_FAILURE + and/or 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. + + 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. + + + + + +Riikonen [Page 11] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + +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. This is used in the key + deriving process as a session identifier. + + Keys are derived from the key material as follows: + + 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) + + + 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 is + produced in following manner: + + 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 ... + + + 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 + + + +Riikonen [Page 12] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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 sending). + + 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. + + +2.4 SILC Key Exchange Groups + + Following groups may be used in the SILC Key Exchange protocol. The + first group diffie-hellman-group1 is mandatory, other groups maybe + 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 doesn't have to be the first on the list). + + +2.4.1 diffie-hellman-group1 + + The length of this group is 1024 bits. This is mandatory group. + The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. + + Its decimal value is + + 179769313486231590770839156793787453197860296048756011706444 + 423684197180216158519368947833795864925541502180565485980503 + 646440548199239100050792877003355816639229553136239076508735 + 759914822574862575007425302077447712589550957937778424442426 + 617334727629299387668709205606050270810842907692932019128194 + 467627007 + + Its hexadecimal value is + + 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 + + + + + +Riikonen [Page 13] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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. + + +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 + + 241031242692103258855207602219756607485695054850245994265411 + 694195810883168261222889009385826134161467322714147790401219 + 650364895705058263194273070680500922306273474534107340669624 + 601458936165977404102716924945320037872943417032584377865919 + 814376319377685986952408894019557734611984354530154704374720 + 774996976375008430892633929555996888245787241299381012913029 + 459299994792636526405928464720973038494721168143446471443848 + 8520940127459844288859336526896320919633919 + + Its hexadecimal value is + + 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 + + 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. + + +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. + Following status types are defined: + + + + +Riikonen [Page 14] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 0 SILC_SKE_STATUS_OK + + Protocol were exeucted succesfully. + + + 1 SILC_SKE_STATUS_ERROR + + Unknown error occured. 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_PUBLIC_KEY + + Provided public key type is not supported. + + + 8 SILC_SKE_STATUS_INCORRECT_SIGNATURE + + Provided signature was incorrect. + + + + + + + + +Riikonen [Page 15] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + +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 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 party by the server. + See section New ID Payload in [SILC2] for detailed description for this + packet's payload. + + 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 is started by the connecting party by sending + SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload, + described in the next section. This payload must include the + authentication data. 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 must + 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. 3.2.1 Passphrase Authentication for + more information. + + + + + +Riikonen [Page 16] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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 section 3.2.2 Public Key Authentication + for more information. + + The connecting party 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. Connecting party 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 server connection where servers create their own ID's. + + + +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. Following diagram + represent the Connection Auth Payload. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Connection Auth Payload + + + 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. + + + +Riikonen [Page 17] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + 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. + + +3.2 Connection Authentication Types + + SILC supports two authentication types to be used in the connection + authentication protocol; passphrase or public key based authentication. + Following sections defines the authentication methods. See [SILC2] + for defined numerical authentication method types. + + +3.2.1 Passphrase Authentication + + Passphrase authentication or pre-shared-key base 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. + + +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 + + + +Riikonen [Page 18] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + implementations. + + +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. + Following status types are defined: + + 0 SILC_AUTH_OK + + Protocol was executed succesfully. + + + 1 SILC_AUTH_FAILED + + Authentication failed. + + +4 Security Considerations + + Security is central to the design of this protocol, and these security + considerations permeate the specification. + + +5 References + + [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, June 2000. + + [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + June 2000. + + [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol", + RFC 1459, May 1993. + + [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. + + + + +Riikonen [Page 19] + +Internet Draft Key Exchange and Authentication 28 June 2000 + + + [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 Exhange + (IKE)", RFC 2409, November 1998. + + [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message + Authentication", RFC 2104, February 1997. + + +6 Author's Address + + Pekka Riikonen + Kasarmikatu 11 A4 + 70110 Kuopio + Finland + + EMail: priikone@poseidon.pspt.fi + + + + + + + + + + + + + + + + + + + +Riikonen [Page 20] + \ No newline at end of file diff --git a/public_html/docs/draft-riikonen-silc-pp-00.txt b/public_html/docs/draft-riikonen-silc-pp-00.txt new file mode 100644 index 00000000..fd618101 --- /dev/null +++ b/public_html/docs/draft-riikonen-silc-pp-00.txt @@ -0,0 +1,2467 @@ + + + + + + +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-pp-00.txt 28 June 2000 +Expires: 28 Jan 2001 + + + SILC Packet Protocol + +Status of this Memo + + This document is an Internet-Draft. 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.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), + munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or + ftp.isi.edu (US West Coast). + + The distribution of this memo is unlimited. + + +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. + + + + + + + + + + + + +Riikonen [Page 1] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +Table of Contents + + 1 Introduction .................................................. 3 + 2 SILC Packet Protocol .......................................... 4 + 2.1 SILC Packet ............................................... 4 + 2.2 SILC Packet Header ........................................ 5 + 2.3 SILC Packet Types ......................................... 7 + 2.3.1 SILC Packet Payloads ................................ 15 + 2.3.2 Disconnect Payload .................................. 15 + 2.3.3 Success Payload ..................................... 16 + 2.3.4 Failure Payload ..................................... 16 + 2.3.5 Reject Payload ...................................... 17 + 2.3.6 Notify Payload ...................................... 17 + 2.3.7 Error Payload ....................................... 18 + 2.3.8 Channel Message Payload ............................. 19 + 2.3.9 Channel Key Payload ................................. 20 + 2.3.10 Private Message Payload ............................ 23 + 2.3.11 Private Message Key Payload ........................ 24 + 2.3.12 Command Payload .................................... 25 + 2.3.12.1 Command Argument Payload .................. 25 + 2.3.13 Command Reply Payload .............................. 26 + 2.3.14 Connection Auth Request Payload .................... 27 + 2.3.15 New ID Payload ..................................... 28 + 2.3.16 New ID List Payload ................................ 29 + 2.3.17 New Client Payload ................................. 29 + 2.3.18 New Server Payload ................................. 31 + 2.3.19 New Channel Payload ................................ 31 + 2.3.20 New Channel User Payload ........................... 32 + 2.3.21 New Channel List Payload ........................... 33 + 2.3.22 New Channel User List Payload ...................... 34 + 2.3.23 Replace ID Payload ................................. 34 + 2.3.24 Remove ID Payload .................................. 35 + 2.4 SILC ID Types ............................................. 36 + 2.5 Packet Encryption And Decryption .......................... 37 + 2.5.1 Normal Packet Encryption And Decryption ............. 37 + 2.5.2 Channel Message Encryption And Decryption ........... 37 + 2.5.3 Private Message Encryption And Decryption ........... 38 + 2.6 Packet MAC Generation ..................................... 39 + 2.7 Packet Padding Generation ................................. 39 + 2.8 Packet Compression ........................................ 40 + 2.9 Packet Sending ............................................ 40 + 2.10 Packet Reception ......................................... 41 + 2.11 Packet Broadcasting ...................................... 41 + 2.12 Packet Routing ........................................... 42 + 2.13 Packet Tunneling ......................................... 42 + 3 Security Considerations ....................................... 43 + 4 References .................................................... 43 + 5 Author's Address .............................................. 44 + + + +Riikonen [Page 2] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +List of Figures + + Figure 1: Typical SILC Packet + Figure 2: SILC Packet Header + Figure 3: Disconnect Payload + Figure 4: Success Payload + Figure 5: Failure Payload + Figure 6: Reject Payload + Figure 7: Notify Payload + Figure 8: Error Payload + Figure 9: Channel Message Payload + Figure 10: Channel Key Payload + Figure 11: Private Message Payload + Figure 12: Private Message Key Payload + Figure 13: Command Payload + Figure 14: Command Argument Payload + Figure 15: Connection Auth Request Payload + Figure 16: New ID Payload + Figure 17: New Client Payload + Figure 18: New Server Payload + Figure 19: New Channel Payload + Figure 20: New Channel User Payload + Figure 21: Replace ID Payload + Figure 22: Remove ID Payload + + +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. + + + + +Riikonen [Page 3] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +2 SILC Packet Protocol + +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. + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | n bytes | 1 - n bytes | n bytes | n bytes + | SILC Header | Padding | Data Payload | MAC + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + 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 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. + + + +Riikonen [Page 4] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +2.2 SILC Packet Header + + The default 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. + + Following diagram represents the default SILC header format. + (*) indicates that this field is never encrypted. Other fields are + always encrypted. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: SILC Packet Header + + + 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. + + Following flags are reserved for this field: + + + + + + +Riikonen [Page 5] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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. + + + Broadcast 0x02 + + 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.11 Packet Broadcasting for description of + packet broadcasting. + + + Tunneled 0x04 + + Marks that the packet is tunneled. Tunneling means + that extra SILC Packet Header has been applied to the + original packet. The outer header has this flag + set. See section 2.13 Packet Tunneling for more + information. + + + + 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. + + + + + +Riikonen [Page 6] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 who 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 source ID that + indicates who is the end receiver of the packet. + + +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. + + + +Riikonen [Page 7] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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. + + Payload of the packet: See section 2.3.2 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. + + Payload of the packet: See section 2.3.3 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. + + Payload of the packet: See section 2.3.4 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. + + Payload of the packet: See section 2.3.5 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 never sends this packet. Server may + send this packet to channel as well when the packet is + distributed to all clients on the channel. Receiver of this + packet may ignore the packet if it chooses so. However, it + should not be ignored. + + + + +Riikonen [Page 8] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + Payload of the packet: See section 2.3.6 Notify Payload. + + + 6 SILC_PACKET_ERROR + + This packet is sent when an error occurs. Server may + send this packet. Client never sends this packet. The + client may entirely ignore the packet, however, server is + most likely to take action anyway. + + Payload of the packet: See section 2.3.7 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. + + When client sends this packet the destination ID in the SILC + header must be the Channel ID of the channel the message is + destined to. If server sends this packet to a client the + destination ID in the SILC header must be the Client ID of + the client receiving the packet. + + If server sends this packet to router or if router sends this + packet to server or another router the destination ID in the + SILC header must be the Channel ID of the channel. Server + (including router) distributes this packet only to its local + clients who are joined to the channel. Servers and routers + also determines who are on the channel and when this packet + needs to be sent, as described in section Client To Client + in [SILC1]. + + Payload of the packet: See section 2.3.8 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. + + + + +Riikonen [Page 9] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + Payload of the packet: See section 2.3.9 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]. + + Payload of the packet: See section 2.3.10 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 + degree 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]. + + Payload of the packet: See section 2.3.11 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 [SILC1]. The contents of this packet is command specific. + This packet may be sent to entity that is indirectly connected + to the sender. + + Payload of the packet: See section 2.3.12 Command Payload + + + + + +Riikonen [Page 10] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 12 SILC_PACKET_COMMAND_REPLY + + This packet is send as reply to the SILC_PACKET_COMMAND packet. + The contents of this packet is command specific. This packet + maybe sent to entity that is indirectly connected to the sender. + + Payload of the packet: See section 2.3.13 Command Reply + Payload and section 2.3.12 Command + Payload + + + 13 SILC_PACKET_KEY_EXCHANGE + + This packet is used to start SILC Key Exchange Protocol, + described in detail in [SILC3]. + + Payload of the packet: Payload of this packet is described + in the section SILC Key Exchange + Protocol and its sub sections in + [SILC3]. + + + 14 SILC_PACKET_KEY_EXCHANGE_1 + + This packet is used as part of the SILC Key Exchange Protocol. + + Payload of the packet: Payload of this packet is described + in the section SILC Key Exchange + Protocol and its sub sections in + [SILC3]. + + + 15 SILC_PACKET_KEY_EXCHANGE_2 + + This packet is used as part of the SILC Key Exchange Protocol. + + Payload of the packet: Payload of this packet is described + in the section SILC Key Exchange + Protocol and its sub sections in + [SILC3]. + + + 16 SILC_PACKET_CONNECTION_AUTH_REQUEST + + This packet is used to request 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 is used to determine it. + + + +Riikonen [Page 11] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + The party receiving this payload must respond with the same + packet including the mandatory authentication method. + + Payload of the packet: See section 2.3.14 Connection Auth + Request Payload + + + 17 SILC_PACKET_CONNECTION_AUTH + + This packet is used to start and perform the SILC Connection + Authentication Protocol. This protocol is used to authenticate + the connecting party. The protocol is described in detail in + [SILC3]. + + Payload of the packet: Payload of this packet is described + in the section SILC Authentication + Protocol and it sub sections in [SILC]. + + + 18 SILC_PACKET_NEW_ID + + This packet is used to distribute new 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. + + Payload of the packet: See section 2.3.15 New ID Payload + + + 19 SILC_PACKET_NEW_ID_LIST + + This packet is used to distribute list of new ID's from + server to routers. This is equivalent to previous packet + type except that it may include several ID's. Client must + not send this packet. + + Payload of the packet: See section 2.3.16 New ID List + Payload + + + 20 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. + + + +Riikonen [Page 12] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + Payload of the packet: See section 2.3.17 New Client Payload + + + 21 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. + Client must not send or receive this packet. + + Payload of the packet: See section 2.3.18 New Server Payload + + + 22 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 maybe sent to entity that is indirectly + connected to the sender. + + Payload of the packet: See section 2.3.19 New Channel Payload + + + 23 SILC_PACKET_NEW_CHANNEL_USER + + This packet is used to notify routers about new user on channel. + The packet is sent after user has joined to the channel. Server + may send this packet to its router and router may send this to + its primary router. Client must not send this packet. This + packet maybe sent to entity that is indirectly connected to the + sender. + + Payload of the packet: See section 2.3.20 New Channel User + Payload + + + 24 SILC_PACKET_NEW_CHANNEL_LIST + + This packet is used to distribute list of created channels + from server to routers. This is equivalent to the packet + SILC_PACKET_NEW_CHANNEL except that it may include several + payloads. Client must not send this packet. + + + + +Riikonen [Page 13] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + Payload of the packet: See section 2.3.21 New Channel List + Payload + + + 25 SILC_PACKET_NEW_CHANNEL_USER_LIST + + This packet is used to distribute list of users on specific + channel from server to routers. This is equivalent to the + packet SILC_PACKET_NEW_CHANNEL_USER except that it may + include several payloads. Client must not send this packet. + + Payload of the packet: See section 2.3.22 New Channel User + List Payload + + + 26 SILC_PACKET_REPLACE_ID + + This packet is used to replace old ID with new ID sent in + the packet payload. For example, when client changes its + nickname new ID is created and this packet can be used to + distribute the new ID and the old ID is removed when it is + send in the packet. Client cannot send or receive this + packet. This packet maybe sent to entity that is indirectly + connected to the sender. + + Payload of the packet: See section 2.3.23 Replace ID Payload + + + 27 SILC_PACKET_REMOVE_ID + + This packet is used to removed ID. For example, when client + exits SILC network its ID is removed. Client must not send + this packet. This packet maybe sent to entity that is + indirectly connected to the sender. + + Payload of the packet: See section 2.3.24 Remove ID Payload + + + 28 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. + + + + + + + +Riikonen [Page 14] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 29 SILC_PACKET_REKEY_DONE + + This packet is used to indicate that re-key is performed and + new keys must be used hereafter. This is sent only if re-key + was done without PFS option. If PFS is set, this is not sent + as SILC Key Exchange protocol is executed. This packet does + not have a payload. + + + 30 - 254 + + Currently undefined commands. + + + 255 SILC_PACKET_MAX + + This type is reserved for future extensions and currently it + is not sent. + + +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 default + 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] and [SILC3]. + + +2.3.2 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. Following diagram represents + the Disconnect Payload. + + + +Riikonen [Page 15] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Disconnect Payload + + + + + o Disconnect Message (variable length) - Human readable + reason of the disconnection. + + +2.3.3 Success Payload + + Success payload is sent when some protocol execution is successfully + completed. The payload is simple; indication of the success is sent. + This maybe any data, including binary or human readable data. + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Success Payload + + + o Success Indication (variable length) - Indication of + the success. This maybe 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. + + +2.3.4 Failure Payload + + This is opposite of Success Payload. Indication of failure of + some protocol is sent in the payload. + + 1 2 3 + + + +Riikonen [Page 16] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Failure Payload + + + o Failure Indication (variable length) - Indication of + the failure. This maybe 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. + + +2.3.5 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. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Reject Payload + + + 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. + + +2.3.6 Notify Payload + + Notify payload is used to send notify messages. The payload is usually + + + +Riikonen [Page 17] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + sent from server to client, however, server may send it to another + server as well. Client must not send this payload. The receiver of + this payload may totally ignore the contents of the payload, however, + notify message should be noted and possibly logged. + + The payload may only be sent with SILC_PACKET_NOTIFY packet. It must + not be sent in any other packet type. Following diagram represents the + Notify Payload. + + + + + + 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 Message ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Notify Payload + + + o Notify Message (variable length) - Human readable notify + message. + + +2.3.7 Error Payload + + Error payload is sent upon error. Error may occur in various + conditions when server sends this packet. Client may 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. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Error Payload + + + + +Riikonen [Page 18] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + o Error Message (variable length) - Human readable error + message. + + +2.3.8 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 who client 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. Following diagram + represents the Channel Message Payload. + + (*) indicates that the field is not encrypted. + + + + + + + + + + + + +Riikonen [Page 19] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Nickname Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Nickname ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Message Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Padding Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Padding ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initial Vector * ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: Channel Message Payload + + + o Nickname Length (2 bytes) - Indicates the length of the + Nickname field, not including any other field. + + o Nickname (variable length) - Nickname of the sender of the + channel message. This should not be trusted as a definite + sender of the channel message. The SILC Packet Header in + the packet indicates the true sender of the packet and + client should verify that the nickname sent here belongs + to the Client ID in the SILC Packet Header. This nickname + is merely provided to be displayed by the client. + + If server is sending this packet this field is not included + and zero (0) length must be set to the Nickname Length field. + + o Message Length (2 bytes) - Indicates the length of the + the Message Data field in the payload, not including any + other field. + + + + + +Riikonen [Page 20] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 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 + 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. + + +2.3.9 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 leaves 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. + + Channel keys are cell specific thus every router in 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 peridiocally, 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. Following diagram + represents the Channel Key Payload. + + + + +Riikonen [Page 21] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: Channel Key Payload + + + + 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. This key is used as such as key material for + + + +Riikonen [Page 22] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + encryption function. + + +2.3.10 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 specific keys 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 needs + to 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 specific key is used to protect the message, servers between + the sender and the receiver needs not to decrypt/re-encrypt the + packet. Section 4.8.2 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. Following + diagram represents the Private Message Payload. + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Nickname Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Nickname ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Message Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: Private Message Payload + + + + + +Riikonen [Page 23] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + o Nickname Length (2 bytes) - Indicates the length of the + Nickname field, not including any other field. + + o Nickname (variable length) - Nickname of the sender of the + private message. This should not be trusted as a definite + sender of the private message. The SILC Packet Header in + the packet indicates the true sender of the packet and + client should verify that the nickname sent here belongs + to the Client ID in the SILC Packet Header. This nickname + is merely provided to be displayed by the client. + + o Message Data (variable length) - The actual message to + the client. Rest of the packet is reserved for the message + data. + + +2.3.11 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. Following + diagram represents the Private Message Key Payload. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 12: Private Message Key Payload + + + + + + +Riikonen [Page 24] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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. This key is used as such as key material + for encryption function. + + +2.3.12 Command Payload + + Command Payload is used to send SILC commands from client to server. + Following diagram represents the Command Payload. + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SILC Command | Arguments Num | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 13: Command Payload + + + o SILC Command (1 byte) - SILC Command identifier. 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. + + o Payload Length (2 bytes) - Length of the entire command + payload including any command argument payloads associated + with this payload. + + See [SILC1] for detailed description of different SILC commands, + their arguments and their reply messages. + + +2.3.12.1 Command Argument Payload + + Command Argument Payload is used to set arguments for SILC commands. + Number of arguments associated with a command are indicated by the + Command Payload in the Arguments Num field. Command argument + payloads may only be used with a command payload and they must + always reside right after the command payload. Incorrect amount of + + + +Riikonen [Page 25] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + argument payloads must cause rejection of the packet. Following + diagram represents the Command Argument Payload. + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Argument Num | Argument Type | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Argument Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 14: Command Argument Payload + + + o Argument Num (1 byte) - Indicates the number of this argument. + For first argument this is set to 1, for second argument this + is set to 2, and so forth. If incorrect value is found + in this field the packet must be discarded. Value is + incorrect if it is zero (0) or, for example, a third argument + does not include value 3. + + o Argument Type (1 byte) - Indicates the type of the argument. + 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. The numbers + are command specific and has been defined in section SILC + Commands in [SILC1]. This field makes it possible to send + arguments in free order as this field is used to identify + the specific type of the argument. + + 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 Data (variable length) - Argument data. + + +2.3.13 Command Reply Payload + + Command Reply Payload is used to send replies to the commands sent + by the client. The Command Reply Payload is identical to the + Command Payload hence see the upper sections for Command Payload + and for Command Argument Payload specifications. Command Reply + message uses the Command Argument Payload as well. + + + + +Riikonen [Page 26] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + See SILC Commands in [SILC1] for detailed description of different + SILC commands, their arguments and their reply messages. + + +2.3.14 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. Following + diagram represents the Connection Auth Request Payload. + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 15: Connection Auth Request Payload + + + o Connection Type (2 bytes) - Indicates the type of the ID. + 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. Following + authentication methods are defined: + + + + +Riikonen [Page 27] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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. + + +2.3.15 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. Similiary 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. + + Hence, this payload is very important and used every time when some + new entity is registered to the SILC network. Client never sends this + payload. Both client and server (and router) may receive this payload. + + The payload may only be sent with SILC_PACKET_NEW_ID packet. It must + not be sent in any other packet type. Following diagram represents the + New ID Payload. + + + + + +Riikonen [Page 28] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 16: New ID Payload + + + 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. + + + +2.3.16 New ID List Payload + + New ID List Payload is used to distribute list of ID's usually from + server to router but also from router to other routers in the network. + This payload is used, for example, when server is connected to router + and the server wants to distribute all of its locally connected clients + and locally created channels to the router. It is convenient in this + case to use this payload instead of sending all the information one + by one using New ID Payload. + + There is no specific payload for this packet type. The packet type + uses same payload as described in previous section. To form a list + several payloads is put in the packet each after each. The payload + is variable in length but can be calculated by calculating the ID + Type field, Length field and the ID Data fields together. This forms + one New ID Payload in the list. + + The list of payloads may only be sent with SILC_PACKET_NEW_ID_LIST + packet. They must not be sent in any other packet type. + + +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 + + + +Riikonen [Page 29] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + server. Clients 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. Following diagram represents + the New Client Payload. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 17: New Client Payload + + + o Username Length (2 bytes) - Length of the username. + + 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. + + o Real Name (variable length) - The real name of the user + on the host where connecting to the SILC server. + + + + +Riikonen [Page 30] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +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 + uses this payload to register itself to the SILC network. 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. Following diagram represents + the New Server Payload. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 18: New Server Payload + + + o Server ID Length (2 bytes) - Length of the ID Data area not + including the length of any other fields in the payload. + + o Server ID Data (variable length) - The actual Server ID + data. + + o Server Name Length (2 bytes) - Length of the server name. + + o Server Name (variable length) - The server name. + + +2.3.19 New Channel Payload + + Information about newly created channel is broadcasted to all routers + + + +Riikonen [Page 31] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 sends JOIN command + to the router (after it has received JOIN command from client) which + then processes the command and creates the channel. Client never sends + this packet. + + The payload may only be sent with SILC_PACKET_NEW_CHANNEL packet. + It must not be sent in any other packet type. Following diagram + represents the New Channel Payload. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 19: New Channel Payload + + + + o Channel Name Length (2 bytes) - Length of the channel name. + + o Channel Name (variable length) - The name of the created + channel. + + o Channel ID Length (2 bytes) - Length of the Channel ID. + + o Channel ID (variable length) - The created Channel ID. + + +2.3.20 New Channel User Payload + + When client (user) joins to a channel, server must notify routers + about the new user on the channel. Normal server sends this packet + payload to its router which then broadcasts the packet further. + + + +Riikonen [Page 32] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + Router sends this packet always to its primary router. Client must + not send this packet payload. The mode of the user is NONE after + user has joined to the channel. + + The payload may only be sent with SILC_PACKET_NEW_CHANNEL_USER + packet. It must not be sent in any other packet type. Following + diagram represents the New Channel User Payload. + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Client ID Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Client ID ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 20: New Channel User Payload + + + o Channel ID Length (2 bytes) - Length of the Channel ID. + + o Channel ID (variable length) - The Channel ID of the channel + to which the client has joined. + + o Client ID Length (2 bytes) - Length of the Client ID. + + o Client ID (variable length) - The Client ID of the client + who has joined the channel. + + +2.3.21 New Channel List Payload + + This payload is used to distribute list of new channels from server + to routers. It might convenient to send list of new channels when + existing server connects to router, instead of sending them one + by one. + + There is no specific payload for this packet type. The packet type + uses same payload as described in 2.3.19 New Channel Payload. To form + + + +Riikonen [Page 33] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + a list several payloads is put in the packet each after each. The + payload is variable in length but can be calculated by calculating + the length of the fields together. This forms one New Channel Payload + in the list. + + The list of payloads may only be sent with SILC_PACKET_NEW_CHANNEL_LIST + packet. They must not be sent in any other packet type. + + +2.3.22 New Channel User List Payload + + This payload is used to distribute list of channel users on specific + channel from server to routers. It might convenient to send list of + channel users when existing server connects to router, instead of + sending them one by one. + + There is no specific payload for this packet type. The packet type + uses same payload as described in 2.3.20 New Channel User Payload. + To form a list several payloads is put in the packet each after each. + The payload is variable in length but can be calculated by calculating + the length of the fields together. This forms one New Channel User + Payload in the list. + + The list of payloads may only be sent with packet + SILC_PACKET_NEW_CHANNEL_USER_LIST. They must not be sent in any other + packet type. + + +2.3.23 Replace ID Payload + + This payload is used to replace old ID with new ID sent in the payload. + When ID changes for some entity and the new ID is wanted to replace the + old one this payload must be used. Client cannot send or receive this + payload. Normal server and router server may send and receive this + payload. After this packet has been sent the old ID must not be used + anymore. + + The payload may only be sent with SILC_PACKET_REPLACE_ID packet. It must + not be sent in any other packet type. Following diagram represents the + Replace Payload Payload. + + + + + + + + + + + +Riikonen [Page 34] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old ID Type | Old ID Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Old ID Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New ID Type | New ID Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ New ID Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 21: Replace ID Payload + + + o Old ID Type (2 bytes) - Indicates the type of the old ID. See + section 2.4 SILC ID Types for list of defined ID types. + + o Old ID Length (2 bytes) - Length of the old ID Data area not + including the length of any other fields in the payload. + + o Old ID Data (variable length) - The actual old ID data. + + o New ID Type (2 bytes) - Indicates the type of the new ID. See + section 2.4 SILC ID Types for list of defined ID types. + + o New ID Length (2 bytes) - Length of the new ID Data area not + including the length of any other fields in the payload. + + o New ID Data (variable length) - The actual new ID data. + + +2.3.24 Remove ID Payload + + Remove ID payload is used to remove ID from SILC network. This is used + for example when client exits SILC network. The server must in this + case send this payload to notify that this ID is not valid anymore. + After this has been send the old ID must not be used anymore. Client + must not send this payload. + + The payload may only be sent with SILC_PACKET_REMOVE_ID packet. It must + not be sent in any other packet type. Following diagram represents the + Remove Payload Payload. + + + + +Riikonen [Page 35] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 22: Remove ID Payload + + + o ID Type (2 bytes) - Indicates the type of the ID to be + removed. See section 2.4 SILC ID Types for list of defined + ID types. + + o ID Length (2 bytes) - Length of the D Data area not including + the length of any other fields in the payload. + + o ID Data (variable length) - The actual ID data to be removed. + + +2.4 SILC ID Types + + ID's are extensively used in the SILC network to associate different + entities. Following ID's has been defined to be used in the SILC + network. + + 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]. + + + + +Riikonen [Page 36] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +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. + + +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 following sections the packet + decryption is special. If the packet type is not among those special + packet types rest of the packet may 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. + + +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 + + + +Riikonen [Page 37] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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 hence 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 who 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, is 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. + + +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 can 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 + + + +Riikonen [Page 38] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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. + + +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. + + +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 size of the + cipher's block size, 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: + + padding length = 16 - ((packet length - 2) % 16) + + + +Riikonen [Page 39] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + 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. + + +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. + + +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. 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 encrypts the packet as has been described in above + + + +Riikonen [Page 40] + +Internet Draft SILC Packet Protocol 28 June 2000 + + + sections according whether the packet is normal packet or special + packet. The computed MAC must not be encrypted. + + +2.10 Packet Reception + + On packet reception the receiver must check that all fields in the + SILC Packet Header are valid sain. 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. + + +2.11 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 may + 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. + + + +Riikonen [Page 41] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +2.12 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, server 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 who 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. + + +2.13 Packet Tunneling + + Tunneling is a feature that is available in SILC protocol. Tunneling + means that extra SILC Packet Header is applied to the original packet + and thus hiding the original packet entirely. There can be some + interesting applications using tunneling, such as, using ID's based on + private network IP addresses inside in the tunneled packet. This can + open many interesting features relating to connecting to private network + from the Internet with SILC and many more. However, this feature is + optional currently in SILC as there does not exist thorough analysis of + this feature. It is with out a doubt that there will be many more + applications that has not yet been discovered. Thus, it is left + to Internet Community to investigate the use of tunneling in SILC + protocol. This document is updated according those investigations + and additional documents on the issue may be written. + + + + + +Riikonen [Page 42] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +3 Security Considerations + + Security is central to the design of this protocol, and these security + considerations permeate the specification. + + +4 References + + [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, June 2000. + + [SILC3] Riikonen, P., "SILC Key Exchange and Authentication + Protocols", Internet Draft, June 2000. + + [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol", + RFC 1459, May 1993. + + [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 Exhange + (IKE)", RFC 2409, November 1998. + + [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message + Authentication", RFC 2104, February 1997. + + + +Riikonen [Page 43] + +Internet Draft SILC Packet Protocol 28 June 2000 + + +5 Author's Address + + Pekka Riikonen + Kasarmikatu 11 A4 + 70110 Kuopio + Finland + + EMail: priikone@poseidon.pspt.fi + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Riikonen [Page 44] + \ No newline at end of file diff --git a/public_html/docs/draft-riikonen-silc-spec-00.txt b/public_html/docs/draft-riikonen-silc-spec-00.txt new file mode 100644 index 00000000..361e865f --- /dev/null +++ b/public_html/docs/draft-riikonen-silc-spec-00.txt @@ -0,0 +1,3363 @@ + + + + + + +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-spec-00.txt 28 June 2000 +Expires: 28 Jan 2001 + + + Secure Internet Live Conferencing (SILC), + Protocol Specification + +Status of this Memo + + This document is an Internet-Draft. 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.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), + munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or + ftp.isi.edu (US West Coast). + + The distribution of this memo is unlimited. + + +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 SILC network. Two + other Internet Drafts relates very closely to this memo; SILC Packet + Protocol [SILC2] and SILC Key Exchange and Authentication Protocols + [SILC3]. + + + + + + + + + + +Riikonen [Page 1] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +Table of Contents + + 1 Introduction .................................................. 3 + 2 SILC Concepts ................................................. 3 + 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 + 3 SILC Specification ............................................ 7 + 3.1 Client .................................................... 7 + 3.1.1 Client ID ........................................... 8 + 3.2 Server .................................................... 8 + 3.2.1 Server's Local ID List .............................. 9 + 3.2.2 Server ID ........................................... 10 + 3.2.3 SILC Server Ports ................................... 10 + 3.3 Router .................................................... 11 + 3.3.1 Router's Local ID List .............................. 11 + 3.3.2 Router's Global ID List ............................. 12 + 3.3.3 Router's Server ID .................................. 12 + 3.4 Channels .................................................. 12 + 3.4.1 Channel ID .......................................... 13 + 3.5 Operators ................................................. 14 + 3.6 SILC Commands ............................................. 14 + 3.7 SILC Packets .............................................. 15 + 3.8 Packet Encryption ......................................... 15 + 3.8.1 Determination of the Source and the Destination ..... 16 + 3.8.2 Client To Client .................................... 16 + 3.8.3 Client To Channel ................................... 17 + 3.8.4 Server To Server .................................... 18 + 3.9 Key Exchange And Authentication ........................... 18 + 3.10 Algorithms ............................................... 19 + 3.10.1 Ciphers ............................................ 19 + 3.10.2 Public Key Algorithms .............................. 20 + 3.10.3 MAC Algorithms ..................................... 20 + 3.10.4 Compression Algorithms ............................. 20 + 3.11 SILC Public Key .......................................... 21 + 4 SILC Procedures ............................................... 23 + 4.1 Creating Client Connection ................................ 23 + 4.2 Creating Server Connection ................................ 24 + 4.3 Joining to a Channel ...................................... 25 + 4.4 Channel Key Generation .................................... 26 + 4.5 Private Message Sending and Reception ..................... 27 + 4.6 Private Message Key Generation ............................ 27 + 4.7 Channel Message Sending and Reception ..................... 28 + 4.8 Session Key Regeneration .................................. 28 + 4.9 Command Sending and Reception ............................. 29 + 5 SILC Commands ................................................. 29 + 5.1 SILC Commands Syntax ...................................... 29 + + + +Riikonen [Page 2] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 5.2 SILC Commands List ........................................ 31 + 5.3 SILC Command Status Types ................................. 54 + 5.3.1 SILC Command Status Payload ......................... 54 + 5.3.2 SILC Command Status List ............................ 54 + 6 Security Considerations ....................................... 58 + 7 References .................................................... 59 + 8 Author's Address .............................................. 60 + + +List of Figures + + Figure 1: SILC Network Topology + Figure 2: Communication Inside cell + Figure 3: Communication Between Cells + Figure 4: SILC Public Key + Figure 5: SILC Command Status Payload + + +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 SILC network. Two + other Internet Drafts relates very closely to this memo; SILC Packet + Protocol [SILC2] and SILC Key Exchange and Authentication Protocols + [SILC3]. + + 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. + + + + + +Riikonen [Page 3] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +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. + + +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 centrum on the cell and servers are connected to the router. + Following diagram represents SILC network topology. + + + ---- ---- ---- ---- ---- ---- + | 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 ... + ---- ---- ---- ---- ---- ---- + + + +Riikonen [Page 4] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + Cell 3. Cell 5. + + 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 + servers. 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 will be written. + + +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. Client who 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. Following diagram represents this + scenario. + + + 1 --- S1 S4 --- 5 + S/R + 2 -- S2 S3 + / | + 4 3 + + + Figure 2: Communication Inside cell + + + Example: Client 1. connected to Server 1. message sent to + Client 4. connected to Server 2. travels from Server 1. + first to Router which routes the message to Server 2. + + + +Riikonen [Page 5] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + which then sends it to the Client 4. All the other + servers in the cell will not see the routed message. + + + If 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. + + +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. Following diagram + represents message sending between cells. + + + 1 --- S1 S4 --- 5 S2 --- 1 + S/R - - - - - - - - S/R + 2 -- S2 S3 S1 + / | \ + 4 3 2 + + Cell 1. Cell 2. + + + Figure 3: Communication Between Cells + + + Example: Client 5. connected to Server 4. in Cell 1. message sent + 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 client point of view is + when clients are connected directly to the routers and the messages + are delivered from one router to the other router. + + + + + + + +Riikonen [Page 6] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +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 who are + joined to the channel. Also, router distributes the message to its + local clients on the channel. + + +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. + + +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 hostname 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 to be used along + with the nicknames to identify specific users when sending messages. + This feature of SILC makes IRC style nickname-wars obsolete as no one + owns their nickname; there can always be someone else with the same + nickname. Another difference is that there are no limit of the length + + + +Riikonen [Page 7] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + of the nickname in the SILC. + + +3.1.1 Client ID + + Client ID is used to identify users in the SILC network. The Client ID + is unique to the extent that there can be 2^128 different Client ID's. + Collisions are not expected to happen. The Client ID is defined as + follows. + + 128 bit Client ID based on IPv4 addresses: + + 32 bit ServerID IP address (bits 1-32) + 8 bit Random number + 88 bit Truncated MD5 hash value of the nickname + + o Server ID IP address - Indicates the server where this + client is coming from. The IP address hence equals the + server IP address where to the client has connected. + + o Random number - Random number to further unify the + Client ID. 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. + + 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. + + +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 focuses on the normal server and router server is described + + + +Riikonen [Page 8] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + in the section 3.3 Router. + + Normal servers may 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 may 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. + + +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 hostnames 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: + + 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 + + + + + +Riikonen [Page 9] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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 + + + +3.2.2 Server ID + + Servers are distinguished from other servers by unique 64 bit Server ID. + The Server ID is used in the SILC to route messages to correct servers. + Server ID's also provide information for Client ID's, see section 3.1.1 + Client ID. Server ID is defined as follows. + + 64 bit Server ID based on IPv4 addresses: + + 32 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 binded to. + + o Random number - This is used to further unify the Server ID. + + Collisions are not expected to happen in any conditions. The Server ID + is always created by the server itself and server is resposible of + distributing it to the router. + + +3.2.3 SILC Server Ports + + SILC uses currently TCP port 334 on SILC network. However, this is not + official port assigned for SILC. Official port has been requested by + the IANA. + + If there are needs to create new SILC networks in the future the port + numbers must be officially assigned by the IANA. Most convenience case + would be to assign port numbers upwards from 334. + + Server on network above privileged ports (>1023) should not be trusted + as they could have been set up by untrusted party. + + + + + +Riikonen [Page 10] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +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. + + +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 keep + information about user's nickname, username and hostname and real name + since these are not needed by the router. Router keeps only information + that it needs. + + Hence, local list for router includes: + + 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 + + + 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 + + + +Riikonen [Page 11] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + List. + + +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 hostnames or user's real names. Router does not 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: + + 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 + + +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. Server ID's for routers are always + created by the remote router where the router is connected to. + + +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 + + + +Riikonen [Page 12] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + exist when the last client leaves 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 that unifies each channel. However, channel names are still + unique and no two global channels with same name may exist. Channel name + is a string which begins with `#' character. There is no limit on the + length of the channel name. Channel names may not contain any spaces + (` '), any non-printable ASCII characters, commas (`,') and wildcard + characters. + + Channels can have operators that can administrate the channel and + operate all of its modes. Following operators on channel exist on SILC + network. + + 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. 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. + + +3.4.1 Channel ID + + Channels are distinguished from other channels by unique Channel ID. + The Channel ID is a 64 bit ID and collisions are not expected to happen + in any conditions. Channel names are just for logical use of channels. + The Channel ID is created by the server where the channel is created. + The Channel ID is defined as follows. + + + + +Riikonen [Page 13] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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 + + 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 unify the Channel ID. This makes + sure that there are no collisions. This also means that + in a cell there can be 2^16 channels. + + +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. + + +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 may not send command + to client and there are some commands that server must not send. + + Note that the command reply is usually sent only after client has sent + the command request but server is allowed to send command reply packet + to client even if client has not requested the command. Client may, + however, choose not to accept the command reply, but there are some + + + +Riikonen [Page 14] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + command replies that the client should accept. Example of a such + command reply is reply to SILC_COMMAND_CMODE command that the server + uses to distribute the channel mode on all clients on the channel + when the mode has changed. + + It is expected that some of the commands may be miss-used by clients + resulting various problems on the server side. Every implementation + should assure that commands may not be executed more than once, say, + in two (2) seconds. This should be sufficient to prevent the miss-use + of commands. + + SILC commands are described in section 5 SILC Commands. + + +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. + + +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 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 knows 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 + + + +Riikonen [Page 15] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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. + + +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 is always 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 does 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 case, for example, with command packets. + + +3.8.2 Client To Client + + 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 + + + +Riikonen [Page 16] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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. + + + + +Riikonen [Page 17] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +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. + + +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]. + + +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 + + + +Riikonen [Page 18] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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]. + + +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. + + +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. + + Following ciphers are defined in SILC protocol: + + blowfish-cbc Blowfish in CBC mode (mandatory) + twofish-cbc Twofish in CBC mode (optional) + rc6-cbc RC6 in CBC mode (optional) + rc5-cbc RC5 in CBC mode (optional) + mars-cbc Mars in CBC mode (optional) + none No encryption (optional) + + + All algorithms must use minimum of 128 bit key, by default. Several + algorithms, however, supports longer keys and it is recommended to use + longer keys if they are available. + + Algorithm none does not perform any encryption process at all and + thus is not recommended to be used. It is recommended that no client + or server implementation would accept none algorithms except in special + debugging mode. + + Additional ciphers may be defined to be used in SILC by using the + same name format as above. + + + + + + + + +Riikonen [Page 19] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +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]. + + Following public key algorithms are defined in SILC protocol: + + rsa RSA (mandatory) + dss DSS (optional) + + Both of the algorithms are described in [Scheneir] and [Menezes]. + + Additional public key algorithms may be defined to be used in SILC. + + +3.10.3 MAC Algorithms + + Data integrity is protected by computing a message authentication code + (MAC) of the packet data. See [SILC2] for details how to compute the + MAC. + + Following MAC algorithms are defined in SILC protocol: + + hmac-sha1 HMAC-SHA1, length = 20 (mandatory) + hmac-md5 HMAC-MD5, length = 16 (optional) + none No MAC (optional) + + 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. + + +3.10.4 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. + + + + +Riikonen [Page 20] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + Following compression algorithms are defined: + + none No compression (mandatory) + zlib GBU ZLIB (LZ77) compression (optional) + + Additional compression algorithms may be defined to be used in SILC. + + +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 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: + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: SILC Public Key + + + 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 + + + +Riikonen [Page 21] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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 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: + + + + +Riikonen [Page 22] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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. + + All fields in the public key are in MSB (most significant byte first) + order. + + +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]. + + +4.1 Creating Client Connection + + This section descibres 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 must have + both valid IP address and fully qualified domain name (FQDN). + + After that client and server performs SILC Key Exchange protocol which + will provide the key material used later in the communication. The + key exchange protocol must be completed successfully before the connection + registration may continue. The SILC Key Exchange protocol is described + in [SILC3]. + + 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 a key exchange protocol. + + + + +Riikonen [Page 23] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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]. + + +4.2 Creating Server Connection + + This section descibres 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 + + + +Riikonen [Page 24] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + to the server thus it is not repeated here. + + One difference is that server must perform connection authentication + protocol with proper authentication. 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. 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. + + If the server has already connected clients and locally created + channels the server must distribute these informations to the router. + The distribution is done by sending packet SILC_PACKET_NEW_CHANNEL. + See [SILC2] for more information on this. + + +4.3 Joining to a Channel + + This section describes the procedure when client joins to a channel. + Client may join 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 client, new channel key is created and information about + newly joined channel is sent to the router. The new channel key is + also distributed to the router and to all clients on the channel. + + If the channel does not exist in the local list the command must be + sent to the router which will then perform the actual joining + procedure. When server receives the reply to the command from the + router it must be distributed to the client who sent the command + originally. Server will also receive the channel key from the server + that it must distribute to the client who originally requested the + join command. The server must also save the channel key. + + + + +Riikonen [Page 25] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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 who sent it. Then the router must also create + new channel key and distribute it to all clients on the channel and + all servers that has clients on the channel. + + 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. + + When the router joins the client to the channel it must send + information about newly joined client to all routers in the SILC + network. Also, if the channel was created in the process, information + about newly created channel must also be distributed to all routers. + The distribution of newly created channel is done by sending packet + SILC_PACKET_NEW_CHANNEL. + + It is important to note that new channel key is created always when + new client joins to channel, whether the channel has existed previously + or not. This way the new client on the channel is not able to decrypt + any of the old traffic on the channel. + + Client who receives the reply to the join command must start using + the received Channel ID in the channel message communication thereafter. + However, client must not start communicating on the channel before + it has received the packet SILC_PACKET_CHANNEL_KEY. + + If client wants to know the other clients currently on the channel + the client must send SILC_COMMAND_NAMES command to receive a list of + channel users. Server implementation, however, may send command reply + packet to SILC_COMMAND_NAMES command after client has joined to the + channel even if the client has not sent the command. + + +4.4 Channel Key Generation + + Channel keys are created by router who 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. + + + +Riikonen [Page 26] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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, who leaved 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. + + +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 ipmlementations + 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. + + Receiver of a private message should not explicitly trust the nickname + that it receives in the Private Message Payload, described in [SILC2]. + Implementations could resolve the nickname from server, as described + previously, and compare the received Client ID and the SILC Packet + Header's Client ID. The nickname in the payload is merely provided + to be displayed for end user. + + See [SILC2] for describtion of private message encryption and decryption + process. + + +4.6 Private Message Key Generation + + Private message may be protected by key generated by 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 + + + +Riikonen [Page 27] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + is used in the private message communication between those clients. + See more information about how this works technically in [SILC2]. + + Other choice is to entirely use keys that are not sent through + the SILC network at all. This significantly adds security. This key + would be pre-shared-key that is known by both of the clients. Both + agree about using the key and starts sending packets that indicate + that the private message is secured using private message key. This + is the technical aspect mentioned previously that is described + in [SILC2]. + + If the private message keys are not set to be used, which is the + case by default in SILC, the private messages are secured by using + normal session keys established by SILC Key Exchange protocol. + + +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 describtion of channel message encryption and decryption + process. + + +4.8 Session Key Regeneration + + Session keys should be regenerated peridiocally, 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. + + 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 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 + hashing the old key with hash function selected earlier in the SKE + protocol. If the digest length of the hash function is too short for the + + + +Riikonen [Page 28] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + key, then the key is distributed as described in section Processing the + Key Material in [SILC3]. After both parties has regenerated the session + key, both send SILC_PACKET_REKEY_DONE packet to each other. These packets + are still secured with the old key. After these packets, following + packets must be protected with the new key. + + +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 usually + sent to the server's router. This is case for example with commands such + as, SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there + are other commands as well. For example, if client sends the WHOIS + command requesting specific information about some client the server must + send the WHOIS command to router so that all clients in SILC network + are searched. The router, on the other hand, sends the WHOIS command + to further to receive the exact information about the requested client. + The WHOIS command travels all the way to the server who owns the client + and it replies with command reply packet. Finally, the server who + sent the command receives the command reply and it must be able to + 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. + + +5 SILC Commands + +5.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. + + + +Riikonen [Page 29] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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. + + Example: Arguments: (1) (2) + + + Every command replies with Status Payload. This payload tells the + sender of the command whether the command was completed succefully or + whether there was an error. If error occured 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: + + EXAMPLE_COMMAND + + Max Arguments: 3 + Arguments: (1) [@] (2) + (3) [] + + The command has maximum of 3 arguments. However, only first + and second arguments are mandatory. + + First argument is mandatory but may have optional + format as well. Second argument is mandatory + argument. Third argument is optional argument. + + The numbers in parentheses are the argument specific numbers + that specify the type of the argument in Command Argument Payload. + The receiver always knows that, say, argument number two (2) is + argument, regardles of the ordering of the arguments in + the Command Payload. + + + + + + + +Riikonen [Page 30] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + Reply messages to the command: + + Max Arguments: 4 + Arguments: (1) (2) [] + (3) (4) [] + + This command may reply with maximum of 4 arguments. However, + only the first and third arguments are mandatory. The numbers + in the parentheses have the same meaning as in the upper + command sending specification. + + Every command reply with , it is mandatory + argument for all command replies and for this reason it is not + described in the command reply descriptions. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_TOO_MANY_TARGETS + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_NO_SUCH_NICK + + Every command reply also defines set of status message that it + may return inside the . All status messages + are defined in the section 5.3 SILC Command Status Types. + + +5.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. + + 0 SILC_COMMAND_NONE + + None. This is reserved command and must not be sent. + + + 2 SILC_COMMAND_WHOIS + + Max Arguments: 2 + Arguments: (1) [@] (2) [] + + Whois. Whois command is used to query various information about + + + +Riikonen [Page 31] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + specific user. The user maybe requested by their nickname and + server name. The query may find multiple matching users as + there are no unique nicknames in the SILC. The option + maybe 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 service wildcards in the nickname + or in the servername are not permitted. It is not allowed + to request all users on some server. The WHOIS requests must + be based on specific nickname request. + + The WHOIS request must be always forwarded to router by server + so that all users are searched. However, the server still must + search its locally connected clients. The server must send + this command to the server who owns the requested client. That + server must reply to the command. + + Reply messages to the command: + + Max Arguments: 7 + Arguments: (1) (2) + (3) [@] (4) + (5) (6) [] + (7) [] + + 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 servername, username and hostnamea and users real + name. Client should process these replies only after the last + reply has been received with the STATUS_LIST_END status. If the + option were defined in the query there will be only + many replies from the server. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_LIST_START + SILC_STATUS_LIST_END + SILC_STATUS_ERR_NO_SUCH_NICK + SILC_STATUS_ERR_WILDCARDS + + + +Riikonen [Page 32] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + + + 3 SILC_COMMAND_WHOWAS + + Max Arguments: 2 + Arguments: (1) [@] (2) [] + + Whowas. This command is used to query history information about + specific user. The user maybe requested by their nickname and + server name. The query may find multiple matching users as there + are no unique nicknames in the SILC. The option maybe + 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 service wildcards in the nickname + or in the servername are not permitted. The WHOWAS requests must + be based on specific nickname request. + + The WHOWAS request must be always forwarded to router by server + so that all users are searched. However, the server still must + search its locally connected clients. + + Reply messages to the command: + + Max Arguments: 3 + Arguments: (1) (2) [@] + (3) + + 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 username and hostname. + 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 + + + +Riikonen [Page 33] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + + + 4 SILC_COMMAND_IDENTIFY + + Max Arguments: 2 + Arguments: (1) [@] (2) [] + + 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 option maybe 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 service wildcards in the nickname + or in the servername are not permitted. It is not allowed + to request all users on some server. The IDENTIFY requests must + be based on specific nickname request. + + Implementations may not want to give interface access to this + commands as it is hardly a command that would be used a end user. + However, it must be implemented as it is used with private message + sending. + + The IDENTIFY must be always forwarded to router by server so that + all users are searched. However, server must still search its + locally connected clients. + + Reply messages to the command: + + Max Arguments: 4 + Arguments: (1) (2) + (3) [[@]] (4) [] + + This command may reply with several command reply messages to form + a list of results. In this case the status payload will include + STATUS_LIST_START status in the first reply and STATUS_LIST_END in + the last reply to indicate the end of the list. If there are only + one reply the status is set to normal STATUS_OK. + + + + +Riikonen [Page 34] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + The command replies with Client ID of the nickname and if more + information is available it may reply with nickname and username + and hostname. If the option were defined in the query + there will be only many replies from the server. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_LIST_START + SILC_STATUS_LIST_END + SILC_STATUS_ERR_NO_SUCH_NICK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + + + 5 SILC_COMMAND_NICK + + Max Arguments: 1 + Arguments: (1) + + Set/change nickname. This command is used to set nickname for + user. There is no limit of the length of the nickname in SILC. + Nickname must not include any spaces (` '), non-printable + characters, commas (`,') and any wildcard characters. Note: + nicknames in SILC are case-sensitive which must be taken into + account when searching clients by nickname. + + Reply messages to the command: + + Max Arguments: 2 + Arguments: (1) (2) + + This command is replied always with New ID Payload that is + generated by the server every time user changes their nickname. + Client receiving this payload must start using the received + Client ID as its current valid Client ID. The New ID Payload + is described in [SILC2]. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NICKNAME_IN_USE + SILC_STATUS_ERR_BAD_NICKNAME + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + + + +Riikonen [Page 35] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 6 SILC_COMMAND_LIST + + Max Arguments: 2 + Arguments: (1) [] [] + + The list command is used to list channels and their topics on + current server. If the parameter is used, only the + status of that channel is displayed. Secret channels are not + listed at all. Private channels are listed with status indicating + that the channel is private. + + If the argument is specified the specified server's + channels are listed. In this case the command must be sent to + the server who owns the channel that was requested. + + Reply messages to the command: + + Max Arguments: 3 + Arguments: (1) (2) + (3) + + 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 name and the topic of the + channel. If the channel is private channel the includes + "*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 + SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + SILC_STATUS_ERR_NO_SUCH_SERVER + + + + + + + + + +Riikonen [Page 36] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 7 SILC_COMMAND_TOPIC + + Max Arguments: 2 + Arguments: (1) (2) []] + + This command is used to change or view the topic of a channel. + The topic for channel is returned if there is no + given. If the parameter is present, the topic + for that channel will be changed, if the channel modes permit + this action. + + Reply messages to the command: + + Max Arguments: 2 + Arguments: (1) (2) [] + + 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 + + + 8 SILC_COMMAND_INVITE + + Max Arguments: 2 + Arguments: (1) (2) + + This command is used to invite other clients to join to the + channel. There is no requirement that the channel the target + client is being invited to must exist or be a valid channel. + The argument is the target client's ID that is being + invited. + + Reply messages to the command: + + + + + +Riikonen [Page 37] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + Max Arguments: 2 + Arguments: (1) + + This command replies only with Status Payload. + + 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_CLIENT_ID + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_RECIPIENT + SILC_STATUS_ERR_USER_ON_CHANNEL + SILC_STATUS_ERR_NO_CLIENT_ID + + + 9 SILC_COMMAND_QUIT + + Max Arguments: 1 + Arguments: (1) [] + + This command is used by client to end SILC session. The server + must close the connection to a client which sends this command. + if is given it will be sent to other clients on + channel if the client is on channel when quitting. + + Reply messages to the command: + + This command does not reply anything. + + + 10 SILC_COMMAND_KILL + + Max Arguments: 2 + Arguments: (1) (2) [] + + This command is used by SILC operators to remove a client from + SILC network. The removing has temporary effects and client may + reconnect to SILC network. The is the client to be + removed from SILC. The argument may be provided to + give to the removed client some information why it was removed + from the network. + + Reply messages to the command: + + + + +Riikonen [Page 38] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_CLIENT_ID + SILC_STATUS_ERR_NO_CLIENT_ID + + + 11 SILC_COMMAND_INFO + + Max Arguments: 1 + Arguments: (1) [] + + This command is used to fetch various information about a server. + If argument is specified the command must be sent to + the requested server. + + Reply messages to the command: + + Max Arguments: 3 + Arguments: (1) (2) + (3) + + 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_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_SERVER_ID + SILC_STATUS_ERR_NO_SUCH_SERVER + + + + + + + + + +Riikonen [Page 39] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 12 SILC_COMMAND_CONNECT + + Max Arguments: 2 + Arguments: (1) + (2) [[:]] + + This command is used by operators to force a server to try to + establish a new connection to another router (if the connecting + server is normal server) or server (if the conneceting server is + router server). Operator may specify the server/router to be + connected by setting argument. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_WILDCARDS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_SERVER_ID + SILC_STATUS_ERR_NO_SERVER_PRIV + SILC_STATUS_ERR_NO_ROUTER_PRIV + + + 13 SILC_COMMAND_PING + + Max Arguments: 1 + Arguments: (1) + + This command is used by clients to test the communication + channel to its server if client suspects that the communication + is not working correctly. The is the ID of the + server the client is connected to. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. Server returns + SILC_STATUS_OK in Status Payload if pinging was successful. + + + +Riikonen [Page 40] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_SERVER_ID + SILC_STATUS_ERR_NOT_REGISTERED + + + 14 SILC_COMMAND_OPER + + Max Arguments: 2 + Arguments: (1) (2) + + This command is used by normal client to obtain server operator + privileges on some server or router. Note that router operator + has router privileges that supersedes the server operator + privileges and this does not obtain those privileges. Client + must use SILCOPER command to obtain router level privileges. + + The is the username set in the server configurations + as operator. The is the data that the + client is authenticated against. It may be passphrase prompted + for user on client's screen or it may be public key + authentication data (data signed with private key), or + certificate. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_BAD_PASSWORD + SILC_STATUS_ERR_AUTH_FAILED + + + + + + + + + +Riikonen [Page 41] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 15 SILC_COMMAND_JOIN + + Max Arguments: 3 + Arguments: (1) (2) [] + (3) [] + + 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 on the server receiving the join request. The channel + may be protected with passphrase. If this is the case the + passphrase must be sent along the join command. + + The name of the must not include any spaces (` '), + non-printable characters, commas (`,') or any wildcard characters. + + Cipher to be used to secure the traffic on the channel may be + requested by sending the name of the requested . This + is used only if the channel does not exist and is created. If + the channel already exists the cipher set previously for the + channel will be used to secure the traffic. + + The 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/hostname 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: 5 + Arguments: (1) (2) + (3) (4) + (5) [] + + This command replies with the channel name requested by the + client, channel ID of the channel and topic of the channel + if it exists. It also replies with the channel mode mask + which tells all the modes set on the channel. If the + + + +Riikonen [Page 42] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + channel is created the mode mask is zero (0). + + Client must not start transmitting to the channel even after + server has replied to this command. Client is permitted to + start transmitting on channel after server has sent packet + SILC_PACKET_CHANNEL_KEY to the client. + + 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 + + + 16 SILC_COMMAND_MOTD + + Max Arguments: 1 + Arguments: (1) + + This command is used to query the Message of the Day of a server. + + Reply messages to the command: + + Max Arguments: 2 + Arguments: (1) (2) [] + + 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 + + + + + + + + +Riikonen [Page 43] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 17 SILC_COMMAND_UMODE + + Max Arguments: 2 + Arguments: (1) (2) + + This command is used by client to set/unset modes for itself. + However, there are some modes that the client may 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. + + 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 cannot + 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 + cannot 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. + + Reply messages to the command: + + Max Arguments: 2 + Arguments: (1) (2) + + This command replies with the changed client mode mask that + the client is required to keep locally. + + + + + +Riikonen [Page 44] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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_UNKNOWN_MODE + SILC_STATUS_ERR_NO_RECIPIENT + SILC_STATUS_ERR_NO_CLIENT_ID + + + 18 SILC_COMMAND_CMODE + + Max Arguments: 6 + Arguments: (1) (2) + (3) [] (4) [] + (5) [] (6) [[:]] + + This command is used by client to set or change channel flags on + a channel. Channel has several modes that set various properties + of a channel. Modes may be masked together by ORing them thus + having several modes set. The is the ID of the + target channel. The client changing channel mode must be on + the same channel and poses sufficient privileges to be able to + change the mode. + + 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 indicatioin 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. + + + + +Riikonen [Page 45] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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). This specification does not define how the private + channel key is set as it is entirely local setting on + client end. + + 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. + + + + + +Riikonen [Page 46] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 0x0008 SILC_CMODE_INVITE + + Channel is invite only channel. Client may join to this + channel only if it is invited to the channel. Channel + founder and channel operator may set/unset this mode. + + Typical implementation would use [+|-]i on user interface + to set/unset this mode. + + + 0x0010 SILC_CMODE_TOPIC + + The topic of the channel may only be set by client that + is channel founder or channel operator. Normal clients + on channel will not be able to set topic when this mode + is set. Channel founder and channel operator may set/ + unset this mode. + + Typical implementation would use [+|-]t on user interface + to set/unset this mode. + + + 0x0020 SILC_CMODE_ULIMIT + + User limit has been set to the channel. New clients + may not join to the channel when the limit set is + reached. Channel founder and channel operator may set/ + unset the limit. The argument is the + number of limited users. + + Typical implementation would use [+|-]l on user interface + to set/unset this mode. + + + 0x0040 SILC_CMODE_PASSPHRASE + + Passphrase has been set to the channel. Client may + join to the channel only if it is able to provide the + correct passphrase. Setting passphrases to channel + is entirely safe as all commands are protected in the + SILC network. Only channel founder may set/unset + the passphrase. The argument is the + set passphrase. + + Typical implementation would use [+|-]a on user interface + to set/unset this mode. + + + + + +Riikonen [Page 47] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 0x0080 SILC_CMODE_BAN + + Ban mask has been set to the channel. The ban mask + may be used to ban specific clients to join the channel. + The argument is the set ban mask. When + unsetting a ban mask the mask must be provided as + argument. Channel founder and channel operator may + set/unset this mode. Channel founder may not be + added to the ban list. + + Typical implementation would use [+|-]b on user interface + to set/unset this mode. + + + 0x0100 SILC_CMODE_OPERATOR + + Sets channel operator privileges on the channel for a + client on the channel. The argument is the + target client on the channel. Channel founder and + channel operator may set/unset (promote/demote) this + mode. + + Typical implementation would use [+|-]o on user interface + to set/unset this mode. + + + 0x0200 SILC_CMODE_CIPHER + + Sets specific cipher to be used to protect channel + traffic. The argument is the requested cipher. + When set or unset the server must re-generate new + channel key. If argument is specified with + argument the new key is generated of + length. + + Typical implementation would use [+|-]c on user interface + to set/unset this mode. + + + To make the mode system work, client must keep the channel mode + mask locally so that the mode setting and unsetting would work + without problems. The client receives the initial channel mode + mask when it joins to the channel. When the mode changes on + channel the server distributes the changed channel mode mask to + all clients on the channel by sending SILC_COMMAND_CMODE command + reply packet. + + + + + +Riikonen [Page 48] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + Reply messages to the command: + + Max Arguments: 2 + Arguments: (1) (2) + + This command replies with the changed channel mode mask that + client is required to keep locally. The same mask is also + sent to all clients on channel by sending additional command + reply to them. + + 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_CLIENT_ID + + + 19 SILC_COMMAND_KICK + + Max Arguments: 3 + Arguments: (1) (2) + (3) [] + + This command is used by channel operators to remove a client from + channel. The argument is the channel the client to be + removed is on currently. Note that the "kicker" must be on the same + channel. If is provided it will be sent to the removed + client. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + + + +Riikonen [Page 49] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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_RESTART + + Max Arguments: 0 + Arguments: None + + This command may only be used by server operator to force a + server to restart itself. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NO_SERVER_PRIV + + + 21 SILC_COMMAND_CLOSE + + Max Arguments: 1 + Arguments: (1) + + This command is used only by operator to close connection to a + remote site. The argument is the ID of the remote + site and must be valid. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + + + + + +Riikonen [Page 50] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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_DIE + + Max Arguments: 0 + Arguments: None + + This command is used only by operator to shutdown the server. + All connections to the server will be closed and the server is + shutdown. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NO_SERVER_PRIV + + + 23 SILC_COMMAND_SILCOPER + + Max Arguments: 2 + Arguments: (1) (2) + + This command is used by normal client to obtain router operator + privileges (also known as SILC operator) on some router. Note + that router operator has router privileges that supersedes the + server operator privileges. + + The is the username set in the server configurations + as operator. The is the data that the + client is authenticated against. It may be passphrase prompted + for user on client's screen or it may be public key + + + +Riikonen [Page 51] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + authentication data (data signed with private key), or + certificate. + + 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. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_BAD_PASSWORD + SILC_STATUS_ERR_AUTH_FAILED + + + 24 SILC_COMMAND_LEAVE + + Max Arguments: 1 + Arguments: (1) + + This command is used by client to leave a channel the client is + joined to. After a client has leaved the channel the server + must create new key for the channel and distribute to all clients + still currently on the channel. + + Reply messages to the command: + + Max Arguments: 1 + Arguments: (1) + + This command replies only with Status Payload. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + + + +Riikonen [Page 52] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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_NAMES + + Max Arguments: 1 + Arguments: (1) + + This command is used to list user names currently on the requested + channel; argument . 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 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. + + Reply messages to the command: + + Max Arguments: 2 + Arguments: (1) (2) + + This command replies with the comma separated list of users on + the channel. + + Status messages: + + SILC_STATUS_OK + SILC_STATUS_ERR_NOT_REGISTERED + SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + SILC_STATUS_ERR_TOO_MANY_PARAMS + SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + SILC_STATUS_ERR_BAD_CHANNEL_ID + SILC_STATUS_ERR_NO_CHANNEL_ID + SILC_STATUS_ERR_NOT_ON_CHANNEL + + + 26 - 254 + + Currently undefined commands. + + + + + +Riikonen [Page 53] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 255 SILC_COMMAND_MAX + + Reserved command. This must not be sent. + + +5.3 SILC Command Status Types + +5.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. Following diagram + represents the Command Status Payload (field is always in MSB order). + + + 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status Message | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: SILC Command Status Payload + + + o Status Message (2 bytes) - Indicates the status message. + All Status messages are described in the next section. + + +5.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 occured the status tells which error occured. 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. + + Generic status messages: + + 0 SILC_STATUS_OK + + Ok status. Everything went Ok. The status payload maybe + safely ignored in this case. + + + + +Riikonen [Page 54] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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_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 + beloning to this list after this one. + + 3 - 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. + + + + + + +Riikonen [Page 55] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 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_BAD_CLIENT_ID + + "Bad Client ID". Client ID provided were erroneous. + + 20 SILC_STATUS_ERR_BAD_CHANNEL_ID + + "Bad Channel ID". Channel ID provided were erroneous. + + 21 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID + + "No such Client ID". Client ID provided does not exist. + + + 22 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID + + "No such Channel ID". Channel ID provided does not exist. + + 23 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. + + 24 SILC_STATUS_ERR_NOT_ON_CHANNEL + + "You are not on that channel". The command were specified for + client user is not currently on. + + 25 SILC_STATUS_ERR_USER_ON_CHANNEL + + "User already on channel". User were invited on channel they + already are on. + + + +Riikonen [Page 56] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 26 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. + + 27 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS + + "Not enough parameters". Command requires more parameters + than provided. + + 28 SILC_STATUS_ERR_TOO_MANY_PARAMS + + "Too many parameters". Too many parameters were provided + for the command. + + 29 SILC_STATUS_ERR_PERM_DENIED + + "Your host is not among the privileged". The client tried to + register on server that does not allow this host to connect. + + 30 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. + + 31 SILC_STATUS_ERR_BAD_PASSWORD + + "Cannot join channel. Incorrect password". Password provided for + channel were not accepted. + + 32 SILC_STATUS_ERR_CHANNEL_IS_FULL + + "Cannot join channel. Channel is full". The channel is full + and client cannot be joined to it. + + 33 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. + + 34 SILC_STATUS_ERR_BANNED_FROM_CHANNEL + + "Cannot join channel. You have been banned". The client has + been banned from the channel. + + + + + + +Riikonen [Page 57] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + + 35 SILC_STATUS_ERR_UNKNOWN_MODE + + "Unknown mode". Mode provided by the client were unknown to + the server. + + 36 SILC_STATUS_ERR_NOT_YOU + + "Cannot change mode for other users". User tried to change + someone else's mode. + + 37 SILC_STATUS_ERR_NO_CHANNEL_PRIV + + "Permission denied. You are not channel operator". Command may + be executed only by channel operator. + + 38 SILC_STATUS_ERR_NO_SERVER_PRIV + + "Permission denied. You are not server operator". Command may + be executed only by server operator. + + 39 SILC_STATUS_ERR_NO_ROUTER_PRIV + + "Permission denied. You are not SILC operator". Command may be + executed only by router (SILC) operator. + + 40 SILC_STATUS_ERR_BAD_NICKNAME + + "Bad nickname". Nickname requested contained illegal characters + or were malformed. + + 41 SILC_STATUS_ERR_BAD_CHANNEL + + "Bad channel name". Channel requested contained illegal characters + or were malformed. + + 42 SILC_STATUS_ERR_AUTH_FAILED + + "Authentication failed". The authentication data sent as + argument were wrong and thus authentication failed. + + +6 Security Considerations + + Security is central to the design of this protocol, and these security + considerations permeate the specification. + + + + + + +Riikonen [Page 58] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +7 References + + [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + June 2000. + + [SILC3] Riikonen, P., "SILC Key Exchange and Authentication + Protocols", Internet Draft, June 2000. + + [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol", + RFC 1459, May 1993. + + [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 Exhange + (IKE)", RFC 2409, November 1998. + + [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message + Authentication", RFC 2104, February 1997. + + + + + + + + + +Riikonen [Page 59] + +Internet Draft Secure Internet Live Conferencing 28 June 2000 + + +8 Author's Address + + Pekka Riikonen + Kasarmikatu 11 A4 + 70110 Kuopio + Finland + + EMail: priikone@poseidon.pspt.fi + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Riikonen [Page 60] + \ No newline at end of file diff --git a/public_html/features.html b/public_html/features.html index 426901f3..91417cb2 100644 --- a/public_html/features.html +++ b/public_html/features.html @@ -1,4 +1,5 @@ +

diff --git a/public_html/history.html b/public_html/history.html index ccfe31be..2a43ec14 100644 --- a/public_html/history.html +++ b/public_html/history.html @@ -1,4 +1,5 @@ +

diff --git a/public_html/index.html b/public_html/index.html index 4ce90b3d..f2117152 100644 --- a/public_html/index.html +++ b/public_html/index.html @@ -17,7 +17,7 @@

SILC Features @@ -39,26 +39,81 @@

SILC XXXX2000 Development Version Available

SILC 28062000 Development Version Available

-No, it's not available just yet. +First public release of SILC is finally available. The Developer's version +28062000 of SILC is available for testing. Note that the version is really +a developer's version and there is no guarantees that this package even +compiles, and even if it compiles there is no guarantees that it would work, +and even if it works there is no guarantees that it would work correctly, +and even if it seems to work correctly it may be just plain luck. +

+Download: SILC 28062000 Development Version

Developers Wanted For SILC Project

-XXX +SILC Project needs developers who would like to contribute their time, +skills and ideas to the project. SILC still has a long road ahead before +the first official stable release. We need C coders, technical writers +(to write documentation) and web administrator to take over these web pages. +Feel free to start narrowing down the TODO list. +

+If You would like to contribute to SILC project please contact me at: +priikone@poseidon.pspt.fi

+ + + +

SILC Project Started

+ + +The Pressrelease: +

+Official SILC Project home page: +http://silc.pspt.fi +

+SILC Development Version is available for download from following addresses: +

+HTTP: +silc-28062000.tar.gz (1.4 MB) +
+FTP: +silc-28062000.tar.gz (1.4 MB) +

+The SILC protocol specification is available from following addresses: +

+HTTP: +http://silc.pspt.fi/docs.html +
+FTP: +ftp://silc.pspt.fi/pub/silc/ +

+Author's contact information: +

+Pekka Riikonen +priikone@poseidon.pspt.fi +
+Home page: +http://poseidon.pspt.fi/~priikone/ +

+ +

@@ -73,4 +128,4 @@ Last updated: Mon Jun 12 10:44:06 EEST 2000 - + \ No newline at end of file diff --git a/public_html/todo.html b/public_html/todo.html new file mode 100644 index 00000000..fb9f238f --- /dev/null +++ b/public_html/todo.html @@ -0,0 +1,388 @@ + + + +

+ + + + + +
+
+ +
TODO
+
+
+This is more or less complete list of tasks that has to be done before +SILC 1.0 could ever be released. It is clear that the list does not +include all the bugs that exists. At the end of list are tasks that +needs to be done but are probably post 1.0. + +Feel free to contribute if you have the ability and free time - all the +help is really appreciated - and needed. + + - Pekka + +[Latest Note: The protocol has changed a bit in some parts which +causes that the current implementation violates some requirements. +These are not listed here, currently.] + + +New features TODO +================= + + o Extended SIM (SILC Module) support. Currently only SILC Cipher API + and SILC Hash API may be used as SIM's. What I have in mind is to + have extended support for SIM's so that basically any SILC API could + be used as SIM's. This would open tremendous possiblities but + opens also issues on security that needs to be dealt with. + + Some sort of SIM compilation environment should be defined so that + the SIM's could use SILC specific symbols from the modules (which they + cannot do currently). In the future modules could add new features + to SILC easily with this support. I'm more thinking this from client's + perspective to add new features to client (such as IRC support as SIM) + but server should have the support as well. Anyhow, this is an + interesting feature... + + This maybe post 1.0 task - dunno. + + o SIM support for other platforms than just for Linux. Apache has + example code (code that we could use directly pretty easily) for + other platforms. + + o We should replace all short, int, long, unsigned short, unsigned int, + unsigned long with some pre-defined datatypes that really are what + we want on all platforms. int16, uint16, int32, uint32 etc. are + what we could use or maybe SilcInt16, SilcUInt16 etc. Also, boolean + datatype should be defined. + + o More platform supports should be added. The code is pretty much + generic but there are some parts that require porting (SIM). Also, + some support for different platforms is needed into configure.in. + + o SILC requires currently GCC to work because we use GCC specific + compilation options. Generally any compiler that supports inline + functions and can build shared libraries (for SIMs) should work. + These cases should be included into configure.in. + + +TODO In SILC Client +=================== + + o Implement all commands. A lot of commands are still yet to be + implemented. Most of them are trivial but some will require some + planning. Go see the command.c for unimplemented commands. + + o Non-blocking connection on the background must be stopped if some + other connection on same window has established. Now it is possible + that some non-blocking connection timeouts on the background when + we already have a working connection to some other place; things + goes bad. + + o Finish WHOIS, finish JOIN and other commands that are partly + implemented. + + o Input line on UI is buggy. Cursor movement etc bugs. Too lazy to + fix it. + + o Logic for handling multiple same nicknames for example in private + message sending. I guess the logic is done in server side but is + missing from client. + + o Private message key setting is missing and must be implemented. + Currently private messages are encrypted with session keys. This + is required by the protocol. + + o Channel private key setting is missing and must be implemented. + Currently there cannot be private keys for channels. Normal channel + keys (generated by server) are used. This is required by the protocol. + + o Public and private key generation is now done everytime the program + is run. Now, this is only for testing period as I've been lazy to + do it any better for now. This must be fixed. + + o I guess, public key authentication (when connecting to a server) + is not working currently. It is just matter of loading the keys + from file and using them (see corresponding code in server, it should + support public key authentication already). + + o Multiple windows support. Basic support for multiple windows already + exists but a lot is still missing to get it working. Also, some + of the existing stuff probably needs to be tweaked a bit before the + multiple windows support could be done. And of course the actual + commands that control the windows needs to be written (/WINDDOW). + + o Implement /KEYMAP (or similiar) command to remap control and function + keys. + + o Implement /ALIAS command to make command aliases. + + o Implement /set/if/do/while etc as in IRC2. Maybe post 1.0 task. + Some scripting would be good. + + o Connection Authentication request resolving is missing and must be + done. This is required by the protocol. + + o Key Exchange protocol's responder side is missing from client. + Generally it is possible for the client to be responder so it should + be implemented (See corresponding code from server). Error handling + in the KE protocol is also in pretty bad shape in client. + + o Configuration file loading from global and from local dirs. This + is currently missing and I guess the global is only used. Old SILC + version (in 1997) had ~./silc directory that I guess should be done + now as well. The code for handling those exists but not in current + source tree. + + o Configuration file format - could be better. + + o Write help files for commands. Nice format for the help files should + be selected. I'm open for ideas. + + o All allocations and freeing needs to be checked for memory leaks. + Also, return values from various allocations and functions needs to + checked. + + +TODO In SILC Server +=================== + + o Implement all commands on server side. A lot of commands are still yet + to be implemented. Most of them are trivial but some will require some + planning. Go see the command.c for unimplemented commands. + + o DNS/IP lookup blocks the server. This must be fixed. Check the + resolver stuff (resolver(3), resolver(5)). Either we have to do the + own resolver stuff (through scheduler, if possible without writing + too much own stuff) or use threads. + + o Lenght of the packet processing timeouts needs to be checked whether + they are too short or too long. I haven't really tested whether they + are suitable. They should be tested on high load which I haven't done + at all yet. + + o Public and private key generation is now done everytime the program + is run. Now, this is only for testing period as I've been lazy to + do it any better for now. This must be fixed. + + o Server says that it is able to listen on multiple ports but currently + that is bogus. It can, but internals are for single server. + + o Command lagging must implemented. Those commands (all currently) that + has the LAG flag set they must not be allowed to be executed more than + once, say, in 2 seconds. + + o Command flag usage in general is not implemented yet. + + o Client history must be implemented. Protocol says that server must + keep history information about clients for some period of time. + + o Channel flags and user modes on channels are not implemented yet as + /MODE command is not implemented yet in client and server. + + o Protocol execution timeouts are hard coded, should be configurable. + + o Channel message sending routines uses a lot of common code. Should + create a common function for those instead of writing the same code + again everytime, as done now. + + o serverutil.c I guess should be created for util-like functions that + now resides in server.c, which is getting too big. + + o serverconfig.c and the function naming in it is inconsistent. It is + not silc_config_server* it should be silc_server_config*. As should + all the SilcConfigServer* types be SilcServerConfig*. + + o Implement DENY_CONNECTION section in serverconfig.c and in server. + + o Implement REDIRECT_CLIENT section in serverconfig.c and in server. + + o Configuration file format - could be better. + + o IP address fields in configuration file should accept mask format + as well, IP/MASK, and not just plain IP. + + o Connection classes should be actually implemented in serverconfig.c. + They can be defined but they are totally ignored currently. + + o Acceptance of incoming connections (client and server connections) + should be checked before key exchange protocol. Currently it is + checked at the authentication phase after KE, that is ok, but it should + be checked before starting KE, as well. + + o Statistics are totally missing from the server. It would be nice + to gather some statistics. + + o All allocations and freeing needs to be checked for memory leaks. + Also, return values from various allocations and functions needs to + checked. + + +TODO In SILC Libraries +====================== + + o Public key verification in SKE (SILC Key Exchange) protocol is missing, + thus currently we trust on all public keys. This probably doesn't cause + bad problems but the mechanism of verifying it from local database + (from files) needs to be done (it can open man-in-the-middle-attacks). + + o Implement PFS (Perfect Forward Secrecy) flag in SKE (and in client and + server, actually). If PFS is set, re-key must cause new key exchange. + This is required by the SILC protocol. + + o Re-key in general is actually missing (from everywhere) and must be done. + + o SKE does not send correct status types. Types are defined but not + sent. + + o Connection authentication protocol does not send correct status types. + These types are not defined currently at all. + + o PKCS#1 style RSA public key encryption/decryption/sign/verify is + missing, and should be added for interoperability reasons. The thing + I've done now is bad and should be removed as soon as possible (or + the protocol should then state the method of how they should be done). + + o SILC public key file type is bad. I'd like to see PEM encoded files. + I have public domain code for base64 encoding but it needs to be + rewritten. + + o Slow ciphers should be removed. I think we don't need more than + the AES finalists plus blowfish and RC5. + + o These slow ciphers actually don't work currently as I've tested + only the ones that are worth testing. The CBC mode on these slow + ciphers probably don't work. No need to worry, these ciphers should + be removed. + + o Scheduler needs to be analyzed on high load as it might be unfair + towards select() because it may run timeout tasks before select() and + after select(). If it is found to be unfair the timeout task running + before select() should probably be removed. + + o On select() issue; maybe we should use poll() instead if it is + available? poll() doesn't have max fd limit... + + 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). + + o Compression routines are missing. The protocol supports packet + compression thus it must be implemented. SILC Comp API must be + defined. zlib package is already included into the lib dir (in CVS, + not in distribution), but it is not used yet, and it requires some + tweaking on the Makefiles (we want static lib not shared). + + o Cipher API needs to be made more consistent. Some parts of the + code generated with current Cipher API looks really bad. Same + is with PKCS API, even worse actually. They need to be made + cleaner. Introducing silc_cipher_encrypt/decrypt/set_key etc. + functions (I actually don't understand why have I left these un-done). + + o Scheduler should automatically allocate task queues if NULL pointers + are passed to the silc_schedule_init. Would make initialization + cleaner. + + o Packet processing routines in client and server are actually pretty + much generic and should be moved from the client/server to the library + as generic routines (silc__packet_decrypt_rest* etc). + This requires heavy changes to the client and server. + + o Random Number Generator needs some tweaking. Reading /dev/random may + block resulting slow initialization of RNG. Some other things in the + RNG may block as well. Also, I have some pending changes to the RNG + that needs to be commited (from Schneier's Yarrow-160 paper). They + should make the RNG even better. + + o Logging should be made more generic in a way that application can + set to where the logging is destined to. Now, it is always destined + to stdout (or stderr) which is a bad thing for client. Ie. some + sort of logging registration functions or similiar should be done + (silclog.[ch] in core). The actual output of logs should be done + by callback function in the application not in lib. + + o I don't like the ID cache system currenly implemented. Ugly and + not so good. Must be rewritten very soon. + + o All allocations and freeing needs to be checked for memory leaks. + + o There are also checks missing from allocations whether the allocation + returns valid memory or NULL. These are missing in library as well + in client and server. Either all checks has to be added or we will + have to make sure that silc_*alloc()s always return valid memory + and assert()s if the system's memory allocator (*alloc()) fails. + + o silc_buffer_[un]format() needs to be made more stable as it may + crash the SILC if malformed data is sent as argument. There are a + lot of places in client and server where we trust directly data coming + from network and try to unformat it. The unformatting routine needs + to be able handle situations where data sent is malformed, by mistake + or intentionally. This is important as it is easy to crash the SILC + now by just sending malformed data. Also, in client and server we + must start checking the return value from silc_buffer_[un]format. + + +Other Things TODO +================= + + o Write manuals for server. + + o Write manuals for client. + + o Write SILC Library Reference manual. This would include all the SILC + API's with simple examples how the functions are to be used. This is + pretty easy to create by taking all the functions plus their comments + from source/header files. However, same sort of reference manual + should be written for client and server as well. + + +TODO After 1.0 +============== + + o Pthreads support. A lot of problems are solved with server (and with + client as well) if we add pthread support. We can forget things such + as non-blocking connecting etc, and we can do things such as DNS/IP + lookups async. The server itself also benefits great deal from + threads, especially from performance point of view. + + But, this is not a small task and almost entire SILC Library has to + be made re-entrant. Own API is probably added for the threads support + to make changes in the future as painless as possible. So the API + would have things like silc_mutex_lock, silc_mutex_unlock and + friends... + + o X.509 certificate support. SILC protocol supports certificates and + it would be great to have support for them. This is a big task as + support has to be made for ASN.1 as well. I've looked into OpenSSL + package as it has X.509 certificate support (and ASN.1 as well). + The code does not look very good to my eye but it has some potentials. + This should be looked at more closely. + + Naturally own SILC Certificate API has to be defined regardles what + the actual X.509 library is (OpenSSL X.509 or something else). Other + choice is to write own X.509 library but I'm not going to do it - + I can help to migrate the OpenSSL X.509 into SILC and I can help if + someone would like to write the X.509 library - but I'm not going + to start writing one myself. Anyhow, the OpenSSL X.509 lib should + be checked. + + o SSH2 public keys support. Maybe - not really needed but could be + nice as SSH is widely used all over the place. SILC Protocol + supports SSH2 public keys. + + o IRC support for SILC client. This would be nice to have on client + as it could be used to connect to SILC and IRC. People wouldn't + have to have two different clients when same would work on both. + I'd like to see this done as SIM, after the extended SIM support + has been added to SILC. + + o Cipher optimizations (asm, that this) at least for i386 would be nice. +
+
+ +
+ + \ No newline at end of file

Contact

SILC Documentation

Other Documentation

SILC Protocol Internet Drafts

SILC XXXX2000 Development Version Available

SILC 28062000 Development Version Available

Developers Wanted For SILC Project

SILC Project Started

TODO