Private Message Key 0x01
- Indicates that the packet must include private
+ Indicates that the packet data 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.
+ client. Servers does not know this key and cannot
+ handle the packet, but passes it along. See section
+ 2.5.3 Private Message Encryption And Decryption for
+ more information.
List 0x02
Broadcast 0x04
- 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
+ Marks the packet to be broadcasted. Client and normal
+ server cannot send broadcast packets. 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.12 Packet Broadcasting for description of
packet broadcasting.
-
Compressed 0x08
Marks that the payload of the packet is compressed.
.in 3
-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 Packet Type (1 byte) - Indicates 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 Pad Length (1 byte) - Indicates the length of the padding
applied after the SILC Packet header. Maximum length for
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 receiver to parse the packet. The packet type is 8 bits 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 the following packet types.
The below list of the SILC Packet types includes reference to the packet
payload as well. Packet payloads are the actual packet data area. Each
-packet type defines packet payload which usually may only be sent with
+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 a
-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 does not have 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 defined separately in the packet
-description below. Other packets MUST NOT be sent or accepted, if sent,
-to indirectly connected entities.
+router to send SILC_PACKET_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 does not have
+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 defined separately in the
+following packet description list. Other packets MUST NOT be sent or
+accepted, if sent, to indirectly connected entities.
Some packets MAY be sent as lists by adding the List flag to the Packet
Header and constructing multiple packet payloads one after the other.
-When this is allowed it is separately defined below. Other packets
-MUST NOT be sent as list and the List flag MUST NOT be set.
+When this is allowed it is separately defined in the following list.
+Other packets MUST NOT be sent as list and the List flag MUST NOT be set.
List of SILC Packet types are defined as follows.
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.
+ the disconnection is sent inside the packet payload.
Payload of the packet: See section 2.3.3 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.
+ This packet is sent upon successful execution of a protocol.
+ The status of the success is sent in the packet payload.
Payload of the packet: See section 2.3.4 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.
+ This packet is sent upon failure of a protocol. The status
+ of the failure is sent in the packet payload.
Payload of the packet: See section 2.3.5 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.
+ This packet MAY be sent upon rejection of a protocol. The
+ status of the rejection is sent in the packet payload.
Payload of the packet: See section 2.3.6 Reject Payload
This packet is used to send notify message. The packet is
usually sent between server and client, but also between
server and router. Client MUST NOT send this packet. Server
- MAY send this packet to channel as well when the packet is
+ MAY destine this packet to channel as well when the packet is
distributed to all clients on the channel. This packet MAY
be sent as list.
Payload of the packet: See section 2.3.7 Notify Payload.
-
6 SILC_PACKET_ERROR
This packet is sent when an error occurs. Server MAY
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. This packet MAY be sent to
- entity that is indirectly connected to the sender.
+ by channel specific keys. This packet MAY be sent to entity
+ that is indirectly connected to the sender.
Payload of the packet: See section 2.3.9 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.
+ channel when server generates it. Each channel has their own
+ independent keys that is used to protect the traffic on the
+ channel. It is also psosible to use channel private keys that
+ are not server generated. In this case this packet is not used.
+ Client MUST NOT send this packet. This packet MAY be sent to
+ entity that is indirectly connected to the sender.
Payload of the packet: See section 2.3.10 Channel Key Payload
This packet is sent as reply to the SILC_PACKET_COMMAND packet.
The contents of this packet is command specific. This packet
MAY be sent to entity that is indirectly connected to the
- sender.
+ sender. This packet MAY be sent as list.
Payload of the packet: See section 2.3.14 Command Reply
Payload and section 2.3.13 Command
-
13 SILC_PACKET_KEY_EXCHANGE
This packet is used to start SILC Key Exchange Protocol,
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.
+ various information about itself in this packet to the server.
Payload of the packet: See section 2.3.17 New Client Payload
all payloads MUST be at the start of the data area after the 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.
+always encrypted. Most of the payloads may only be sent with specific
+packet type which is defined in the description of the payload.
-There are many other payloads in SILC as well. However, they are not
+There are some other payloads in 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],
payload.
o Argument Type (1 byte) - Indicates the type of the argument.
- Every argument can have a specific type that MUST be defined
+ Every argument can have a specific type that are defined
by the packet payload needing the argument. For example
every command specify a number for each argument that may be
associated with the command. By using this number the receiver
after the other. The number of arguments is indicated in the
payload.
-
The following diagram represents the Argument List Payload.
.in 5
.in 6
-o Channel Name Length (2 bytes) - Length of the channel name
+o Channel Name Length (2 bytes) - Length of the Channel Name
field.
o Channel Name (variable length) - The name of the channel.
o Channel ID Length (2 bytes) - Length of the Channel ID field.
-o Channel ID (variable length) - The Channel ID.
+o Channel ID (variable length) - The encoded Channel ID.
o Mode Mask (4 bytes) - A mode. This can be the mode of the
channel but it can also be the mode of a client on the
the packet. See the [SILC3] for defined public key types.
o Public Key (or certificate) (variable length) - The
- public key or certificate data.
+ encoded public key or certificate data.
.in 3
it is possible to have multiple private channel keys set,
and receiver can use the MAC to verify which of the keys
must be used in decryption. This field is not encrypted.
+ This field is authenticated by the SILC packet MAC.
.in 3
-
.in 5
.nf
1 2 3
Notify payload is used to send notify messages. The payload is usually
sent from server to client and from server to router. It is also used
by routers to notify other routers in the network. This payload MAY also
-be sent to a channel. Client MUST NOT send this payload. If client
-receives this payload it MAY ignore the contents of the payload, however,
-notify message SHOULD be audited. Servers and routers MUST process
-notify packets.
+be sent to a channel. Client MUST NOT send this payload. When this
+packet is received by client it SHOULD process it. Servers and routers
+MUST process notify packets.
The payload may only be sent with SILC_PACKET_NOTIFY packet. It MUST
NOT be sent in any other packet type. The following diagram represents
o Argument Nums (1 byte) - Indicates the number of Argument
Payloads associated to this payload. Notify types may define
- arguments to be send along the notify message.
+ arguments to be sent along the notify message.
.in 3
The following list of currently defined notify types. The format for
this type to the local clients on the channel and then send it
to its primary router. The router or server receiving the
packet distributes this type to the local clients on the channel
- and broadcast it to the network.
+ and broadcast it to the network. This notify MUST NOT be sent to
+ the leaving client.
Max Arguments: 1
Arguments: (1) <Client ID>
distribute this type to the local clients on the channel and then
send it to its primary router. The router or server receiving
the packet distributes this type to the local clients on the
- channel and broadcast it to the network.
+ channel and broadcast it to the network. This notify MUST NOT be
+ sent to the quitting client.
Max Arguments: 2
Arguments: (1) <Client ID> (2) <message>
5 SILC_NOTIFY_TYPE_TOPIC_SET
- Sent when topic is set/changed on a channel. This type must be
+ Sent when topic is set/changed on a channel. This type may be
sent only to the clients which are joined on the channel which
- topic was set or changed.
+ topic was just set or changed. The packet is destined to the
+ channel.
Max Arguments: 2
Arguments: (1) <ID Payload> (2) <topic>
distribute this type only to the local clients on the channel
and then send it to its primary router. The router or server
receiving the packet distributes this type to the local clients
- on the channel and broadcast it to the network.
+ on the channel and broadcast it to the network. This packet is
+ destined directly to the sent entity. This MUST be sent to those
+ clients that are joined on same channels as the client that changed
+ the nickname. This notify MUST NOT be sent multiple times to the
+ same recipient. This notify MUST be sent also to the client that
+ changed the nickname.
Max Arguments: 3
Arguments: (1) <Old Client ID> (2) <New Client ID>
Sent when channel mode has changed. This type MUST be sent only
to the clients which are joined on the channel which mode was
- changed.
+ changed. This packet is destined to the channel.
Max Arguments: 8
Arguments: (1) <ID Payload> (2) <mode mask>
Sent when user mode on channel has changed. This type MUST be
sent only to the clients which are joined on the channel where
- the target client is on.
+ the target client is on. This packet is destined to the channel.
Max Arguments: 4
Arguments: (1) <ID Payload> (2) <mode mask>
change) of the entity which changed the mode. The <mode mask>
is the new mode mask of the channel. The <Target Client ID>
is the client which mode was changed. The <founder pubkey>
- is the public key of the channel founder and is sent only
- when first setting the channel founder mode using the
+ is the public key of the channel founder and may be sent only
+ when first time setting the channel founder mode using the
SILC_COMMAND_CUMODE command, and when sending this notify.
This is sent by normal server to the client. This can also be
sent by router to other server to force the Channel ID change.
The Channel ID MUST be changed to use the new one. When sent
- to clients, this type MUST be sent only to the clients which is
- joined on the channel.
+ to clients, this type MUST be sent only to the clients which are
+ joined on the channel. This packet is destined to the sent entity.
Max Arguments: 2
Arguments: (1) <Old Channel ID> (2) <New Channel ID>
Sent when server quits SILC network. Those clients from this
server that are on channels must be removed from the channel.
+ This packet is destined to the sent entity.
Max Arguments: 256
Arguments: (1) <Server ID> (n) [<Client ID>] [...]
12 SILC_NOTIFY_TYPE_KICKED
- Sent when a client has been kicked from a channel. This is
- sent also to the client which was kicked from the channel.
+ Sent when a client has been kicked from a channel. This MUST
+ also be sent to the client which was kicked from the channel.
The client which was kicked from the channel MUST be removed
from the channel. The client MUST also be removed from channel's
- invite list if it is explicitly added in the list. This notify
- type is always destined to the channel. The router or server
- receiving the packet distributes this type to the local clients
- on the channel and broadcast it to the network.
+ invite list if it is explicitly added in the list. This packet
+ is destined to the channel. The router or server receiving the
+ packet distributes this type to the local clients on the channel
+ and broadcast it to the network.
Max Arguments: 3
Arguments: (1) <Client ID> (2) [<comment>]
13 SILC_NOTIFY_TYPE_KILLED
- Sent when a client has been killed from the network. This is sent
- also to the client which was killed from the network. The client
- which was killed from the network MUST be removed from the network.
- This notify type is destined directly to the client which was
- killed and to channel if the client is on any channel. The router
- or server receiving the packet distributes this type to the local
- clients on the channel and broadcast it to the network. The client
- MUST also be removed from joined channels invite list if it is
- explicitly added in the lists.
+ Sent when a client has been killed from the network. This MUST
+ also be sent to the client which was killed from the network.
+ This notify MUST be sent to those clients which are joined on same
+ channels as the killed client. The client which was killed MUST
+ be removed from the network. This packet is destined directly to
+ the sent entity. The router or server receiving the packet
+ distributes this type to the local clients on the channel and
+ broadcast it to the network. The client MUST also be removed from
+ joined channels invite list if it is explicitly added in the lists.
+ This notify MUST NOT be sent multiple times to same recipient.
Max Arguments: 3
Arguments: (1) <Client ID> (2) [<comment>]
SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE
MUST check whether someone in the local cell is watching the nickname
the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the
-watcher, unless the client in case has the SILC_UMODE_REJECT_WATCHING
-user mode set. If the watcher client and the client that was
-watched is same the notify SHOULD NOT be sent.
+watcher, unless the watched client in case has the user mode
+SILC_UMODE_REJECT_WATCHING set. If the watcher client and the client
+that was watched is same the notify SHOULD NOT be sent.
.ti 0
Error payload is sent upon error in protocol. Error may occur in
various conditions when server sends this packet. Client MUST 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.
+MAY 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.
.in 5
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.
+encrypted with the session key is SILC Header plus padding to it.
Receiver of the the channel message packet is able to determine
the channel the message is destined to by checking the destination
whenever a user has left 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
+the client. After that, client MUST start using the key received
in this payload to protect the traffic on the channel.
The client which is joining to the channel receives its key in the
Channel key SHOULD expire periodically, say, in one hour, in
which case new channel key is created and distributed.
+Note that, this packet is not used if SILC_CMODE_PRIVKEY mode is set
+on channel. This means that channel uses channel private keys which
+are not server generated. For this reason server cannot send this
+packet as it does not know the key.
+
The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet.
It MUST NOT be sent in any other packet type. The following diagram
represents the Channel Key Payload.
field.
o Channel ID (variable length) - The Channel ID of the
- channel this key is meant for.
+ channel.
o Cipher Name Length (2 bytes) - Indicates the length of the
Cipher name field in the payload, not including any other
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.
+ 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
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 private key is used to protect the message, servers between
-the sender and the receiver needs not to decrypt/re-encrypt the
-packet. Section Client To Client in [SILC1] gives example of this
-scheme as well.
+When the private message key is used, and the Private Message Key
+flag was set in the SILC Packet header no server or router en route
+is able to decrypt or re-encrypt the packet. In this case only the
+SILC Packet header is processed by the servers and routers en route.
+Section Client To Client in [SILC1] gives example of this scheme.
This packet use generic Message Payload as Private Message Payload.
See section 2.3.2.5 for generic Message Payload.
Agreement payload directly peer to peer, see section 2.3.20.
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.
+MUST NOT send this payload. 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. The following
-
-
.in 5
.nf
1 2 3
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. See section 2.3.2.2 for definition of the
+ Command Payload. See section 2.3.2.2 for definition of the
Argument Payload.
o Command Identifier (2 bytes) - Identifies this command at the
can identify which command reply belongs to which originally
sent command. What this field includes is implementation
issue but it is RECOMMENDED that wrapping counter value is
- used in the field. Value zero (0) in this field means that
- no specific value is set.
+ used in the field.
.in 3
See [SILC4] for detailed description of different SILC commands,
sending SILC_PACKET_NEW_SERVER to the router it connected to. The case
is same when router connects to another router.
-However, this payload MUST NOT be used to send information about new
-channels. New channels are always distributed by sending the dedicated
+This payload MUST NOT be used to send information about new channels.
+New channels are always distributed by sending the dedicated
SILC_PACKET_NEW_CHANNEL packet. Client MUST NOT send this payload.
Both client and server (and router) MAY receive this payload.
When client is connected to the server, keys has been exchanged and
connection has been authenticated, client MUST register itself to the
server. Client's first packet after key exchange and authentication
-protocols must be SILC_PACKET_NEW_CLIENT. This payload tells server all
+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.
o Server ID Length (2 bytes) - Length of the Server ID Data
field.
-o Server ID Data (variable length) - The actual Server ID
+o Server ID Data (variable length) - The encoded Server ID
data.
o Server Name Length (2 bytes) - Length of the server name
field.
-o Server Name (variable length) - The server name.
+o Server Name (variable length) - The server name string.
.in 3
another client in the SILC Network. The key agreement protocol used
is the SKE protocol. The result of the protocol, the secret key
material, can be used for example as private message key between the
-two clients. This significantly adds security as the key agreement
-is performed outside the SILC network. The server and router MUST NOT
-send this payload.
+two clients. This significantly adds security as the clients agree
+about the key without any server interaction. The protocol is executed
+peer to peer. The server and router MUST NOT send this payload.
The sender MAY tell the receiver of this payload the hostname and the
port where the SKE protocol is running in the sender's end. The
.ti 0
2.3.22 File Transfer Payload
-File Transfer Payload is used to perform file transfer protocol
-between two entities in the network. The actual file transfer
-protocol is always encapsulated inside the SILC Packet. The actual
-data stream is also sent peer to peer outside SILC network.
-
-When an entity, usually a client wishes to perform file transfer
-protocol with another client in the network, they perform Key Agreement
-protocol as described in the section 2.3.20 Key Agreement Payload and
-in [SILC3], inside File Transfer Payload. After the Key Agreement
-protocol has been performed the subsequent packets in the data stream
-will be protected using the new key material. The actual file transfer
-protocol is also initialized in this stage. All file transfer protocol
-packets are always encapsulated in the File Transfer Payload and
-protected with the negotiated key material.
+File Transfer Payload is used to perform file transfer protocol between
+two entities in the network. The actual file transfer protocol is always
+encapsulated inside the SILC Packet. The actual data stream is also sent
+peer to peer outside SILC network.
+
+When an entity, usually a client wishes to perform file transfer protocol
+with another client in the network, they perform Key Agreement protocol
+as described in the section 2.3.20 Key Agreement Payload and in [SILC3],
+inside File Transfer Payload. After the Key Agreement protocol has been
+performed the subsequent packets in the data stream will be protected
+using the new key material. The actual file transfer protocol is also
+initialized in this stage. All file transfer protocol packets are always
+encapsulated in the File Transfer Payload and protected with the
+negotiated key material.
The payload may only be sent with SILC_PACKET_FTP packet. It MUST NOT
be sent in any other packet type. The following diagram represents the
-
-
.in 5
.nf
1 2 3
protocol. The following file transfer protocols has been
defined:
- 1 Secure File Transfer Protocol (SFTP) (mandatory)
+ 1 Secure File Transfer Protocol (SFTP) (mandatory)
If zero (0) value or any unsupported file transfer protocol
- type is found in this field the packet must be discarded.
+ type is found in this field the packet MUST be discarded.
The currently mandatory file transfer protocol is SFTP.
The SFTP protocol is defined in [SFTP].
any of the special cases described in the following sections the packet
decryption is special. If the packet type is not among those special
packet types rest of the packet can be decrypted with the same key.
+At this point the receiver is also able to determine the length of the
+packet.
With out a doubt, this sort of decryption processing causes some
overhead to packet decryption, but never the less, is required.
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
-at all; it MUST NOT be re-encrypted with the session key.
+with the key of the next receiver of the packet. Note that, in this
+case the encrypted data area is not touched 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 recognize the packet to be as
If the receiver of the channel message is router which is routing the
message to another router then it MUST decrypt the Channel Message
-payload. Between routers (that is, between cells) channel messages
+payload too. 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
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
+message encryption and decryption is as described before. This
different processing of channel messages with router to router
connection is because channel keys are cell specific. All cells have
their own channel keys thus the channel message traveling from one
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.
+touched and is not re-encrypted.
The true receiver of the private message is able to decrypt the private
message as it shares the key with the sender of the message.
projects / silc.git / commitdiff