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
privileges by SILC_COMMAND_SILCOPER command. Client
may unset the mode itself.
+ 0x0004 SILC_UMODE_GONE
+
+ Marks that the user is not currently present in the
+ SILC Network. Client may set and unset this mode.
+
Reply messages to the command:
Max Arguments: 2
17 SILC_COMMAND_CMODE
- Max Arguments: 6
- Arguments: (1) <Channel ID> (2) <channel mode mask>
- (3) [<user limit>] (4) [<passphrase>]
- (5) [<cipher>] (6) [<hmac>]
+ Max Arguments: 7
+ Arguments: (1) <Channel ID> (2) <channel mode mask>
+ (3) [<user limit>] (4) [<passphrase>]
+ (5) [<cipher>] (6) [<hmac>]
+ (7) [<auth payload>]
This command is used by client to set or change channel flags on
a channel. Channel has several modes that set various properties
to set/unset this mode.
+ 0x0200 SILC_CMODE_FOUNDER_AUTH
+
+ Channel founder can set this mode to be able to regain
+ channel founder rights even if the client leaves the
+ channel. The <auth payload> is the Authentication Payload
+ consisting of the authentication method and authentication
+ data to be used in the authentication. The server must
+ not accept NONE authentication method. Also, if the
+ method is public key authentication the server must not
+ save the authentication data from the payload as the
+ data is different on all authentications. In this case the
+ server only saves the authentication method.
+
+ Note, that this mode is effective only in the current server.
+ The client must connect to the same server later to be able
+ to regain the channel founder rights. The server must save
+ the public key of the channel founder and use that to identify
+ the client who is claiming the channel founder rights.
+ The rights may be claimed by the SILC_CUMODE_FOUNDER
+ channel user mode using SILC_COMMAND_CUMODE command. The
+ set authentication data remains valid as long as the channel
+ exists or until the founder unsets this mode.
+
+ Typical implementation would use [+|-]f on user interface
+ to set/unset this mode.
+
+
To make the mode system work, client must keep the channel mode
mask locally so that the mode setting and unsetting would work
without problems. The client receives the initial channel mode
18 SILC_COMMAND_CUMODE
- Max Arguments: 3
- Arguments: (1) <Channel ID> (2) <mode mask>
- (3) <Client ID>
+ Max Arguments: 4
+ Arguments: (1) <Channel ID> (2) <mode mask>
+ (3) <Client ID> (4) [<auth payload>]
This command is used by client to change channel user modes on
channel. Users on channel may have some special modes and this
0x0001 SILC_CUMODE_FOUNDER
- The client is channel founder of the channel. This mode
- cannot be set by other client, it is set by the server when
- the channel was founded (created). The mode is provided
- because client may remove the founder rights from itself.
+ The client is channel founder of the channel. Usually this
+ mode is set only by the server when the channel was created.
+ However, if the SILC_CMODE_FOUNDER_AUTH channel mode has
+ been set, the client can claim channel founder privileges
+ by providing the <auth payload> that the server will use
+ to authenticate the client. The client can remove this
+ mode at any time.
0x0002 SILC_CUMODE_OPERATOR
SILC_STATUS_ERR_NO_CHANNEL_PRIV
SILC_STATUS_ERR_UNKNOWN_MODE
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+ SILC_STATUS_ERR_AUTH_FAILED
19 SILC_COMMAND_KICK
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