From: Pekka Riikonen Date: Tue, 31 Jul 2001 21:05:04 +0000 (+0000) Subject: updates. X-Git-Tag: robodoc-323~18 X-Git-Url: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff_plain;h=ffd05b70722719de41399b91b7505f8a43c286e8 updates. --- diff --git a/doc/whitepaper/silc_protocol.html b/doc/whitepaper/silc_protocol.html index 62c7aa4d..e7bdaa23 100644 --- a/doc/whitepaper/silc_protocol.html +++ b/doc/whitepaper/silc_protocol.html @@ -11,10 +11,10 @@ -SILC Protocol White Paper
+SILC Protocol White Paper
Version 1.0 / 05 Aug 2001 -


+

Introduction

Chat protocols are very popular on the Internet. They have actually @@ -51,7 +51,7 @@ protocol specifications are freely available and they have been submitted to the IETF. The very first implementations of the protocol are also already available. - +


About This White Paper

The purpose of this white paper is to give short but deep enough introduction @@ -213,8 +213,36 @@ the routers. All the secondary routes also have their own session keys.

SILC Packet Protocol

+The basis of SILC protocol relies in the SILC packets and they are with +out a doubt the most important part of the protocol. The SILC Packet +protocol is a binary packet protocol. The protocol provides secure +binary packets and assures that the contents of the packets are secured +and authenticated. +

+ +Packets are used in the SILC protocol all the time to send for example +channel messages, private messages, commands and other information. All +packets in SILC network are always encrypted and their integrity is +assured by computed Message Authentication Codes (MAC). 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. Hence, the actual data in the packet is the packet payload +defined in the protocol. +

+ Typical SILC Packet +


+As the diagram above illustrates the SILC packet is constructed from the +SILC Packet Header that is included in all SILC packets, data area that +includes the packet payloads, and MAC area which assures the integrity of the +packet. Entire SILC packet is always encrypted, except for the MAC area +which is never encrypted. The encryption process and the key used, +however depends on the packet payload. Some of the payloads are encrypted +with the session key and some are encrypted with other keys, for example +with channel message keys. The SILC Packet Header is always encrypted with +the session key. The MAC is computed from the SILC Packet Header and the +data area before encrypting the packet.


@@ -232,16 +260,137 @@ the routers. All the secondary routes also have their own session keys.

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 joins to it, and the channel ceases to exist when the last client +leaves it. When channel exists, any client can reference it using the +name of the channel. Channel is a place where group of people can engage +conversation. +

+ +Channel names are unique in the SILC Network. There cannot be multiple +same channels in the network at the same time. However, channel has also +a Channel ID which is actually used to reference the channel in the +SILC Network. The maximum length for the channel name is 256 characters. +

+ +Channels can have operators that can administrate the channel and operate +all of its modes. There are two types of operators on the channel: +channel founder and channel operator. +

+ +The channel founder is the client which created the channel. Channel +founder is channel operator with some more privileges. Channel founder +can operate all of the channel's modes. Furthermore, channel founder +privileges cannot be removed by any other operator on channel and channel +founder cannot be removed from the channel by force. It is also possible +for the channel founder to regain its privileges at later time, even if +they have left the channel. +

+ +Channel operator is operator that can operate most of the channel's +modes and administrate the channel. However, it cannot operate all +modes which are strictly reserved for channel founder. Channel operator +is, however able to adminstrate the channel, set some modes on the +channel, remove a badly behaving client from the channel, and promote +other clients to become channel operator. + +


Channel Message Delivery

+All clients that have joined the channel can send messages to the channel. +All channel messages are secured and authenticated by channel key. The +channel key is generated by the server when the channel is created, +a client joins the channel, or a client leaves the channel. The channel +key is also regenerated periodically. The reason for the regeneration +of channel key everytime someone joins or leaves the channel is that +it prevents new clients joining the channel, and old clients leaving the +channel, to encrypt or decrypt old or new messages. They can encrypt +and decrypt channel messages only when they have joined on the channel. +

+ +Channel keys are cell specific in the SILC Network. Each cell that +have clients joined on a particular channel have also own key for the +channel. That key is not shared by other cells in the network. Inside +the cell the channel key is known by the router and all servers that +have clients on the channel and all clients that have joined the channel. + +

Channel Message Delivery +


+ +The diagram above illustrates typical delivery of channel messages inside +a cell and between two cells. Both of the cells have their own channel +key. Both cells knows all clients joined on the channel. When message +is sent to the channel by an client, it is encrypted with the current +channel key in that cell. The servers and the router in the local cell +then routes the message to all local clients who have joined the channel. +If the channel has clients that belong to other cell in the network the +router will route the channel message to that cell. When channel +messages are send between routers they are first decrypted with the +current channel key, and then re-encrypted with the session key shared +between the two routers. The router who receives the channel message +then decrypts it with the session and re-encrypts it with the +current channel key in that cell. It then distributes the channel message +to all clients on the channel. The clients who have joined the channel +always knows the current channel key and can decrypt all channel messages +they receive. Note that normal servers in the SILC network never decrypt +the channel messages even though the have the key. There is no reason +for servers to decrypt the message. The router decrypts the message +only when sending it between two routers. +

+ +This method of channel message delivery is the the default way to send +channel messages in the SILC Network. However, this is not perfect +solution on all circumstances. If the clients joined on a particular +channel cannot trust, or do not want to trust the servers and routers +in the SILC Network they can consider the fact, that servers and routers +knows the channel key is actually a breach of security. +

+ +If the clients on the other hand can trust their servers and routers +in the SILC Network this is the recommended way of sending channel +messages. This method is the simplest method for end user since it +does not require any special settings before engaging the conversation +on the channel. The client merely joins the channel, receives the +channel key from the server and can start the conversation on the +channel.


Channel Message Delivery With Channel Private Key

+If the clients cannot trust the servers and routers in the SILC Network +they should not use the default way of sending the channel messages. +Instead, they should use channel private keys to encrypt and decrypt +the channel messages. Channel private keys are keys that are known +only by the clients who have joined the channel. All servers and +routers do not know the key and cannot decrypt the messages. When +message is sent between two routers they are merely re-encrypted with +the session key but not decrypted since the router do not have the +key to do that. +

+ +The clients who have joined the channel must first agree on the channel +private key they are going to use. The key may generally be anything. +It may be a passphrase or a random string, or the key may negotiated +using some key negotiation protocol which provides exchanging the +key for multiple clients at the same time. +

+ +As the channel private key is actually entirely local setting in the +client, it is possible to set several channel private keys for one +channel. It is possible to have multiple channel private keys that +are not known by all channel members. When encrypting messages with +one channel private key only the clients who have that key can decrypt +the message. The other key could be shared for example by all clients +on the channel and thus all clients can decrypt messages encrypted with +that key. In this way it is actually possible to have private group +conversation inside the channel while having global conversation at the +same time. +


Private Messages