.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 13 September 2000
+.ds RH 6 October 2000
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-01.txt 13 September 2000
-Expires: 13 May 2001
+draft-riikonen-silc-spec-01.txt 6 October 2000
+Expires: 6 Jun 2001
.in 3
2.2 Communication Inside a Cell ............................... 5
2.3 Communication in the Network .............................. 6
2.4 Channel Communication ..................................... 7
-3 SILC Specification ............................................ 7
- 3.1 Client .................................................... 7
- 3.1.1 Client ID ........................................... 8
- 3.2 Server .................................................... 9
- 3.2.1 Server's Local ID List .............................. 9
- 3.2.2 Server ID ........................................... 10
+ 2.5 Router Connections ........................................ 7
+3 SILC Specification ............................................ 8
+ 3.1 Client .................................................... 8
+ 3.1.1 Client ID ........................................... 9
+ 3.2 Server .................................................... 10
+ 3.2.1 Server's Local ID List .............................. 10
+ 3.2.2 Server ID ........................................... 11
3.2.3 SILC Server Ports ................................... 11
- 3.3 Router .................................................... 11
- 3.3.1 Router's Local ID List .............................. 11
- 3.3.2 Router's Global ID List ............................. 12
+ 3.3 Router .................................................... 12
+ 3.3.1 Router's Local ID List .............................. 12
+ 3.3.2 Router's Global ID List ............................. 13
3.3.3 Router's Server ID .................................. 13
- 3.4 Channels .................................................. 13
- 3.4.1 Channel ID .......................................... 14
- 3.5 Operators ................................................. 14
+ 3.4 Channels .................................................. 14
+ 3.4.1 Channel ID .......................................... 15
+ 3.5 Operators ................................................. 15
3.6 SILC Commands ............................................. 15
- 3.7 SILC Packets .............................................. 15
+ 3.7 SILC Packets .............................................. 16
3.8 Packet Encryption ......................................... 16
- 3.8.1 Determination of the Source and the Destination ..... 16
+ 3.8.1 Determination of the Source and the Destination ..... 17
3.8.2 Client To Client .................................... 17
- 3.8.3 Client To Channel ................................... 18
+ 3.8.3 Client To Channel ................................... 19
3.8.4 Server To Server .................................... 19
- 3.9 Key Exchange And Authentication ........................... 19
- 3.10 Algorithms ............................................... 19
- 3.10.1 Ciphers ............................................ 19
- 3.10.2 Public Key Algorithms .............................. 20
- 3.10.3 MAC Algorithms ..................................... 20
- 3.10.4 Compression Algorithms ............................. 21
- 3.11 SILC Public Key .......................................... 21
+ 3.9 Key Exchange And Authentication ........................... 20
+ 3.10 Algorithms ............................................... 20
+ 3.10.1 Ciphers ............................................ 20
+ 3.10.2 Public Key Algorithms .............................. 21
+ 3.10.3 MAC Algorithms ..................................... 21
+ 3.10.4 Compression Algorithms ............................. 22
+ 3.11 SILC Public Key .......................................... 22
3.12 SILC Version Detection ................................... 24
-4 SILC Procedures ............................................... 24
- 4.1 Creating Client Connection ................................ 24
- 4.2 Creating Server Connection ................................ 25
- 4.3 Joining to a Channel ...................................... 26
- 4.4 Channel Key Generation .................................... 27
- 4.5 Private Message Sending and Reception ..................... 27
- 4.6 Private Message Key Generation ............................ 28
- 4.7 Channel Message Sending and Reception ..................... 29
- 4.8 Session Key Regeneration .................................. 29
- 4.9 Command Sending and Reception ............................. 29
-5 SILC Commands ................................................. 30
- 5.1 SILC Commands Syntax ...................................... 30
- 5.2 SILC Commands List ........................................ 32
- 5.3 SILC Command Status Types ................................. 53
- 5.3.1 SILC Command Status Payload ......................... 53
- 5.3.2 SILC Command Status List ............................ 54
-6 Security Considerations ....................................... 59
-7 References .................................................... 59
-8 Author's Address .............................................. 60
+4 SILC Procedures ............................................... 25
+ 4.1 Creating Client Connection ................................ 25
+ 4.2 Creating Server Connection ................................ 26
+ 4.3 Joining to a Channel ...................................... 27
+ 4.4 Channel Key Generation .................................... 28
+ 4.5 Private Message Sending and Reception ..................... 29
+ 4.6 Private Message Key Generation ............................ 29
+ 4.7 Channel Message Sending and Reception ..................... 30
+ 4.8 Session Key Regeneration .................................. 30
+ 4.9 Command Sending and Reception ............................. 30
+5 SILC Commands ................................................. 31
+ 5.1 SILC Commands Syntax ...................................... 31
+ 5.2 SILC Commands List ........................................ 33
+ 5.3 SILC Command Status Types ................................. 56
+ 5.3.1 SILC Command Status Payload ......................... 56
+ 5.3.2 SILC Command Status List ............................ 57
+6 Security Considerations ....................................... 61
+7 References .................................................... 61
+8 Author's Address .............................................. 62
.ti 0
Figure 1: SILC Network Topology
Figure 2: Communication Inside cell
Figure 3: Communication Between Cells
-Figure 4: SILC Public Key
-Figure 5: SILC Command Status Payload
+Figure 4: Router Connections
+Figure 5: SILC Public Key
+Figure 6: SILC Command Status Payload
.ti 0
keep global information up to date at all time.
This, on the other hand, leads to cellular like network, where routers
-are in the centrum on the cell and servers are connected to the router.
+are in the center of the cell and servers are connected to the router.
Following diagram represents SILC network topology.
server in the cell and is talking on channel to other client connected
to other server in the same cell, will have its messages delivered from
its local server first to the router of the cell, and from the router
-to the other server in the cell. Following diagram represents this
-scenario.
+to the other server in the cell.
+
+Following diagram represents this scenario:
.in 25
local clients on the channel.
+.ti 0
+2.5 Router Connections
+
+Router connections play very important role in making the SILC like
+network topology to work. For example, sending broadcast packets in
+SILC network require special connections between routers; routers must
+be connected in specific way.
+
+Every router has their primary route which is a connection to another
+router in the network. Unless there is only two routers in the network
+must not routers use each other as their primary routes. The router
+connections in the network must form a circular.
+
+Example with three routers in the network:
+
+
+
+
+
+
+
+.in 16
+.nf
+ S/R1 - > - > - > - > - > - > - S/R2
+ \\ /
+ ^ v
+ \\ - < - < - S/R3 - < - < - /
+.in 3
+
+
+.ce
+Figure 4: Router Connections
+
+
+Example: Network with three routers. Router 1. uses Router 2. as its
+ primary router. Router 2. uses Router 3. as its primary router,
+ and Router 3. uses Router 1. as its primary router. There may
+ be other direct connections between the routers but they must
+ not be used as primary routes.
+
+The above example is applicable to any amount of routers in the network
+except for two routers. If there are only two routers in the network both
+routers must be able to handle situation where they use each other as their
+primary routes.
+
+The issue of router connections are very important especially with SILC
+broadcast packets. Usually all router wide information in the network is
+distributed by SILC broadcast packets.
+
+
.ti 0
3. SILC Specification
Servers are the most important parts of the SILC network. They form the
basis of the SILC, providing a point to which clients may connect to.
There are two kinds of servers in SILC; normal servers and router servers.
-This section focuses on the normal server and router server is described
+This section focus on the normal server and router server is described
in the section 3.3 Router.
Normal servers may not directly connect to other normal server. Normal
their Channel ID's.
-
-
-
-
-
-
Hence, local list for normal server includes:
.in 6
o Receiving key
o Public key
+
+
+
client list - All clients in server
o Nickname
o Username@host
o IP address of the server - This is the real IP address of
the server.
-o Port - This is the port the server is binded to.
+o Port - This is the port the server is bound to.
o Random number - This is used to further randomize the Server ID.
.in 3
Collisions are not expected to happen in any conditions. The Server ID
-is always created by the server itself and server is resposible of
+is always created by the server itself and server is responsible of
distributing it to the router.
that it needs.
-
-
-
Hence, local list for router includes:
.in 6
client list - All clients in the cell
o Client ID
+
channel list - All channels in the cell
o Channel ID
o Client ID's on channel
A channel is a named group of one or more clients which will all receive
messages addressed to that channel. The channel is created when first
client requests JOIN command to the channel, and the channel ceases to
-exist when the last client leaves it. When channel exists, any client
+exist when the last client has left it. When channel exists, any client
can reference it using the name of the channel.
Channel names are unique although the real uniqueness comes from 64 bit
Note that the command reply is usually sent only after client has sent
the command request but server is allowed to send command reply packet
to client even if client has not requested the command. Client may,
-however, choose not to accept the command reply, but there are some
-command replies that the client should accept. Example of a such
-command reply is reply to SILC_COMMAND_CMODE command that the server
-uses to distribute the channel mode on all clients on the channel
-when the mode has changed.
+however, choose ignore the command reply, but should not.
It is expected that some of the commands may be miss-used by clients
resulting various problems on the server side. Every implementation
-
.ti 0
3.8 Packet Encryption
definition of how it must be done. SILC has a mandatory algorithm that
must be supported in order to be compliant with this protocol.
-
-
-
-
-
Following ciphers are defined in SILC protocol:
.in 6
-blowfish-cbc Blowfish in CBC mode (mandatory)
+aes-cbc AES in CBC mode (mandatory)
twofish-cbc Twofish in CBC mode (optional)
+blowfish-cbc Blowfish in CBC mode (optional)
rc6-cbc RC6 in CBC mode (optional)
rc5-cbc RC5 in CBC mode (optional)
mars-cbc Mars in CBC mode (optional)
(MAC) of the packet data. See [SILC2] for details how to compute the
MAC.
-
-
-
-
Following MAC algorithms are defined in SILC protocol:
.in 6
.in 6
none No compression (mandatory)
-zlib GBU ZLIB (LZ77) compression (optional)
+zlib GNU ZLIB (LZ77) compression (optional)
.in 3
Additional compression algorithms may be defined to be used in SILC.
The format of the SILC Public Key is as follows:
-
-
-
-
-
.in 5
.nf
1 2 3
.in 3
.ce
-Figure 4: SILC Public Key
+Figure 5: SILC Public Key
.in 6
The version detection of both client and server is performed at the
connection phase while executing the SILC Key Exchange protocol. The
-version identifier is exchanged between intiator and responder. The
+version identifier is exchanged between initiator and responder. The
version identifier is of following format:
.in 6
Software version may provide major, minor and build version. The
software version may be freely set and accepted.
+
Thus, the version string could be, for example:
.in 6
.ti 0
4.1 Creating Client Connection
-This section descibres the procedure when client connects to SILC server.
+This section describes the procedure when client connects to SILC server.
When client connects to server the server must perform IP address lookup
and reverse IP address lookup to assure that the origin host really is
who it claims to be. Client, host, connecting to server must have
also distributed to the router and to all clients on the channel.
If the channel does not exist in the local list the command must be
-fowarded to the router which will then perform the actual joining
+forwarded to the router which will then perform the actual joining
procedure. When server receives the reply to the command from the
router it must be distributed to the client who sent the command
originally. Server will also receive the channel key from the server
It is important to note that new channel key is created always when
new client joins to channel, whether the channel has existed previously
or not. This way the new client on the channel is not able to decrypt
-any of the old traffic on the channel.
-
-Client who receives the reply to the join command must start using
-the received Channel ID in the channel message communication thereafter.
-However, client must not start communicating on the channel before
-it has received the packet SILC_PACKET_CHANNEL_KEY.
+any of the old traffic on the channel. Client who receives the reply to
+the join command must start using the received Channel ID in the channel
+message communication thereafter. However, client must not start
+communicating on the channel before it has received the packet
+SILC_PACKET_CHANNEL_KEY.
If client wants to know the other clients currently on the channel
the client must send SILC_COMMAND_NAMES command to receive a list of
channel users. Server implementation, however, may send command reply
packet to SILC_COMMAND_NAMES command after client has joined to the
-channel even if the client has not sent the command.
+channel even if the client has not sent the command. Server should also
+send SILC_NOTIFY_TYPE_JOIN to all clients on the channel about a new
+client on the channel.
.ti 0
In this case the key is created from scratch by taking enough randomness
from the random number generator. After that the key is distributed to
all clients on the channel. However, channel keys are cell specific thus
-the key is created only on the cell where the client, who leaved the
+the key is created only on the cell where the client, who left the
channel, exists. While the server or router is creating the new channel
key, no other client may join to the channel. Messages that are sent
while creating the new key are still processed with the old key. After
If the sender of a private message does not know the receiver's Client
ID, it must resolve it from server. There are two ways to resolve the
-client ID from server; it is recommended that client ipmlementations
+client ID from server; it is recommended that client implementations
send SILC_COMMAND_IDENTIFY command to receive the Client ID. Client
may also send SILC_COMMAND_WHOIS command to receive the Client ID.
If the sender has received earlier a private message from the receiver
Header's Client ID. The nickname in the payload is merely provided
to be displayed for end user.
-See [SILC2] for describtion of private message encryption and decryption
+See [SILC2] for description of private message encryption and decryption
process.
distribute the message to all clients on the channel by sending the
channel message destined explicitly to a client on the channel.
-See [SILC2] for describtion of channel message encryption and decryption
+See [SILC2] for description of channel message encryption and decryption
process.
.ti 0
4.8 Session Key Regeneration
-Session keys should be regenerated peridiocally, say, once in an hour.
+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.
-
-
.in 6
Example: Arguments: (1) <nickname> (2) <username@host>
.in 3
Every command replies with Status Payload. This payload tells the
-sender of the command whether the command was completed succefully or
+sender of the command whether the command was completed successfully or
whether there was an error. If error occured the payload includes the
error type. In the next section the Status Payload is not described
as it is common to all commands and has been described here. Commands
The numbers in parentheses are the argument specific numbers
that specify the type of the argument in Command Argument Payload.
The receiver always knows that, say, argument number two (2) is
-<message> argument, regardles of the ordering of the arguments in
+<message> argument, regardless of the ordering of the arguments in
the Command Payload.
Reply messages to the command:
may return inside the <Status Payload>. All status messages
are defined in the section 5.3 SILC Command Status Types.
+.in 3
Every command that has some kind of ID as argument (for example
<Client ID>) are actually ID Payloads, defined in [SILC2] that includes
the type of the ID, length of the ID and the actual ID data. This
way variable length ID's can be sent as arguments.
-.in 3
.ti 0
1 SILC_COMMAND_WHOIS
Max Arguments: 3
- Arguments: (1) <nickname>[@<server>] (2) [<Client ID>]
+ Arguments: (1) [<nickname>[@<server>]] (2) [<Client ID>]
(3) [<count>]
Whois command is used to query various information about specific
STATUS_OK.
The command replies include the Client ID of the nickname,
- nickname and servername, username and hostnamea and users real
+ nickname and servername, username and hostname and users real
name. Client should process these replies only after the last
reply has been received with the STATUS_LIST_END status. If the
<count> option were defined in the query there will be only
SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
2 SILC_COMMAND_WHOWAS
Max Arguments: 2
3 SILC_COMMAND_IDENTIFY
Max Arguments: 2
- Arguments: (1) <nickname>[@<server>] (2) [<count>]
+ Arguments: (1) [<nickname>[@<server>]] (2) [<Client ID>]
+ (3) [<count>]
Identify. Identify command is almost analogous to WHOIS command,
except that it does not return as much information. Only relevant
are no limit of accepted results. The query may also be narrowed
down by defining the server name of the nickname.
+ It is also possible to search the user by Client ID. If <Client ID>
+ is provided server must use it as the search value instead of
+ the <nickname>.
+
To prevent miss-use of this service wildcards in the nickname
or in the servername are not permitted. It is not allowed
to request all users on some server. The IDENTIFY requests must
be based on specific nickname request.
Implementations may not want to give interface access to this
- command as it is hardly a command that would be used a end user.
+ command as it is hardly a command that would be used by an end user.
However, it must be implemented as it is used with private message
sending.
nicknames in SILC are case-sensitive which must be taken into
account when searching clients by nickname.
+ When nickname is changed new Client ID is generated. Server must
+ distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
+ channels (if any) the client is joined on. Then it must send
+ SILC_PACKET_REPLACE_ID to its primary route to replace the old
+ Client ID with the new one.
+
Reply messages to the command:
Max Arguments: 2
6 SILC_COMMAND_TOPIC
Max Arguments: 2
- Arguments: (1) <Channel ID> (2) [<server>]]
+ Arguments: (1) <Channel ID> (2) [<topic>]]
This command is used to change or view the topic of a channel.
The topic for channel <Channel ID> is returned if there is no
Reply messages to the command:
Max Arguments: 2
- Arguments: (1) <Status Payload> (2) [<topic>]
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<topic>]
The command may reply with the topic of the channel if it is
set.
SILC_STATUS_ERR_NO_CLIENT_ID
-
-
-
10 SILC_COMMAND_INFO
Max Arguments: 1
This command is used by operators to force a server to try to
establish a new connection to another router (if the connecting
- server is normal server) or server (if the conneceting server is
+ server is normal server) or server (if the connecting server is
router server). Operator may specify the server/router to be
connected by setting <remote server> argument. The separator
between <remote server address> and <port> is whitespace (` ').
This command replies only with Status Payload. Server returns
SILC_STATUS_OK in Status Payload if pinging was successful.
+
+
Status messages:
SILC_STATUS_OK
Reply messages to the command:
- Max Arguments: 5
+ Max Arguments: 6
Arguments: (1) <Status Payload> (2) <channel>
(3) <Channel ID> (4) <channel mode mask>
(5) [<ban mask>] (6) [<invite list>]
Max Arguments: 1
Arguments: (1) <server>
- This command is used to query the Message of the Day of a server.
+ This command is used to query the Message of the Day of the server.
Reply messages to the command:
17 SILC_COMMAND_CMODE
- Max Arguments: 8
+ Max Arguments: 7
Arguments: (1) <Channel ID> (2) <channel mode mask>
(3) [<user limit>] (4) [<passphrase>]
(5) [<ban mask>] (6) [<invite list>]
- (7) [<Client ID>] (8) [<cipher>[:<key len>]]
+ (7) [<cipher>[:<key len>]]
This command is used by client to set or change channel flags on
a channel. Channel has several modes that set various properties
the same channel and poses sufficient privileges to be able to
change the mode.
+ When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
+ type is distributed to the channel.
+
Following channel modes are defined:
0x0000 SILC_CMODE_NONE
Channel is private channel. Private channels are shown
in the channel list listed with SILC_COMMAND_LIST command
- with indicatioin that the channel is private. Also,
+ with indication that the channel is private. Also,
client on private channel will no be detected to be on
the channel as the channel is not shown in the client's
currently joined channel list. Channel founder and
unsetting a ban mask the mask must be provided as
argument. Channel founder and channel operator may
set/unset this mode. Channel founder may not be
- added to the ban list.
+ added to the ban list. <ban mask> is comma (`,') separated
+ list of banned clients in following format:
+
+ [<nickname>!][<username>]@[<hostname>]
+
+ Wildcards maybe used when banning clients.
Typical implementation would use [+|-]b on user interface
to set/unset this mode.
- 0x0100 SILC_CMODE_INVITE
+ 0x0100 SILC_CMODE_INVITE_LIST
Invite list has been set to the channel. The invite list
can be used to mark the clients that is able to join
be invite-only channel. The <invite list> argument is the
set invite mask. When unsetting entry from the invite list
the entry must be provided as argument. Channel founder and
- channel operator may set/unset this mode.
-
- Typical implementation would use [+|-]I on user interface
- to set/unset this mode.
+ channel operator may set/unset this mode. The <invite list>
+ is command (`,') separated list of invited clients in following
+ format:
-
- 0x0200 SILC_CMODE_OPERATOR
+ [<nickname>!][<username>]@[<hostname>]
- Sets channel operator privileges on the channel for a
- client on the channel. The <Client ID> argument is the
- target client on the channel. Channel founder and
- channel operator may set/unset (promote/demote) this
- mode.
+ Wildcards maybe used when setting the invite list.
- Typical implementation would use [+|-]o on user interface
+ Typical implementation would use [+|-]I on user interface
to set/unset this mode.
-
- 0x0400 SILC_CMODE_CIPHER
+
+ 0x0200 SILC_CMODE_CIPHER
Sets specific cipher to be used to protect channel
traffic. The <cipher> argument is the requested cipher.
When set or unset the server must re-generate new
channel key. If <key len> argument is specified with
<cipher> argument the new key is generated of <key len>
- length.
+ length in bits. Only channel founder may set the cipher of
+ the channel. When unset the new key is generated using
+ default cipher for the channel.
Typical implementation would use [+|-]c on user interface
to set/unset this mode.
Arguments: (1) <Status Payload> (2) <channel mode mask>
This command replies with the changed channel mode mask that
- client is required to keep locally. The same mask is also
- sent to all clients on channel by sending additional command
- reply to them.
+ client is required to keep locally.
Status messages:
SILC_STATUS_ERR_NO_CHANNEL_ID
SILC_STATUS_ERR_NO_CHANNEL_PRIV
SILC_STATUS_ERR_UNKNOWN_MODE
- SILC_STATUS_ERR_NO_CLIENT_ID
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+
+
+ 19 SILC_COMMAND_CUMODE
+
+ Max Arguments: 3
+ Arguments: (1) <Channel ID> (2) <mode mask>
+ (3) <Client ID>
+
+ This command is used by client to change channel user modes on
+ channel. Users on channel may have some special modes and this
+ command is used by channel operators to set or change these modes.
+ 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
+ change the mode.
+ When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
+ type is distributed to the channel.
+ Following channel modes are defined:
+
+ 0x0000 SILC_CUMODE_NONE
+
+ No specific mode. This is the normal situation for client.
+ Also, this is the mode set when removing all modes from client.
+
+
+ 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.
- 18 SILC_COMMAND_KICK
+
+ 0x0002 SILC_CUMODE_OPERATOR
+
+ Sets channel operator privileges on the channel for a
+ client on the channel. Channel founder and channel operator
+ may set/unset (promote/demote) this mode.
+
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <channel user mode mask>
+ (3) <Client ID>
+
+ This command replies with the changed channel user mode mask that
+ client is required to keep locally. The <Client ID> is the target
+ client.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_BAD_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ SILC_STATUS_ERR_UNKNOWN_MODE
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+
+
+ 19 SILC_COMMAND_KICK
Max Arguments: 3
Arguments: (1) <channel> (2) <Client ID>
SILC_STATUS_ERR_NO_CLIENT_ID
- 19 SILC_COMMAND_RESTART
+ 20 SILC_COMMAND_RESTART
Max Arguments: 0
Arguments: None
This command replies only with Status Payload.
-
-
Status messages:
SILC_STATUS_OK
SILC_STATUS_ERR_NO_SERVER_PRIV
- 20 SILC_COMMAND_CLOSE
+
+
+
+ 21 SILC_COMMAND_CLOSE
Max Arguments: 1
Arguments: (1) <Server ID>
This command replies only with Status Payload.
-
-
Status messages:
SILC_STATUS_OK
SILC_STATUS_ERR_NO_SUCH_SERVER_ID
- 21 SILC_COMMAND_DIE
+ 22 SILC_COMMAND_DIE
Max Arguments: 0
Arguments: None
SILC_STATUS_ERR_NO_SERVER_PRIV
- 22 SILC_COMMAND_SILCOPER
+ 23 SILC_COMMAND_SILCOPER
Max Arguments: 2
Arguments: (1) <username> (2) <authentication data>
SILC_STATUS_ERR_AUTH_FAILED
- 23 SILC_COMMAND_LEAVE
+ 24 SILC_COMMAND_LEAVE
Max Arguments: 1
Arguments: (1) <Channel ID>
SILC_STATUS_ERR_NO_CHANNEL_ID
- 24 SILC_COMMAND_NAMES
+ 25 SILC_COMMAND_NAMES
Max Arguments: 1
Arguments: (1) <Channel ID>
command must not send the list of users, as private and secret
channels cannot be seen by outside. In this case the returned
name list may include a indication that the server could not
- resolve the names of the users on the channel.
+ resolve the names of the users on the channel. Also, in this case
+ Client ID's or client modes are not sent either.
Reply messages to the command:
- Max Arguments: 3
+ Max Arguments: 5
Arguments: (1) <Status Payload> (2) <Channel ID>
(3) <name list> (4) <Client ID list>
+ (5) <client mode list>
This command replies with the Channel ID of the requested channel,
comma separated list of users on the channel and Client ID list
of the users on the list. The Client ID list has Client ID's
of all users in the list. First Client ID in the list must be
- the Client ID of the first user in <name list>. The Client ID
- List is formed by adding Client ID's each after each. Note that
- the Client ID list is binary data.
+ the Client ID of the first user in <name list>. The <Client ID
+ list> is formed by adding Client ID's each after each. Note that
+ the Client ID list is binary data and the length of each ID must
+ be snooped from the data. The <client mode list> is formed by
+ adding client's user modes on the channel each after each (4 bytes
+ each).
Status messages:
SILC_STATUS_ERR_NOT_ON_CHANNEL
- 25 - 254
+ 26 - 199
Currently undefined commands.
- 255 SILC_COMMAND_MAX
+ 200 - 254
+
+ These commands are reserved for private use and will not be defined
+ in this document.
+
+
+ 255 SILC_COMMAND_MAX
Reserved command. This must not be sent.
.in 3
represents the Command Status Payload (field is always in MSB order).
+
+
+
.in 21
.nf
1
.in 3
.ce
-Figure 5: SILC Command Status Payload
+Figure 6: SILC Command Status Payload
.in 6
Start of the list. There will be several command replies and
this reply is the start of the list.
- 2 SILC_STATUS_LIST_END
+ 2 SILC_STATUS_LIST_ITEM
+
+ Item in the list. This is one of the item in the list but not the
+ first or last one.
+
+ 3 SILC_STATUS_LIST_END
End of the list. There were several command replies and this
reply is the last of the list. There won't be other replies
- beloning to this list after this one.
+ belonging to this list after this one.
3 - 9
"No such Client ID". Client ID provided does not exist.
-
23 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
"No such Channel ID". Channel ID provided does not exist.
25 SILC_STATUS_ERR_NOT_ON_CHANNEL
"You are not on that channel". The command were specified for
- client user is not currently on.
+ channel user is not currently on.
+
+ 26 SILC_STATUS_ERR_USER_NOT_ON_CHANNEL
- 26 SILC_STATUS_ERR_USER_ON_CHANNEL
+ "They are not on channel". The requested target client is not
+ on requested channel.
+
+ 27 SILC_STATUS_ERR_USER_ON_CHANNEL
"User already on channel". User were invited on channel they
already are on.
- 27 SILC_STATUS_ERR_NOT_REGISTERED
+ 28 SILC_STATUS_ERR_NOT_REGISTERED
"You have not registered". User executed command that requires
the client to be registered on the server before it may be
executed.
- 28 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+ 29 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
"Not enough parameters". Command requires more parameters
than provided.
- 29 SILC_STATUS_ERR_TOO_MANY_PARAMS
+ 30 SILC_STATUS_ERR_TOO_MANY_PARAMS
"Too many parameters". Too many parameters were provided
for the command.
- 30 SILC_STATUS_ERR_PERM_DENIED
+ 31 SILC_STATUS_ERR_PERM_DENIED
"Your host is not among the privileged". The client tried to
register on server that does not allow this host to connect.
- 31 SILC_STATUS_ERR_BANNED_FROM_SERVER
+ 32 SILC_STATUS_ERR_BANNED_FROM_SERVER
"You are banned from this server". The client tried to register
on server that has explicitly denied this host to connect.
-
-
- 32 SILC_STATUS_ERR_BAD_PASSWORD
+ 33 SILC_STATUS_ERR_BAD_PASSWORD
"Cannot join channel. Incorrect password". Password provided for
channel were not accepted.
- 33 SILC_STATUS_ERR_CHANNEL_IS_FULL
+ 34 SILC_STATUS_ERR_CHANNEL_IS_FULL
"Cannot join channel. Channel is full". The channel is full
and client cannot be joined to it.
- 34 SILC_STATUS_ERR_NOT_INVITED
+ 35 SILC_STATUS_ERR_NOT_INVITED
"Cannot join channel. You have not been invited". The channel
is invite only channel and client has not been invited.
- 35 SILC_STATUS_ERR_BANNED_FROM_CHANNEL
+ 36 SILC_STATUS_ERR_BANNED_FROM_CHANNEL
"Cannot join channel. You have been banned". The client has
been banned from the channel.
- 36 SILC_STATUS_ERR_UNKNOWN_MODE
+ 37 SILC_STATUS_ERR_UNKNOWN_MODE
"Unknown mode". Mode provided by the client were unknown to
the server.
- 37 SILC_STATUS_ERR_NOT_YOU
+ 38 SILC_STATUS_ERR_NOT_YOU
"Cannot change mode for other users". User tried to change
someone else's mode.
- 38 SILC_STATUS_ERR_NO_CHANNEL_PRIV
+ 39 SILC_STATUS_ERR_NO_CHANNEL_PRIV
"Permission denied. You are not channel operator". Command may
be executed only by channel operator.
- 39 SILC_STATUS_ERR_NO_SERVER_PRIV
+ 40 SILC_STATUS_ERR_NO_SERVER_PRIV
"Permission denied. You are not server operator". Command may
be executed only by server operator.
- 40 SILC_STATUS_ERR_NO_ROUTER_PRIV
+ 41 SILC_STATUS_ERR_NO_ROUTER_PRIV
"Permission denied. You are not SILC operator". Command may be
executed only by router (SILC) operator.
- 41 SILC_STATUS_ERR_BAD_NICKNAME
+ 42 SILC_STATUS_ERR_BAD_NICKNAME
"Bad nickname". Nickname requested contained illegal characters
or were malformed.
- 42 SILC_STATUS_ERR_BAD_CHANNEL
+ 43 SILC_STATUS_ERR_BAD_CHANNEL
"Bad channel name". Channel requested contained illegal characters
or were malformed.
- 43 SILC_STATUS_ERR_AUTH_FAILED
+ 44 SILC_STATUS_ERR_AUTH_FAILED
"Authentication failed". The authentication data sent as
argument were wrong and thus authentication failed.
considerations permeate the specification.
-
-
-
.ti 0
7 References
Key Management Protocol (ISAKMP)", RFC 2408, November
1998.
-[IKE] Harkins D., and Carrel D., "The Internet Key Exhange
+[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
EMail: priikone@poseidon.pspt.fi
-This Internet-Draft expires 13 May 2001
+This Internet-Draft expires 6 Jun 2001
projects / silc.git / blobdiff