Introduction

The security is important feature in applications and protocols in contemporary network environment. The older chat protocols, however have failed to deal with the growing security requirements on the Internet. It is not anymore enough to just provide services, like for example chat services. Now, they need to be secure services.

The Secure Internet Live Conferencing (SILC) protocol is a new generation chat protocol which provides full featured conferencing services, just like any other contemporary chat protocol provides. In addition, it provides security by encrypting and authenticating the messages in the network. The security has been the primary goal of the SILC protocol and the protocol has been designed from the day one security in mind. All packets and messages travelling in the SILC Network are always encrypted and authenticated. The network topology is also different from for example IRC network. The SILC network topology attempts to be more powerful and scalable than the IRC network. The basic purpose of the SILC protocol is to provide secure conferencing services.

The SILC Protocol have been developed as Open Source project. The 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 to the SILC Protocol. The document describes the purpose of the protocol and how the protocol works in practice. This document is intended for all audience. This document should be easy to understand for non-technical person and still be detailed enough for technically oriented person. See the section Terms and Abbreviations for terms used in this documents.

(c) Copyright 2001 Pekka Riikonen (priikone at silcnet.org)

This document is free document; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

SILC Protocol

Clients

A client is a piece of software connecting to SILC server. The software is usually run by the end user, a real person that is. The purpose of the clients is to provide the end user an interface to the SILC services. They are used to actually engage the conversations on the SILC Network, and they can be used to execute various SILC commands.

The clients are distinquished from other clients by unique Client ID. There cannot be multiple same Client IDs in the SILC Network at the same time. The end user, however does not use Client IDs. The end users usually selects a perferred nickname they want to use, and identifies themself with that nickname to other users on the network. The nicknames are not unique in the SILC Network. There can be multiple same nicknames at the same time on the network. The maximum length for the nickname is 128 characters.

Most of the other chat protocols have unique nicknames. This is where SILC differs from most of the other chat protocols. The purpose of this feature is to make IRC style nickname wars obsolete, as no one owns their nickname; there can always be somene else with the same nickname.

When client connects to the server the SILC Key Exchange (SKE) protocol and SILC Connection Authentication protocol are executed. The result of the SKE protocol is the session key that the client and server use to secure their communication. All commands, for example, that the client sends to the server are secured with the session key. The session key expires periodically and the rekey process can be executed with or without the Perfect Forward Secrecy (PFS). The connection authentication protocol is used to authenticate the client to the server. The server may allow the client to connect without authentication, or it may require a passphrase or public key encryption based authentication.

Servers

Servers forms the basis for the SILC Network, by providing a point to which clients may connect. There are two kinds of servers in SILC; normal servers and router servers. The next section describes the function of router server.

Normal servers connect to router server. Normal servers cannot directly connect to other normal servers. Messages that are destined outside the local server are always sent to the router for further routing. The clients usually connect to the normal server, however, clients may connect to router servers as well. The SILC Network diagram above illustrates how normal servers connects to the router server.

The servers are distinquished by other servers in the network by unique Server ID. There cannot be multiple same Server IDs in the SILC Network at the same time. The servers keep track of local information. It knows all locally connected clients and it knows all channels that its clients have joined. However, it does not know any global information. It usually does not keep track of global clients, however, it may cache that information if it was queried. The reason for this is that the server does not need to keep global information up to date and thus makes the server faster. They can always query the information from the router.

When server connects to its router the SILC Key Exchange (SKE) protocol and the SILC Connection Authentication protocol are executed, just like when client connects to server. The SKE results in to the session key that is used to secure the communication between the server and the router. The connection authentication protocol is used to authenticate the server to the router. The authentication is always based in either passphrase or public key encryption.

Routers

The router servers are servers that actually handles the message routing in the network. They are, however also normal servers and they do accept client connections. Each of the router in the network is called a cell. A cell can have only one active router and it may have several servers and several clients. The cell, however may have backup routers that can take over the tasks of the primary router if it becomes unresponsive. The switch to the backup router should be transparent and only local connections to the primary router are lost. Other connections in the cell are intact, and clients and servers merely experience some lag in the network connection during the switch to the backup router.

The normal server knows only local information. Router server on the other hand knows local information and global information. It considers the cell as local and outside cells as global. It knows all the clients connected to the network, all created channels, and all routers and servers in the network. The server may query the global information if it is needed. For example, when client sends WHOIS command, the server may query the information from the router. If the router does not know all the details that the WHOIS command requires it can query the information from a router or a server which knows all the details. It may then cache that information.

The primary purpose of the router server is to route the messages to local servers and local clients, and messages that are destined to outside the cell are routed to the primary route or some other secondary route if it is a faster route. The routers in the network forms a ring. Each router has a primary route to other router in the network. Finally the ring is closed by the last router using the first router in the network as its primary route.

The diagram above illustrates how the routers forms a ring in the network. A router may have several secondary routes which it may use when it routes the packets.

When routers connect to its primary router the SKE and the SILC Connection Authentication protocols are executed just like when normal server connects to its router. The session key is used to secure the communication between the routers. All the secondary routes also have their own session keys.

SILC Packet Protocol

SILC Key Exchange Protocol

SILC Connection Authentcation Protocol

Channels

Channel Message Delivery

Channel Message Delivery With Channel Private Key

Private Messages

Private messages are messages that are sent from one client to another through the SILC Network. They are private because they are not sent to anyone else except to the true receiver of the message. Private messages can be used to engage private conversation with another client if channels are not desired.

As all messages in SILC the private message are also encrypted and authenticated. There are several ways to secure private messages. By default private messages are encrypted using the session keys established in the SKE protocol. It is also possible to negotiate a private message key between the two clients and encrypt the messages with that key. It is even possible to encrypt the messages with public key cryptosystem, if desired. The next sections will describe all these private message delivery methods.

