Session keys should be regenerated periodically, say, once in an hour.
The re-key process is started by sending SILC_PACKET_REKEY packet to
-other end, to indicate that re-key must be performed.
+other end, to indicate that re-key must be performed. The initiator
+of the connection should perform the re-key.
If perfect forward secrecy (PFS) flag was selected in the SILC Key
Exchange protocol [SILC3] the re-key must cause new key exchange with
information. After the SILC_PACKET_REKEY packet is sent the sender
will perform the SKE protocol.
+If PFS flag was set the resulted key material is processed as described
+in the section Processing the Key Material in [SILC3]. The difference
+with re-key in the processing is that the initial data for the hash
+function is just the resulted key material and not the HASH as it
+is not computed at all with re-key. Other than that, the key processing
+it equivalent to normal SKE negotiation.
+
If PFS flag was not set, which is the default case, then re-key is done
without executing SKE protocol. In this case, the new key is created by
-hashing the old key with hash function selected earlier in the SKE
-protocol. If the digest length of the hash function is too short for the
-key, then the key is distributed as described in section Processing the
-Key Material in [SILC3]. After both parties has regenerated the session
-key, both send SILC_PACKET_REKEY_DONE packet to each other. These packets
-are still secured with the old key. After these packets, the following
-packets must be protected with the new key.
+providing the current sending encryption key to the SKE protocol's key
+processing function. The process is described in the section Processing
+the Key Material in [SILC3]. The difference in the processing is that
+the initial data for the hash function is the current sending encryption
+key and not the SKE's KEY and HASH values. Other than that, the key
+processing is equivalent to normal SKE negotiation.
+
+After both parties has regenerated the session key, both send
+SILC_PACKET_REKEY_DONE packet to each other. These packets are still
+secured with the old key. After these packets, the subsequent packets
+must be protected with the new key.
.ti 0
SILC_STATUS_ERR_NO_CLIENT_ID
- 20 SILC_COMMAND_RESTART
+ 20 SILC_COMMAND_BAN
- Max Arguments: 0
- Arguments: None
+ Max Arguments: 3
+ Arguments: (1) <Channel ID> (2) [<adding client>]
+ (3) [<removing client>]
+
+ This command is used to manage the ban list of the channel
+ indicated by the <Channel ID>. A client that is banned from
+ channel is no longer able to join the channel. The client which
+ is executing this command must have at least channel operator
+ privileges on the channel.
+
+ The <adding client> and <removing client> are used to add to and
+ remove from the ban list. The format of the <adding client> and
+ the <removing client> is of following format:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
+
+ The server must send the notify type SILC_NOTIFY_TYPE_BAN to its
+ primary router after adding to or removing from the ban list.
+ The wildcards may be used with this command. If adding or removing
+ from than one clients then the lists are an comma (`,') separated
+ list.
+
+ If this command is executed without the ban arguments the command
+ merely replies with the current ban list.
- This command may only be used by server operator to force a
- server to restart itself.
Reply messages to the command:
- Max Arguments: 1
- Arguments: (1) <Status Payload>
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<ban list>]
- This command replies only with Status Payload.
+ This command replies with the <Channel ID> of the channel and
+ the current <ban list> of the channel if it exists.
Status messages:
SILC_STATUS_OK
SILC_STATUS_ERR_NOT_REGISTERED
- SILC_STATUS_ERR_NO_SERVER_PRIV
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
21 SILC_COMMAND_CLOSE
SILC_STATUS_ERR_NOT_ON_CHANNEL
- 26 SILC_COMMAND_BAN
-
- Max Arguments: 3
- Arguments: (1) <Channel ID> (2) [<adding client>]
- (3) [<removing client>]
-
- This command is used to manage the ban list of the channel
- indicated by the <Channel ID>. A client that is banned from
- channel is no longer able to join the channel. The client which
- is executing this command must have at least channel operator
- privileges on the channel.
-
- The <adding client> and <removing client> are used to add to and
- remove from the ban list. The format of the <adding client> and
- the <removing client> is of following format:
-
- [<nickname>[@<server>]!][<username>]@[<hostname>]
-
- The server must send the notify type SILC_NOTIFY_TYPE_BAN to its
- primary router after adding to or removing from the ban list.
- The wildcards may be used with this command. If adding or removing
- from than one clients then the lists are an comma (`,') separated
- list.
-
- If this command is executed without the ban arguments the command
- merely replies with the current ban list.
-
-
- Reply messages to the command:
-
- Max Arguments: 3
- Arguments: (1) <Status Payload> (2) <Channel ID>
- (3) [<ban list>]
-
- This command replies with the <Channel ID> of the channel and
- the current <ban list> of the channel if it exists.
-
- Status messages:
-
- SILC_STATUS_OK
- SILC_STATUS_ERR_NOT_REGISTERED
- SILC_STATUS_ERR_TOO_MANY_PARAMS
- SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
- SILC_STATUS_ERR_NO_CHANNEL_ID
- SILC_STATUS_ERR_NOT_ON_CHANNEL
- SILC_STATUS_ERR_NO_CHANNEL_PRIV
-
-
27 - 199
Currently undefined commands.
projects / silc.git / blobdiff