8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-silc-spec-02.txt 26 April 2001
20 Expires: 26 October 2001
25 Secure Internet Live Conferencing (SILC),
26 Protocol Specification
27 <draft-riikonen-silc-spec-02.txt>
32 This document is an Internet-Draft and is in full conformance with
33 all provisions of Section 10 of RFC 2026. Internet-Drafts are
34 working documents of the Internet Engineering Task Force (IETF), its
35 areas, and its working groups. Note that other groups may also
36 distribute working documents as Internet-Drafts.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 The list of current Internet-Drafts can be accessed at
44 http://www.ietf.org/ietf/1id-abstracts.txt
46 The list of Internet-Draft Shadow Directories can be accessed at
47 http://www.ietf.org/shadow.html
49 The distribution of this memo is unlimited.
55 This memo describes a Secure Internet Live Conferencing (SILC)
56 protocol which provides secure conferencing services over insecure
57 network channel. SILC is IRC [IRC] like protocol, however, it is
58 not equivalent to IRC and does not support IRC. Strong cryptographic
59 methods are used to protect SILC packets inside the SILC network.
60 Three other Internet Drafts relates very closely to this memo;
61 SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication
62 Protocols [SILC3] and SILC Commands [SILC4].
73 1 Introduction .................................................. 3
74 1.1 Requirements Terminology .................................. 4
75 2 SILC Concepts ................................................. 4
76 2.1 SILC Network Topology ..................................... 4
77 2.2 Communication Inside a Cell ............................... 5
78 2.3 Communication in the Network .............................. 6
79 2.4 Channel Communication ..................................... 7
80 2.5 Router Connections ........................................ 7
81 2.6 Backup Routers ............................................ 8
82 3 SILC Specification ............................................ 10
83 3.1 Client .................................................... 10
84 3.1.1 Client ID ........................................... 10
85 3.2 Server .................................................... 11
86 3.2.1 Server's Local ID List .............................. 12
87 3.2.2 Server ID ........................................... 13
88 3.2.3 SILC Server Ports ................................... 14
89 3.3 Router .................................................... 14
90 3.3.1 Router's Local ID List .............................. 14
91 3.3.2 Router's Global ID List ............................. 15
92 3.3.3 Router's Server ID .................................. 15
93 3.4 Channels .................................................. 16
94 3.4.1 Channel ID .......................................... 17
95 3.5 Operators ................................................. 17
96 3.6 SILC Commands ............................................. 18
97 3.7 SILC Packets .............................................. 18
98 3.8 Packet Encryption ......................................... 19
99 3.8.1 Determination of the Source and the Destination ..... 19
100 3.8.2 Client To Client .................................... 20
101 3.8.3 Client To Channel ................................... 21
102 3.8.4 Server To Server .................................... 22
103 3.9 Key Exchange And Authentication ........................... 22
104 3.9.1 Authentication Payload .............................. 22
105 3.10 Algorithms ............................................... 24
106 3.10.1 Ciphers ............................................ 24
107 3.10.2 Public Key Algorithms .............................. 25
108 3.10.3 Hash Functions ..................................... 26
109 3.10.4 MAC Algorithms ..................................... 26
110 3.10.5 Compression Algorithms ............................. 26
111 3.11 SILC Public Key .......................................... 27
112 3.12 SILC Version Detection ................................... 29
113 4 SILC Procedures ............................................... 30
114 4.1 Creating Client Connection ................................ 30
115 4.2 Creating Server Connection ................................ 31
116 4.2.1 Announcing Clients, Channels and Servers ............ 32
117 4.3 Joining to a Channel ...................................... 33
118 4.4 Channel Key Generation .................................... 34
119 4.5 Private Message Sending and Reception ..................... 34
120 4.6 Private Message Key Generation ............................ 35
121 4.7 Channel Message Sending and Reception ..................... 35
122 4.8 Session Key Regeneration .................................. 36
123 4.9 Command Sending and Reception ............................. 37
124 4.10 Closing Connection ....................................... 37
125 5 Security Considerations ....................................... 38
126 6 References .................................................... 38
127 7 Author's Address .............................................. 39
135 Figure 1: SILC Network Topology
136 Figure 2: Communication Inside cell
137 Figure 3: Communication Between Cells
138 Figure 4: Router Connections
139 Figure 5: SILC Public Key
145 This document describes a Secure Internet Live Conferencing (SILC)
146 protocol which provides secure conferencing services over insecure
147 network channel. SILC is IRC [IRC] like protocol, however, it is
148 not equivalent to IRC and does not support IRC.
150 Strong cryptographic methods are used to protect SILC packets inside
151 the SILC network. Three other Internet Drafts relates very closely
152 to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and
153 Authentication Protocols [SILC3] and SILC Commands [SILC4].
155 The protocol uses extensively packets as conferencing protocol
156 requires message and command sending. The SILC Packet Protocol is
157 described in [SILC2] and should be read to fully comprehend this
158 document and protocol. [SILC2] also describes the packet encryption
159 and decryption in detail.
161 The security of SILC protocol, and for any security protocol for that
162 matter, is based on strong and secure key exchange protocol. The SILC
163 Key Exchange protocol is described in [SILC3] along with connection
164 authentication protocol and should be read to fully comprehend this
165 document and protocol.
167 The SILC protocol has been developed to work on TCP/IP network
168 protocol, although it could be made to work on other network protocols
169 with only minor changes. However, it is recommended that TCP/IP
170 protocol is used under SILC protocol. Typical implementation would
171 be made in client-server model.
175 1.1 Requirements Terminology
177 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
178 MAY, and OPTIONAL, when they appear in this document, are to be
179 interpreted as described in [RFC2119].
185 This section describes various SILC protocol concepts that forms the
186 actual protocol, and in the end, the actual SILC network. The mission
187 of the protocol is to deliver messages from clients to other clients
188 through routers and servers in secure manner. The messages may also
189 be delivered from one client to many clients forming a group, also
192 This section does not focus to security issues. Instead, basic network
193 concepts are introduced to make the topology of the SILC network
198 2.1 SILC Network Topology
200 SILC network is a cellular network as opposed to tree style network
201 topology. The rationale for this is to have servers that can perform
202 specific kind of tasks what other servers cannot perform. This leads
203 to two kinds of servers; normal SILC servers and SILC routers.
205 A difference between normal server and router server is that routers
206 knows everything about everything in the network. They also do the
207 actual routing of the messages to the correct receiver. Normal servers
208 knows only about local information and nothing about global information.
209 This makes the network faster as there are less servers that needs to
210 keep global information up to date at all time.
212 This, on the other hand, leads to cellular like network, where routers
213 are in the center of the cell and servers are connected to the router.
221 The following diagram represents SILC network topology.
225 ---- ---- ---- ---- ---- ----
226 | S8 | S5 | S4 | | S7 | S5 | S6 |
227 ----- ---- ----- ----- ---- -----
228 | S7 | S/R1 | S2 | --- | S8 | S/R2 | S4 |
229 ---- ------ ---- ---- ------ ----
230 | S6 | S3 | S1 | | S1 | S3 | S2 | ---- ----
231 ---- ---- ---- ---- ---- ---- | S3 | S1 |
232 Cell 1. \\ Cell 2. | \\____ ----- -----
234 ---- ---- ---- ---- ---- ---- ---- ------
235 | S7 | S4 | S2 | | S1 | S3 | S2 | | S2 | S5 |
236 ----- ---- ----- ----- ---- ----- ---- ----
237 | S6 | S/R3 | S1 | --- | S4 | S/R5 | S5 | ____/ Cell 4.
238 ---- ------ ---- ---- ------ ----
239 | S8 | S5 | S3 | | S6 | S7 | S8 | ... etc ...
240 ---- ---- ---- ---- ---- ----
245 Figure 1: SILC Network Topology
248 A cell is formed when a server or servers connect to one router. In
249 SILC network normal server cannot directly connect to other normal
250 server. Normal server may only connect to SILC router which then
251 routes the messages to the other servers in the cell. Router servers
252 on the other hand may connect to other routers to form the actual SILC
253 network, as seen in above figure. However, router is also normal SILC
254 server; clients may connect to it the same way as to normal SILC
255 server. Normal server also cannot have active connections to more
256 than one router. Normal server cannot be connected to two different
257 cells. Router servers, on the other hand, may have as many router to
258 router connections as needed.
260 There are many issues in this network topology that needs to be careful
261 about. Issues like the size of the cells, the number of the routers in
262 the SILC network and the capacity requirements of the routers. These
263 issues should be discussed in the Internet Community and additional
264 documents on the issue may be written.
268 2.2 Communication Inside a Cell
270 It is always guaranteed that inside a cell message is delivered to the
271 recipient with at most two server hops. A client which is connected to
272 server in the cell and is talking on channel to other client connected
273 to other server in the same cell, will have its messages delivered from
274 its local server first to the router of the cell, and from the router
275 to the other server in the cell.
277 The following diagram represents this scenario:
291 Figure 2: Communication Inside cell
294 Example: Client 1. connected to Server 1. send message to
295 Client 4. connected to Server 2. travels from Server 1.
296 first to Router which routes the message to Server 2.
297 which then sends it to the Client 4. All the other
298 servers in the cell will not see the routed message.
301 If the client is connected directly to the router, as router is also normal
302 SILC server, the messages inside the cell are always delivered only with
303 one server hop. If clients communicating with each other are connected
304 to the same server, no router interaction is needed. This is the optimal
305 situation of message delivery in the SILC network.
309 2.3 Communication in the Network
311 If the message is destined to server that does not belong to local cell
312 the message is routed to the router server to which the destination
313 server belongs, if the local router is connected to destination router.
314 If there is no direct connection to the destination router, the local
315 router routes the message to its primary route. The following diagram
316 represents message sending between cells.
321 1 --- S1 S4 --- 5 S2 --- 1
322 S/R - - - - - - - - S/R
332 Figure 3: Communication Between Cells
335 Example: Client 5. connected to Server 4. in Cell 1. sends message
336 to Client 2. connected to Server 1. in Cell 2. travels
337 from Server 4. to Router which routes the message to
338 Router in Cell 2, which then routes the message to
339 Server 1. All the other servers and routers in the
340 network will not see the routed message.
343 The optimal case of message delivery from the client point of view is
344 when clients are connected directly to the routers and the messages
345 are delivered from one router to the other.
349 2.4 Channel Communication
351 Messages may be sent to group of clients as well. Sending messages to
352 many clients works the same way as sending messages point to point, from
353 message delivery point of view. Security issues are another matter
354 which are not discussed in this section.
356 Router server handles the message routing to multiple recipients. If
357 any recipient is not in the same cell as the sender the messages are
360 Server distributes the channel message to its local clients which are
361 joined to the channel. Router also distributes the message to its
362 local clients on the channel.
366 2.5 Router Connections
368 Router connections play very important role in making the SILC like
369 network topology to work. For example, sending broadcast packets in
370 SILC network require special connections between routers; routers must
371 be connected in a specific way.
373 Every router has their primary route which is a connection to another
374 router in the network. Unless there is only two routers in the network
375 must not routers use each other as their primary routes. The router
376 connections in the network must form a circular.
384 Example with three routers in the network:
389 S/R1 - > - > - > - > - > - > - S/R2
392 \\ - < - < - S/R3 - < - < - /
397 Figure 4: Router Connections
400 Example: Network with three routers. Router 1. uses Router 2. as its
401 primary router. Router 2. uses Router 3. as its primary router,
402 and Router 3. uses Router 1. as its primary router. There may
403 be other direct connections between the routers but they must
404 not be used as primary routes.
406 The above example is applicable to any amount of routers in the network
407 except for two routers. If there are only two routers in the network both
408 routers must be able to handle situation where they use each other as their
411 The issue of router connections are very important especially with SILC
412 broadcast packets. Usually all router wide information in the network is
413 distributed by SILC broadcast packets.
419 Backup routers may exist in the cell in addition of the primary router.
420 However, they must not be active routers and act as routers in the cell.
421 Only one router may be acting as primary router in the cell. In the case
422 of failure of the primary router may one of the backup routers become
423 active. The purpose of backup routers are in case of failure of the
424 primary router to maintain working connections inside the cell and outside
425 the cell and to avoid netsplits.
427 Backup routers are normal servers in the cell that are prepared to take
428 over the tasks of the primary router if needed. They need to have at
429 least one direct and active connection to the primary router of the cell.
430 This communication channel is used to send the router information to
433 Backup router must know everything that the primary router knows to be
434 able to take over the tasks of the primary router. It is the primary
435 router's responsibility to feed the data to the backup router. If the
436 backup router does not know all the data in the case of failure some
437 connections may be lost. The primary router of the cell must consider
438 the backup router being normal router server and feed the data
441 In addition of having direct connection to the primary router of the
442 cell the backup router must also have connection to the same router
443 the primary router of the cell is connected. However, it must not be
444 active router connection meaning that the backup router must not use
445 that channel as its primary route and it must not notify the router
446 about having connected servers, channels and clients behind it. It
447 merely connects to the router. This sort of connection is later
448 referred as being passive connection. Some keepalive actions may be
449 needed by the router to keep the connection alive.
451 The primary router notifies its primary router about having backup
452 routers in the cell by sending SILC_PACKET_CELL_ROUTERS packet. If
453 and when the primary router of the cell becomes unresponsive, its
454 primary router knows that there exists backup routers in the cell.
455 After that it will start using the first backup router sent in the
456 packet as router of that cell.
458 In this case the backup router must notify its new primary router about
459 the servers, channels and clients it has connected to it. The primary
460 router knows that this server has become a router of the cell because
461 of failure of the primary router in the cell. It must also cope with
462 the fact that the servers, channels and clients that the new backup
463 router announces are not really new, since they used to exist in the
464 primary router of the cell.
466 It is required that other normal servers has passive connections to
467 the backup router(s) in the cell. Some keepalive actions may be needed
468 by the server to keep the connection alive. After they notice the
469 failure of the primary router they must start using the connection to
470 the first backup router as their primary route.
472 It is RECOMMENDED that there would be at least one backup router in
473 the cell. It is NOT RECOMMENDED to have all servers in the cell acting
474 as backup routers as it requires establishing several connections to
475 several servers in the cell. Large cells can easily have several
476 backup routers in the cell.
478 The order of the backup routers are decided at the primary router of the
479 cell and servers and backup routers in the cell must be configured
480 accordingly. It is not required that the backup server is actually
481 active server in the cell. Backup router may be a spare server in the
482 cell that does not accept normal client connections at all. It may be
483 reserved purely for the backup purposes. These, however, are cell
486 If also the first backup router is down as well and there is another
487 backup router in the cell then it will start acting as the primary
488 router as described above.
492 3. SILC Specification
494 This section describes the SILC protocol. However, [SILC2] and
495 [SILC3] describes other important protocols that are part of this SILC
496 specification and must be read.
502 A client is a piece of software connecting to SILC server. SILC client
503 cannot be SILC server. Purpose of clients is to provide the user
504 interface of the SILC services for end user. Clients are distinguished
505 from other clients by unique Client ID. Client ID is a 128 bit ID that
506 is used in the communication in the SILC network. The client ID is
507 based on the nickname selected by the user. User uses logical nicknames
508 in communication which are then mapped to the corresponding Client ID.
509 Client ID's are low level identifications and must not be seen by the
512 Clients provide other information about the end user as well. Information
513 such as the nickname of the user, username and the host name of the end
514 user and user's real name. See section 3.2 Server for information of
515 the requirements of keeping this information.
517 The nickname selected by the user is not unique in the SILC network.
518 There can be 2^8 same nicknames for one IP address. As for comparison
519 to IRC [IRC] where nicknames are unique this is a fundamental difference
520 between SILC and IRC. This causes the server names or client's host names
521 to be used along with the nicknames to identify specific users when sending
522 messages. This feature of SILC makes IRC style nickname-wars obsolete as
523 no one owns their nickname; there can always be someone else with the same
524 nickname. The maximum length of nickname is 128 characters.
530 Client ID is used to identify users in the SILC network. The Client ID
531 is unique to the extent that there can be 2^128 different Client ID's,
532 and ID's based on IPv6 addresses extends this to 2^224 different Client
533 ID's. Collisions are not expected to happen. The Client ID is defined
539 128 bit Client ID based on IPv4 addresses:
541 32 bit Server ID IP address (bits 1-32)
542 8 bit Random number or counter
543 88 bit Truncated MD5 hash value of the nickname
545 224 bit Client ID based on IPv6 addresses:
547 128 bit Server ID IP address (bits 1-128)
548 8 bit Random number or counter
549 88 bit Truncated MD5 hash value of the nickname
551 o Server ID IP address - Indicates the server where this
552 client is coming from. The IP address hence equals the
553 server IP address where to the client has connected.
555 o Random number or counter - Random number to further
556 randomize the Client ID. Another choice is to use
557 a counter starting from the zero (0). This makes it
558 possible to have 2^8 same nicknames from the same
561 o MD5 hash - MD5 hash value of the nickname is truncated
562 taking 88 bits from the start of the hash value. This
563 hash value is used to search the user's Client ID from
567 Collisions could occur when more than 2^8 clients using same nickname
568 from the same server IP address is connected to the SILC network.
569 Server MUST be able to handle this situation by refusing to accept
570 anymore of that nickname.
572 Another possible collision may happen with the truncated hash value of
573 the nickname. It could be possible to have same truncated hash value for
574 two different nicknames. However, this is not expected to happen nor
575 cause any problems if it would occur. Nicknames are usually logical and
576 it is unlikely to have two distinct logical nicknames produce same
577 truncated hash value.
583 Servers are the most important parts of the SILC network. They form the
584 basis of the SILC, providing a point to which clients may connect to.
585 There are two kinds of servers in SILC; normal servers and router servers.
586 This section focus on the normal server and router server is described
587 in the section 3.3 Router.
589 Normal servers MUST NOT directly connect to other normal server. Normal
590 servers may only directly connect to router server. If the message sent
591 by the client is destined outside the local server it is always sent to
592 the router server for further routing. Server may only have one active
593 connection to router on same port. Normal server MUST NOT connect to other
594 cell's router except in situations where its cell's router is unavailable.
596 Servers and routers in the SILC network are considered to be trusted.
597 With out a doubt, servers that are set to work on ports above 1023 are
598 not considered to be trusted. Also, the service provider acts important
599 role in the server's trustworthy.
603 3.2.1 Server's Local ID List
605 Normal server keeps various information about the clients and their end
606 users connected to it. Every normal server MUST keep list of all locally
607 connected clients, Client ID's, nicknames, usernames and host names and
608 user's real name. Normal servers only keeps local information and it
609 does not keep any global information. Hence, normal servers knows only
610 about their locally connected clients. This makes servers efficient as
611 they don't have to worry about global clients. Server is also responsible
612 of creating the Client ID's for their clients.
614 Normal server also keeps information about locally created channels and
618 Hence, local list for normal server includes:
621 server list - Router connection
629 client list - All clients in server
639 channel list - All channels in server
642 o Client ID's on channel
643 o Client ID modes on channel
651 Servers are distinguished from other servers by unique 64 bit Server ID
652 (for IPv4) or 160 bit Server ID (for IPv6). The Server ID is used in
653 the SILC to route messages to correct servers. Server ID's also provide
654 information for Client ID's, see section 3.1.1 Client ID. Server ID is
658 64 bit Server ID based on IPv4 addresses:
660 32 bit IP address of the server
664 160 bit Server ID based on IPv6 addresses:
666 128 bit IP address of the server
670 o IP address of the server - This is the real IP address of
673 o Port - This is the port the server is bound to.
675 o Random number - This is used to further randomize the Server ID.
678 Collisions are not expected to happen in any conditions. The Server ID
679 is always created by the server itself and server is responsible of
680 distributing it to the router.
684 3.2.3 SILC Server Ports
686 The following ports has been assigned by IANA for the SILC protocol:
694 If there are needs to create new SILC networks in the future the port
695 numbers must be officially assigned by the IANA.
697 Server on network above privileged ports (>1023) SHOULD NOT be trusted
698 as they could have been set up by untrusted party.
704 Router server in SILC network is responsible for keeping the cell together
705 and routing messages to other servers and to other routers. Router server
706 is also a normal server thus clients may connect to it as it would be
707 just normal SILC server.
709 However, router servers has a lot of important tasks that normal servers
710 do not have. Router server knows everything about everything in the SILC.
711 They know all clients currently on SILC, all servers and routers and all
712 channels in SILC. Routers are the only servers in SILC that care about
713 global information and keeping them up to date at all time. And, this
714 is what they must do.
718 3.3.1 Router's Local ID List
720 Router server as well MUST keep local list of connected clients and
721 locally created channels. However, this list is extended to include all
722 the informations of the entire cell, not just the server itself as for
725 However, on router this list is a lot smaller since routers do not need
726 to keep information about user's nickname, username and host name and real
727 name since these are not needed by the router. The router keeps only
728 information that it needs.
731 Hence, local list for router includes:
734 server list - All servers in the cell
741 client list - All clients in the cell
745 channel list - All channels in the cell
747 o Client ID's on channel
748 o Client ID modes on channel
753 Note that locally connected clients and other information include all the
754 same information as defined in section section 3.2.1 Server's Local ID
759 3.3.2 Router's Global ID List
761 Router server MUST also keep global list. Normal servers do not have
762 global list as they know only about local information. Global list
763 includes all the clients on SILC, their Client ID's, all created channels
764 and their Channel ID's and all servers and routers on SILC and their
765 Server ID's. That is said, global list is for global information and the
766 list must not include the local information already on the router's local
769 Note that the global list does not include information like nicknames,
770 usernames and host names or user's real names. Router does not need to
771 keep these informations as they are not needed by the router. This
772 information is available from the client's server which maybe queried
775 Hence, global list includes:
778 server list - All servers in SILC
783 client list - All clients in SILC
786 channel list - All channels in SILC
788 o Client ID's on channel
789 o Client ID modes on channel
800 3.3.3 Router's Server ID
802 Router's Server ID's are equivalent to normal Server ID's. As routers
803 are normal servers as well same types of ID's applies for routers as well.
804 Thus, see section 3.2.2 Server ID.
810 A channel is a named group of one or more clients which will all receive
811 messages addressed to that channel. The channel is created when first
812 client requests JOIN command to the channel, and the channel ceases to
813 exist when the last client has left it. When channel exists, any client
814 can reference it using the name of the channel.
816 Channel names are unique although the real uniqueness comes from 64 bit
817 Channel ID. However, channel names are still unique and no two global
818 channels with same name may exist. The Channel name is a string of
819 maximum length of 256 characters. Channel names MUST NOT contain any
820 spaces (` '), any non-printable ASCII characters, commas (`,') and
823 Channels can have operators that can administrate the channel and
824 operate all of its modes. The following operators on channel exist on
828 o Channel founder - When channel is created the joining client becomes
829 channel founder. Channel founder is channel operator with some more
830 privileges. Basically, channel founder can fully operate the channel
831 and all of its modes. The privileges are limited only to the
832 particular channel. There can be only one channel founder per
833 channel. Channel founder supersedes channel operator's privileges.
835 Channel founder privileges cannot be removed by any other operator on
836 channel. When channel founder leaves the channel there is no channel
837 founder on the channel. However, it is possible to set a mode for
838 the channel which allows the original channel founder to regain the
839 founder privileges even after leaving the channel. Channel founder
840 also cannot be removed by force from the channel.
842 o Channel operator - When client joins to channel that has not existed
843 previously it will become automatically channel operator (and channel
844 founder discussed above). Channel operator is able administrate the
845 channel, set some modes on channel, remove a badly behaving client
846 from the channel and promote other clients to become channel
847 operator. The privileges are limited only to the particular channel.
849 Normal channel user may be promoted (opped) to channel operator
850 gaining channel operator privileges. Channel founder or other
851 channel operator may also demote (deop) channel operator to normal
859 Channels are distinguished from other channels by unique Channel ID.
860 The Channel ID is a 64 bit ID (for IPv4) or 160 bit ID (for IPv6), and
861 collisions are not expected to happen in any conditions. Channel names
862 are just for logical use of channels. The Channel ID is created by the
863 server where the channel is created. The Channel ID is defined as
867 64 bit Channel ID based on IPv4 addresses:
869 32 bit Router's Server ID IP address (bits 1-32)
870 16 bit Router's Server ID port (bits 33-48)
873 160 bit Channel ID based on IPv6 addresses:
875 128 bit Router's Server ID IP address (bits 1-128)
876 16 bit Router's Server ID port (bits 129-144)
879 o Router's Server ID IP address - Indicates the IP address of
880 the router of the cell where this channel is created. This is
881 taken from the router's Server ID. This way SILC router knows
882 where this channel resides in the SILC network.
884 o Router's Server ID port - Indicates the port of the channel on
885 the server. This is taken from the router's Server ID.
887 o Random number - To further randomize the Channel ID. This makes
888 sure that there are no collisions. This also means that
889 in a cell there can be 2^16 channels.
896 Operators are normal users with extra privileges to their server or
897 router. Usually these people are SILC server and router administrators
898 that take care of their own server and clients on them. The purpose of
899 operators is to administrate the SILC server or router. However, even
900 an operator with highest privileges is not able to enter invite-only
901 channel, to gain access to the contents of a encrypted and authenticated
902 packets traveling in the SILC network or to gain channel operator
903 privileges on public channels without being promoted. They have the
904 same privileges as everyone else except they are able to administrate
905 their server or router.
911 Commands are very important part on SILC network especially for client
912 which uses commands to operate on the SILC network. Commands are used
913 to set nickname, join to channel, change modes and many other things.
915 Client usually sends the commands and server replies by sending a reply
916 packet to the command. Server MAY also send commands usually to serve
917 the original client's request. However, server MUST NOT send commands
918 to client and there are some commands that server must not send.
920 Note that the command reply is usually sent only after client has sent
921 the command request but server is allowed to send command reply packet
922 to client even if client has not requested the command. Client MAY,
923 choose to ignore the command reply.
925 It is expected that some of the commands may be miss-used by clients
926 resulting various problems on the server side. Every implementation
927 SHOULD assure that commands may not be executed more than once, say,
928 in two (2) seconds. However, to keep response rate up, allowing for
929 example five (5) commands before limiting is allowed. It is RECOMMENDED
930 that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN,
931 SILC_COMMAND_LEAVE and SILC_COMMAND_KILL SHOULD be limited in all cases
932 as they require heavy operations. This should be sufficient to prevent
933 the miss-use of commands.
935 SILC commands are described in [SILC4].
941 Packets are naturally the most important part of the protocol and the
942 packets are what actually makes the protocol. Packets in SILC network
943 are always encrypted using, usually the shared secret session key
944 or some other key, for example, channel key, when encrypting channel
945 messages. The SILC Packet Protocol is a wide protocol and is described
946 in [SILC2]. This document does not define or describe details of
954 3.8 Packet Encryption
956 All packets passed in SILC network MUST be encrypted. This section
957 defines how packets must be encrypted in the SILC network. The detailed
958 description of the actual encryption process of the packets are
959 described in [SILC2].
961 Client and its server shares secret symmetric session key which is
962 established by the SILC Key Exchange Protocol, described in [SILC3].
963 Every packet sent from client to server, with exception of packets for
964 channels, are encrypted with this session key.
966 Channels has their own key that are shared by every client on the channel.
967 However, the channel keys are cell specific thus one cell does not know
968 the channel key of the other cell, even if that key is for same channel.
969 Channel key is also known by the routers and all servers that has clients
970 on the channel. However, channels MAY have channel private keys that
971 are entirely local setting for the client. All clients on the channel
972 MUST know the channel private key before hand to be able to talk on the
973 channel. In this case, no server or router know the key for channel.
975 Server shares secret symmetric session key with router which is
976 established by the SILC Key Exchange Protocol. Every packet passed from
977 server to router, with exception of packets for channels, are encrypted
978 with the shared session key. Same way, router server shares secret
979 symmetric key with its primary route. However, every packet passed
980 from router to other router, including packets for channels, are
981 encrypted with the shared session key. Every router connection has
982 their own session keys.
986 3.8.1 Determination of the Source and the Destination
988 The source and the destination of the packet needs to be determined
989 to be able to route the packets to correct receiver. This information
990 is available in the SILC Packet Header which is included in all packets
991 sent in SILC network. The SILC Packet Header is described in [SILC2].
993 The header MUST be encrypted with the session key who is next receiver
994 of the packet along the route. The receiver of the packet, for example
995 a router along the route, is able to determine the sender and the
996 destination of the packet by decrypting the SILC Packet Header and
997 checking the ID's attached to the header. The ID's in the header will
998 tell to where the packet needs to be sent and where it is coming from.
1000 The header in the packet MUST NOT change during the routing of the
1001 packet. The original sender, for example client, assembles the packet
1002 and the packet header and server or router between the sender and the
1003 receiver MUST NOT change the packet header.
1005 Note that the packet and the packet header may be encrypted with
1006 different keys. For example, packets to channels are encrypted with
1007 the channel key, however, the header is encrypted with the session key
1008 as described above. However, the header and the packet may be encrypted
1009 with same key. This is the case, for example, with command packets.
1013 3.8.2 Client To Client
1015 The process of message delivery and encryption from client to another
1016 client is as follows.
1018 Example: Private message from client to another client on different
1019 servers. Clients do not share private message delivery
1020 keys; normal session keys are used.
1022 o Client 1. sends encrypted packet to its server. The packet is
1023 encrypted with the session key shared between client and its
1026 o Server determines the destination of the packet and decrypts
1027 the packet. Server encrypts the packet with session key shared
1028 between the server and its router, and sends the packet to the
1031 o Router determines the destination of the packet and decrypts
1032 the packet. Router encrypts the packet with session key
1033 shared between the router and the destination server, and sends
1034 the packet to the server.
1036 o Server determines the client to which the packet is destined
1037 to and decrypts the packet. Server encrypts the packet with
1038 session key shared between the server and the destination client,
1039 and sends the packet to the client.
1041 o Client 2. decrypts the packet.
1044 Example: Private message from client to another client on different
1045 servers. Clients has established secret shared private
1046 message delivery key with each other and that is used in
1047 the message encryption.
1049 o Client 1. sends encrypted packet to its server. The packet is
1050 encrypted with the private message delivery key shared between
1053 o Server determines the destination of the packet and sends the
1054 packet to the router.
1056 o Router determines the destination of the packet and sends the
1057 packet to the server.
1059 o Server determines the client to which the packet is destined
1060 to and sends the packet to the client.
1062 o Client 2. decrypts the packet with the secret shared key.
1065 If clients share secret key with each other the private message
1066 delivery is much simpler since servers and routers between the
1067 clients do not need to decrypt and re-encrypt the packet.
1069 The process for clients on same server is much simpler as there are
1070 no need to send the packet to the router. The process for clients
1071 on different cells is same as above except that the packet is routed
1072 outside the cell. The router of the destination cell routes the
1073 packet to the destination same way as described above.
1077 3.8.3 Client To Channel
1079 Process of message delivery from client on channel to all the clients
1082 Example: Channel of four users; two on same server, other two on
1083 different cells. Client sends message to the channel.
1085 o Client 1. encrypts the packet with channel key and sends the
1086 packet to its server.
1088 o Server determines local clients on the channel and sends the
1089 packet to the Client on the same server. Server then sends
1090 the packet to its router for further routing.
1092 o Router determines local clients on the channel, if found
1093 sends packet to the local clients. Router determines global
1094 clients on the channel and sends the packet to its primary
1095 router or fastest route.
1097 o (Other router(s) do the same thing and sends the packet to
1100 o Server determines local clients on the channel and sends the
1101 packet to the client.
1103 o All clients receiving the packet decrypts the packet.
1107 3.8.4 Server To Server
1109 Server to server packet delivery and encryption is described in above
1110 examples. Router to router packet delivery is analogous to server to
1111 server. However, some packets, such as channel packets, are processed
1112 differently. These cases are described later in this document and
1113 more in detail in [SILC2].
1117 3.9 Key Exchange And Authentication
1119 Key exchange is done always when for example client connects to server
1120 but also when server and router, and router and router connects to each
1121 other. The purpose of key exchange protocol is to provide secure key
1122 material to be used in the communication. The key material is used to
1123 derive various security parameters used to secure SILC packets. The
1124 SILC Key Exchange protocol is described in detail in [SILC3].
1126 Authentication is done after key exchange protocol has been successfully
1127 completed. The purpose of authentication is to authenticate for example
1128 client connecting to the server. However, usually clients are accepted
1129 to connect to server without explicit authentication. Servers are
1130 required use authentication protocol when connecting. The authentication
1131 may be based on passphrase (pre-shared-secret) or public key. The
1132 connection authentication protocol is described in detail in [SILC3].
1136 3.9.1 Authentication Payload
1138 Authentication payload is used separately from the SKE and the Connection
1139 Authentication protocol. It is used during the session to authenticate
1140 with the remote. For example, the client can authenticate itself to the
1141 server to become server operator. In this case, Authentication Payload is
1154 The format of the Authentication Payload is as follows:
1160 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
1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1162 | Payload Length | Authentication Method |
1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1164 | Public Data Length | |
1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1170 | Authentication Data Length | |
1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
1173 ~ Authentication Data ~
1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1179 Figure 5: Authentication Payload
1183 o Payload Length (2 bytes) - Length of the entire payload.
1185 o Authentication Method (2) - The method of the authentication.
1186 The authentication methods are defined in [SILC2] in the
1187 Connection Auth Request Payload. The NONE authentication
1188 method SHOULD NOT be used.
1190 o Public Data Length (2 bytes) - Indicates the length of
1191 the Public Data field.
1193 o Public Data (variable length) - This is defined only if
1194 the authentication method is public key. If it is any other
1195 this field does not exist and the Public Data Length field
1198 When the authentication method is public key this includes
1199 128 to 4096 bytes of non-zero random data that is used in
1200 the signature process, described subsequently.
1202 o Authentication Data Length (2 bytes) - Indicates the
1203 length of the Authentication Data field.
1205 o Authentication Data (variable length) - Authentication
1206 method dependent authentication data.
1210 If the authentication method is password based, the Authentication
1211 Data field includes the plaintext password. It is safe to send
1212 plaintext password since the entire payload is encrypted. In this
1213 case the Public Data Length is set to zero (0).
1215 If the authentication method is public key based (or certificate)
1216 the Authentication Data is computed as follows:
1218 HASH = hash(random bytes | ID | public key (or certificate));
1219 Authentication Data = sign(HASH);
1221 The hash() and the sign() are the hash function and the public key
1222 cryptography function selected in the SKE protocol. The public key
1223 is SILC style public key unless certificates are used. The ID is the
1224 entity's ID (Client or Server ID) which is authenticating itself. The
1225 ID is raw ID data. The random bytes are non-zero random bytes of
1226 length between 128 and 4096 bytes, and will be included into the
1227 Public Data field as is.
1229 The receiver will compute the signature using the random data received
1230 in the payload, the ID associated to the connection and the public key
1231 (or certificate) received in the SKE protocol. After computing the
1232 receiver MUST verify the signature. In this case also, the entire
1233 payload is encrypted.
1239 This section defines all the allowed algorithms that can be used in
1240 the SILC protocol. This includes mandatory cipher, mandatory public
1241 key algorithm and MAC algorithms.
1247 Cipher is the encryption algorithm that is used to protect the data
1248 in the SILC packets. See [SILC2] of the actual encryption process and
1249 definition of how it must be done. SILC has a mandatory algorithm that
1250 must be supported in order to be compliant with this protocol.
1252 The following ciphers are defined in SILC protocol:
1255 aes-256-cbc AES in CBC mode, 256 bit key (REQUIRED)
1256 aes-192-cbc AES in CBC mode, 192 bit key (OPTIONAL)
1257 aes-128-cbc AES in CBC mode, 128 bit key (OPTIONAL)
1258 twofish-256-cbc Twofish in CBC mode, 256 bit key (OPTIONAL)
1259 twofish-192-cbc Twofish in CBC mode, 192 bit key (OPTIONAL)
1260 twofish-128-cbc Twofish in CBC mode, 128 bit key (OPTIONAL)
1261 blowfish-128-cbc Blowfish in CBC mode, 128 bit key (OPTIONAL)
1262 cast-256-cbc CAST-256 in CBC mode, 256 bit key (OPTIONAL)
1263 cast-192-cbc CAST-256 in CBC mode, 192 bit key (OPTIONAL)
1264 cast-128-cbc CAST-256 in CBC mode, 128 bit key (OPTIONAL)
1265 rc6-256-cbc RC6 in CBC mode, 256 bit key (OPTIONAL)
1266 rc6-192-cbc RC6 in CBC mode, 192 bit key (OPTIONAL)
1267 rc6-128-cbc RC6 in CBC mode, 128 bit key (OPTIONAL)
1268 mars-256-cbc Mars in CBC mode, 256 bit key (OPTIONAL)
1269 mars-192-cbc Mars in CBC mode, 192 bit key (OPTIONAL)
1270 mars-128-cbc Mars in CBC mode, 128 bit key (OPTIONAL)
1271 none No encryption (OPTIONAL)
1275 Algorithm none does not perform any encryption process at all and
1276 thus is not recommended to be used. It is recommended that no client
1277 or server implementation would accept none algorithms except in special
1280 Additional ciphers MAY be defined to be used in SILC by using the
1281 same name format as above.
1285 3.10.2 Public Key Algorithms
1287 Public keys are used in SILC to authenticate entities in SILC network
1288 and to perform other tasks related to public key cryptography. The
1289 public keys are also used in the SILC Key Exchange protocol [SILC3].
1291 The following public key algorithms are defined in SILC protocol:
1298 DSS is described in [Menezes]. The RSA MUST be implemented according
1299 PKCS #1 [PKCS1]. The mandatory PKCS #1 implementation in SILC MUST be
1300 compliant to either PKCS #1 version 1.5 or newer with the following
1301 notes: The signature encoding is always in same format as the encryption
1302 encoding regardless of the PKCS #1 version. The signature with appendix
1303 (with hash algorithm OID in the data) MUST NOT be used in the SILC. The
1304 rationale for this is that there is no binding between the PKCS #1 OIDs
1305 and the hash algorithms used in the SILC protocol. Hence, the encoding
1306 is always in PKCS #1 version 1.5 format.
1308 Additional public key algorithms MAY be defined to be used in SILC.
1314 3.10.3 Hash Functions
1316 Hash functions are used as part of MAC algorithms defined in the next
1317 section. They are also used in the SILC Key Exchange protocol defined
1320 The following Hash algorithm are defined in SILC protocol:
1323 sha1 SHA-1, length = 20 (REQUIRED)
1324 md5 MD5, length = 16 (OPTIONAL)
1329 3.10.4 MAC Algorithms
1331 Data integrity is protected by computing a message authentication code
1332 (MAC) of the packet data. See [SILC2] for details how to compute the
1335 The following MAC algorithms are defined in SILC protocol:
1338 hmac-sha1-96 HMAC-SHA1, length = 12 (REQUIRED)
1339 hmac-md5-96 HMAC-MD5, length = 12 (OPTIONAL)
1340 hmac-sha1 HMAC-SHA1, length = 20 (OPTIONAL)
1341 hmac-md5 HMAC-MD5, length = 16 (OPTIONAL)
1342 none No MAC (OPTIONAL)
1345 The none MAC is not recommended to be used as the packet is not
1346 authenticated when MAC is not computed. It is recommended that no
1347 client or server would accept none MAC except in special debugging
1350 The HMAC algorithm is described in [HMAC] and hash algorithms that
1351 are used as part of the HMACs are described in [Scheneir] and in
1354 Additional MAC algorithms MAY be defined to be used in SILC.
1358 3.10.5 Compression Algorithms
1360 SILC protocol supports compression that may be applied to unencrypted
1361 data. It is recommended to use compression on slow links as it may
1362 significantly speed up the data transmission. By default, SILC does not
1363 use compression which is the mode that must be supported by all SILC
1368 The following compression algorithms are defined:
1371 none No compression (REQUIRED)
1372 zlib GNU ZLIB (LZ77) compression (OPTIONAL)
1375 Additional compression algorithms MAY be defined to be used in SILC.
1379 3.11 SILC Public Key
1381 This section defines the type and format of the SILC public key. All
1382 implementations MUST support this public key type. See [SILC3] for
1383 other optional public key and certificate types allowed in the SILC
1384 protocol. Public keys in SILC may be used to authenticate entities
1385 and to perform other tasks related to public key cryptography.
1387 The format of the SILC Public Key is as follows:
1393 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
1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1395 | Public Key Length |
1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1397 | Algorithm Name Length | |
1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1403 | Identifier Length | |
1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1416 Figure 5: SILC Public Key
1420 o Public Key Length (4 bytes) - Indicates the full length
1421 of the public key, not including this field.
1423 o Algorithm Name Length (2 bytes) - Indicates the length
1424 of the Algorithm Length field, not including this field.
1426 o Algorithm name (variable length) - Indicates the name
1427 of the public key algorithm that the key is. See the
1428 section 3.10.2 Public Key Algorithms for defined names.
1430 o Identifier Length (2 bytes) - Indicates the length of
1431 the Identifier field, not including this field.
1433 o Identifier (variable length) - Indicates the identifier
1434 of the public key. This data can be used to identify
1435 the owner of the key. The identifier is of the following
1439 HN Host name or IP address
1446 Examples of an identifier:
1448 `UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi'
1450 `UN=sam, HN=dummy.fi, RN=Sammy Sam, O=Company XYZ, C=Finland'
1452 At least user name (UN) and host name (HN) MUST be provided as
1453 identifier. The fields are separated by commas (`,'). If
1454 comma is in the identifier string it must be written as `\\,',
1455 for example, `O=Company XYZ\\, Inc.'.
1457 o Public Data (variable length) - Includes the actual
1458 public data of the public key.
1460 The format of this field for RSA algorithm is
1469 The format of this field for DSS algorithm is
1481 The variable length fields are multiple precession
1482 integers encoded as strings in both examples.
1484 Other algorithms must define their own type of this
1485 field if they are used.
1488 All fields in the public key are in MSB (most significant byte first)
1493 3.12 SILC Version Detection
1495 The version detection of both client and server is performed at the
1496 connection phase while executing the SILC Key Exchange protocol. The
1497 version identifier is exchanged between initiator and responder. The
1498 version identifier is of the following format:
1501 SILC-<protocol version>-<software version>
1504 The version strings are of the following format:
1507 protocol version = <major>.<minor>
1508 software version = <major>[.<minor>[.<build>]]
1511 Protocol version MAY provide both major and minor version. Currently
1512 implementations MUST set the protocol version and accept the protocol
1513 version as SILC-1.0-<software version>.
1515 Software version MAY provide major, minor and build version. The
1516 software version MAY be freely set and accepted.
1519 Thus, the version string could be, for example:
1531 This section describes various SILC procedures such as how the
1532 connections are created and registered, how channels are created and
1533 so on. The section describes the procedures only generally as details
1534 are described in [SILC2] and [SILC3].
1538 4.1 Creating Client Connection
1540 This section describes the procedure when client connects to SILC server.
1541 When client connects to server the server MUST perform IP address lookup
1542 and reverse IP address lookup to assure that the origin host really is
1543 who it claims to be. Client, host, connecting to server SHOULD have
1544 both valid IP address and fully qualified domain name (FQDN).
1546 After that the client and server performs SILC Key Exchange protocol
1547 which will provide the key material used later in the communication.
1548 The key exchange protocol MUST be completed successfully before the
1549 connection registration may continue. The SILC Key Exchange protocol
1550 is described in [SILC3].
1552 Typical server implementation would keep a list of connections that it
1553 allows to connect to the server. The implementation would check, for
1554 example, the connecting client's IP address from the connection list
1555 before the SILC Key Exchange protocol has been started. Reason for
1556 this is that if the host is not allowed to connect to the server there
1557 is no reason to perform the key exchange protocol.
1559 After successful key exchange protocol the client and server performs
1560 connection authentication protocol. The purpose of the protocol is to
1561 authenticate the client connecting to the server. Flexible
1562 implementation could also accept the client to connect to the server
1563 without explicit authentication. However, if authentication is
1564 desired for a specific client it may be based on passphrase or
1565 public key authentication. If authentication fails the connection
1566 MUST be terminated. The connection authentication protocol is described
1569 After successful key exchange and authentication protocol the client
1570 registers itself by sending SILC_PACKET_NEW_CLIENT packet to the
1571 server. This packet includes various information about the client
1572 that the server uses to create the client. Server creates the client
1573 and sends SILC_PACKET_NEW_ID to the client which includes the created
1574 Client ID that the client MUST start using after that. After that
1575 all SILC packets from the client MUST have the Client ID as the
1576 Source ID in the SILC Packet Header, described in [SILC2].
1578 Client MUST also get the server's Server ID that is to be used as
1579 Destination ID in the SILC Packet Header when communicating with
1580 the server (for example when sending commands to the server). The
1581 ID may be resolved in two ways. Client can take the ID from an
1582 previously received packet from server that MUST include the ID,
1583 or to send SILC_COMMAND_INFO command and receive the Server ID as
1586 Server MAY choose not to use the information received in the
1587 SILC_PACKET_NEW_CLIENT packet. For example, if public key or
1588 certificate were used in the authentication, server MAY use those
1589 informations rather than what it received from client. This is suitable
1590 way to get the true information about client if it is available.
1592 The nickname of client is initially set to the username sent in the
1593 SILC_PACKET_NEW_CLIENT packet. User should set the nickname to more
1594 suitable by sending SILC_COMMAND_NICK command. However, this is not
1595 required as part of registration process.
1597 Server MUST also distribute the information about newly registered
1598 client to its router (or if the server is router, to all routers in
1599 the SILC network). More information about this in [SILC2].
1603 4.2 Creating Server Connection
1605 This section describes the procedure when server connects to its
1606 router (or when router connects to other router, the cases are
1607 equivalent). The procedure is very much alike when client connects
1608 to the server thus it is not repeated here.
1610 One difference is that server MUST perform connection authentication
1611 protocol with proper authentication. A proper authentication is based
1612 on passphrase or public key authentication.
1614 After server and router has successfully performed the key exchange
1615 and connection authentication protocol, the server register itself
1616 to the router by sending SILC_PACKET_NEW_SERVER packet. This packet
1617 includes the server's Server ID that it has created by itself and
1618 other relevant information about the server.
1620 After router has received the SILC_PACKET_NEW_SERVER packet it
1621 distributes the information about newly registered server to all routers
1622 in the SILC network. More information about this in [SILC2].
1624 As client needed to resolve the destination ID this MUST be done by the
1625 server that connected to the router, as well. The way to resolve it is
1626 to get the ID from previously received packet. The server MAY also
1627 use SILC_COMMAND_INFO command to resolve the ID. Server MUST also start
1628 using its own Server ID as Source ID in SILC Packet Header and the
1629 router's Server ID as Destination when communicating with the router.
1633 4.2.1 Announcing Clients, Channels and Servers
1635 After server or router has connected to the remote router, and it already
1636 has connected clients and channels it MUST announce them to the router.
1637 If the server is router server, also all the local servers in the cell
1640 All clients are announced by compiling a list of ID Payloads into the
1641 SILC_PACKET_NEW_ID packet. All channels are announced by compiling a
1642 list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet. Also,
1643 the channel users on the channels must be announced by compiling a
1644 list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into
1645 the SILC_PACKET_NOTIFY packet.
1647 The router MUST also announce the local servers by compiling list of
1648 ID Payloads into the SILC_PACKET_NEW_ID packet.
1650 The router which receives these lists MUST process them and broadcast
1651 the packets to its primary route.
1653 When processing the announced channels and channel users the router MUST
1654 check whether a channel exists already with the same name. If channel
1655 exists with the same name it MUST check whether the Channel ID is
1656 different. If the Channel ID is different the router MUST send the notify
1657 type SILC_NOTIFY_TYPE_CHANNEL_CHANGE to the server to force the channel ID
1658 change to the ID the router has. If the mode of the channel is different
1659 the router MUST send the notify type SILC_NOTIFY_TYPE_CMODE_CHANGE to the
1660 server to force the mode change to the mode that the router has.
1662 The router MUST also generate new channel key and distribute it to the
1663 channel. The key MUST NOT be generated if the SILC_CMODE_PRIVKEY mode
1666 If the channel has channel founder on the router the router MUST send
1667 the notify type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server to force
1668 the mode change for the channel founder on the server. The channel
1669 founder privileges MUST be removed.
1671 The router processing the channels MUST also compile a list of
1672 Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into the
1673 SILC_PACKET_NOTIFY and send the packet to the server. This way the
1674 server (or router) will receive the clients on the channel that
1679 4.3 Joining to a Channel
1681 This section describes the procedure when client joins to a channel.
1682 Client joins to channel by sending command SILC_COMMAND_JOIN to the
1683 server. If the receiver receiving join command is normal server the
1684 server MUST check its local list whether this channel already exists
1685 locally. This would indicate that some client connected to the server
1686 has already joined to the channel. If this is case the client is
1687 joined to the channel, new channel key is created and information about
1688 newly joined channel is sent to the router. The router is informed
1689 by sending SILC_NOTIFY_TYPE_JOIN notify type. The notify type MUST
1690 also be sent to the local clients on the channel. The new channel key
1691 is also sent to the router and to local clients on the channel.
1693 If the channel does not exist in the local list the client's command
1694 MUST be sent to the router which will then perform the actual joining
1695 procedure. When server receives the reply to the command from the
1696 router it MUST be sent to the client which sent the command originally.
1697 Server will also receive the channel key from the server that it MUST
1698 send to the client which originally requested the join command. The
1699 server MUST also save the channel key.
1701 If the receiver of the join command is router it MUST first check its
1702 local list whether anyone in the cell has already joined to the channel.
1703 If this is the case the client is joined to the channel and reply is
1704 sent to the client. If the command was sent by server the command reply
1705 is sent to the server which sent it. Then the router MUST also create
1706 new channel key and distribute it to all clients on the channel and
1707 all servers that has clients on the channel. Router MUST also send
1708 the SILC_NOTIFY_TYPE_JOIN notify type to local clients on the channel
1709 and to local servers that has clients on the channel.
1711 If the channel does not exist on the router's local list it MUST
1712 check the global list whether the channel exists at all. If it does
1713 the client is joined to the channel as described previously. If
1714 the channel does not exist the channel is created and the client
1715 is joined to the channel. The channel key is also created and
1716 distributed as previously described. The client joining to the created
1717 channel is made automatically channel founder and both channel founder
1718 and channel operator privileges is set for the client.
1720 If the router created the channel in the process, information about the
1721 new channel MUST be broadcasted to all routers. This is done by
1722 broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary
1723 route. When the router joins the client to the channel it MUST also
1724 send information about newly joined client to all routers in the SILC
1725 network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify
1726 type to the router's primary route.
1728 It is important to note that new channel key is created always when
1729 new client joins to channel, whether the channel has existed previously
1730 or not. This way the new client on the channel is not able to decrypt
1731 any of the old traffic on the channel. Client which receives the reply to
1732 the join command MUST start using the received Channel ID in the channel
1733 message communication thereafter. Client also receives the key for the
1734 channel in the command reply. Note that the channel key is never
1735 generated if the SILC_CMODE_PRIVKEY mode is set.
1739 4.4 Channel Key Generation
1741 Channel keys are created by router which creates the channel by taking
1742 enough randomness from cryptographically strong random number generator.
1743 The key is generated always when channel is created, when new client
1744 joins a channel and after the key has expired. Key could expire for
1747 The key MUST also be re-generated whenever some client leaves a channel.
1748 In this case the key is created from scratch by taking enough randomness
1749 from the random number generator. After that the key is distributed to
1750 all clients on the channel. However, channel keys are cell specific thus
1751 the key is created only on the cell where the client, which left the
1752 channel, exists. While the server or router is creating the new channel
1753 key, no other client may join to the channel. Messages that are sent
1754 while creating the new key are still processed with the old key. After
1755 server has sent the SILC_PACKET_CHANNEL_KEY packet MUST client start
1756 using the new key. If server creates the new key the server MUST also
1757 send the new key to its router. See [SILC2] on more information about
1758 how channel messages must be encrypted and decrypted when router is
1761 When client receives the SILC_PACKET_CHANNEL_KEY packet with the
1762 Channel Key Payload it MUST process the key data to create encryption
1763 and decryption key, and to create the HMAC key that is used to compute
1764 the MACs of the channel messages. The processing is as follows:
1766 channel_key = raw key data
1767 HMAC key = hash(raw key data)
1769 The raw key data is the key data received in the Channel Key Payload.
1770 The hash() function is the hash function used in the HMAC of the channel.
1771 Note that the server MUST also save the channel key.
1775 4.5 Private Message Sending and Reception
1777 Private messages are sent point to point. Client explicitly destines
1778 a private message to specific client that is delivered to only to that
1779 client. No other client may receive the private message. The receiver
1780 of the private message is destined in the SILC Packet Header as any
1781 other packet as well.
1783 If the sender of a private message does not know the receiver's Client
1784 ID, it MUST resolve it from server. There are two ways to resolve the
1785 client ID from server; it is RECOMMENDED that client implementations
1786 send SILC_COMMAND_IDENTIFY command to receive the Client ID. Client
1787 MAY also send SILC_COMMAND_WHOIS command to receive the Client ID.
1788 If the sender has received earlier a private message from the receiver
1789 it should have cached the Client ID from the SILC Packet Header.
1791 See [SILC2] for description of private message encryption and decryption
1796 4.6 Private Message Key Generation
1798 Private message MAY be protected by the key generated by the client.
1799 The key may be generated and sent to the other client by sending packet
1800 SILC_PACKET_PRIVATE_MESSAGE_KEY which travels through the network
1801 and is secured by session keys. After that the private message key
1802 is used in the private message communication between those clients.
1804 Other choice is to entirely use keys that are not sent through
1805 the SILC network at all. This significantly adds security. This key
1806 would be pre-shared-key that is known by both of the clients. Both
1807 agree about using the key and starts sending packets that indicate
1808 that the private message is secured using private message key.
1810 The key material used as private message key is implementation issue.
1811 However, SILC_PACKET_KEY_AGREEMENT packet MAY be used to negotiate
1812 the key material. If the key is normal pre-shared-key or randomly
1813 generated key, and the SILC_PACKET_KEY_AGREEMENT was not used, then
1814 the key material SHOULD be processed as defined in the [SILC3]. In
1815 the processing, however, the HASH, as defined in [SILC3] MUST be
1816 ignored. After processing the key material it is employed as defined
1817 in [SILC3], however, the HMAC key material MUST be discarded.
1819 If the key is pre-shared-key or randomly generated the implementations
1820 should use the SILC protocol's mandatory cipher as the cipher. If the
1821 SKE was used to negotiate key material the cipher was negotiated as well.
1824 4.7 Channel Message Sending and Reception
1826 Channel messages are delivered to group of users. The group forms a
1827 channel and all clients on the channel receives messages sent to the
1830 Channel messages are destined to channel by specifying the Channel ID
1831 as Destination ID in the SILC Packet Header. The server MUST then
1832 distribute the message to all clients on the channel by sending the
1833 channel message destined explicitly to a client on the channel.
1835 See [SILC2] for description of channel message encryption and decryption
1840 4.8 Session Key Regeneration
1842 Session keys MUST be regenerated periodically, say, once in an hour.
1843 The re-key process is started by sending SILC_PACKET_REKEY packet to
1844 other end, to indicate that re-key must be performed. The initiator
1845 of the connection SHOULD initiate the re-key.
1847 If perfect forward secrecy (PFS) flag was selected in the SILC Key
1848 Exchange protocol [SILC3] the re-key MUST cause new key exchange with
1849 SKE protocol. In this case the protocol is secured with the old key
1850 and the protocol results to new key material. See [SILC3] for more
1851 information. After the SILC_PACKET_REKEY packet is sent the sender
1852 will perform the SKE protocol.
1854 If PFS flag was set the resulted key material is processed as described
1855 in the section Processing the Key Material in [SILC3]. The difference
1856 with re-key in the processing is that the initial data for the hash
1857 function is just the resulted key material and not the HASH as it
1858 is not computed at all with re-key. Other than that, the key processing
1859 it equivalent to normal SKE negotiation.
1861 If PFS flag was not set, which is the default case, then re-key is done
1862 without executing SKE protocol. In this case, the new key is created by
1863 providing the current sending encryption key to the SKE protocol's key
1864 processing function. The process is described in the section Processing
1865 the Key Material in [SILC3]. The difference in the processing is that
1866 the initial data for the hash function is the current sending encryption
1867 key and not the SKE's KEY and HASH values. Other than that, the key
1868 processing is equivalent to normal SKE negotiation.
1870 After both parties has regenerated the session key, both MUST send
1871 SILC_PACKET_REKEY_DONE packet to each other. These packets are still
1872 secured with the old key. After these packets, the subsequent packets
1873 MUST be protected with the new key.
1879 4.9 Command Sending and Reception
1881 Client usually sends the commands in the SILC network. In this case
1882 the client simply sends the command packet to server and the server
1883 processes it and replies with command reply packet.
1885 However, if the server is not able to process the command, it is sent
1886 to the server's router. This is case for example with commands such
1887 as, SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there
1888 are other commands as well. For example, if client sends the WHOIS
1889 command requesting specific information about some client the server must
1890 send the WHOIS command to router so that all clients in SILC network
1891 are searched. The router, on the other hand, sends the WHOIS command
1892 further to receive the exact information about the requested client.
1893 The WHOIS command travels all the way to the server which owns the client
1894 and it replies with command reply packet. Finally, the server which
1895 sent the command receives the command reply and it must be able to
1896 determine which client sent the original command. The server then
1897 sends command reply to the client. Implementations should have some
1898 kind of cache to handle, for example, WHOIS information. Servers
1899 and routers along the route could all cache the information for faster
1900 referencing in the future.
1902 The commands sent by server may be sent hop by hop until someone is able
1903 to process the command. However, it is preferred to destine the command
1904 as precisely as it is possible. In this case, other routers en route
1905 MUST route the command packet by checking the true sender and true
1906 destination of the packet. However, servers and routers MUST NOT route
1907 command reply packets to clients coming from other server. Client
1908 MUST NOT accept command reply packet originated from anyone else but
1909 from its own server.
1913 4.10 Closing Connection
1915 When remote client connection is closed the server MUST send the notify
1916 type SILC_NOTIFY_TYPE_SIGNOFF to its primary router and to all channels
1917 the client was joined. The server MUST also save the client's information
1918 for a period of time for history purposes.
1920 When remote server or router connection is closed the server or router
1921 MUST also remove all the clients that was behind the server or router
1922 from the SILC Network. The server or router MUST also send the notify
1923 type SILC_NOTIFY_TYPE_SERVER_SIGNOFF to its primary router and to all
1924 local clients that are joined on the same channels with the remote
1925 server's or router's clients.
1929 5 Security Considerations
1931 Security is central to the design of this protocol, and these security
1932 considerations permeate the specification. Common security considerations
1933 such as keeping private keys truly private and using adequate lengths for
1934 symmetric and asymmetric keys must be followed in order to maintain the
1935 security of this protocol.
1937 Special attention must also be paid on the servers and routers that are
1938 running the SILC service. The SILC protocol's security depends greatly
1939 on the security and the integrity of the servers and administrators that
1940 are running the service. It is recommended that some form of registration
1941 is required by the server and router administrator prior acceptance to
1942 the SILC Network. The clients must be able to trust the servers they
1945 It is also recommended that router operators in the SILC Network would
1946 form a joint forum to discuss the router and SILC Network management
1947 issues. Also, router operators along with the cell's server operators
1948 should have a forum to discuss the cell management issues.
1954 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
1957 [SILC3] Riikonen, P., "SILC Key Exchange and Authentication
1958 Protocols", Internet Draft, April 2001.
1960 [SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001.
1962 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
1965 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
1968 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
1971 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
1974 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
1977 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
1980 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
1983 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
1986 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
1987 Infrastructure, Certificate and CRL Profile", RFC 2459,
1990 [Schneier] Schneier, B., "Applied Cryptography Second Edition",
1991 John Wiley & Sons, New York, NY, 1996.
1993 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
1996 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
1997 RFC 2412, November 1998.
1999 [ISAKMP] Maughan D., et al, "Internet Security Association and
2000 Key Management Protocol (ISAKMP)", RFC 2408, November
2003 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
2004 (IKE)", RFC 2409, November 1998.
2006 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
2007 Authentication", RFC 2104, February 1997.
2009 [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
2010 Specifications, Version 2.0", RFC 2437, October 1998.
2012 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
2013 Requirement Levels", BCP 14, RFC 2119, March 1997.
2025 EMail: priikone@poseidon.pspt.fi
2027 This Internet-Draft expires 26 October 2001