The SILC protocol provides these three methods of delivering private messages because none of the methods alone can satisfy the security requirements of all people. The end user should decide the acceptable level of risk, the required level of security and other security and usability aspects when deciding what way of sending private message suites for them.

Private Message Delivery With Session Keys

Sending private messages are by default secured with session keys established in the SKE protocol. This means that the private message is always encrypted with the session key of the next receiver of the message enroute to the receiving client. This also means that the message is decrypted and re-encrypted everytime it is sent further to the receiving client.

As the above diagram shows the private messages sent by Client A to the Client B travels through the SILC Network and is always decrypted and re-encrypted with the session key of the next receiver. The Client B then finally decrypts the private messages that is encrypted with the session key shared between the Client B and the Server Y.

This way of securing private messages is not perfect and cannot be used in all circumstances. If the clients having the conversation cannot trust the servers and routers in the SILC Network they should not send private messages that are secured in this manner. Messages secured in this manner can be decrypted by the servers and routers that the clients may consider to be untrusted.

If the clients on the other hand trust the servers and routers in their SILC Network, or they do not care that servers can decrypt their messages, sending private messages in this way is very simple from client's point of view. For servers and routers this of course means that they need to decrypt and re-encrypt each private message. Since this way of securing private message cannot be used at all times the SILC protocol provides other ways of securing private messages.

Private Message Delivery With Private Message Key

Private messages can be secured with private message key as well. This key is known only by the sender of the message and the receiver of the message. This way no one else except the sender and the receiver can encrypt and decrypt the private messages. The message is encrypted by the sender with the private message key and all the servers and routers pass the message through enroute to the receiver. They cannot decrypt the message since they do not have the key. When sending private messages in this way it does not matter whether the clients trust or do not trust the servers and routers in the SILC network.

As the above diagram shows the Client A encrypts the message with private message key and sends the message to the SILC Network. All servers and routers merely pass the message through since they cannot decrypt it. The Client B then receives the message and decrypts it with the private message key.

Sending private messages in this manner is always secure since the key is shared only by the sender and the receiver. The problem of this method is that the sender and the receiver must somehow agree about the key they are going to use. The private message key can generally be anything. It can be a passphrase that only the sender and the receiver knows. They could have been agreed to use some word or phrase as the key sometime earlier before they started the conversation. Or the key maybe from some random string from a code book that only the sender and the receiver poses. Or it can be a key that is negotiated using some key negotiation protocol.

The problem however is fundamental. How to agree to use some key when you cannot reach the other person over secure channel? The SILC protocol solves this problem by providing a possiblity to negotiate the key between two clients using the SKE protocol. One or both of the clients can set up the SKE server running in their host and ask the other client to connect to it. As a result of the SKE protocol the clients have now shared secret that they can use as private message key. The key is known only by the two clients that exexcuted the SKE protocol. They can then use that key to secure all subsequent private messages.

Using this method of private messages delivery is recommended if the clients cannot trust the servers and routers in the SILC Network. The drawback is the extra phase of setting the private message key before starting the conversation. However, using the SKE protocol is the recommended way to negotiate the private message key since it can be automized and does not cause any extra tasks for end user.

Private Message Delivery With Public Key Encryption

If the clients cannot trust the servers and routers in the SILC Network they can use the private message key. As described in the previous section it is easy to set up with the SKE protocol. However, sometimes the two clients do not want to use any passphrases as private message key or negotiate the key with SKE, or perhaps they are unable to negotiate the key because of some other external problem. The SILC protocol provides yet another way of securing the private messages. This way does not require setting or negotiating private message key. And, in this method also it does not matter whether the clients trust or do not trust the servers and routers in the SILC Network. The method is public key encryption. The clients can encrypt the private messages with the receiver's public key and send the message to the network. The servers and routers cannot decrypt the messages since they do not have the receiver's private key. The receiver on the other hand has the private key which it uses to decrypt the message.

As the above diagram shows the Client A has the Client B's public key. It will encrypt the message with that key and sends the message to the SILC Network. All servers and routers pass the message through since they cannot decrypt it. The Client B then uses its private key to decrypt the message. The Client B has also the Client A's public key that it can use to encrypt messages that it will send to Client A.

Even this method of private message delivery is not perfect. The drawbacks of this method is that the public key encryption process, as being assymmetric cryptosystem, is much slower than encryption process with symmetric cryptosystems. This is not probably problem with short messages but may be inconvenient with long messages. The other drawback is that the sender must first assure that the public key it is using in the encryption is actually the receiver's public key. This is a absolute requirement in this method. If the sender cannot authenticate the receiver's public key this method of private message delivery should not be used. In SILC protocol clients can fetch other clients public keys from servers. However, the servers may not have authenticated the fetched public key so that should not be fully trusted. Use of certificates can solve the problem. The receiver's certificate could be authenticated by a third party Certificate Authority (CA).

Usually verifying the public key is not a problem since the receiver can provide the public key on some website, or verify the fingerprint of the key over email, or phone call. The clients can also fetch the public keys from SILC servers if they trust that the keys are authentic. If both of the clients trust that the public keys are authentic using this method of private message delivery is very simple and recommended.

Conclusions

Further Information

More detailed information about the SILC Protocol is available in the SILC Protocol specification documents. There exists currently four Internet Drafts that defines the protocol in great detail. The Internet Drafts are available from the following sources but also from the IETF website.

- Secure Internet Live Conferencing (SILC), Protocol Specification
- SILC Packet Protocol
- SILC Key Exchange and Authentication Protocols
- SILC Commands

Terms and Abbreviations