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.
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.
+message communication thereafter. Client also receives the key for the
+channel in the command reply.
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
+the client must send SILC_COMMAND_USERS 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
+packet to SILC_COMMAND_USERS 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.
the client simply sends the command packet to server and the server
processes it and replies with command reply packet.
-However, if the server is not able to process the command, it is usually
-sent to the server's router. This is case for example with commands such
+However, if the server is not able to process the command, it is sent
+to the server's router. This is case for example with commands such
as, SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there
are other commands as well. For example, if client sends the WHOIS
command requesting specific information about some client the server must
send the WHOIS command to router so that all clients in SILC network
are searched. The router, on the other hand, sends the WHOIS command
-to further to receive the exact information about the requested client.
+further to receive the exact information about the requested client.
The WHOIS command travels all the way to the server who owns the client
and it replies with command reply packet. Finally, the server who
sent the command receives the command reply and it must be able to
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>.
+ 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
The WHOIS request must be always forwarded to router by server
so that all users are searched. However, the server still must
- search its locally connected clients. The server must send
+ search its locally connected clients. The router must send
this command to the server who owns the requested client. That
- server must reply to the command.
+ server must reply to the command. Server should not send whois
+ replies to the client until it has received the reply from its
+ router.
Reply messages to the command:
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
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
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
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:
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.
6 Security Considerations
Security is central to the design of this protocol, and these security
-considerations permeate the specification.
+considerations permeate the specification. Common security considerations
+such as keeping private keys truly private and using adequate lengths for
+symmetric and asymmetric keys must be followed in order to maintain the
+security of this protocol.
.ti 0
projects / silc.git / blobdiff