2.3.20 Key Agreement Payload .............................. 43
2.3.21 Resume Router Payload .............................. 44
2.3.22 File Transfer Payload .............................. 44
+ 2.3.23 Resume Client Payload .............................. XXXXXX
2.4 SILC ID Types ............................................. 46
2.5 Packet Encryption And Decryption .......................... 46
2.5.1 Normal Packet Encryption And Decryption ............. 46
Figure 21: Key Agreement Payload
Figure 22: Resume Router Payload
Figure 23: File Transfer Payload
+Figure 24: Resume Client Payload
.ti 0
Payload of the packet: See section 2.3.22 File Transfer Payload
- 28 - 199
+ 28 SILC_PACKET_RESUME_CLIENT
+
+ This packet is used to resume a client back to the network
+ after it has been detached. A client is able to detach from
+ the network but the client is still valid client in the network.
+ The client may then later resume its session back by sending
+ this packet to a server. Routers also use this packet to notify
+ other routers in the network that the detached client has resumed.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.23 Resume Client Payload
+
+
+ 29 - 199
Currently undefined commands.
Max Arguments: 3
Arguments: (1) <Client ID> (2) [<comment>]
- (3) <Killer's Client ID>
+ (3) <Killer's ID>
The <Client ID> is the client which was killed from the network.
The killer may have set the <comment> to indicate the reason for
- the killing. The <Killer's Client ID> is the killer.
+ the killing. The <Killer's ID> is the killer, which may be
+ client but also router server.
14 SILC_NOTIFY_TYPE_UMODE_CHANGE
other parts of the packet.
o MAC (variable length) - The MAC computed from the
- Message Length, Message Data, Padding Length and Padding
- fields. This protects the integrity of the plaintext
- channel message. The receiver can verify from the MAC
- whether the message decrypted correctly. Also, if more than
- one private key has been set for the channel, the receiver
- can verify which of the keys decrypted the message
+ Message Length, Message Data, Padding Length, Padding and
+ Initial Vector fields. This protects the integrity of the
+ plaintext channel message. The receiver can verify from
+ the MAC whether the message decrypted correctly. Also, if
+ more than one private key has been set for the channel, the
+ receiver can verify which of the keys decrypted the message
correctly. Note that, this field is encrypted and MUST
be added to the padding calculation.
.ti 0
2.3.12 Private Message Key Payload
-This payload is used to send key from client to another client that
-is going to be used to protect the private messages between these
-two clients. If this payload is not sent normal session key
-established by the SILC Key Exchange Protocol is used to protect
-the private messages.
+This payload is optional and can be used to send private message
+key between two clients in the network. The packet is secured with
+normal session keys. By default private messages are encrypted
+with session keys, and with this payload it is possible to set
+private key for private message encryption between two clients.
+
+The receiver of this payload SHOULD verify for example from user
+whether user wants to receive private message key. Note that there
+are other, more secure ways of exchanging private message keys in
+the SILC network. Instead of sending this payload it is possible to
+negotiate the private message key with SKE protocol using the Key
+Agreement payload directly peer to peer.
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 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
-File Transfer Payload
+File Transfer Payload.
.in 5
.nf
.in 3
+.ti 0
+2.3.23 Resume Client Payload
+
+This payload is used by client to resume its detached session in the
+SILC Network. A client is able to detach itself from the network by
+sending SILC_COMMAND_DETACH command to its server. The network
+connection to the client is lost but the client remains as valid
+client in the network. The client is able to resume the session back
+by sending this packet and including the old Client ID, and an
+Authentication Payload [SILC1] which the server uses to verify with
+the detached client's public key. This also implies that the
+mandatory authentication method is public key authentication.
+
+Server or router that receives this from the client also sends this,
+without the Authentication Payload, to routers in the network so that
+they know the detached client has resumed. Refer to the [SILC1] for
+detailed description how the detaching and resuming prodecure is
+performed.
+
+The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the Resume Client Payload.
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Client ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Client ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Authentication Payload ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 24: Resume Client Payload
+
+
+.in 6
+o Client ID Length (1 byte) - The length of the Client ID
+ field not including any other field.
+
+o Client ID (variable length) - The detached client's Client
+ ID. The client that sends this payload must know the Client
+ ID.
+
+o Authentication Payload (variable length) - The authentication
+ payload that the server will verify with the detached client's
+ public key. If the server doesn't know the public key, it must
+ retrieve it for example with SILC_COMMAND_GETKEY command.
+.in 3
+
.ti 0