From: Pekka Riikonen Date: Sat, 26 Jul 2003 12:02:17 +0000 (+0000) Subject: updates. X-Git-Tag: silc.toolkit.0.9.10~65 X-Git-Url: http://git.silcnet.org/gitweb/?a=commitdiff_plain;h=693d35eefab0e78a327c412d8b260cabb9fe6acb;p=silc.git updates. --- diff --git a/doc/draft-riikonen-silc-pp-07.nroff b/doc/draft-riikonen-silc-pp-07.nroff index d48d0477..e7ceda94 100644 --- a/doc/draft-riikonen-silc-pp-07.nroff +++ b/doc/draft-riikonen-silc-pp-07.nroff @@ -293,13 +293,12 @@ o Flags (1 byte) - Indicates flags to be used in packet 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 @@ -315,18 +314,16 @@ o Flags (1 byte) - Indicates flags to be used in packet 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. @@ -338,9 +335,9 @@ o Flags (1 byte) - Indicates flags to be used in packet .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 @@ -380,34 +377,33 @@ o Destination ID (variable length) - The actual destination 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. @@ -421,32 +417,31 @@ 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 @@ -456,14 +451,13 @@ List of SILC Packet types are defined as follows. 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 @@ -480,9 +474,8 @@ List of SILC Packet types are defined as follows. 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 @@ -491,10 +484,12 @@ List of SILC Packet types are defined as follows. 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 @@ -544,7 +539,7 @@ List of SILC Packet types are defined as follows. 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 @@ -552,7 +547,6 @@ List of SILC Packet types are defined as follows. - 13 SILC_PACKET_KEY_EXCHANGE This packet is used to start SILC Key Exchange Protocol, @@ -630,7 +624,7 @@ List of SILC Packet types are defined as follows. 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 @@ -754,14 +748,10 @@ 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 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], @@ -848,7 +838,7 @@ o Payload Length (2 bytes) - Length of the Argument Data 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 @@ -866,7 +856,6 @@ Argument List Payload is a list of Argument Payloads appended one after the other. The number of arguments is indicated in the payload. - The following diagram represents the Argument List Payload. .in 5 @@ -934,14 +923,14 @@ Figure 6: New Channel Payload .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 @@ -985,7 +974,7 @@ o Public Key Type (2 bytes) - The public key (or certificate) 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 @@ -1157,6 +1146,7 @@ o MAC (variable length) - The MAC computed from the 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 @@ -1242,7 +1232,6 @@ some protocol is sent in the payload. - .in 5 .nf 1 2 3 @@ -1310,10 +1299,9 @@ o Reject Indication (variable length) - Indication of 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 @@ -1345,7 +1333,7 @@ o Payload Length (2 bytes) - Length of the entire Notify Payload 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 @@ -1419,7 +1407,8 @@ sent inside arguments are actually Public Key Payloads. 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) @@ -1433,7 +1422,8 @@ sent inside arguments are actually Public Key Payloads. 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) (2) @@ -1444,9 +1434,10 @@ sent inside arguments are actually Public Key Payloads. 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) (2) @@ -1461,7 +1452,12 @@ sent inside arguments are actually Public Key Payloads. 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) (2) @@ -1478,7 +1474,7 @@ sent inside arguments are actually Public Key Payloads. 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) (2) @@ -1515,7 +1511,7 @@ sent inside arguments are actually Public Key Payloads. 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) (2) @@ -1526,8 +1522,8 @@ sent inside arguments are actually Public Key Payloads. change) of the entity which changed the mode. The is the new mode mask of the channel. The is the client which mode was changed. The - 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. @@ -1548,8 +1544,8 @@ sent inside arguments are actually Public Key Payloads. 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) (2) @@ -1565,6 +1561,7 @@ sent inside arguments are actually Public Key Payloads. 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) (n) [] [...] @@ -1581,14 +1578,14 @@ sent inside arguments are actually Public Key Payloads. 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) (2) [] @@ -1601,15 +1598,16 @@ sent inside arguments are actually Public Key Payloads. 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) (2) [] @@ -1703,9 +1701,9 @@ SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED, 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 @@ -1714,9 +1712,9 @@ watched is same the notify SHOULD NOT be sent. 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 @@ -1758,9 +1756,7 @@ 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. +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 @@ -1783,7 +1779,7 @@ the channel is created, when new user joins to the channel and 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 @@ -1800,6 +1796,11 @@ channel traffic is encrypted with the specified channel key. 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. @@ -1841,7 +1842,7 @@ o Channel ID Length (2 bytes) - Indicates the length of the 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 @@ -1850,7 +1851,7 @@ o Cipher Name Length (2 bytes) - Indicates the length of the 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 @@ -1883,10 +1884,11 @@ between the sender client and the receiving client MUST 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 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. @@ -1909,9 +1911,9 @@ negotiate the private message key with SKE protocol using the Key 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 @@ -1920,8 +1922,6 @@ diagram represents the Private Message Key Payload. - - .in 5 .nf 1 2 3 @@ -2015,7 +2015,7 @@ o SILC Command (1 byte) - Indicates the SILC command. This MUST 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 @@ -2025,8 +2025,7 @@ 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, @@ -2143,8 +2142,8 @@ 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. -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. @@ -2158,7 +2157,7 @@ The packet use generic ID Payload as New ID Payload. See section 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. @@ -2253,13 +2252,13 @@ Figure 20: New Server 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 @@ -2289,9 +2288,9 @@ This payload is used by clients to request key negotiation between 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 @@ -2387,20 +2386,20 @@ o Session ID (1 bytes) - Indicates the session ID for 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 @@ -2410,8 +2409,6 @@ File Transfer Payload. - - .in 5 .nf 1 2 3 @@ -2434,10 +2431,10 @@ o Type (1 byte) - Indicates the type of the file transfer 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]. @@ -2576,6 +2573,8 @@ how the rest of the packet must be decrypted. If the packet type is 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. @@ -2594,9 +2593,9 @@ be verified from the entire ciphertext. 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 @@ -2611,7 +2610,7 @@ information about padding on special packets. 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 @@ -2625,7 +2624,7 @@ 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 +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 @@ -2658,7 +2657,7 @@ 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. +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.