include STATUS_LIST_START status in the first reply and
STATUS_LIST_END in the last reply to indicate the end of the
list. If there are only one reply the status is set to normal
- STATUS_OK.
+ STATUS_OK. If multiple Client IDs was requested then each found
+ and unfound client must cause successful or error reply,
+ respectively.
The command replies include the Client ID of the nickname,
nickname and server name, user name and host name and user's real
The server also returns client's user mode, idle time, and the
fingerprint of the client's public key. The <fingerprint> is the
binary hash digest of the public key. The fingerprint MUST NOT
- be sent if the server has not verified the proof of posession of
+ be sent if the server has not verified the proof of possession of
the corresponding private key. Server can do this during the
SILC Key Exchange protocol. The <fingerprint> is SHA1 digest.
a list of results. In this case the status payload will include
STATUS_LIST_START status in the first reply and STATUS_LIST_END in
the last reply to indicate the end of the list. If there are only
- one reply the status is set to normal STATUS_OK.
+ one reply the status is set to normal STATUS_OK. If multiple Client
+ IDs was requested then each found and unfound client must cause
+ successful or error reply, respectively.
When querying clients the <entity's name> must include the client's
nickname in the following format: nickname[@server]. The
Reply messages to the command:
- Max Arguments: 2
+ Max Arguments: 3
Arguments: (1) <Status Payload> (2) <New ID Payload>
+ (3) <nickname>
This command is replied always with New ID Payload that is
generated by the server every time user changes their nickname.
Client receiving this payload MUST start using the received
Client ID as its current valid Client ID. The New ID Payload
- is described in [SILC2].
+ is described in [SILC2]. The <nickname> is the user's new
+ nickname.
Status messages:
privileges the same way as the client had given the
SILC_COMMAND_CUMODE command to gain founder privileges. The
client is still able to join the channel even if the founder
- privileges could not be gained.
+ privileges could not be gained. The hash function used with
+ the <founder payload> MUST be sha1.
The server MUST check whether the user is allowed to join to
the requested channel. Various modes set to the channel affect
of a channel. Modes may be masked together by ORing them thus
having several modes set. The <Channel ID> is the ID of the
target channel. The client changing channel mode MUST be on
- the same channel and poses sufficient privileges to be able to
+ the same channel and posses sufficient privileges to be able to
change the mode.
When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
Channel founder may 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. However,
- server MUST verify the sent authentication payload and
- set the mode only if the verification was successful.
-
- 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 which 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.
+ consisting of the public key authentication method and the
+ authentication data for that method. The passphrase
+ method cannot be used with this mode. The server MUST NOT
+ accept NONE authentication method. The server does not
+ save <auth payload> but MUST verify it. The public key
+ used to verify the payload is the public key of the
+ client sending this command. The mode may be set only
+ if the <auth payload> was verified successfully. The
+ server also MUST save the founder's public key. The
+ hash function used with the <auth payload> MUST be sha1.
+
+ The public key of the founder is sent in the
+ SILC_NOTIFY_TYPE_CMODE_CHANGE notify type so that other
+ routers and servers in the network may save the public key.
+ This way the founder can reclaim the founder rights back
+ to the channel from any server in the network. The founder
+ rights can be regained by the SILC_CUMODE_FOUNDER channel
+ user mode, or during joining procedure with the command
+ SILC_COMMAND_JOIN.
+
+ When this channel mode is set the channel also becomes
+ permanent. If all clients leave the channel while this
+ mode is set the channel MUST NOT be destroyed. The founder
+ can reclaim the founder mode back on these empty channels
+ at any time. Implementations MAY limit the number of how
+ many channels a user can own.
Typical implementation would use [+|-]f on user interface
to set/unset this mode.
The <Channel ID> is the ID of the target channel. The <mode mask>
is OR'ed mask of modes. The <Client ID> is the target client.
The client changing channel user modes MUST be on the same channel
- as the target client and poses sufficient privileges to be able to
+ as the target client and posses sufficient privileges to be able to
change the mode.
When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
been set, the client can claim channel founder privileges
by providing the <auth payload> that the server will use
to authenticate the client. The public key that server will
- use to verify the <auth payload> must the same public key
+ use to verify the <auth payload> MUST the same public key
that was saved when the SILC_CMODE_FOUNDER_AUTH channel
mode was set. The client MAY remove this mode at any time.
replies at the same time, however in this case the
list of error replies MUST be sent after the successful
replies. This way the recipient may ignore the multiple
-errors if it wishes to do so.
+errors if it wishes to do so. Also note that in this
+case the successful and error replies belong to the
+same list.
All Status messages are described in the next section.
4 References
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
- Protocol Specification", Internet Draft, April 2001.
+ Protocol Specification", Internet Draft, May 2002.
[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
- April 2001.
+ May 2002.
[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
- Protocols", Internet Draft, April 2001.
+ Protocols", Internet Draft, May 2002.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
-
-
+[ATTRS] Riikonen, P., "User Online Presence and Information
+ Attributes", Internet Draft, May 2002.
.ti 0
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
projects / crypto.git / blobdiff