is used in the communication in the SILC network. The client ID is
based on the user's IP address and nickname. User use logical nicknames
in communication which are then mapped to the corresponding Client ID.
-Client ID's are low level identifications and should not be seen by the
+Client IDs are low level identifications and should not be seen by the
end user.
Clients provide other information about the end user as well. Information
3.1.1 Client ID
Client ID is used to identify users in the SILC network. The Client ID
-is unique to the extent that there can be 2^128 different Client ID's,
-and ID's based on IPv6 addresses extends this to 2^224 different Client
-ID's. Collisions are not expected to happen. The Client ID is defined
+is unique to the extent that there can be 2^128 different Client IDs,
+and IDs based on IPv6 addresses extends this to 2^224 different Client
+IDs. Collisions are not expected to happen. The Client ID is defined
as follows.
.in 6
Normal server keeps various information about the clients and their end
users connected to it. Every normal server MUST keep list of all locally
-connected clients, Client ID's, nicknames, usernames and host names and
+connected clients, Client IDs, nicknames, usernames and host names and
user's real name. Normal servers only keeps local information and it
does not keep any global information. Hence, normal servers knows only
about their locally connected clients. This makes servers efficient as
they do not have to worry about global clients. Server is also responsible
-of creating the Client ID's for their clients.
+of creating the Client IDs for their clients.
Normal server also keeps information about locally created channels and
-their Channel ID's.
+their Channel IDs.
Hence, local list for normal server includes:
channel list - All channels in server
o Channel name
o Channel ID
- o Client ID's on channel
+ o Client IDs on channel
o Client ID modes on channel
o Channel key
.in 3
Servers are distinguished from other servers by unique 64 bit Server ID
(for IPv4) or 160 bit Server ID (for IPv6). The Server ID is used in
-the SILC to route messages to correct servers. Server ID's also provide
-information for Client ID's, see section 3.1.1 Client ID. Server ID is
+the SILC to route messages to correct servers. Server IDs also provide
+information for Client IDs, see section 3.1.1 Client ID. Server ID is
defined as follows.
.in 6
channel list - All channels in the cell
o Channel ID
- o Client ID's on channel
+ o Client IDs on channel
o Client ID modes on channel
o Channel key
.in 3
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
+includes all the clients on SILC, their Client IDs, all created channels
+and their Channel IDs and all servers and routers on SILC and their
+Server IDs. 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.
channel list - All channels in SILC
o Channel ID
- o Client ID's on channel
+ o Client IDs on channel
o Client ID modes on channel
.in 3
.ti 0
3.3.3 Router's Server ID
-Router's Server ID's are equivalent to normal Server ID's. As routers
-are normal servers same types of ID's applies for routers as well. See
+Router's Server ID is equivalent to normal Server ID. As routers are
+normal servers same types of IDs applies for routers as well. See
section 3.2.2 Server ID.
on the channel. However, channels MAY have channel private keys that are
entirely local setting for the client. All clients on the channel MUST
know the channel private key beforehand to be able to talk on the
-channel. In this case, no server or router knows the key for channel.
+channel. In this case, no server or router knows the key for the channel.
Server shares secret symmetric session key with router which is
established by the SILC Key Exchange Protocol. Every packet passed from
server to router, with exception of packets for channels, are encrypted
with the shared session key. Same way, router server shares secret
-symmetric key with its primary route. However, every packet passed
+symmetric key with its primary router. However, every packet passed
from router to other router, including packets for channels, are
encrypted with the shared session key. Every router connection MUST
have their own session keys.
is available in the SILC Packet Header which is included in all packets
sent in SILC network. The SILC Packet Header is described in [SILC2].
-The header MUST be encrypted with the session key who is next receiver
-of the packet along the route. The receiver of the packet, for example
-a router along the route, is able to determine the sender and the
+The header MUST be encrypted with the session key of whom is the 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
+checking the IDs attached to the header. The IDs in the header will
tell to where the packet needs to be sent and where it is coming from.
The header in the packet MUST NOT change during the routing of the
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
+o Client 1 sends encrypted packet to its server. The packet is
encrypted with the session key shared between client and its
server.
session key shared between the server and the destination client,
and sends the packet to the client.
-o Client 2. decrypts the packet.
+o Client 2 decrypts the packet.
Example: Private message from client to another client on different
- servers. Clients has established secret shared private
+ servers. Clients have established a 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 header
+o Client 1 sends encrypted packet to its server. The packet header
is encrypted with the session key shared between the client and
server, and the private message is encrypted with the private
message delivery key shared between clients.
to and sends the packet to the client. Header is encrypted with
the session key.
-o Client 2. decrypts the packet with the secret shared key.
+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
Packet header is encrypted with the session key, message
data is encrypted with channel key.
-o Client 1. encrypts the packet with channel key and sends the
+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
router or fastest route.
o (Other router(s) do the same thing and sends the packet to
- the server(s))
+ the server(s).)
o Server determines local clients on the channel and sends the
packet to the client.
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 another router connects
+but also when server and router, and router and another router connect
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
client connecting to the server. However, clients MAY be accepted
to connect to server without explicit authentication. Servers are
REQUIRED to use authentication protocol when connecting. The
-authentication may be based on passphrase (pre-shared-secret) or public
+authentication may be based on passphrase (pre-shared secret) or public
key based on digital signatures. All passphrases sent in SILC protocol
MUST be UTF-8 [RFC2279] encoded. The connection authentication protocol
is described in detail in [SILC3].
.ti 0
3.9.1 Authentication Payload
-Authentication payload is used separately from the SKE and the Connection
+Authentication Payload is used separately from the SKE and the Connection
Authentication protocols. It can be used during the session to
authenticate with a remote. For example, a client can authenticate
itself to a server to become server operator. In this case,
o Public Data (variable length) - This is defined only if
the authentication method is public key. If it is any other
- this field MAY include a random data for padding purposes.
+ this field MAY include random data for padding purposes.
However, in this case the field MUST be ignored by the
receiver.
.in 3
-If the authentication method is password based, the Authentication
-Data field includes the plaintext UTF-8 encoded password. It is safe
-to send plaintext password since the entire payload is encrypted. In
+If the authentication method is passphrase-based, the Authentication
+Data field includes the plaintext UTF-8 encoded passphrase. It is safe
+to send plaintext passphrase since the entire payload is encrypted. In
this case the Public Data Length is set to zero (0), but MAY also include
random data for padding purposes. It is also RECOMMENDED that maximum
-amount of padding is applied to SILC packet when using password based
+amount of padding is applied to SILC packet when using passphrase-based
authentication. This way it is not possible to approximate the length
-of the password from the encrypted packet.
+of the passphrase from the encrypted packet.
If the authentication method is public key based (or certificate)
the Authentication Data is computed as follows:
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
+in the SILC packets. See [SILC2] for 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.
3.10.1.1 CBC Mode
The "cbc" encryption mode is CBC mode with inter-packet chaining. This
-means that the Initial Vector (IV) for the next encryption block is
-the previous ciphertext block. The very first IV MUST be random and is
-generated as described in [SILC3].
+means that the Initialization Vector (IV) for the next encryption block
+is the previous ciphertext block. The very first IV MUST be random and
+is generated as described in [SILC3].
.ti 0
3.10.1.2 CTR Mode
-The "ctr" encryption mode is CTR mode. The CTR mode in SILC is stateful
-in encryption and decryption. Both sender and receiver maintain the
-counter for the CTR mode and thus can precompute the key stream for
+The "ctr" encryption mode is Counter Mode (CTR). The CTR mode in SILC is
+stateful in encryption and decryption. Both sender and receiver maintain
+the counter for the CTR mode and thus can precompute the key stream for
encryption and decryption. By default, CTR mode does not require
plaintext padding, however implementations MAY apply padding to the
packets. If the last key block is larger than the last plaintext block
process is simple XOR with the plaintext block and the key stream block.
The counter block is used to create the key for the CTR mode. When
-SILC specifications refer to Initial Vector (IV) in general cases, in
-case of CTR mode it refers to the counter block. The format of the
+SILC specifications refer to Initialization Vector (IV) in general cases,
+in case of CTR mode it refers to the counter block. The format of the
128 bit counter block is as follows:
.in 5
of the public key algorithm, and the public key or certificate encoding.
When using SILC public key the signature is computed as described in
previous paragraph for RSA and DSS keys. If the hash function is not
-specified separately for signing process sha1 MUST be used. When using
+specified separately for signing process SHA-1 MUST be used. When using
SSH2 public keys the signature is computed as described in [SSH-TRANS].
When using X.509 version 3 certificates the signature is computed as
described in [PKCS7]. When using OpenPGP certificates the signature is
.in 6
o Public Key Length (4 bytes) - Indicates the full length
- of the public key, not including this field.
+ of the SILC Public Key, not including this field.
o Algorithm Name Length (2 bytes) - Indicates the length
of the Algorithm Length field, not including this field.
All fields in the public key are in MSB (most significant byte first)
order. All strings in the public key MUST be UTF-8 encoded.
-If an external protocol need to refer to SILC Public Key by name, the
-name "silc-rsa" and "silc-dss" for SILC Public Key based on RSA algorithm
+If an external protocol needs to refer to SILC Public Key by name, the
+names "silc-rsa" and "silc-dss" for SILC Public Key based on RSA algorithm
and SILC Public Key based on DSS algorithm, respectively, are to be used.
However, this SILC specification does not use these names directly, and
they are defined here for external protocols (protocols that may like
.ti 0
3.13 Backup Routers
-Backup routers may exist in the cell in addition of the primary router.
-However, they must not be active routers and act as routers in the cell.
+Backup routers may exist in the cell in addition to the primary router.
+However, they must not be active routers or act as routers in the cell.
Only one router may be acting as primary router in the cell. In the case
-of failure of the primary router may one of the backup routers become
-active. The purpose of backup routers are in case of failure of the
-primary router to maintain working connections inside the cell and outside
-the cell and to avoid netsplits.
+of failure of the primary router one of the backup routers becomes active.
+The purpose of backup routers are in case of failure of the primary router
+to maintain working connections inside the cell and outside the cell and
+to avoid netsplits.
Backup routers are normal servers in the cell that are prepared to take
over the tasks of the primary router if needed. They need to have at
router's responsibility to feed the data to the backup router. If the
backup router does not know all the data in the case of failure some
connections may be lost. The primary router of the cell must consider
-the backup router being actual router server when it feeds the data to
-it.
+the backup router being an actual router server when it feeds the data
+to it.
-In addition of having direct connection to the primary router of the
+In addition to having direct connection to the primary router of the
cell, the backup router must also have connection to the same router
-the primary router of the cell is connected. However, it must not be
-active router connection meaning that the backup router must not use
-that channel as its primary route and it must not notify the router
-about having connected servers, channels and clients behind it. It
-merely connects to the router. This sort of connection is later
-referred as being passive connection. Some keepalive actions may be
-needed by the router to keep the connection alive.
+to which the primary router of the cell is connected. However, it must
+not be the active router connection meaning that the backup router must
+not use that channel as its primary route and it must not notify the
+router about having connected servers, channels and clients behind it.
+It merely connects to the router. This sort of connection is later
+referred to as being a passive connection. Some keepalive actions may
+be needed by the router to keep the connection alive.
It is required that other normal servers have passive connections to
the backup router(s) in the cell. Some keepalive actions may be needed
backup router as its new primary router as soon as the original primary
router becomes unresponsive.
-All of the parties of this protocol knows which one is the backup router
-of the cell from their local configuration. Each of the entity must
+All of the parties of this protocol know which one is the backup router
+of the cell from their local configuration. Each of the entities must
be configured accordingly and care must be taken when configuring the
backup routers, servers and other routers in the network.
It must be noted that some of the channel messages and private messages
may be lost during the switch to the backup router. The announcements
-assures that the state of the network is not lost during the switch.
+assure that the state of the network is not lost during the switch.
It is RECOMMENDED that there would be at least one backup router in
the cell. It is NOT RECOMMENDED to have all servers in the cell acting
backup routers in the cell.
The order of the backup routers are decided at the local configuration
-phase. All the parties of this protocol must be configured accordingly
-to understand the order of the backup routers. It is not required that
-the backup server is actually active server in the cell. Backup router
+phase. All the parties of this protocol must be configured accordingly to
+understand the order of the backup routers. It is not required that the
+backup server is actually an active server in the cell. The backup router
may be a redundant server in the cell that does not accept normal client
connections at all. It may be reserved purely for the backup purposes.
topics and other information to the backup router. This is to assure
that none of the important notify packets were lost during the switch
to the backup router. The backup router must check which of these
-announced entities it already have and distribute the new ones to the
-primary route.
+announced entities it already has and distribute the new ones to the
+primary router.
The backup router too must announce its servers, clients, channels
and other information to the new primary router. The primary router
-of the backup router too must announce its informations to the backup
+of the backup router too must announce its information to the backup
router. Both must process only the ones they do not know about. If
-any of the announced modes does not match then they are enforced in
+any of the announced modes do not match then they are enforced in
normal manner as defined in section 4.2.1 Announcing Clients, Channels
and Servers.
resuming protocol is executed. The protocol is advanced as follows:
1. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
- value 1 the primary router that came back online. The packet
+ value 1 to the primary router that came back online. The packet
will indicate the primary router has been replaced by the backup
router. After sending the packet the backup router will announce
all of its channels, channel users, modes etc. to the primary
Other choice is to entirely use keys that are not sent through
the SILC network at all. This significantly adds security. This key
-could be a pre-shared-key that is known by both of the clients. Both
+could be a 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. In
case of pre-shared keys (static keys) the IV used in encryption SHOULD
projects / silc.git / commitdiff