From: Pekka Riikonen Date: Thu, 29 Jun 2000 13:08:43 +0000 (+0000) Subject: Removed. Not needed, create by hand always for the site. X-Git-Tag: SILC.0.1~548 X-Git-Url: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff_plain;h=8e9f24545a6ce1ee2a7d478bfd15a09c9fec8833 Removed. Not needed, create by hand always for the site. No reason to start keeping these up to date here. --- diff --git a/public_html/docs/draft-riikonen-silc-ke-auth-00.txt b/public_html/docs/draft-riikonen-silc-ke-auth-00.txt deleted file mode 100644 index d180a985..00000000 --- a/public_html/docs/draft-riikonen-silc-ke-auth-00.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -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 deleted file mode 100644 index fd618101..00000000 --- a/public_html/docs/draft-riikonen-silc-pp-00.txt +++ /dev/null @@ -1,2467 +0,0 @@ - - - - - - -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 deleted file mode 100644 index 361e865f..00000000 --- a/public_html/docs/draft-riikonen-silc-spec-00.txt +++ /dev/null @@ -1,3363 +0,0 @@ - - - - - - -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