the requirements of keeping this information.
The nickname selected by the user is not unique in the SILC network.
-There can be 2^8 same nicknames for one IP address. As for comparison to
-IRC [IRC] where nicknames are unique this is a fundamental difference
+There can be 2^8 same nicknames for one IP address. As for comparison
+to IRC [IRC] where nicknames are unique this is a fundamental difference
between SILC and IRC. This causes the server names to be used along
with the nicknames to identify specific users when sending messages.
This feature of SILC makes IRC style nickname-wars obsolete as no one
owns their nickname; there can always be someone else with the same
-nickname. Another difference is that there are no limit of the length
-of the nickname in the SILC.
+nickname. The maximum length of nickname is 128 characters.
.ti 0
3.1.1 Client ID
Client ID is used to identify users in the SILC network. The Client ID
-is unique to the extent that there can be 2^128 different Client ID's.
-Collisions are not expected to happen. The Client ID is defined as
-follows.
+is unique to the extent that there can be 2^128 different Client ID's,
+and ID's based on IPv6 addresses extends this to 2^224 different Client
+ID's. Collisions are not expected to happen. The Client ID is defined
+as follows.
.in 6
128 bit Client ID based on IPv4 addresses:
-32 bit ServerID IP address (bits 1-32)
- 8 bit Random number
+32 bit Server ID IP address (bits 1-32)
+ 8 bit Random number or counter
88 bit Truncated MD5 hash value of the nickname
+224 bit Client ID based on IPv6 addresses:
+
+128 bit Server ID IP address (bits 1-128)
+ 8 bit Random number or counter
+ 88 bit Truncated MD5 hash value of the nickname
+
o Server ID IP address - Indicates the server where this
client is coming from. The IP address hence equals the
server IP address where to the client has connected.
-o Random number - Random number to further randomize the
- Client ID. This makes it possible to have 2^8 same
- nicknames from the same server IP address.
+o Random number or counter - Random number to further
+ randomize the Client ID. Another choice is to use
+ a counter starting from the zero (0). This makes it
+ possible to have 2^8 same nicknames from the same
+ server IP address.
o MD5 hash - MD5 hash value of the nickname is truncated
taking 88 bits from the start of the hash value. This
.ti 0
3.2.2 Server ID
-Servers are distinguished from other servers by unique 64 bit Server ID.
-The Server ID is used in the SILC to route messages to correct servers.
-Server ID's also provide information for Client ID's, see section 3.1.1
-Client ID. Server ID is defined as follows.
+Servers are distinguished from other servers by unique 64 bit Server ID
+(for IPv4) or 160 bit Server ID (for IPv6). The Server ID is used in
+the SILC to route messages to correct servers. Server ID's also provide
+information for Client ID's, see section 3.1.1 Client ID. Server ID is
+defined as follows.
.in 6
64 bit Server ID based on IPv4 addresses:
16 bit Port
16 bit Random number
+160 bit Server ID based on IPv6 addresses:
+
+128 bit IP address of the server
+ 16 bit Port
+ 16 bit Random number
+
o IP address of the server - This is the real IP address of
the server.
Channel names are unique although the real uniqueness comes from 64 bit
Channel ID that unifies each channel. However, channel names are still
-unique and no two global channels with same name may exist. Channel name
-is a string which begins with `#' character. There is no limit on the
-length of the channel name. Channel names may not contain any spaces
-(` '), any non-printable ASCII characters, commas (`,') and wildcard
-characters.
+unique and no two global channels with same name may exist. The Channel
+name is a string of maximum length of 256 characters. Channel names may
+not contain any spaces (` '), any non-printable ASCII characters,
+commas (`,') and wildcard characters.
Channels can have operators that can administrate the channel and
operate all of its modes. Following operators on channel exist on SILC
3.4.1 Channel ID
Channels are distinguished from other channels by unique Channel ID.
-The Channel ID is a 64 bit ID and collisions are not expected to happen
-in any conditions. Channel names are just for logical use of channels.
-The Channel ID is created by the server where the channel is created.
-The Channel ID is defined as follows.
+The Channel ID is a 64 bit ID (for IPv4) or 160 bit ID (for IPv6), and
+collisions are not expected to happen in any conditions. Channel names
+are just for logical use of channels. The Channel ID is created by the
+server where the channel is created. The Channel ID is defined as
+follows.
.in 6
64 bit Channel ID based on IPv4 addresses:
16 bit Router's Server ID port (bits 33-48)
16 bit Random number
+160 bit Channel ID based on IPv6 addresses:
+
+128 bit Router's Server ID IP address (bits 1-128)
+ 16 bit Router's Server ID port (bits 129-144)
+ 16 bit Random number
+
o Router's Server ID IP address - Indicates the IP address of
the router of the cell where this channel is created. This is
taken from the router's Server ID. This way SILC router knows
Client usually sends the commands and server replies by sending a reply
packet to the command. Server may also send commands usually to serve
the original client's request. However, server may not send command
-to client and there are some commands that server must not send. Server
-is also able to send the forwarded command packets. For example,
-SILC_COMMAND_JOIN is always forwarded packet. See [SILC2] for more
-about packet forwarding.
+to client and there are some commands that server must not send.
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
connection authentication protocol is described in detail in [SILC3].
+.ti 0
+3.9.1 Authentication Payload
+
+Authentication payload is used separately from the SKE and the Connection
+authentication protocol. It is used during the session to authenticate
+with the remote. For example, the client can authenticate itself to the
+server to be server operator. In this case, Authentication Payload is
+used.
+
+The format of the Authentication Payload is as follows:
+
+
+.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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Payload Length | Authentication Method |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Public Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Authentication Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Authentication Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
+.in 3
+
+.ce
+Figure 5: Authentication Payload
+
+
+.in 6
+o Payload Length (2 bytes) - Length of the entire payload.
+
+o Authentication Type (2) - The method of the authentication.
+ The authentication methods are defined in [SILC2] in the
+ Connection Auth Request Payload. The NONE authentication
+ method is not recommended.
+
+o Public Data Length (2 bytes) - Indicates the length of
+ the Public Data field.
+
+o Public Data (variable length) - This is defined only if
+ the authentication method is public key. If it is any other
+ this field does not exist and the Public Data Length field
+ is set to zero (0).
+
+ When the authentication method is public key this includes
+ 128 to 4096 bytes of non-zero random data that is used in
+ the signature process, described subsequently.
+
+o Authentication Data Length (2 bytes) - Indicates the
+ length of the Authentication Data field.
+
+o Authentication Data (variable length) - Authentication
+ method dependent authentication data.
+.in 3
+
+
+If the authentication method is password based, the Authentication
+Data field includes the plaintext password. It is safe to send
+plaintext password since the entire payload is encrypted.
+
+If the authentication method is public key based (or certificate)
+the Authentication Data is computed as follows:
+
+ HASH = hash(random bytes | ID | public key (or certificate));
+ Authentication Data = sign(HASH);
+
+The hash() and the sign() are the hash funtion and the public key
+cryptography function selected in the SKE protocol. The public key
+is SILC style public key unless certificates are used. The ID is the
+entity's ID (Client or Server ID) who is authenticating itself. The ID
+is raw ID data. The random bytes are non-zero random bytes of length
+between 128 and 4096 bytes, and will be included into the Public Data
+field as is.
+
+The receiver will compute the signature using the random data received
+in the payload, the ID associated to the connection and the public key
+(or certificate) received in the SKE protocol. After computing the
+receiver must verify the signature. In this case also, the entire
+payload is encrypted.
+
+
.ti 0
3.10 Algorithms
dss DSS (optional)
.in 3
-Both of the algorithms are described in [Scheneir] and [Menezes].
+DSS is described in [Menezes]. The RSA must be implemented according
+PKCS #1 [PKCS1]. The mandatory PKCS #1 implementation in SILC must be
+compliant to either PKCS #1 version 1.5 or newer with the following
+notes: The signature encoding is always in same format as the encryption
+encoding regardles of the PKCS #1 version. The signature with appendix
+(with hash algorithm OID in the data) must not be used in the SILC. The
+rationale for this is that there is no binding between the PKCS #1 OIDs
+and the hash algorithms used in the SILC protocol. Hence, the encoding
+is always in PKCS #1 version 1.5 format.
Additional public key algorithms may be defined to be used in SILC.
who it claims to be. Client, host, connecting to server must have
both valid IP address and fully qualified domain name (FQDN).
-After that client and server performs SILC Key Exchange protocol which
-will provide the key material used later in the communication. The
-key exchange protocol must be completed successfully before the connection
-registration may continue. The SILC Key Exchange protocol is described
-in [SILC3].
+After that the client and server performs SILC Key Exchange protocol
+which will provide the key material used later in the communication.
+The key exchange protocol must be completed successfully before the
+connection registration may continue. The SILC Key Exchange protocol
+is described in [SILC3].
Typical server implementation would keep a list of connections that it
allows to connect to the server. The implementation would check, for
locally. This would indicate that some client connected to the server
has already joined to the channel. If this is case the client is
joined to the client, new channel key is created and information about
-newly joined channel is sent to the router. The new channel key is
-also distributed to the router and to all clients on the channel.
+newly joined channel is sent to the router. The router is informed
+by sending SILC_NOTIFY_TYPE_JOIN notify type. The notify type must
+also be sent to the local clients on the channel. The new channel key
+is also sent to the router and to local clients on the channel.
-If the channel does not exist in the local list the command must be
-forwarded to the router which will then perform the actual joining
+If the channel does not exist in the local list the client's command
+must be sent 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
-that it must distribute to the client who originally requested the
-join command. The server must also save the channel key.
+router it must be sent to the client who sent the command originally.
+Server will also receive the channel key from the server that it must
+send to the client who originally requested the join command. The server
+must also save the channel key.
If the receiver of the join command is router it must first check its
local list whether anyone in the cell has already joined to the channel.
sent to the client. If the command was sent by server the command reply
is sent to the server who sent it. Then the router must also create
new channel key and distribute it to all clients on the channel and
-all servers that has clients on the channel.
+all servers that has clients on the channel. Router must also send
+the SILC_NOTIFY_TYPE_JOIN notify type to local clients on the channel
+and to local servers that has clients on the channel.
If the channel does not exist on the router's local list it must
check the global list whether the channel exists at all. If it does
channel is made automatically channel founder and both channel founder
and channel operator privileges is set for the client.
-When the router joins the client to the channel it must send
-information about newly joined client to all routers in the SILC
-network. Also, if the channel was created in the process, information
-about newly created channel must also be distributed to all routers.
-The distribution of newly created channel is done by sending packet
-SILC_PACKET_NEW_CHANNEL.
+If the router created the channel in the process, information about the
+new channel must be broadcasted to all routers. This is done by
+broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary
+route. When the router joins the client to the channel it must also
+send information about newly joined client to all routers in the SILC
+network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify
+type to the router's primary route.
+
+After joining the client to the channel server or router must send
+command reply packet for SILC_COMMAND_USERS command. This way the
+client gets the list of users on the channel. If the router joined
+the client to the channel then the router sends this command reply
+to the server which must send it further to the original client.
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.
-
-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. Server should also
-send SILC_NOTIFY_TYPE_JOIN to all clients on the channel about a new
-client on the channel.
+message communication thereafter. Client also receives the key for the
+channel in the command reply.
.ti 0
1 SILC_COMMAND_WHOIS
- Max Arguments: 3
- Arguments: (1) [<nickname>[@<server>]] (2) [<Client ID>]
- (3) [<count>]
+ Max Arguments: 3328
+ Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
+ (3) [<Client ID>] (n) [...]
Whois command is used to query various information about specific
user. The user maybe requested by their nickname and server name.
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>. One of the arguments must be given.
+ the <nickname>. One of the arguments must be given. It is also
+ possible to define multiple Client ID's to search multiple users
+ sending only one WHOIS command. In this case the Client ID's are
+ appended as normal arguments. The server replies in this case
+ with only one reply message for all requested users.
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 WHOIS requests must
be based on specific nickname request.
- The WHOIS request must be always forwarded to router by server
+ The WHOIS request must be always sent to the router by server
so that all users are searched. However, the server still must
search its locally connected clients. The router must send
this command to the server who owns the requested client. That
SILC_STATUS_LIST_START
SILC_STATUS_LIST_END
SILC_STATUS_ERR_NO_SUCH_NICK
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_WILDCARDS
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
or in the servername are not permitted. The WHOWAS requests must
be based on specific nickname request.
- The WHOWAS request must be always forwarded to router by server
+ The WHOWAS request must be always sent to the router by server
so that all users are searched. However, the server still must
search its locally connected clients.
3 SILC_COMMAND_IDENTIFY
- Max Arguments: 2
- Arguments: (1) [<nickname>[@<server>]] (2) [<Client ID>]
- (3) [<count>]
+ Max Arguments: 3328
+ Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
+ (3) [<Client ID>] (n) [...]
Identify. Identify command is almost analogous to WHOIS command,
except that it does not return as much information. Only relevant
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>.
+ the <nickname>. One of the arguments must be given. It is also
+ possible to define multiple Client ID's to search multiple users
+ sending only one IDENTIFY command. In this case the Client ID's are
+ appended as normal arguments. The server replies in this case
+ with only one reply message for all requested users.
To prevent miss-use of this service wildcards in the nickname
or in the servername are not permitted. It is not allowed
However, it must be implemented as it is used with private message
sending.
- The IDENTIFY must be always forwarded to router by server so that
+ The IDENTIFY must be always sent to the router by server so that
all users are searched. However, server must still search its
locally connected clients.
SILC_STATUS_LIST_START
SILC_STATUS_LIST_END
SILC_STATUS_ERR_NO_SUCH_NICK
+ SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_WILDCARDS
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_NO_CLIENT_ID
+ SILC_STATUS_ERR_NO_ROUTER_PRIV
10 SILC_COMMAND_INFO
14 SILC_COMMAND_JOIN
- Max Arguments: 3
- Arguments: (1) <channel> (2) [<passphrase>]
- (3) [<cipher>]
+ Max Arguments: 4
+ Arguments: (1) <channel> (2) <Client ID>
+ (3) [<passphrase>] (4) [<cipher>]
Join to channel/create new channel. This command is used to
join to a channel. If the channel does not exist the channel is
- created. If server is normal server this command must be forwarded
- to router who will create the channel. The channel may be protected
- with passphrase. If this is the case the passphrase must be sent
- along the join command.
+ created. If server is normal server this command must be sent
+ to router who will create the channel. The channel may be
+ protected with passphrase. If this is the case the passphrase
+ must be sent along the join command.
The name of the <channel> must not include any spaces (` '),
non-printable characters, commas (`,') or any wildcard characters.
+ The second argument <Client ID> is the Client ID of the client who
+ is joining to the client. When client sends this command to the
+ server the <Client ID> must be the client's own ID.
+
Cipher to be used to secure the traffic on the channel may be
requested by sending the name of the requested <cipher>. This
is used only if the channel does not exist and is created. If
Reply messages to the command:
- Max Arguments: 6
+ Max Arguments: 9
Arguments: (1) <Status Payload> (2) <channel>
(3) <Channel ID> (4) <channel mode mask>
- (5) [<ban mask>] (6) [<invite list>]
- (6) [<topic>]
+ (5) <created> (6) <Channel Key Payload>
+ (7) [<ban mask>] (8) [<invite list>]
+ (9) [<topic>]
This command replies with the channel name requested by the
client, channel ID of the channel and topic of the channel
channel is created the mode mask is zero (0). If ban mask
and/or invite list is set they are sent as well.
- Client must not start transmitting to the channel even after
- server has replied to this command. Client is permitted to
- start transmitting on channel after server has sent packet
- SILC_PACKET_CHANNEL_KEY to the client.
+ Client receives the channel key in the reply message as well
+ inside <Channel Key Payload>.
Status messages:
19 SILC_COMMAND_KICK
Max Arguments: 3
- Arguments: (1) <channel> (2) <Client ID>
+ Arguments: (1) <Channel ID> (2) <Client ID>
(3) [<comment>]
This command is used by channel operators to remove a client from
SILC_STATUS_ERR_NO_CHANNEL_ID
- 25 SILC_COMMAND_NAMES
+ 25 SILC_COMMAND_USERS
Max Arguments: 1
Arguments: (1) <Channel ID>
Max Arguments: 5
Arguments: (1) <Status Payload> (2) <Channel ID>
- (3) <name list> (4) <Client ID list>
+ (3) <list count> (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 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).
+ This command replies with the Channel ID of the requested channel
+ Client ID list of the users on the channel and list of their modes.
+ The Client ID list has Client ID's of all users in the list. The
+ <Client ID list> is formed by adding Client ID's one after another.
+ The <client mode list> is formed by adding client's user modes on
+ the channel one after another (4 bytes (32 bits) each). The <list
+ count> of length of 4 bytes (32 bits), tells the number of entries
+ in the lists. Both lists must have equal number of entries.
Status messages:
reply is the last of the list. There won't be other replies
belonging to this list after this one.
- 3 - 9
+ 4 - 9
Currently undefined and has been reserved for the future.
"Permission denied. You are not channel operator". Command may
be executed only by channel operator.
- 40 SILC_STATUS_ERR_NO_SERVER_PRIV
+ 40 SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+
+ "Permission denied. You are not channel founder". Command may
+ be executed only by channel operator.
+
+ 41 SILC_STATUS_ERR_NO_SERVER_PRIV
"Permission denied. You are not server operator". Command may
be executed only by server operator.
- 41 SILC_STATUS_ERR_NO_ROUTER_PRIV
+ 42 SILC_STATUS_ERR_NO_ROUTER_PRIV
"Permission denied. You are not SILC operator". Command may be
executed only by router (SILC) operator.
- 42 SILC_STATUS_ERR_BAD_NICKNAME
+ 43 SILC_STATUS_ERR_BAD_NICKNAME
"Bad nickname". Nickname requested contained illegal characters
or were malformed.
- 43 SILC_STATUS_ERR_BAD_CHANNEL
+ 44 SILC_STATUS_ERR_BAD_CHANNEL
"Bad channel name". Channel requested contained illegal characters
or were malformed.
- 44 SILC_STATUS_ERR_AUTH_FAILED
+ 45 SILC_STATUS_ERR_AUTH_FAILED
"Authentication failed". The authentication data sent as
argument were wrong and thus authentication failed.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
Internet Draft.
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
.ti 0
projects / silc.git / blobdiff