idnits 2.17.1 draft-riikonen-silc-spec-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2666. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 575 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([SILC2], [SILC3], [SILC4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1391 has weird spacing: '... length e...' == Line 1393 has weird spacing: '... length n...' == Line 1399 has weird spacing: '... length p...' == Line 1401 has weird spacing: '... length q...' == Line 1403 has weird spacing: '... length g...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (15 January 2007) is 6309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3269' is mentioned on line 1467, but not defined == Unused Reference: 'IRC-ARCH' is defined on line 2425, but no explicit reference was found in the text == Unused Reference: 'IRC-CHAN' is defined on line 2428, but no explicit reference was found in the text == Unused Reference: 'IRC-CLIENT' is defined on line 2431, but no explicit reference was found in the text == Unused Reference: 'IRC-SERVER' is defined on line 2434, but no explicit reference was found in the text == Unused Reference: 'SPKI' is defined on line 2443, but no explicit reference was found in the text == Unused Reference: 'PKIX-Part1' is defined on line 2446, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 2450, but no explicit reference was found in the text == Unused Reference: 'OAKLEY' is defined on line 2456, but no explicit reference was found in the text == Unused Reference: 'ISAKMP' is defined on line 2459, but no explicit reference was found in the text == Unused Reference: 'IKE' is defined on line 2463, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SILC2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SILC3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SILC4' ** Downref: Normative reference to an Experimental RFC: RFC 1459 (ref. 'IRC') ** Downref: Normative reference to an Informational RFC: RFC 2810 (ref. 'IRC-ARCH') ** Downref: Normative reference to an Informational RFC: RFC 2811 (ref. 'IRC-CHAN') ** Downref: Normative reference to an Informational RFC: RFC 2812 (ref. 'IRC-CLIENT') ** Downref: Normative reference to an Informational RFC: RFC 2813 (ref. 'IRC-SERVER') -- Possible downref: Non-RFC (?) normative reference: ref. 'SSH-TRANS' ** Obsolete normative reference: RFC 2440 (ref. 'PGP') (Obsoleted by RFC 4880) ** Downref: Normative reference to an Experimental RFC: RFC 2693 (ref. 'SPKI') ** Obsolete normative reference: RFC 2459 (ref. 'PKIX-Part1') (Obsoleted by RFC 3280) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'Menezes' ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'OAKLEY') ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2437 (ref. 'PKCS1') (Obsoleted by RFC 3447) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS7') ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4634 (ref. 'SHA256') (Obsoleted by RFC 6234) Summary: 29 errors (**), 0 flaws (~~), 20 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Riikonen 3 Internet-Draft 4 draft-riikonen-silc-spec-09.txt 15 January 2007 5 Expires: 15 July 2007 7 Secure Internet Live Conferencing (SILC), 8 Protocol Specification 9 11 Status of this Draft 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memo describes a Secure Internet Live Conferencing (SILC) 34 protocol which provides secure conferencing services over insecure 35 network channel. SILC provides advanced and feature rich conferencing 36 services with security as main design principal. Strong cryptographic 37 methods are used to protect SILC packets inside the SILC network. 38 Three other specifications relates very closely to this memo; 39 SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication 40 Protocols [SILC3] and SILC Commands [SILC4]. 42 Table of Contents 44 1 Introduction .................................................. 3 45 1.1 Requirements Terminology .................................. 4 46 2 SILC Concepts ................................................. 4 47 2.1 SILC Network Topology ..................................... 5 48 2.2 Communication Inside a Cell ............................... 6 49 2.3 Communication in the Network .............................. 7 50 2.4 Channel Communication ..................................... 7 51 2.5 Router Connections ........................................ 8 52 3 SILC Specification ............................................ 9 53 3.1 Client .................................................... 9 54 3.1.1 Client ID ........................................... 10 55 3.2 Server .................................................... 11 56 3.2.1 Server's Local ID List .............................. 11 57 3.2.2 Server ID ........................................... 12 58 3.2.3 SILC Server Ports ................................... 12 59 3.3 Router .................................................... 13 60 3.3.1 Router's Local ID List .............................. 13 61 3.3.2 Router's Global ID List ............................. 14 62 3.3.3 Router's Server ID .................................. 15 63 3.4 Channels .................................................. 15 64 3.4.1 Channel ID .......................................... 16 65 3.5 Operators ................................................. 17 66 3.6 SILC Commands ............................................. 17 67 3.7 SILC Packets .............................................. 17 68 3.8 Packet Encryption ......................................... 18 69 3.8.1 Determination of the Source and the Destination ..... 18 70 3.8.2 Client To Client .................................... 19 71 3.8.3 Client To Channel ................................... 20 72 3.8.4 Server To Server .................................... 21 73 3.9 Key Exchange And Authentication ........................... 21 74 3.9.1 Authentication Payload .............................. 22 75 3.10 Algorithms ............................................... 24 76 3.10.1 Ciphers ............................................ 24 77 3.10.1.1 CBC Mode .................................. 24 78 3.10.1.2 CTR Mode .................................. 25 79 3.10.1.3 Randomized CBC Mode ....................... 27 80 3.10.2 Public Key Algorithms .............................. 27 81 3.10.2.1 Multi-Precision Integers .................. 28 82 3.10.3 Hash Functions ..................................... 28 83 3.10.4 MAC Algorithms ..................................... 28 84 3.10.5 Compression Algorithms ............................. 29 85 3.11 SILC Public Key .......................................... 29 86 3.12 SILC Version Detection ................................... 32 87 3.13 UTF-8 Strings in SILC .................................... 33 88 3.13.1 UTF-8 Identifier Strings ........................... 33 89 3.14 Backup Routers ........................................... 34 90 3.14.1 Switching to Backup Router ......................... 36 91 3.14.2 Resuming Primary Router ............................ 37 92 4 SILC Procedures ............................................... 39 93 4.1 Creating Client Connection ................................ 39 94 4.2 Creating Server Connection ................................ 41 95 4.2.1 Announcing Clients, Channels and Servers ............ 42 96 4.3 Joining to a Channel ...................................... 43 97 4.4 Channel Key Generation .................................... 44 98 4.5 Private Message Sending and Reception ..................... 45 99 4.6 Private Message Key Generation ............................ 46 100 4.7 Channel Message Sending and Reception ..................... 47 101 4.8 Session Key Regeneration .................................. 47 102 4.9 Command Sending and Reception ............................. 48 103 4.10 Closing Connection ....................................... 49 104 4.11 Detaching and Resuming a Session ......................... 49 105 4.12 UDP/IP Connections ...................................... 51 106 5 Security Considerations ....................................... 52 107 6 References .................................................... 53 108 7 Author's Address .............................................. 55 109 Appendix A ...................................................... 55 110 Appendix B ...................................................... 56 111 Appendix C ...................................................... 57 112 Appendix D ...................................................... 57 113 Full Copyright Statement ........................................ 58 115 List of Figures 117 Figure 1: SILC Network Topology 118 Figure 2: Communication Inside cell 119 Figure 3: Communication Between Cells 120 Figure 4: Router Connections 121 Figure 5: SILC Public Key 122 Figure 6: Counter Block 123 Figure 7: CTR Mode Initialization Vector 125 1. Introduction 127 This document describes a Secure Internet Live Conferencing (SILC) 128 protocol which provides secure conferencing services over insecure 129 network channel. SILC can be used as a secure conferencing service 130 that provides rich conferencing features. Some of the SILC features 131 are found in traditional chat protocols such as IRC [IRC] but many 132 of the SILC features can also be found in Instant Message (IM) style 133 protocols. SILC combines features from both of these chat protocol 134 styles, and can be implemented as either IRC-like system or IM-like 135 system. Some of the more advanced and secure features of the 136 protocol are new to all conferencing protocols. SILC also supports 137 multimedia messages and can also be implemented as a video and audio 138 conferencing system. 140 Strong cryptographic methods are used to protect SILC packets inside 141 the SILC network. Three other specifications relates very closely 142 to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and 143 Authentication Protocols [SILC3] and SILC Commands [SILC4]. 145 The protocol uses extensively packets as conferencing protocol 146 requires message and command sending. The SILC Packet Protocol is 147 described in [SILC2] and should be read to fully comprehend this 148 document and protocol. [SILC2] also describes the packet encryption 149 and decryption in detail. The SILC Packet Protocol provides secured 150 and authenticated packets, and the protocol is designed to be compact. 151 This makes SILC also suitable in environment of low bandwidth 152 requirements such as mobile networks. All packet payloads in SILC 153 can be also compressed. 155 The security of SILC protocol sessions are based on strong and secure 156 key exchange protocol. The SILC Key Exchange protocol is described 157 in [SILC3] along with connection authentication protocol and should 158 be read to fully comprehend this document and protocol. 160 The SILC protocol has been developed to work on both TCP/IP and UDP/IP 161 network protocols. However, typical implementation would use only TCP/IP 162 with SILC protocol. Typical implementation would be made in client-server 163 model. 165 1.1 Requirements Terminology 167 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, 168 MAY, and OPTIONAL, when they appear in this document, are to be 169 interpreted as described in [RFC2119]. 171 2. SILC Concepts 173 This section describes various SILC protocol concepts that forms the 174 actual protocol, and in the end, the actual SILC network. The mission 175 of the protocol is to deliver messages from clients to other clients 176 through servers and routers in secure manner. The messages may also 177 be delivered from one client to many clients forming a group, also 178 known as a channel. 180 This section does not focus to security issues. Instead, basic network 181 concepts are introduced to make the topology of the SILC network 182 clear. 184 2.1 SILC Network Topology 186 SILC network forms a ring as opposed to tree style network topology that 187 conferencing protocols usually have. The network has a cells which are 188 constructed from a router and zero or more servers. The servers are 189 connected to the router in a star like network topology. Routers in the 190 network are connected to each other forming a ring. The rationale for 191 this is to have servers that can perform specific kind of tasks what 192 other servers cannot perform. This leads to two kinds of servers; normal 193 SILC servers and SILC router servers. 195 A difference between normal server and router server is that routers 196 knows all global information and keep the global network state up to date. 197 They also do the actual routing of the messages to the correct receiver 198 within the cell and between other cells. Normal servers knows only local 199 information and receive global information only when it is needed. They do 200 not need to keep the global network state up to date. This makes the 201 network faster and scalable as there are less servers that needs to 202 maintain global network state. 204 This, on the other hand, leads into a cellular like network, where 205 routers are in the center of the cell and servers are connected to the 206 router. 208 The following diagram represents SILC network topology. 210 ---- ---- ---- ---- ---- ---- 211 | S8 | S5 | S4 | | S7 | S5 | S6 | 212 ----- ---- ----- ----- ---- ----- 213 | S7 | S/R1 | S2 | --- | S8 | S/R2 | S4 | 214 ---- ------ ---- ---- ------ ---- 215 | S6 | S3 | S1 | | S1 | S3 | S2 | ---- ---- 216 ---- ---- ---- ---- ---- ---- | S3 | S1 | 217 Cell 1. \ Cell 2. | \____ ----- ----- 218 | | | S4 | S/R4 | 219 ---- ---- ---- ---- ---- ---- ---- ------ 220 | S7 | S4 | S2 | | S1 | S3 | S2 | | S2 | S5 | 221 ----- ---- ----- ----- ---- ----- ---- ---- 222 | S6 | S/R3 | S1 | --- | S4 | S/R5 | S5 | ____/ Cell 4. 223 ---- ------ ---- ---- ------ ---- 224 | S8 | S5 | S3 | | S6 | S7 | S8 | ... etc ... 225 ---- ---- ---- ---- ---- ---- 226 Cell 3. Cell 5. 228 Figure 1: SILC Network Topology 230 A cell is formed when a server or servers connect to one router. In 231 SILC network normal server cannot directly connect to other normal 232 server. Normal server may only connect to SILC router which then 233 routes the messages to the other servers in the cell. Router servers 234 on the other hand may connect to other routers to form the actual SILC 235 network, as seen in above figure. However, router is also able to act 236 as normal SILC server; clients may connect to it the same way as to 237 normal SILC server. This, however is not a requirement and if needed 238 router servers may be hidden from users by not allowing direct client 239 connections. Normal server also cannot have active connections to more 240 than one router. Normal server cannot be connected to two different 241 cells. Router servers, on the other hand, may have as many router to 242 router connections as needed. Other direct routes between other routers 243 is also possible in addition of the mandatory ring connections. This 244 leads into a hybrid ring-mesh network topology. 246 There are many issues in this network topology that needs to be careful 247 about. Issues like routing, the size of the cells, the number of the 248 routers in the SILC network and the capacity requirements of the 249 routers. These issues should be discussed in the Internet Community 250 and additional documents on the issue may be written. 252 2.2 Communication Inside a Cell 254 It is always guaranteed that inside a cell message is delivered to the 255 recipient with at most two server hops. A client which is connected to 256 server in the cell and is talking on channel to other client connected 257 to other server in the same cell, will have its messages delivered from 258 its local server first to the router of the cell, and from the router 259 to the other server in the cell. 261 The following diagram represents this scenario: 263 1 --- S1 S4 --- 5 264 S/R 265 2 -- S2 S3 266 / | 267 4 3 269 Figure 2: Communication Inside cell 271 Example: Client 1. connected to Server 1. send message to 272 Client 4. connected to Server 2. travels from Server 1. 273 first to Router which routes the message to Server 2. 274 which then sends it to the Client 4. All the other 275 servers in the cell will not see the routed message. 277 If the client is connected directly to the router, as router is also normal 278 SILC server, the messages inside the cell are always delivered only with 279 one server hop. If clients communicating with each other are connected 280 to the same server, no router interaction is needed. This is the optimal 281 situation of message delivery in the SILC network. 283 2.3 Communication in the Network 285 If the message is destined to client that does not belong to local cell 286 the message is routed to the router server to which the destination 287 client belongs, if the local router is connected to destination router. 288 If there is no direct connection to the destination router, the local 289 router routes the message to its primary route. The following diagram 290 represents message sending between cells. 292 1 --- S1 S4 --- 5 S2 --- 1 293 S/R - - - - - - - - S/R 294 2 -- S2 S3 S1 295 / | \ 296 4 3 2 298 Cell 1. Cell 2. 300 Figure 3: Communication Between Cells 302 Example: Client 5. connected to Server 4. in Cell 1. sends message 303 to Client 2. connected to Server 1. in Cell 2. travels 304 from Server 4. to Router which routes the message to 305 Router in Cell 2, which then routes the message to 306 Server 1. All the other servers and routers in the 307 network will not see the routed message. 309 The optimal case of message delivery from the client point of view is 310 when clients are connected directly to the routers and the messages 311 are delivered from one router to the other. 313 2.4 Channel Communication 315 Messages may be sent to group of clients as well. Sending messages to 316 many clients works the same way as sending messages point to point, from 317 message delivery point of view. Security issues are another matter 318 which are not discussed in this section. 320 Router server handles the message routing to multiple recipients. If 321 any recipient is not in the same cell as the sender the messages are 322 routed further. 324 Server distributes the channel message to its local clients which are 325 joined to the channel. Router also distributes the message to its 326 local clients on the channel. 328 2.5 Router Connections 330 Router connections play very important role in making the SILC like 331 network topology to work. For example, sending broadcast packets in 332 SILC network require special connections between routers; routers must 333 be connected in a specific way. 335 Every router has their primary route which is a connection to another 336 router in the network. Unless there is only two routers in the network 337 must not routers use each other as their primary routes. The router 338 connections in the network must form a ring. 340 Example with three routers in the network: 342 S/R1 - < - < - < - < - < - < - S/R2 343 \ / 344 v ^ 345 \ - > - > - S/R3 - > - > - / 347 Figure 4: Router Connections 349 Example: Network with three routers. Router 1. uses Router 2. as its 350 primary router. Router 2. uses Router 3. as its primary router, 351 and Router 3. uses Router 1. as its primary router. When there 352 are four or more routers in th enetwork, there may be other 353 direct connections between the routers but they must not be used 354 as primary routes. 356 The above example is applicable to any amount of routers in the network 357 except for two routers. If there are only two routers in the network both 358 routers must be able to handle situation where they use each other as their 359 primary routes. 361 The issue of router connections are very important especially with SILC 362 broadcast packets. Usually all router wide information in the network is 363 distributed by SILC broadcast packets. This sort of ring network, with 364 ability to have other direct routes in the network can cause interesting 365 routing problems. The [SILC2] discusses the routing of packets in this 366 sort of network in more detail. 368 3. SILC Specification 370 This section describes the SILC protocol. However, [SILC2] and 371 [SILC3] describes other important protocols that are part of this SILC 372 specification and must be read. 374 3.1 Client 376 A client is a piece of software connecting to SILC server. SILC client 377 cannot be SILC server. Purpose of clients is to provide the user 378 interface of the SILC services for end user. Clients are distinguished 379 from other clients by unique Client ID. Client ID is a 128 bit ID that 380 is used in the communication in the SILC network. The client ID is 381 based on the user's IP address and nickname. User use logical nicknames 382 in communication which are then mapped to the corresponding Client ID. 383 Client IDs are low level identifications and should not be seen by the 384 end user. 386 Clients provide other information about the end user as well. Information 387 such as the nickname of the user, username and the host name of the end 388 user and user's real name. See section 3.2 Server for information of 389 the requirements of keeping this information. 391 The nickname selected by the user is not unique in the SILC network. 392 There can be 2^8 same nicknames for one IP address. As for comparison to 393 IRC [IRC] where nicknames are unique this is a fundamental difference 394 between SILC and IRC. This typically causes the server names or client's 395 host names to be used along with the nicknames on user interface to 396 identify specific users when sending messages. This feature of SILC 397 makes IRC style nickname-wars obsolete as no one owns their nickname; 398 there can always be someone else with the same nickname. Also, any kind 399 of nickname registering service becomes obsolete. See the section 3.13.1 400 for more information about nicknames. 402 3.1.1 Client ID 404 Client ID is used to identify users in the SILC network. The Client ID 405 is unique to the extent that there can be 2^128 different Client IDs, 406 and IDs based on IPv6 addresses extends this to 2^224 different Client 407 IDs. Collisions are not expected to happen. The Client ID is defined 408 as follows. 410 128 bit Client ID based on IPv4 addresses: 412 32 bit Server ID IP address (bits 1-32) 413 8 bit Random number or counter 414 88 bit Truncated MD5 hash value of the nickname 416 224 bit Client ID based on IPv6 addresses: 418 128 bit Server ID IP address (bits 1-128) 419 8 bit Random number or counter 420 88 bit Truncated MD5 hash value of the nickname 422 o Server ID IP address - Indicates the server where this 423 client is coming from. The IP address hence equals the 424 server IP address where the client is connected. 426 o Random number or counter - Random number to further 427 randomize the Client ID. Another choice is to use 428 a counter starting from the zero (0). This makes it 429 possible to have 2^8 same nicknames from the same 430 server IP address. 432 o MD5 hash - MD5 hash value of the case folded nickname is 433 truncated taking 88 bits from the start of the hash value. 434 This hash value is used to search the user's Client ID 435 from the ID lists. Note that the nickname MUST be prepared 436 using the stringprep [RFC3454] profile described in the 437 Appendix A before computing the MD5 hash. See also the 438 section 3.13.1 for more information. 440 Collisions could occur when more than 2^8 clients using same nickname 441 from the same server IP address is connected to the SILC network. 442 Server MUST be able to handle this situation by refusing to accept 443 anymore of that nickname. 445 Another possible collision may happen with the truncated hash value of 446 the nickname. It could be possible to have same truncated hash value 447 for two different nicknames. However, this is not expected to happen 448 nor cause any serious problems if it would occur. Nicknames are usually 449 logical and it is unlikely to have two distinct logical nicknames 450 produce same truncated hash value. Use of MD5 in nickname hash is not 451 a security feature. 453 3.2 Server 455 Servers are the most important parts of the SILC network. They form the 456 basis of the SILC, providing a point to which clients may connect to. 457 There are two kinds of servers in SILC; normal servers and router servers. 458 This section focus on the normal server and router server is described 459 in the section 3.3 Router. 461 Normal servers MUST NOT directly connect to other normal server. Normal 462 servers may only directly connect to router server. If the message sent 463 by the client is destined outside the local server it is always sent to 464 the router server for further routing. Server may only have one active 465 connection to router on same port. Normal server MUST NOT connect to other 466 cell's router except in situations where its cell's router is unavailable. 468 3.2.1 Server's Local ID List 470 Normal server keeps various information about the clients and their end 471 users connected to it. Every normal server MUST keep list of all locally 472 connected clients, Client IDs, nicknames, usernames and host names and 473 user's real name. Normal servers only keeps local information and it 474 does not keep any global information. Hence, normal servers knows only 475 about their locally connected clients. This makes servers efficient as 476 they do not have to worry about global clients. Server is also responsible 477 of creating the Client IDs for their clients. 479 Normal server also keeps information about locally created channels and 480 their Channel IDs. 482 Hence, local list for normal server includes: 484 server list - Router connection 485 o Server name 486 o Server IP address 487 o Server ID 488 o Sending key 489 o Receiving key 490 o Public key 492 client list - All clients in server 493 o Nickname 494 o Username@host 495 o Real name 496 o Client ID 497 o Sending key 498 o Receiving key 499 o Public key 501 channel list - All channels in server 502 o Channel name 503 o Channel ID 504 o Client IDs on channel 505 o Client ID modes on channel 506 o Channel key 508 3.2.2 Server ID 510 Servers are distinguished from other servers by unique 64 bit Server ID 511 (for IPv4) or 160 bit Server ID (for IPv6). The Server ID is used in 512 the SILC to route messages to correct servers. Server IDs also provide 513 information for Client IDs, see section 3.1.1 Client ID. Server ID is 514 defined as follows. 516 64 bit Server ID based on IPv4 addresses: 518 32 bit IP address of the server 519 16 bit Port 520 16 bit Random number 522 160 bit Server ID based on IPv6 addresses: 524 128 bit IP address of the server 525 16 bit Port 526 16 bit Random number 528 o IP address of the server - This is the real IP address of 529 the server. 531 o Port - This is the port the server is bound to. 533 o Random number - This is used to further randomize the Server ID. 535 Collisions are not expected to happen in any conditions. The Server ID 536 is always created by the server itself and server is responsible of 537 distributing it to the router. 539 3.2.3 SILC Server Ports 541 The following ports has been assigned by IANA for the SILC protocol: 543 silc 706/tcp SILC 544 silc 706/udp SILC 546 If there are needs to create new SILC networks in the future the port 547 numbers must be officially assigned by the IANA. 549 Server on network above privileged ports (>1023) SHOULD NOT be trusted 550 as they could have been set up by untrusted party. 552 3.3 Router 554 Router server in SILC network is responsible for keeping the cell together 555 and routing messages to other servers and to other routers. Router server 556 may also act as normal server when clients may connect to it. This is not 557 requirement and router servers may be hidden from clients. 559 However, router servers have a lot of important tasks that normal servers 560 do not have. Router server knows everything and keeps the global state. 561 They know all clients currently on SILC, all servers and routers and all 562 channels in SILC. Routers are the only servers in SILC that care about 563 global information and keeping them up to date at all time. 565 3.3.1 Router's Local ID List 567 Router server as well MUST keep local list of connected clients and 568 locally created channels. However, this list is extended to include all 569 the informations of the entire cell, not just the server itself as for 570 normal servers. 572 However, on router this list is a lot smaller since routers do not need 573 to keep information about user's nickname, username and host name and real 574 name since these are not needed by the router. The router keeps only 575 information that it needs. 577 Hence, local list for router includes: 579 server list - All servers in the cell 580 o Server name 581 o Server ID 582 o Router's Server ID 583 o Sending key 584 o Receiving key 586 client list - All clients in the cell 587 o Client ID 589 channel list - All channels in the cell 590 o Channel ID 591 o Client IDs on channel 592 o Client ID modes on channel 593 o Channel key 595 Note that locally connected clients and other information include all the 596 same information as defined in section section 3.2.1 Server's Local ID 597 List. Router MAY also cache same detailed information for other clients 598 if needed. 600 3.3.2 Router's Global ID List 602 Router server MUST also keep global list. Normal servers do not have 603 global list as they know only about local information. Global list 604 includes all the clients on SILC, their Client IDs, all created channels 605 and their Channel IDs and all servers and routers on SILC and their 606 Server IDs. That is said, global list is for global information and the 607 list must not include the local information already on the router's local 608 list. 610 Note that the global list does not include information like nicknames, 611 usernames and host names or user's real names. Router does not need to 612 keep these informations as they are not needed by the router. This 613 information is available from the client's server which maybe queried 614 when needed. 616 Hence, global list includes: 618 server list - All servers in SILC 619 o Server name 620 o Server ID 621 o Router's Server ID 623 client list - All clients in SILC 624 o Client ID 626 channel list - All channels in SILC 627 o Channel ID 628 o Client IDs on channel 629 o Client ID modes on channel 631 3.3.3 Router's Server ID 633 Router's Server ID is equivalent to normal Server ID. As routers are 634 normal servers same types of IDs applies for routers as well. See 635 section 3.2.2 Server ID. 637 3.4 Channels 639 A channel is a named group of one or more clients which will all receive 640 messages addressed to that channel. The channel is created when first 641 client requests JOIN command to the channel, and the channel ceases to 642 exist when the last client has left it. When channel exists, any client 643 can reference it using the Channel ID of the channel. If the channel has 644 a founder mode set and last client leaves the channel the channel does 645 not cease to exist. The founder mode can be used to make permanent 646 channels in the network. The founder of the channel can regain the 647 channel founder privileges on the channel later when he joins the 648 channel. 650 Channel names are unique although the real uniqueness comes from 64 bit 651 Channel ID. However, channel names are still unique and no two global 652 channels with same name may exist. See the section 3.13.1 for more 653 information about channel names. 655 Channels can have operators that can administrate the channel and operate 656 all of its modes. The following operators on channel exist on the 657 SILC network. 659 o Channel founder - When channel is created the joining client becomes 660 channel founder. Channel founder is channel operator with some more 661 privileges. Basically, channel founder can fully operate the channel 662 and all of its modes. The privileges are limited only to the 663 particular channel. There can be only one channel founder per 664 channel. Channel founder supersedes channel operator's privileges. 666 Channel founder privileges cannot be removed by any other operator on 667 channel. When channel founder leaves the channel there is no channel 668 founder on the channel. However, it is possible to set a mode for 669 the channel which allows the original channel founder to regain the 670 founder privileges even after leaving the channel. Channel founder 671 also cannot be removed by force from the channel. 673 o Channel operator - When client joins to channel that has not existed 674 previously it will become automatically channel operator (and channel 675 founder discussed above). Channel operator is able to administrate the 676 channel, set some modes on channel, remove a badly behaving client 677 from the channel and promote other clients to become channel 678 operator. The privileges are limited only to the particular channel. 680 Normal channel user may be promoted (opped) to channel operator 681 gaining channel operator privileges. Channel founder or other 682 channel operator may also demote (deop) channel operator to normal 683 channel user. 685 3.4.1 Channel ID 687 Channels are distinguished from other channels by unique Channel ID. 688 The Channel ID is a 64 bit ID (for IPv4) or 160 bit ID (for IPv6), and 689 collisions are not expected to happen in any conditions. Channel names 690 are just for logical use of channels. The Channel ID is created by the 691 server where the channel is created. The Channel ID is defined as 692 follows. 694 64 bit Channel ID based on IPv4 addresses: 696 32 bit Router's Server ID IP address (bits 1-32) 697 16 bit Router's Server ID port (bits 33-48) 698 16 bit Random number or counter 700 160 bit Channel ID based on IPv6 addresses: 702 128 bit Router's Server ID IP address (bits 1-128) 703 16 bit Router's Server ID port (bits 129-144) 704 16 bit Random number or counter 706 o Router's Server ID IP address - Indicates the IP address of 707 the router of the cell where this channel is created. This is 708 taken from the router's Server ID. This way SILC routers know 709 where this channel resides in the SILC network. 711 o Router's Server ID port - Indicates the port of the channel on 712 the server. This is taken from the router's Server ID. 714 o Random number or counter - To further randomize the Channel ID. 715 Another choice is to use a counter starting from zero (0). 716 This makes sure that there are no collisions. This also means 717 that in a cell there can be 2^16 different channels. 719 3.5 Operators 721 Operators are normal users with extra privileges to their server or 722 router. Usually these people are SILC server and router administrators 723 that take care of their own server and clients on them. The purpose of 724 operators is to administrate the SILC server or router. However, even 725 an operator with highest privileges is not able to enter invite-only 726 channels, to gain access to the contents of encrypted and authenticated 727 packets traveling in the SILC network or to gain channel operator 728 privileges on public channels without being promoted. They have the 729 same privileges as any normal user except they are able to administrate 730 their server or router. 732 3.6 SILC Commands 734 Commands are very important part on SILC network especially for client 735 which uses commands to operate on the SILC network. Commands are used 736 to set nickname, join to channel, change modes and many other things. 738 Client usually sends the commands and server replies by sending a reply 739 packet to the command. Server MAY also send commands usually to serve 740 the original client's request. Usually server cannot send commands to 741 clients, however there MAY be commands that allow the server to send 742 commands to client. By default servers MAY send commands only to other 743 servers and routers. 745 Note that the command reply is usually sent only after client has sent 746 the command request but server is allowed to send command reply packet 747 to client even if client has not requested the command. Client MAY 748 choose to ignore the command reply. 750 It is expected that some of the commands may be misused by clients 751 resulting various problems on the server side. Every implementation 752 SHOULD assure that commands may not be executed more than once, say, 753 in two (2) seconds. However, to keep response rate up, allowing for 754 example five (5) commands before limiting is allowed. It is RECOMMENDED 755 that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN, 756 SILC_COMMAND_LEAVE and SILC_COMMAND_KILL SHOULD be limited in all cases 757 as they require heavy operations. This should be sufficient to prevent 758 the misuse of commands. 760 SILC commands are described in [SILC4]. 762 3.7 SILC Packets 764 Packets are naturally the most important part of the protocol and the 765 packets are what actually makes the protocol. Packets in SILC network 766 are always encrypted using, usually the shared secret session key 767 or some other key, for example, channel key, when encrypting channel 768 messages. It is not possible to send a packet in SILC network without 769 encryption. The SILC Packet Protocol is a wide protocol and is described 770 in [SILC2]. This document does not define or describe details of 771 SILC packets. 773 3.8 Packet Encryption 775 All packets passed in SILC network MUST be encrypted. This section 776 gives generic description of how packets must be encrypted in the SILC 777 network. The detailed description of the actual encryption process 778 of the packets are described in [SILC2]. 780 Client and its server shares secret symmetric session key which is 781 established by the SILC Key Exchange Protocol, described in [SILC3]. 782 Every packet sent from client to server, with exception of packets for 783 channels, are encrypted with this session key. 785 Channels have a channel key that are shared by every client on the channel. 786 However, the channel keys are cell specific thus one cell does not know 787 the channel key of the other cell, even if that key is for same channel. 788 Channel key is also known by the routers and all servers that have clients 789 on the channel. However, channels MAY have channel private keys that are 790 entirely local setting for the client. All clients on the channel MUST 791 know the channel private key beforehand to be able to talk on the 792 channel. In this case, no server or router knows the key for the channel. 794 Server shares secret symmetric session key with router which is 795 established by the SILC Key Exchange Protocol. Every packet passed from 796 server to router, with exception of packets for channels, are encrypted 797 with the shared session key. Same way, router server shares secret 798 symmetric key with its primary router. However, every packet passed 799 from router to other router, including packets for channels, are 800 encrypted with the shared session key. Every router connection MUST 801 have their own session keys. 803 3.8.1 Determination of the Source and the Destination 805 The source and the destination of the packet needs to be determined 806 to be able to route the packets to correct receiver. This information 807 is available in the SILC Packet Header which is included in all packets 808 sent in SILC network. The SILC Packet Header is described in [SILC2]. 810 The header MUST be encrypted with the session key of who is the next 811 receiver of the packet along the route. The receiver of the packet, for 812 example a router along the route, is able to determine the sender and the 813 destination of the packet by decrypting the SILC Packet Header and 814 checking the IDs attached to the header. The IDs in the header will 815 tell to where the packet needs to be sent and where it is coming from. 817 The header in the packet MUST NOT change during the routing of the 818 packet. The original sender, for example client, assembles the packet 819 and the packet header and server or router between the sender and the 820 receiver MUST NOT change the packet header. Note however, that some 821 packets such as commands may be resent by a server to serve the client's 822 original command. In this case the command packet sent by the server 823 includes the server's IDs as it is a different packet. When server 824 or router receives a packet it MUST verify that the Source ID is 825 valid and correct ID for that sender. 827 Note that the packet and the packet header may be encrypted with 828 different keys. For example, packets to channels are encrypted with 829 the channel key, however, the header is encrypted with the session key 830 as described above. Most other packets have both header and packet 831 payload encrypted with the same key, such as command packets. 833 3.8.2 Client To Client 835 The process of message delivery and encryption from client to another 836 client is as follows. 838 Example: Private message from client to another client on different 839 servers. Clients do not share private message delivery 840 keys; normal session keys are used. 842 o Client 1 sends encrypted packet to its server. The packet is 843 encrypted with the session key shared between client and its 844 server. 846 o Server determines the destination of the packet and decrypts 847 the packet. Server encrypts the packet with session key shared 848 between the server and its router, and sends the packet to the 849 router. 851 o Router determines the destination of the packet and decrypts 852 the packet. Router encrypts the packet with session key 853 shared between the router and the destination server, and sends 854 the packet to the server. 856 o Server determines the client to which the packet is destined 857 to and decrypts the packet. Server encrypts the packet with 858 session key shared between the server and the destination client, 859 and sends the packet to the client. 861 o Client 2 decrypts the packet. 863 Example: Private message from client to another client on different 864 servers. Clients have established a secret shared private 865 message delivery key with each other and that is used in 866 the message encryption. 868 o Client 1 sends encrypted packet to its server. The packet header 869 is encrypted with the session key shared between the client and 870 server, and the private message payload is encrypted with the 871 private message delivery key shared between clients. 873 o Server determines the destination of the packet and sends the 874 packet to the router. Header is encrypted with the session key. 876 o Router determines the destination of the packet and sends the 877 packet to the server. Header is encrypted with the session key. 879 o Server determines the client to which the packet is destined 880 to and sends the packet to the client. Header is encrypted with 881 the session key. 883 o Client 2 decrypts the packet with the secret shared key. 885 If clients share secret key with each other the private message 886 delivery is much simpler since servers and routers between the 887 clients do not need to decrypt and re-encrypt the entire packet. 888 The packet header however is always encrypted with session key and 889 is decrypted and re-encrypted with the session key of next recipient. 891 The process for clients on same server is much simpler as there is 892 no need to send the packet to the router. The process for clients 893 on different cells is same as above except that the packet is routed 894 outside the cell. The router of the destination cell routes the 895 packet to the destination same way as described above. 897 3.8.3 Client To Channel 899 Process of message delivery from client on channel to all the clients 900 on the channel. 902 Example: Channel of four users; two on same server, other two on 903 different cells. Client sends message to the channel. 905 Packet header is encrypted with the session key, message 906 data is encrypted with channel key. 908 o Client 1 encrypts the packet with channel key and sends the 909 packet to its server. 911 o Server determines local clients on the channel and sends the 912 packet to the Client on the same server. Server then sends 913 the packet to its router for further routing. 915 o Router determines local clients on the channel, if found 916 sends packet to the local clients. Router determines global 917 clients on the channel and sends the packet to its primary 918 router or fastest route. 920 o (Other router(s) do the same thing and sends the packet to 921 the server(s).) 923 o Server determines local clients on the channel and sends the 924 packet to the client. 926 o All clients receiving the packet decrypts it. 928 3.8.4 Server To Server 930 Server to server packet delivery and encryption is described in above 931 examples. Router to router packet delivery is analogous to server to 932 server. However, some packets, such as channel packets, are processed 933 differently. These cases are described later in this document and 934 more in detail in [SILC2]. 936 3.9 Key Exchange And Authentication 938 Key exchange is done always when for example client connects to server 939 but also when server and router, and router and another router connect 940 to each other. The purpose of key exchange protocol is to provide secure 941 key material to be used in the communication. The key material is used 942 to derive various security parameters used to secure SILC packets. The 943 SILC Key Exchange protocol is described in detail in [SILC3]. 945 Authentication is done after key exchange protocol has been successfully 946 completed. The purpose of authentication is to authenticate for example 947 client connecting to the server. However, clients MAY be accepted 948 to connect to server without explicit authentication. Servers are 949 REQUIRED to use authentication protocol when connecting. The 950 authentication may be based on passphrase (pre-shared secret) or public 951 key based on digital signatures. All passphrases sent in SILC protocol 952 MUST be UTF-8 [RFC3629] encoded. The connection authentication protocol 953 is described in detail in [SILC3]. 955 3.9.1 Authentication Payload 957 Authentication Payload is used separately from the SKE and the Connection 958 Authentication protocols. It can be used during the session to 959 authenticate with a remote. For example, a client can authenticate 960 itself to a server to become server operator. In this case, 961 Authentication Payload is used. 963 The format of the Authentication Payload is as follows: 965 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Payload Length | Authentication Method | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Public Data Length | | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 972 | | 973 ~ Public Data ~ 974 | | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Authentication Data Length | | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 978 | | 979 ~ Authentication Data ~ 980 | | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 Figure 5: Authentication Payload 985 o Payload Length (2 bytes) - Length of the entire payload. 987 o Authentication Method (2 bytes) - The method of the 988 authentication. The authentication methods are defined 989 in [SILC2] in the Connection Auth Request Payload. The NONE 990 authentication method SHOULD NOT be used. 992 o Public Data Length (2 bytes) - Indicates the length of 993 the Public Data field. 995 o Public Data (variable length) - This is defined only if 996 the authentication method is public key. If it is any other 997 this field MAY include random data for padding purposes. 998 However, in this case the field MUST be ignored by the 999 receiver. 1001 When the authentication method is public key this includes 1002 128 to 4096 bytes of non-zero random data that is used in 1003 the signature process, described subsequently. 1005 o Authentication Data Length (2 bytes) - Indicates the 1006 length of the Authentication Data field. If zero (0) 1007 value is found in this field the payload MUST be 1008 discarded. 1010 o Authentication Data (variable length) - Authentication 1011 method dependent authentication data. 1013 If the authentication method is passphrase-based, the Authentication 1014 Data field includes the plaintext UTF-8 encoded passphrase. It is safe 1015 to send plaintext passphrase since the entire payload is encrypted. In 1016 this case the Public Data Length is set to zero (0), but MAY also include 1017 random data for padding purposes. It is also RECOMMENDED that maximum 1018 amount of padding is applied to SILC packet when using passphrase-based 1019 authentication. This way it is not possible to approximate the length 1020 of the passphrase from the encrypted packet. 1022 If the authentication method is public key based (or certificate) 1023 the Authentication Data is computed as follows: 1025 HASH = hash(random bytes | ID | public key (or certificate)); 1026 Authentication Data = sign(HASH); 1028 The hash() and the sign() are the hash function and the public key 1029 cryptography function selected in the SKE protocol, unless otherwise 1030 stated in the context where this payload is used. The public key 1031 is SILC style public key unless certificates are used. The ID is the 1032 entity's ID (Client or Server ID) which is authenticating itself. The 1033 ID encoding is described in [SILC2]. The random bytes are non-zero 1034 random bytes of length between 128 and 4096 bytes, and will be included 1035 into the Public Data field as is. 1037 The receiver will compute the signature using the random data received 1038 in the payload, the ID associated to the connection and the public key 1039 (or certificate) received in the SKE protocol. After computing the 1040 receiver MUST verify the signature. Also in case of public key 1041 authentication this payload is always encrypted. This payload is 1042 always sent as part of some other payload. 1044 3.10 Algorithms 1046 This section defines all the allowed algorithms that can be used in 1047 the SILC protocol. This includes mandatory cipher, mandatory public 1048 key algorithm and MAC algorithms. 1050 3.10.1 Ciphers 1052 Cipher is the encryption algorithm that is used to protect the data 1053 in the SILC packets. See [SILC2] for the actual encryption process and 1054 definition of how it must be done. SILC has a mandatory algorithm that 1055 must be supported in order to be compliant with this protocol. 1057 The following ciphers are defined in SILC protocol: 1059 aes-256-cbc AES in CBC mode, 256 bit key (REQUIRED) 1060 aes-256-ctr AES in CTR mode, 256 bit key (RECOMMENDED) 1061 aes-256-rcbc AES in randomized CBC mode, 256 bit key (OPTIONAL) 1062 aes-192- AES in mode, 192 bit key (OPTIONAL) 1063 aes-128- AES in mode, 128 bit key (RECOMMENDED) 1064 twofish-256- Twofish in mode, 256 bit key (OPTIONAL) 1065 twofish-192- Twofish in mode, 192 bit key (OPTIONAL) 1066 twofish-128- Twofish in mode, 128 bit key (OPTIONAL) 1067 cast-256- CAST-256 in mode, 256 bit key (OPTIONAL) 1068 cast-192- CAST-256 in mode, 192 bit key (OPTIONAL) 1069 cast-128- CAST-256 in mode, 128 bit key (OPTIONAL) 1070 serpent-- Serpent in mode, bit key (OPTIONAL) 1071 rc6-- RC6 in mode, bit key (OPTIONAL) 1072 mars-- MARS in mode, bit key (OPTIONAL) 1073 none No encryption (OPTIONAL) 1075 The is either "cbc", "ctr" or "rcbc". Other encryption modes MAY 1076 be defined to be used in SILC using the same name format. The is 1077 either 256, 192 or 128 bit key length. Also, additional ciphers MAY be 1078 defined to be used in SILC by using the same name format as above. 1080 Algorithm "none" does not perform any encryption process at all and 1081 thus is not recommended to be used. It is recommended that no client 1082 or server implementation would accept "none" algorithm except in special 1083 debugging mode. 1085 3.10.1.1 CBC Mode 1087 The "cbc" encryption mode is the standard cipher-block chaining mode. 1088 The very first IV is derived from the SILC Key Exchange protocol. 1089 Subsequent IVs for encryption is the previous ciphertext block. The very 1090 first IV MUST be random and is generated as described in [SILC3]. 1092 3.10.1.2 CTR Mode 1094 The "ctr" encryption mode is Counter Mode (CTR). The CTR mode in SILC is 1095 stateful in encryption and decryption. Both sender and receiver maintain 1096 the counter for the CTR mode and thus can precompute the key stream for 1097 encryption and decryption. By default, CTR mode does not require 1098 plaintext padding, however implementations MAY apply padding to the 1099 packets. If the last key block is larger than the last plaintext block 1100 the resulted value is truncated to the size of the plaintext block and 1101 the most significant bits are used. When sending authentication data 1102 inside packets the maximum amount of padding SHOULD be applied with 1103 CTR mode as well. 1105 In CTR mode only the encryption operation of the cipher is used. The 1106 decryption operation is not needed since both encryption and decryption 1107 process is simple XOR with the plaintext block and the key stream block. 1109 The counter block is used to create the key for the CTR mode. The format 1110 of the 128 bit counter block is as follows: 1112 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Truncated HASH from SKE | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Sending/Receiving IV from SKE | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Packet Counter | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Block Counter | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Figure 6: Counter Block 1126 o Truncated HASH from SKE (4 bytes) - This value is the first 4 1127 bytes from the HASH value that was computed as a result of SKE 1128 protocol. This acts as session identifier and each rekey MUST 1129 produce a new HASH value. 1131 o Sending/Receiving IV from SKE (4 bytes) - If the CTR mode is fully 1132 stateful this field MUST include the first 4 bytes from the Sending 1133 IV or Receiving IV generated in SKE protocol. When this mode is 1134 used to encrypt sending traffic the Sending IV is used, when used 1135 to decrypt receiving traffic the Receiving IV is used. This assures 1136 that two parties of the protocol use different IV for sending 1137 traffic. Each rekey MUST produce a new value. 1139 If the IV Included flag is negotiated in SKE or CTR mode is used 1140 where the IV is included in the data payload, this field is the 1141 Nonce field from the IV received in the packet, defined below. 1143 o Packet Counter (4 bytes) - This is MSB first ordered monotonically 1144 increasing packet counter. It is set value 1 for first packet and 1145 increases for subsequent packets. After rekey the counter MUST 1146 restart from 1. 1148 If the IV Included flag is negotiated in SKE or CTR mode is used 1149 where the IV is included in the data payload, this field is the 1150 Packet Counter field from the IV received in the packet, defined 1151 below. 1153 o Block Counter (4 bytes) - This is an MSB first ordered block 1154 counter starting from 1 for first block and increasing for 1155 subsequent blocks. The counter is always set to value 1 for 1156 a new packet. 1158 CTR mode MUST NOT be used with "none" MAC. Implementations also MUST 1159 assure that the same counter block is not used to encrypt more than 1160 one block. None of the counters must be allowed to wrap without rekey. 1161 Also, the key material used with CTR mode MUST be fresh key material. 1162 Static keys (pre-shared keys) MUST NOT be used with CTR mode. For this 1163 reason using CTR mode to encrypt for example channel messages or private 1164 messages with a pre-shared key is inappropriate. For private messages, 1165 the Key Agreement [SILC2] could be performed to produce fresh key material. 1167 If the IV Included flag was negotiated in SKE, or CTR mode is used to 1168 protect channel messages where the IV will be included in the Message 1169 Payload, the Initialization Vector (IV) to be used is a 64-bit block 1170 containing randomness and packet counter. Also note, that in this case 1171 the decryption process is not stateful and receiver cannot precompute 1172 the key stream. Hence, the Initialization Vector (IV) when CTR mode is 1173 used is as follows. 1175 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Nonce | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Packet Counter | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 Figure 7: CTR Mode Initialization Vector 1185 o Nonce (4 bytes) - This field should be random or otherwise not 1186 easily determinable and SHOULD change for each packet. 1188 o Packet Counter (4 bytes) - This is MSB first ordered monotonically 1189 increasing packet counter. It is set value 1 for first packet and 1190 increases for subsequent packets. After rekey the counter MUST 1191 restart from 1. 1193 When decrypting the packet the Counter Block is assembled by concatenating 1194 the truncated hash, with the received nonce and packet counter, and with 1195 the block counter. The Counter Block is then used to compute the key 1196 stream to perform the decryption. 1198 3.10.1.3 Randomized CBC Mode 1200 The "rcbc" encryption mode is CBC mode with randomized IV. This means 1201 that each IV for each packet MUST be chosen randomly. When encrypting 1202 more than one block the normal IV chaining is used, but for the first 1203 block new random IV is selected in each packet. In this mode the IV 1204 is appended to the ciphertext. If this mode is used to secure the SILC 1205 session, the IV Included flag must be negotiated in SILC Key Exchange 1206 protocol. It may also be used to secure Message Payloads which can 1207 deliver the IV to the recipient. 1209 3.10.2 Public Key Algorithms 1211 Public keys are used in SILC to authenticate entities in SILC network 1212 and to perform other tasks related to public key cryptography. The 1213 public keys are also used in the SILC Key Exchange protocol [SILC3]. 1215 The following public key algorithms are defined in SILC protocol: 1217 rsa RSA (REQUIRED) 1218 dss DSS (OPTIONAL) 1220 DSS is described in [Menezes]. The RSA MUST be implemented according 1221 PKCS #1 [PKCS1]. When using SILC Public Key version 2 the PKCS #1 1222 implementation MUST be compliant with PKCS #1 version 1.5. The signatures 1223 are computed with appendix; the hash OID is included in the signature. 1224 The user may always select the hash algorithm for the signatures. When 1225 using SILC Public Key version 1 the PKCS #1 implementation MUST be 1226 compliant with PKCS #1 version 1.5 where signatures are computed without 1227 appendix; the hash OID is not present in the signature. The hash 1228 algorithm used is specified separately or the default hash algorithm is 1229 used, as defined below. 1231 Additional public key algorithms MAY be defined to be used in SILC. 1233 When signatures are computed in SILC the computing of the signature is 1234 denoted as sign(). The signature computing procedure is dependent of 1235 the public key algorithm, and the public key or certificate encoding. 1236 When using SILC public key the signature is computed as described in 1237 previous paragraph for RSA and DSS keys. If the hash function is not 1238 specified separately for signing process SHA-1 MUST be used, except with 1239 SILC public key version 2 and RSA algorithm when the user MAY always 1240 select the hash algorithm. In this case the hash algorithm is included 1241 in the signature and can be retrieved during verification. When using 1242 SSH2 public keys the signature is computed as described in [SSH-TRANS]. 1243 When using X.509 version 3 certificates the signature is computed as 1244 described in [PKCS7]. When using OpenPGP certificates the signature is 1245 computed as described in [PGP] and the PGP signature type used is 0x00. 1247 3.10.2.1 Multi-Precision Integers 1249 Multi-Precision (MP) integers in SILC are encoded and decoded as defined 1250 in PKCS #1 [PKCS1]. MP integers are unsigned, encoded with the exact 1251 octet length of the integer. No extra leading zero octets may appear. 1252 The actual length of the integer is the bit size of the integer not 1253 counting any leading zero bits. The octet length is derived by calculating 1254 (bit_length + 7) / 8. 1256 3.10.3 Hash Functions 1258 Hash functions are used as part of MAC algorithms defined in the next 1259 section. They are also used in the SILC Key Exchange protocol defined 1260 in the [SILC3]. 1262 The following Hash algorithm are defined in SILC protocol: 1264 sha1 SHA-1, length = 20 bytes (REQUIRED) 1265 sha256 SHA-256, length = 32 bytes (RECOMMENDED) 1266 md5 MD5, length = 16 bytes (RECOMMENDED) 1268 3.10.4 MAC Algorithms 1270 Data integrity is protected by computing a message authentication code 1271 (MAC) of the packet data. See [SILC2] for details how to compute the 1272 MAC for a packet. 1274 The following MAC algorithms are defined in SILC protocol: 1276 hmac-sha1-96 HMAC-SHA1, length = 12 bytes (REQUIRED) 1277 hmac-sha256-96 HMAC-SHA256, length = 12 bytes (RECOMMENDED) 1278 hmac-md5-96 HMAC-MD5, length = 12 bytes (OPTIONAL) 1279 hmac-sha1 HMAC-SHA1, length = 20 bytes (OPTIONAL) 1280 hmac-sha256 HMAC-SHA256, length = 32 bytes (OPTIONAL) 1281 hmac-md5 HMAC-MD5, length = 16 bytes (OPTIONAL) 1282 none No MAC (OPTIONAL) 1284 The "none" MAC is not recommended to be used as the packet is not 1285 authenticated when MAC is not computed. It is recommended that no 1286 client or server would accept none MAC except in special debugging 1287 mode. 1289 The HMAC algorithm is described in [HMAC]. The hash algorithms used 1290 in HMACs, the SHA-1 is described in [RFC3174] and MD5 is described 1291 in [RFC1321]. The SHA-256 algorithm and its used with HMAC is described 1292 in [SHA256]. 1294 Additional MAC algorithms MAY be defined to be used in SILC. 1296 3.10.5 Compression Algorithms 1298 SILC protocol supports compression that may be applied to unencrypted 1299 data. It is recommended to use compression on slow links as it may 1300 significantly speed up the data transmission. By default, SILC does not 1301 use compression which is the mode that must be supported by all SILC 1302 implementations. 1304 The following compression algorithms are defined: 1306 none No compression (REQUIRED) 1307 zlib GNU ZLIB (LZ77) compression (OPTIONAL) 1309 Additional compression algorithms MAY be defined to be used in SILC. 1311 3.11 SILC Public Key 1313 This section defines the type and format of the SILC public key. All 1314 implementations MUST support this public key type. See [SILC3] for 1315 other optional public key and certificate types allowed in the SILC 1316 protocol. Public keys in SILC may be used to authenticate entities 1317 and to perform other tasks related to public key cryptography. 1319 The format of the SILC Public Key is as follows: 1321 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Public Key Length | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Algorithm Name Length | | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1328 | | 1329 ~ Algorithm Name ~ 1330 | | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Identifier Length | | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1334 | | 1335 ~ Identifier ~ 1336 | | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | | 1339 ~ Public Data ~ 1340 | | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 Figure 5: SILC Public Key 1345 o Public Key Length (4 bytes) - Indicates the full length 1346 of the SILC Public Key, not including this field. 1348 o Algorithm Name Length (2 bytes) - Indicates the length 1349 of the Algorithm Length field, not including this field. 1351 o Algorithm name (variable length) - Indicates the name 1352 of the public key algorithm that the key is. See the 1353 section 3.10.2 Public Key Algorithms for defined names. 1355 o Identifier Length (2 bytes) - Indicates the length of 1356 the Identifier field, not including this field. 1358 o Identifier (variable length) - Indicates the identifier 1359 of the public key. This data can be used to identify the 1360 owner of the key. The identifier may be of the following 1361 format: 1363 UN User name 1364 HN Host name or IP address 1365 RN Real name 1366 E EMail address 1367 O Organization 1368 C Country 1369 V Version 1371 Examples of an identifier: 1373 'UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi' 1375 'UN=sam, HN=dummy.fi, RN=Sammy Sam, C=Finland, V=2' 1377 At least user name (UN) and host name (HN) MUST be provided as 1378 identifier. The fields are separated by commas (','). If 1379 comma is in the identifier string it must be escaped as '\,', 1380 for example, 'O=Company XYZ\, Inc.'. Other characters that 1381 require escaping are listed in [RFC2253] and are to be escaped 1382 as defined therein. The Version (V) may only be a decimal digit. 1384 o Public Data (variable length) - Includes the actual 1385 public data of the public key. 1387 The format of this field for RSA algorithm is 1388 as follows: 1390 4 bytes Length of e 1391 variable length e 1392 4 bytes Length of n 1393 variable length n 1395 The format of this field for DSS algorithm is 1396 as follows: 1398 4 bytes Length of p 1399 variable length p 1400 4 bytes Length of q 1401 variable length q 1402 4 bytes Length of g 1403 variable length g 1404 4 bytes Length of y 1405 variable length y 1407 The variable length fields are multiple precession 1408 integers encoded as strings in both examples. 1410 Other algorithms must define their own type of this 1411 field if they are used. 1413 The SILC Public Key is version is 2. If the Version (V) identifier is 1414 not present the SILC Public Key version is expected to be 1. All new 1415 implementations SHOULD support version 1 but SHOULD only generate version 2. 1416 In this case the Version (V) identifier MUST be present. 1418 All fields in the public key are in MSB (most significant byte first) 1419 order. All strings in the public key MUST be UTF-8 encoded. 1421 If an external protocol needs to refer to SILC Public Key by name, the 1422 names "silc-rsa" and "silc-dss" for SILC Public Key based on RSA algorithm 1423 and SILC Public Key based on DSS algorithm, respectively, are to be used. 1424 However, this SILC specification does not use these names directly, and 1425 they are defined here for external protocols (protocols that may like 1426 to use SILC Public Key). 1428 A fingerprint from SILC Public Key is computed from the whole encoded 1429 public key data block. All fields are included in computation. Compliant 1430 implementations MUST support computing a 160-bit SHA-1 fingerprint. 1432 3.12 SILC Version Detection 1434 The version detection of both client and server is performed at the 1435 connection phase while executing the SILC Key Exchange protocol. The 1436 version identifier is exchanged between initiator and responder. The 1437 version identifier is of the following format: 1439 SILC-- 1441 The version strings are of the following format: 1443 protocol version = . 1444 software version = [.[.]] 1446 Protocol version MUST provide both major and minor version. Currently 1447 implementations MUST set the protocol version and accept at least the 1448 protocol version as SILC-1.2-. If new protocol version 1449 causes incompatibilities with older version the version number 1450 MUST be incremented. The is incremented if new protocol version 1451 is fully incompatible. 1453 Software version MAY provide major, minor and build (vendor) version. 1454 The software version MAY be freely set and accepted. The version string 1455 MUST consist of printable US-ASCII characters. 1457 Thus, the version strings could be, for example: 1459 SILC-1.1-2.0.2 1460 SILC-1.0-1.2 1461 SILC-1.2-1.0.VendorXYZ 1462 SILC-1.2-2.4.5 Vendor Limited 1464 3.13 UTF-8 Strings in SILC 1466 By default all strings that are sent in SILC protocol MUST be UTF-8 1467 [RFC3269] encoded, unless otherwise defined. This means that any string 1468 sent inside for example, command, command reply, notify or any packet 1469 payload is UTF-8 encoded. Also nicknames, channel names, server names, 1470 and hostnames are UTF-8 encoded. This definition does not affect 1471 messages sent in SILC, as the Message Payload provides its own mechanism 1472 to indicate whether a message is UTF-8 text message, data message, which 1473 may use its own character encoding, or pure binary message [SILC2]. 1475 Certain limitations are imposed on the UTF-8 encoded strings in SILC. 1476 The UTF-8 encoded strings MUST NOT include any characters that are 1477 marked in the Unicode standard as control codes, noncharacters, 1478 reserved or private range characters, or any other illegal Unicode 1479 characters. Also the BOM (Byte-Order Mark) MUST NOT be used as byte 1480 order signature in UTF-8 encoded strings. A string containing these 1481 characters MUST be treated as malformed UTF-8 encoding. 1483 The Unicode standard defines that malformed sequences shall be signalled 1484 by replacing the sequence with a replacement character. Even though, 1485 in case of SILC these strings may not be malformed UTF-8 encodings 1486 they MUST be treated as malformed strings. Implementation MAY use 1487 a replacement character, however, the character Unicode standard defines 1488 MUST NOT be used, but another character must be chosen. It is, however, 1489 RECOMMENDED that an error is returned instead of using replacement 1490 character if it is possible. For example, when setting a nickname 1491 with SILC_COMMAND_NICK command, implementation is able to send error 1492 indication back to the command sender. It must be noted that on server 1493 implementation if a character sequence is merely outside of current 1494 character subset, but is otherwise valid character, it MUST NOT be 1495 replaced by a replacement character. 1497 On user interface where UTF-8 strings are displayed the implementation 1498 is RECOMMENDED to escape any character that it is unable to render 1499 properly. The escaping may be done for example as described in 1500 [RFC2253]. The escaping makes it possible to retrieve the original 1501 UTF-8 encoding. Alternatively, a replacement character may be used 1502 if it does not cause practical problems to the implementation. 1504 3.13.1 UTF-8 Identifier Strings 1506 Identifier strings are special strings in SILC protocol that require 1507 more careful processing, than the general UTF-8 strings described in the 1508 previous section. These strings include the nicknames, server names, 1509 hostnames and some other identifier strings. These strings are prepared 1510 using the stringprep [RFC3454] standard. The Appendix A defines the 1511 stringprep profile for SILC identifier strings and conforming 1512 implementation MUST use the profile to prepare any identifier string. 1514 The stringprep profile describes how identifier strings are prepared, 1515 what characters they may include, and which characters are prohibited. 1516 Identifier strings with prohibited characters MUST be treated as 1517 malformed strings. 1519 The channel name is also special identifier strings with some slight 1520 differences to other identifier strings. The Appendix B defines the 1521 stringprep profile for the channel name strings and conforming 1522 implementation MUST use the profile to prepare any channel name string. 1524 Because of the profile the identifier strings in SILC may generally 1525 include only letters, numbers, most punctuation characters, and some 1526 other characters. For practical reasons most symbol characters and 1527 many other special characters are prohibited. All identifier strings 1528 are case folded and comparing the identifier strings MUST be done as 1529 caseless matching. 1531 In general, the identifier strings does not have a maximum length. 1532 However, the length of a nickname string MUST NOT exceed 128 bytes, and 1533 the length of a channel name string MUST NOT exceed 256 bytes. Since 1534 these strings are UTF-8 encoded the length of one character may be 1535 longer than one byte. This means that the character length of these 1536 strings may be shorter than the maximum length of the string in bytes. 1537 The minimum length of an identifier string MUST be at least one character, 1538 which may be one byte or more in length. Implementation MAY limit the 1539 maximum length of an identifier string, with exception of the nickname 1540 and channel name strings which has the explicit length definition. 1542 3.14 Backup Routers 1544 Backup routers may exist in the cell in addition to the primary router. 1545 However, they must not be active routers or act as routers in the cell. 1546 Only one router may be acting as primary router in the cell. In the case 1547 of failure of the primary router one of the backup routers becomes active. 1548 The purpose of backup routers are in case of failure of the primary router 1549 to maintain working connections inside the cell and outside the cell and 1550 to avoid netsplits. 1552 Backup routers are normal servers in the cell that are prepared to take 1553 over the tasks of the primary router if needed. They need to have at 1554 least one direct and active connection to the primary router of the cell. 1556 This communication channel is used to send the router information to 1557 the backup router. When the backup router connects to the primary router 1558 of the cell it MUST present itself as router server in the Connection 1559 Authentication protocol, even though it is normal server as long as the 1560 primary router is available. Reason for this is that the configuration 1561 needed in the responder end requires usually router connection level 1562 configuration. The responder, however must understand and treat the 1563 connection as normal server (except when feeding router level data to 1564 the backup router). 1566 Backup router must know everything that the primary router knows to be 1567 able to take over the tasks of the primary router. It is the primary 1568 router's responsibility to feed the data to the backup router. If the 1569 backup router does not know all the data in the case of failure some 1570 connections may be lost. The primary router of the cell must consider 1571 the backup router being an actual router server when it feeds the data 1572 to it. 1574 In addition to having direct connection to the primary router of the 1575 cell, the backup router must also have connection to the same router 1576 to which the primary router of the cell is connected. However, it must 1577 not be the active router connection meaning that the backup router must 1578 not use that channel as its primary route and it must not notify the 1579 router about having connected servers, channels and clients behind it. 1580 It merely connects to the router. This sort of connection is later 1581 referred to as being a passive connection. Some keepalive actions may 1582 be needed by the router to keep the connection alive. 1584 It is required that other normal servers have passive connections to 1585 the backup router(s) in the cell. Some keepalive actions may be needed 1586 by the server to keep the connection alive. After they notice the 1587 failure of the primary router they must start using the connection to 1588 the first backup router as their primary route. 1590 Also, if any other router in the network is using the cell's primary 1591 router as its own primary router, it must also have passive connection 1592 to the cell's backup router. It too is prepared to switch to use the 1593 backup router as its new primary router as soon as the original primary 1594 router becomes unresponsive. 1596 All of the parties of this protocol know which one is the backup router 1597 of the cell from their local configuration. Each of the entities must 1598 be configured accordingly and care must be taken when configuring the 1599 backup routers, servers and other routers in the network. 1601 It must be noted that some of the channel messages and private messages 1602 may be lost during the switch to the backup router, unless the message 1603 flag SILC_MESSAGE_FLAG_ACK is set in the message. The announcements 1604 assure that the state of the network is not lost during the switch. 1606 It is RECOMMENDED that there would be at least one backup router in 1607 the cell. It is NOT RECOMMENDED to have all servers in the cell acting 1608 as backup routers as it requires establishing several connections to 1609 several servers in the cell. Large cells can easily have several 1610 backup routers in the cell. 1612 The order of the backup routers are decided at the local configuration 1613 phase. All the parties of this protocol must be configured accordingly to 1614 understand the order of the backup routers. It is not required that the 1615 backup server is actually an active server in the cell. The backup router 1616 may be a redundant server in the cell that does not accept normal client 1617 connections at all. It may be reserved purely for the backup purposes. 1619 If also the first backup router is down as well and there is another 1620 backup router in the cell then it will start acting as the primary 1621 router as described above. 1623 3.14.1 Switching to Backup Router 1625 When the primary router of the cell becomes unresponsive, for example 1626 by sending EOF to the connection, all the parties of this protocol MUST 1627 replace the old connection to the primary router with first configured 1628 backup router. The backup router usually needs to do local modifications 1629 to its database in order to update all the information needed to maintain 1630 working routes. The backup router must understand that clients that 1631 were originated from the primary router are now originated from some of 1632 the existing server connections and must update them accordingly. It 1633 must also remove those clients that were owned by the primary router 1634 since those connections were lost when the primary router became 1635 unresponsive. 1637 All the other parties of the protocol must also update their local 1638 database to understand that the route to the primary router will now go 1639 to the backup router. 1641 Servers connected to the backup router MUST send SILC_PACKET_RESUME_ROUTER 1642 packet with type value 21, to indicate that the server will start using 1643 the backup router as primary router. The backup router MUST NOT allow 1644 this action if it detects that primary is still up and running. If 1645 backup router knows that primary is up and running it MUST send 1646 SILC_PACKET_FAILURE with type value 21 (4 bytes, MSB first order) back 1647 to the server. The server then MUST NOT use the backup as primary 1648 router, but must try to establish connection back to the primary router. 1649 If the action is allowed type value 21 is sent back to the server from 1650 the backup router. It is RECOMMENDED that implementations use the 1651 SILC_COMMAND_PING command to detect whether primary router is responsive. 1652 If the backup router notices that the primary router is unresponsive 1653 it SHOULD NOT start sending data to server links before the server has 1654 sent the SILC_PACKET_RESUME_ROUTER with type value 21. 1656 The servers connected to the backup router must then announce their 1657 clients, channels, channel users, channel user modes, channel modes, 1658 topics and other information to the backup router. This is to assure 1659 that none of the important notify packets were lost during the switch 1660 to the backup router. The backup router must check which of these 1661 announced entities it already has and distribute the new ones to the 1662 primary router. 1664 The backup router too must announce its servers, clients, channels 1665 and other information to the new primary router. The primary router 1666 of the backup router too must announce its information to the backup 1667 router. Both must process only the ones they do not know about. If 1668 any of the announced modes do not match then they are enforced in 1669 normal manner as defined in section 4.2.1 Announcing Clients, Channels 1670 and Servers. 1672 3.14.2 Resuming Primary Router 1674 Usually the primary router is unresponsive only a short period of time 1675 and it is intended that the original router of the cell will resume 1676 its position as primary router when it comes back online. The backup 1677 router that is now acting as primary router of the cell must constantly 1678 try to connect to the original primary router of the cell. It is 1679 RECOMMENDED that it would try to reconnect in 30 second intervals to 1680 the primary router. 1682 When the connection is established to the primary router the backup 1683 resuming protocol is executed. The protocol is advanced as follows: 1685 1. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type 1686 value 1 to the primary router that came back online. The packet 1687 will indicate the primary router has been replaced by the backup 1688 router. After sending the packet the backup router will announce 1689 all of its channels, channel users, modes etc. to the primary 1690 router. 1692 If the primary knows that it has not been replaced (for example 1693 the backup itself disconnected from the primary router and thinks 1694 that it is now primary in the cell) the primary router send 1695 SILC_PACKET_FAILURE with the type value 1 (4 bytes, MSB first 1696 order) back to the backup router. If backup receives this it 1697 MUST NOT continue with the backup resuming protocol. 1699 2. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type 1700 value 1 to its current primary router to indicate that it will 1701 resign as being primary router. Then, backup router sends the 1702 SILC_PACKET_RESUME_ROUTER packet with type value 1 to all 1703 connected servers to also indicate that it will resign as being 1704 primary router. 1706 3. Backup router also send SILC_PACKET_RESUME_ROUTER packet with 1707 type value 1 to the router that is using the backup router 1708 currently as its primary router. 1710 4. Any server and router that receives the SILC_PACKET_RESUME_ROUTER 1711 with type value 1 must reconnect immediately to the primary 1712 router of the cell that came back online. After they have created 1713 the connection they MUST NOT use that connection as active primary 1714 route but still route all packets to the backup router. After 1715 the connection is created they MUST send SILC_PACKET_RESUME_ROUTER 1716 with type value 2 back to the backup router. The session ID value 1717 found in the first packet MUST be set in this packet. 1719 5. Backup router MUST wait for all packets with type value 2 before 1720 it continues with the protocol. It knows from the session ID values 1721 set in the packet when it has received all packets. The session 1722 value should be different in all packets it has sent earlier. 1723 After the packets are received the backup router sends the 1724 SILC_PACKET_RESUME_ROUTER packet with type value 3 to the 1725 primary router that came back online. This packet will indicate 1726 that the backup router is now ready to resign as being primary 1727 router. The session ID value in this packet MUST be the same as 1728 in the first packet sent to the primary router. During this time 1729 the backup router must still route all packets it is receiving 1730 from server connections. 1732 6. The primary router receives the packet and send the packet 1733 SILC_PACKET_RESUME_ROUTER with type value 4 to all connected servers 1734 including the backup router. It also sends the packet with type 1735 value 4 to its primary router, and to the router that is using 1736 it as its primary router. The Session ID value in these packets 1737 SHOULD be zero (0). 1739 7. Any server and router that receives the SILC_PACKET_RESUME_ROUTER 1740 packet with type value 4 must switch their primary route to the new 1741 primary router and remove the route for the backup router, since 1742 it is no longer the primary router of the cell. They must also 1743 update their local database to understand that the clients are 1744 not originated from the backup router but from the locally connected 1745 servers. After that they MUST announce their channels, channel 1746 users, modes etc. to the primary router. They MUST NOT use the 1747 backup router connection after this and the connection is considered 1748 to be a passive connection. The implementation SHOULD be able 1749 to disable the connection without closing the actual link. 1751 After this protocol is executed the backup router is now again a normal 1752 server in the cell that has the backup link to the primary router. The 1753 primary router feeds the router specific data again to the backup router. 1754 All server connections to the backup router are considered passive 1755 connections. 1757 When the primary router of the cell comes back online and connects 1758 to its remote primary router, the remote primary router MUST send the 1759 SILC_PACKET_RESUME_ROUTER packet with type value 20 indicating that the 1760 connection is not allowed since the router has been replaced by an 1761 backup router in the cell. The session ID value in this packet SHOULD be 1762 zero (0). When the primary router receives this packet it MUST NOT use 1763 the connection as active connection but must understand that it cannot 1764 act as primary router in the cell, until the backup resuming protocol has 1765 been executed. 1767 The following type values has been defined for SILC_PACKET_RESUME_ROUTER 1768 packet: 1770 1 SILC_SERVER_BACKUP_START 1771 2 SILC_SERVER_BACKUP_START_CONNECTED 1772 3 SILC_SERVER_BACKUP_START_ENDING 1773 4 SILC_SERVER_BACKUP_START_RESUMED 1774 20 SILC_SERVER_BACKUP_START_REPLACED 1775 21 SILC_SERVER_BACKUP_START_USE 1777 If any other value is found in the type field the packet MUST be 1778 discarded. The SILC_PACKET_RESUME_ROUTER packet and its payload 1779 is defined in [SILC2]. 1781 4 SILC Procedures 1783 This section describes various SILC procedures such as how the 1784 connections are created and registered, how channels are created and 1785 so on. The references [SILC2], [SILC3] and [SILC4] permeate this 1786 section's definitions. 1788 4.1 Creating Client Connection 1790 This section describes the procedure when a client connects to SILC 1791 server. When client connects to server the server MUST perform IP 1792 address lookup and reverse IP address lookup to assure that the origin 1793 host really is who it claims to be. Client, a host, connecting to server 1794 SHOULD have both valid IP address and fully qualified domain name (FQDN). 1796 After that the client and server performs SILC Key Exchange protocol 1797 which will provide the key material used later in the communication. 1798 The key exchange protocol MUST be completed successfully before the 1799 connection registration may continue. The SILC Key Exchange protocol 1800 is described in [SILC3]. 1802 Typical server implementation would keep a list of connections that it 1803 allows to connect to the server. The implementation would check, for 1804 example, the connecting client's IP address from the connection list 1805 before the SILC Key Exchange protocol has been started. The reason for 1806 this is that if the host is not allowed to connect to the server there 1807 is no reason to perform the key exchange protocol. 1809 After successful key exchange protocol the client and server perform 1810 connection authentication protocol. The purpose of the protocol is to 1811 authenticate the client connecting to the server. Flexible 1812 implementation could also accept the client to connect to the server 1813 without explicit authentication. However, if authentication is 1814 desired for a specific client it may be based on passphrase or 1815 public key authentication. If authentication fails the connection 1816 MUST be terminated. The connection authentication protocol is described 1817 in [SILC3]. 1819 After successful key exchange and authentication protocol the client 1820 MUST register itself by sending SILC_PACKET_NEW_CLIENT packet to the 1821 server. This packet includes various information about the client 1822 that the server uses to register the client. Server registers the 1823 client and sends SILC_PACKET_NEW_ID to the client which includes the 1824 created Client ID that the client MUST start using after that. After 1825 that all SILC packets from the client MUST have the Client ID as the 1826 Source ID in the SILC Packet Header, described in [SILC2]. 1828 Client MUST also get the server's Server ID that is to be used as 1829 Destination ID in the SILC Packet Header when communicating with 1830 the server (for example when sending commands to the server). The 1831 ID may be resolved in two ways. Client can take the ID from an 1832 previously received packet from server that MUST include the ID, 1833 or to send SILC_COMMAND_INFO command and receive the Server ID as 1834 command reply. 1836 Server MAY choose not to use the information received in the 1837 SILC_PACKET_NEW_CLIENT packet. For example, if public key or 1838 certificate were used in the authentication, server MAY use that 1839 information rather than what it received from client. This is a suitable 1840 way to get the true information about client if it is available. 1842 The nickname of client is initially set to the username sent in the 1843 SILC_PACKET_NEW_CLIENT packet. User may set the nickname to something 1844 more desirable by sending SILC_COMMAND_NICK command. However, this is 1845 not required as part of registration process. 1847 Server MUST also distribute the information about newly registered 1848 client to its router (or if the server is router, to all routers in 1849 the SILC network). More information about this in [SILC2]. 1851 Router server MUST also check whether some client in the local cell 1852 is watching for the nickname this new client has, and send the 1853 SILC_NOTIFY_TYPE_WATCH to the watcher. 1855 4.2 Creating Server Connection 1857 This section describes the procedure when server connects to its 1858 router (or when router connects to other router, the cases are 1859 equivalent). The procedure is very much alike to when a client 1860 connects to the server thus it is not repeated here. 1862 One difference is that server MUST perform connection authentication 1863 protocol with proper authentication. A proper authentication is based 1864 on passphrase authentication or public key authentication based on 1865 digital signatures. 1867 After server and router have successfully performed the key exchange 1868 and connection authentication protocol, the server MUST register itself 1869 to the router by sending SILC_PACKET_NEW_SERVER packet. This packet 1870 includes the server's Server ID that it has created by itself and 1871 other relevant information about the server. The router receiving the 1872 ID MUST verify that the IP address in the Server ID is same as the 1873 server's real IP address. 1875 After router has received the SILC_PACKET_NEW_SERVER packet it 1876 distributes the information about newly registered server to all routers 1877 in the SILC network. More information about this is in [SILC2]. 1879 As the client needed to resolve the destination ID this MUST be done by 1880 the server that connected to the router, as well. The way to resolve it 1881 is to get the ID from previously received packet. The server MAY also 1882 use SILC_COMMAND_INFO command to resolve the ID. Server MUST also start 1883 using its own Server ID as Source ID in SILC Packet Header and the 1884 router's Server ID as Destination when communicating with the router. 1886 4.2.1 Announcing Clients, Channels and Servers 1888 After server or router has connected to the remote router, and it already 1889 has connected clients and channels it MUST announce them to the router. 1890 If the server is router server, also all the local servers in the cell 1891 MUST be announced. 1893 All clients are announced by compiling a list of ID Payloads into the 1894 SILC_PACKET_NEW_ID packet. All channels are announced by compiling a 1895 list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet. 1896 Channels' mode, founder public key, channel public keys, and other 1897 channel mode specific data is announced by sending the 1898 SILC_NOTIFY_TYPE_CMODE_CHANGE notify list. 1900 The channel public keys that are announced are compiled in Argument 1901 List Payload where the argument type is 0x03, and each argument is 1902 Public Key Payload containing one public key or certificate. 1904 Also, the channel users on the channels must be announced by compiling 1905 a list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type 1906 into the SILC_PACKET_NOTIFY packet. The users' modes on the channel 1907 must also be announced by compiling list of Notify Payloads with the 1908 SILC_NOTIFY_TYPE_CUMODE_CHANGE notify type into the SILC_PACKET_NOTIFY 1909 packet. 1911 The router MUST also announce the local servers by compiling list of 1912 ID Payloads into the SILC_PACKET_NEW_ID packet. 1914 Also, clients' modes (user modes in SILC) MUST be announced. This is 1915 done by compiling a list of Notify Payloads with SILC_NOTIFY_UMODE_CHANGE 1916 notify type into the SILC_PACKET_NOTIFY packet. Also, channels' topics 1917 MUST be announced by compiling a list of Notify Payloads with the 1918 SILC_NOTIFY_TOPIC_SET notify type into the SILC_PACKET_NOTIFY packet. 1919 Also, channel's invite and ban lists MUST be announced by compiling list 1920 of Notify Payloads with the SILC_NOTIFY_TYPE_INVITE and 1921 SILC_NOTIFY_TYPE_BAN notify types, respectively, into the 1922 SILC_PACKET_NOTIFY packet. 1924 The router which receives these lists MUST process them and broadcast 1925 the packets to its primary router. When processing the announced channels 1926 and channel users the router MUST check whether a channel exists already 1927 with the same name. If channel exists with the same name it MUST check 1928 whether the Channel ID is different. If the Channel ID is different the 1929 router MUST send the notify type SILC_NOTIFY_TYPE_CHANNEL_CHANGE to the 1930 server to force the channel ID change to the ID the router has. If the 1931 mode of the channel is different the router MUST send the notify type 1932 SILC_NOTIFY_TYPE_CMODE_CHANGE to the server to force the mode change 1933 to the mode that the router has. 1935 The router MUST also generate new channel key and distribute it to the 1936 channel. The key MUST NOT be generated if the SILC_CMODE_PRIVKEY mode 1937 is set. 1939 If the channel has a channel founder already on the router, the router 1940 MUST send the notify type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server 1941 to force the mode change for the channel founder on the server. The 1942 channel founder privileges MUST be removed on the server. 1944 If the channel public keys are already set on the on router, the router 1945 MUST ignore the received channel public key list and send the notify 1946 type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server which includes the 1947 channel public key list that is on router. The server MUST change the 1948 list to the one it receives from router. 1950 The router processing the channels MUST also compile a list of 1951 Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into the 1952 SILC_PACKET_NOTIFY and send the packet to the server. This way the 1953 server (or router) will receive the clients on the channel that 1954 the router has. 1956 4.3 Joining to a Channel 1958 This section describes the procedure when client joins to a channel. 1959 Client joins to channel by sending command SILC_COMMAND_JOIN to the 1960 server. If the receiver receiving join command is normal server the 1961 server MUST check its local list whether this channel already exists 1962 locally. This would indicate that some client connected to the server 1963 has already joined to the channel. If this is the case, the client is 1964 joined to the channel, new channel key is created and information about 1965 newly joined channel is sent to the router. The router is informed 1966 by sending SILC_NOTIFY_TYPE_JOIN notify type. The notify type MUST 1967 also be sent to the local clients on the channel. The new channel key 1968 is also sent to the router and to local clients on the channel. 1970 If the channel does not exist in the local list the client's command 1971 MUST be sent to the router which will then perform the actual joining 1972 procedure. When server receives the reply to the command from the 1973 router it MUST be sent to the client which sent the command originally. 1974 Server will also receive the channel key from the server that it MUST 1975 send to the client which originally requested the join command. The 1976 server MUST also save the channel key. 1978 If the receiver of the join command is router it MUST first check its 1979 local list whether anyone in the cell has already joined to the channel. 1980 If this is the case, the client is joined to the channel and reply is 1981 sent to the client. If the command was sent by server the command reply 1982 is sent to the server which sent it. Then the router MUST also create 1983 new channel key and distribute it to all clients on the channel and 1984 all servers that have clients on the channel. Router MUST also send 1985 the SILC_NOTIFY_TYPE_JOIN notify type to local clients on the channel 1986 and to local servers that have clients on the channel. 1988 If the channel does not exist on the router's local list it MUST 1989 check the global list whether the channel exists at all. If it does 1990 the client is joined to the channel as described previously. If 1991 the channel does not exist the channel is created and the client 1992 is joined to the channel. The channel key is also created and 1993 distributed as previously described. The client joining to the created 1994 channel is made automatically channel founder and both channel founder 1995 and channel operator privileges are set for the client. 1997 If the router created the channel in the process, information about the 1998 new channel MUST be broadcast to all routers. This is done by 1999 broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary 2000 route. When the router joins the client to the channel it MUST also 2001 send information about newly joined client to all routers in the SILC 2002 network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify 2003 type to the router's primary route. 2005 It is important to note that new channel key is created always when 2006 new client joins to channel, whether the channel has existed previously 2007 or not. This way the new client on the channel is not able to decrypt 2008 any of the old traffic on the channel. Client which receives the reply to 2009 the join command MUST start using the received Channel ID in the channel 2010 message communication thereafter. Client also receives the key for the 2011 channel in the command reply. Note that the channel key is never 2012 generated or distributed if the SILC_CMODE_PRIVKEY mode is set. 2014 4.4 Channel Key Generation 2016 Channel keys are created by router which creates the channel by taking 2017 enough randomness from cryptographically strong random number generator. 2018 The key is generated always when channel is created, when new client 2019 joins a channel and after the key has expired. Key could expire for 2020 example in an hour. 2022 The key MUST also be re-generated whenever some client leaves a channel. 2023 In this case the key is created from scratch by taking enough randomness 2024 from the random number generator. After that the key is distributed to 2025 all clients on the channel. However, channel keys are cell specific thus 2026 the key is created only on the cell where the client, which left the 2027 channel, exists. While the server or router is creating the new channel 2028 key, no other client may join to the channel. Messages that are sent 2029 while creating the new key are still processed with the old key. After 2030 server has sent the SILC_PACKET_CHANNEL_KEY packet client MUST start 2031 using the new key. If server creates the new key the server MUST also 2032 send the new key to its router. See [SILC2] for more information about 2033 how channel messages must be encrypted and decrypted when router is 2034 processing them. 2036 If the key changes very often due to joining traffic on the channel it 2037 is RECOMMENDED that client implementation would cache some of the old 2038 channel keys for short period of time so that it is able to decrypt all 2039 channel messages it receives. It is possible that on a heavy traffic 2040 channel a message encrypted with channel key that was just changed 2041 is received by client after the new key was set into use. This is 2042 possible because not all clients may receive the new key at the same 2043 time, and may still be sending messages encrypted with the old key. 2045 When client receives the SILC_PACKET_CHANNEL_KEY packet with the 2046 Channel Key Payload it MUST process the key data to create encryption 2047 and decryption key, and to create the MAC key that is used to compute 2048 the MACs of the channel messages. The processing is as follows: 2050 channel_key = raw key data 2051 MAC key = hash(raw key data) 2053 The raw key data is the key data received in the Channel Key Payload. 2054 It is used for both encryption and decryption. The hash() is the hash 2055 function used with the HMAC of the channel. Note that the server also 2056 MUST save the channel key. 2058 4.5 Private Message Sending and Reception 2060 Private messages are sent point to point. Client explicitly destine 2061 a private message to specific client that is delivered to only to that 2062 client. No other client may receive the private message. The receiver 2063 of the private message is destined in the SILC Packet Header as in any 2064 other packet as well. The Source ID in the SILC Packet Header MUST be 2065 the ID of the sender of the message. 2067 If the sender of a private message does not know the receiver's Client 2068 ID, it MUST resolve it from server. There are two ways to resolve the 2069 client ID from server; it is RECOMMENDED that client implementations 2070 send SILC_COMMAND_IDENTIFY command to receive the Client ID. Client 2071 MAY also send SILC_COMMAND_WHOIS command to receive the Client ID. 2072 If the sender has received earlier a private message from the receiver 2073 it should have cached the Client ID from the SILC Packet Header. 2075 If server receives a private message packet which includes invalid 2076 destination Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR 2077 notify to the client with error status indicating that such Client ID 2078 does not exist. 2080 See [SILC2] for description of private message encryption and decryption 2081 process. 2083 4.6 Private Message Key Generation 2085 Private message MAY be protected with a key generated by the client. 2086 One way to generate private message key is to use static or pre-shared 2087 keys in the client implementation. Client that wants to indicate other 2088 client on the network that a private message key should be set, the 2089 client MAY send SILC_PACKET_PRIVATE_MESSAGE_KEY packet to indicate this. 2090 The actual key material has to be transferred outside the SILC network, 2091 or it has to be pre-shared key. The client receiving this packet knows 2092 that the sender wishes to use private message key in private message 2093 communication. In case of static or pre-shared keys the IV used in 2094 the encryption SHOULD be chosen randomly. Sending the 2095 SILC_PACKET_PRIVATE_MESSAGE_KEY is not mandatory, and clients may 2096 naturally agree to use a key without sending the packet. 2098 Another choice to use private message keys is to negotiate fresh key 2099 material by performing the Key Agreement. The SILC_PACKET_KEY_AGREEMENT 2100 packet MAY be used to negotiate the fresh key material. In this case 2101 the resulting key material is used to secure the private messages. 2102 Also, the IV used in encryption is used as defined in [SILC3], unless 2103 otherwise stated by the encryption mode used. By performing Key 2104 Agreement the clients can also negotiate the cipher and HMAC to be used 2105 in the private message encryption and to negotiate additional security 2106 parameters. The actual Key Agreement [SILC2] is performed by executing 2107 the SILC Key Exchange protocol [SILC3], peer to peer. Because of NAT 2108 devices in the network, it might be impossible to perform the Key 2109 Agreement. In this case using static or pre-shared key and sending the 2110 SILC_PACKET_PRIVATE_MESSAGE_KEY to indicate the use of a private message 2111 key is a working alternative. 2113 If the key is pre-shared key or other key material not generated by 2114 Key Agreement, then the key material SHOULD be processed as defined 2115 in [SILC3]. In the processing, however, the HASH, as defined in [SILC3] 2116 MUST be ignored. After processing the key material it is employed as 2117 defined in [SILC3]. If the SILC_PACKET_PRIVATE_MESSAGE_KEY was sent, 2118 then it defines the cipher and HMAC to be used. The hash algorithm to be 2119 used in the key material processing is the one that HMAC algorithm is 2120 defined to use. If the SILC_PACKET_PRIVATE_MESSAGE_KEY was not sent at 2121 all, then the hash algorithm to be used SHOULD be SHA1. In this case 2122 also, implementations SHOULD use the SILC protocol's mandatory cipher 2123 and HMAC in private message encryption. 2125 4.7 Channel Message Sending and Reception 2127 Channel messages are delivered to a group of users. The group forms a 2128 channel and all clients on the channel receives messages sent to the 2129 channel. The Source ID in the SILC Packet Header MUST be the ID 2130 of the sender of the message. 2132 Channel messages are destined to a channel by specifying the Channel ID 2133 as Destination ID in the SILC Packet Header. The server MUST then 2134 distribute the message to all clients, except to the original sender, 2135 on the channel by sending the channel message destined explicitly to a 2136 client on the channel. However, the Destination ID MUST still remain 2137 as the Channel ID. 2139 If server receives a channel message packet which includes invalid 2140 destination Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR 2141 notify to the sender with error status indicating that such Channel ID 2142 does not exist. 2144 See the [SILC2] for description of channel message routing for router 2145 servers, and channel message encryption and decryption process. 2147 4.8 Session Key Regeneration 2149 Session keys MUST be regenerated periodically, say, once in an hour. 2150 The re-key process is started by sending SILC_PACKET_REKEY packet to 2151 other end, to indicate that re-key must be performed. The initiator 2152 of the connection SHOULD initiate the re-key. 2154 If perfect forward secrecy (PFS) flag was selected in the SILC Key 2155 Exchange protocol [SILC3] the re-key MUST cause new key exchange with 2156 SKE protocol. In this case the protocol is secured with the old key 2157 and the protocol results to new key material. See [SILC3] for more 2158 information. After the SILC_PACKET_REKEY packet is sent the sender 2159 will perform the SKE protocol. 2161 If PFS flag was set the resulted key material is processed as described 2162 in the section Processing the Key Material in [SILC3]. The difference 2163 with re-key in the processing is that the initial data for the hash 2164 function is just the resulted key material and not the HASH as it 2165 is not computed at all with re-key. Other than that, the key processing 2166 it equivalent to normal SKE negotiation. 2168 If PFS flag was not set, which is the default case, then re-key is done 2169 without executing SKE protocol. In this case, the new key is created by 2170 providing the current sending encryption key to the SKE protocol's key 2171 processing function. The process is described in the section Processing 2172 the Key Material in [SILC3]. The difference in the processing is that 2173 the initial data for the hash function is the current sending encryption 2174 key and not the SKE's KEY and HASH values. Other than that, the key 2175 processing is equivalent to normal SKE negotiation. 2177 After both parties have regenerated the session key, both MUST send 2178 SILC_PACKET_REKEY_DONE packet to each other. These packets are still 2179 secured with the old key. After these packets, the subsequent packets 2180 MUST be protected with the new key. Note that, in case SKE was performed 2181 again the SILC_PACKET_SUCCESS is not sent. The SILC_PACKET_REKEY_DONE 2182 is sent in its stead. 2184 4.9 Command Sending and Reception 2186 Client usually sends the commands in the SILC network. In this case 2187 the client simply sends the command packet to server and the server 2188 processes it and replies with command reply packet. See the [SILC4] 2189 for detailed description of all commands. 2191 However, if the server is not able to process the command, it is sent to 2192 the server's router. This is case for example with commands such as 2193 SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there are 2194 other commands as well [SILC4]. For example, if client sends the WHOIS 2195 command requesting specific information about some client the server must 2196 send the WHOIS command to router so that all clients in SILC network are 2197 searched. The router, on the other hand, sends the WHOIS command further 2198 to receive the exact information about the requested client. The WHOIS 2199 command travels all the way to the server which owns the client and it 2200 replies with command reply packet. Finally, the server which sent the 2201 command receives the command reply and it must be able to determine which 2202 client sent the original command. The server then sends command reply to 2203 the client. Implementations should have some kind of cache to handle, for 2204 example, WHOIS information. Servers and routers along the route could all 2205 cache the information for faster referencing in the future. 2207 The commands sent by server may be sent hop by hop until someone is able 2208 to process the command. However, it is preferred to destine the command 2209 as precisely as it is possible. In this case, other routers en route 2210 MUST route the command packet by checking the true sender and true 2211 destination of the packet. However, servers and routers MUST NOT route 2212 command reply packets to clients coming from other servers. Client 2213 MUST NOT accept command reply packet originated from anyone else but 2214 from its own server. 2216 4.10 Closing Connection 2218 When remote client connection is closed the server MUST send the notify 2219 type SILC_NOTIFY_TYPE_SIGNOFF to its primary router and to all channels 2220 the client was joined. The server MUST also save the client's information 2221 for a period of time for history purposes. 2223 When remote server or router connection is closed the server or router 2224 MUST also remove all the clients that was behind the server or router 2225 from the SILC Network. The server or router MUST also send the notify 2226 type SILC_NOTIFY_TYPE_SERVER_SIGNOFF to its primary router and to all 2227 local clients that are joined on the same channels with the remote 2228 server's or router's clients. 2230 Router server MUST also check whether some client in the local cell 2231 is watching for the nickname this client has, and send the 2232 SILC_NOTIFY_TYPE_WATCH to the watcher, unless the client which left 2233 the network has the SILC_UMODE_REJECT_WATCHING user mode set. 2235 4.11 Detaching and Resuming a Session 2237 SILC protocol provides a possibility for a client to detach itself from 2238 the network without actually signing off from the network. The client 2239 connection to the server is closed but the client remains as valid client 2240 in the network. The client may then later resume its session back from 2241 any server in the network. 2243 When client wishes to detach from the network it MUST send the 2244 SILC_COMMAND_DETACH command to its server. The server then MUST set 2245 SILC_UMODE_DETACHED mode to the client and send SILC_NOTIFY_UMODE_CHANGE 2246 notify to its primary router, which then MUST broadcast it further 2247 to other routers in the network. This user mode indicates that the 2248 client is detached from the network. Implementations MUST NOT use 2249 the SILC_UMODE_DETACHED flag to determine whether a packet can be sent 2250 to the client. All packets MUST still be sent to the client even if 2251 client is detached from the network. Only the server that originally 2252 had the active client connection is able to make the decision after it 2253 notices that the network connection is not active. In this case the 2254 default case is to discard the packet. 2256 The SILC_UMODE_DETACHED flag cannot be set by client itself directly 2257 with SILC_COMMAND_UMODE command, but only implicitly by sending the 2258 SILC_COMMAND_DETACH command. The flag also cannot be unset by the 2259 client, server or router with SILC_COMMAND_UMODE command, but only 2260 implicitly by sending and receiving the SILC_PACKET_RESUME_CLIENT 2261 packet. 2263 When the client wishes to resume its session in the SILC Network it 2264 connects to a server in the network, which MAY also be a different 2265 from the original server, and performs normal procedures regarding 2266 creating a connection as described in section 4.1. After the SKE 2267 and the Connection Authentication protocols has been successfully 2268 completed the client MUST NOT send SILC_PACKET_NEW_CLIENT packet, but 2269 MUST send SILC_PACKET_RESUME_CLIENT packet. This packet is used to 2270 perform the resuming procedure. The packet MUST include the detached 2271 client's Client ID, which the client must know. It also includes 2272 Authentication Payload which includes signature computed with the 2273 client's private key. The signature is computed as defined in the 2274 section 3.9.1. Thus, the authentication method MUST be based in 2275 public key authentication. 2277 When server receive the SILC_PACKET_RESUME_CLIENT packet it MUST 2278 do the following: Server checks that the Client ID is valid client 2279 and that it has the SILC_UMODE_DETACHED mode set. Then it verifies 2280 the Authentication Payload with the detached client's public key. 2281 If it does not have the public key it retrieves it by sending 2282 SILC_COMMAND_GETKEY command to the server that has the public key from 2283 the original client connection. The server MUST NOT use the public 2284 key received in the SKE protocol for this connection. If the 2285 signature is valid the server unsets the SILC_UMODE_DETACHED flag, 2286 and sends the SILC_PACKET_RESUME_CLIENT packet to its primary router. 2287 The routers MUST broadcast the packet and unset the SILC_UMODE_DETACHED 2288 flag when the packet is received. If the server is router server it 2289 also MUST send the SILC_PACKET_RESUME_CLIENT packet to the original 2290 server whom owned the detached client. 2292 The servers and routers that receives the SILC_PACKET_RESUME_CLIENT 2293 packet MUST know whether the packet already has been received for 2294 the client. It is a protocol error to attempt to resume the client 2295 session from more than one server. The implementations could set 2296 internal flag that indicates that the client is resumed. If router 2297 receive SILC_PACKET_RESUME_CLIENT packet for client that is already 2298 resumed the client MUST be killed from the network. This would 2299 indicate that the client is attempting to resume the session more 2300 than once which is a protocol error. In this case the router sends 2301 SILC_NOTIFY_TYPE_KILLED to the client. All routers that detect 2302 the same situation MUST also send the notify for the client. 2304 The servers and routers that receive the SILC_PACKET_RESUME_CLIENT 2305 must also understand that the client may not be found behind the 2306 same server that it originally came from. They must update their 2307 caches according to this. The server that now owns the client session 2308 MUST check whether the Client ID of the resumed client is based 2309 on the server's Server ID. If it is not it creates a new Client 2310 ID and send SILC_NOTIFY_TYPE_NICK_CHANGE to the network. It MUST 2311 also send the channel keys of all channels that the client has 2312 joined to the client since it does not have them. Whether the 2313 Client ID was changed or not the server MUST send SILC_PACKET_NEW_ID 2314 packet to the client. Only after this is the client resumed back 2315 to the network and may start sending packets and messages. 2317 It is also possible that the server did not know about the global 2318 channels before the client resumed. In this case it joins the client 2319 to the channels, generates new channel keys and distributes the keys 2320 to the channels as described in section 4.4. 2322 It is an implementation issue for how long servers keep detached client 2323 sessions. It is RECOMMENDED that the detached sessions would be 2324 persistent as long as the server is running. 2326 4.12 UDP/IP Connections 2328 SILC protocol allows the use of UDP/IP instead of TCP/IP. There may be 2329 many reasons to use UDP, such as video and audio conferencing might 2330 be more efficient with UDP. 2332 When UDP/IP is used, in the SILC Key Exchange protocol the IV Included 2333 flag MUST be set and the first 16-bits of the Cookie field in the Key 2334 Exchange Start Payload MUST include the port that the other end will use 2335 as the SILC session port. The port is in MSB first order. Both initiator 2336 and responder will set the port they are going to use and all packets 2337 after the SKE has been completed with the SILC_PACKET_SUCCESS packet MUST 2338 be sent to the specified port. Initiator will send them to the port 2339 responder specified and vice versa. When verifying the cookie for 2340 modifications the first two bytes are to be ignored in case IV Included 2341 flag has been set. 2343 The default SILC port or port where the SILC server is listenning for 2344 incoming packets is used only during initial key exchange protocol. After 2345 SKE has been completed all packets are sent to the specified ports, 2346 including connection authentication packets and rekey packets even when 2347 PFS is used in rekey. 2349 Changing the ports during SILC session is possible only by first detaching 2350 from the server (with client-server connections) and then performing the 2351 SILC Key Exchange protocol from the beginning and resuming the detached 2352 session. 2354 Since the UDP is unreliable transport the SKE packets may not arrive to 2355 the recipient. Implementation should support retransmission of SKE 2356 packets by using exponential backoff algorithm. Also other SILC packets 2357 such as messages may drop en route. With message packets only way to 2358 assure reliable delivery is to use message acking and retransmit the 2359 message by using for example exponential backoff algorithm. With SKE 2360 packets the initial timeout value should be no more than 1000 2361 milliseconds. With message packets the initial timeout value should be 2362 around 5000 milliseconds. 2364 5 Security Considerations 2366 Security is central to the design of this protocol, and these security 2367 considerations permeate the specification. Common security considerations 2368 such as keeping private keys truly private and using adequate lengths for 2369 symmetric and asymmetric keys must be followed in order to maintain the 2370 security of this protocol. 2372 Special attention must also be paid to the servers and routers that are 2373 running the SILC service. The SILC protocol's security depends greatly 2374 on the security and the integrity of the servers and administrators that 2375 are running the service. It is recommended that some form of registration 2376 is required by the server and router administrator prior to acceptance to 2377 the SILC Network. Even though the SILC protocol is secure in a network 2378 of mutual distrust between clients, servers, routers and administrators 2379 of the servers, the client should be able to trust the servers they are 2380 using if they wish to do so. 2382 It however must be noted that if the client requires absolute security 2383 by not trusting any of the servers or routers in the SILC Network, it can 2384 be accomplished by negotiating private secret keys outside the SILC 2385 Network, either using SKE or some other key exchange protocol, or to use 2386 some other external means for distributing the keys. This applies for 2387 all messages, private messages and channel messages. 2389 It is important to note that SILC, like any other security protocol, is 2390 not a foolproof system; the SILC servers and routers could very well be 2391 compromised. However, to provide an acceptable level of security and 2392 usability for end users, the protocol uses many times session keys or 2393 other keys generated by the servers to secure the messages. This is an 2394 intentional design feature to allow ease of use for end users. This way 2395 the network is still usable, and remains encrypted even if the external 2396 means of distributing the keys is not working. The implementation, 2397 however, may like to not follow this design feature, and may always 2398 negotiate the keys outside SILC network. This is an acceptable solution 2399 and many times recommended. The implementation still must be able to 2400 work with the server generated keys. 2402 If this is unacceptable for the client or end user, the private keys 2403 negotiated outside the SILC Network should always be used. In the end 2404 it is the implementor's choice whether to negotiate private keys by 2405 default or whether to use the keys generated by the servers. 2407 It is also recommended that router operators in the SILC Network would 2408 form a joint forum to discuss the router and SILC Network management 2409 issues. Also, router operators along with the cell's server operators 2410 should have a forum to discuss the cell management issues. 2412 6 References 2414 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, 2415 January 2007. 2417 [SILC3] Riikonen, P., "SILC Key Exchange and Authentication 2418 Protocols", Internet Draft, January 2007. 2420 [SILC4] Riikonen, P., "SILC Commands", Internet Draft, January 2007. 2422 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol", 2423 RFC 1459, May 1993. 2425 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 2426 April 2000. 2428 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2429 2811, April 2000. 2431 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2432 2812, April 2000. 2434 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2435 2813, April 2000. 2437 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", 2438 Internet Draft. 2440 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, 2441 November 1998. 2443 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, 2444 September 1999. 2446 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key 2447 Infrastructure, Certificate and CRL Profile", RFC 2459, 2448 January 1999. 2450 [Schneier] Schneier, B., "Applied Cryptography Second Edition", 2451 John Wiley & Sons, New York, NY, 1996. 2453 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography", 2454 CRC Press 1997. 2456 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 2457 RFC 2412, November 1998. 2459 [ISAKMP] Maughan D., et al, "Internet Security Association and 2460 Key Management Protocol (ISAKMP)", RFC 2408, November 2461 1998. 2463 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange 2464 (IKE)", RFC 2409, November 1998. 2466 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message 2467 Authentication", RFC 2104, February 1997. 2469 [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography 2470 Specifications, Version 2.0", RFC 2437, October 1998. 2472 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 2473 Requirement Levels", BCP 14, RFC 2119, March 1997. 2475 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2476 10646", RFC 3629, November 2003. 2478 [RFC1321] Rivest R., "The MD5 Message-Digest Algorithm", RFC 1321, 2479 April 1992. 2481 [RFC3174] Eastlake, F., et al., "US Secure Hash Algorithm 1 (SHA1)", 2482 RFC 3174, September 2001. 2484 [PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax, 2485 Version 1.5", RFC 2315, March 1998. 2487 [RFC2253] Wahl, M., et al., "Lightweight Directory Access Protocol 2488 (v3): UTF-8 String Representation of Distinguished Names", 2489 RFC 2253, December 1997. 2491 [RFC3454] Hoffman, P., et al., "Preparation of Internationalized 2492 Strings ("stringprep")", RFC 3454, December 2002. 2494 [SHA256] Eastlake 3rd, D., et al., "US Secure Hash Algorithms (SHA 2495 and HMAC-SHA)", RFC 4634, July 2006. 2497 7 Author's Address 2499 Pekka Riikonen 2500 Helsinki 2501 Finland 2503 EMail: priikone@iki.fi 2505 Appendix A 2507 This appendix defines the stringprep [RFC3454] profile for string 2508 identifiers in SILC protocol. Compliant implementation MUST use this 2509 profile to prepare the identifier strings in the SILC protocol. The 2510 profile defines the following as required by [RFC3454]. 2512 - Intended applicability of the profile: the following identifiers in 2513 the SILC Protocol; nicknames, usernames, server names, hostnames, 2514 service names, algorithm names and other security property names [SILC3], 2515 and SILC Public Key name. 2517 - The character repertoire that is the input and output to 2518 stringprep: Unicode 3.2 with the list of unassigned code points 2519 being the Table A.1, as defined in [RFC3454]. 2521 - The mapping tables used: the following tables are used, in order, 2522 as defined in [RFC3454]. 2524 Table B.1 2525 Table B.2 2527 The mandatory case folding is done using the Table B.2 which includes 2528 the characters for the normalization form KC. 2530 - The Unicode normalization used: the Unicode normalization form 2531 KC is used, as defined in [RFC3454]. 2533 - The prohibited characters as output: the following tables are used 2534 to prohibit characters, as defined in [RFC3454]; 2536 Table C.1.1 2537 Table C.1.2 2538 Table C.2.1 2539 Table C.2.2 2540 Table C.3 2541 Table C.4 2542 Table C.5 2543 Table C.6 2544 Table C.7 2545 Table C.8 2546 Table C.9 2548 - Additional prohibited characters as output: in addition, the following 2549 tables are used to prohibit characters, as defined in this document; 2551 Appendix C 2552 Appendix D 2554 - The bidirectional string testing used: bidirectional string testing 2555 is ignored in this profile. 2557 This profile is to be maintained in the IANA registry for stringprep 2558 profiles. The name of this profile is "silc-identifier-prep" and this 2559 document defines the profile. This document defines the first version of 2560 this profile. 2562 Appendix B 2564 This appendix defines the stringprep [RFC3454] profile for channel name 2565 strings in SILC protocol. Compliant implementation MUST use this profile 2566 to prepare the channel name strings in the SILC protocol. The profile 2567 defines the following as required by [RFC3454]. 2569 - Intended applicability of the profile: channel names. 2571 - The character repertoire that is the input and output to 2572 stringprep: Unicode 3.2 with the list of unassigned code points 2573 being the Table A.1, as defined in [RFC3454]. 2575 - The mapping tables used: the following tables are used, in order, 2576 as defined in [RFC3454]. 2578 Table B.1 2579 Table B.2 2581 The mandatory case folding is done using the Table B.2 which includes 2582 the characters for the normalization form KC. 2584 - The Unicode normalization used: the Unicode normalization form 2585 KC is used, as defined in [RFC3454]. 2587 - The prohibited characters as output: the following tables are used 2588 to prohibit characters, as defined in [RFC3454]; 2590 Table C.1.1 2591 Table C.1.2 2592 Table C.2.1 2593 Table C.2.2 2594 Table C.3 2595 Table C.4 2596 Table C.5 2597 Table C.6 2598 Table C.7 2599 Table C.8 2600 Table C.9 2602 - Additional prohibited characters as output: in addition, the following 2603 tables are used to prohibit characters, as defined in this document; 2605 Appendix D 2607 - The bidirectional string testing used: bidirectional string testing 2608 is ignored in this profile. 2610 This profile is to be maintained in the IANA registry for stringprep 2611 profiles. The name of this profile is "silc-identifier-ch-prep" and this 2612 document defines the profile. This document defines the first version of 2613 this profile. 2615 Appendix C 2617 This appendix defines additional prohibited characters in the identifier 2618 strings as defined in the stringprep profile in Appendix A. 2620 Reserved US-ASCII characters 2621 0021 002A 002C 003F 0040 2623 Appendix D 2625 This appendix defines additional prohibited characters in the identifier 2626 strings as defined in the stringprep profile in Appendix A and Appendix B. 2627 Note that the prohibited character tables listed in the Appendix A and 2628 Appendix B may include some of the same characters listed in this 2629 appendix as well. 2631 Symbol characters and other symbol like characters 2632 00A2-00A9 00AC 00AE 00AF 00B0 00B1 00B4 00B6 00B8 00D7 00F7 2633 02C2-02C5 02D2-02FF 0374 0375 0384 0385 03F6 0482 060E 060F 2634 06E9 06FD 06FE 09F2 09F3 09FA 0AF1 0B70 0BF3-0BFA 0E3F 2635 0F01-0F03 0F13-0F17 0F1A-0F1F 0F34 0F36 0F38 0FBE 0FBF 2636 0FC0-0FC5 0FC7-0FCF 17DB 1940 19E0-19FF 1FBD 1FBF-1FC1 2637 1FCD-1FCF 1FDD-1FDF 1FED-1FEF 1FFD 1FFE 2044 2052 207A-207C 2638 208A-208C 20A0-20B1 2100-214F 2150-218F 2190-21FF 2200-22FF 2639 2300-23FF 2400-243F 2440-245F 2460-24FF 2500-257F 2580-259F 2640 25A0-25FF 2600-26FF 2700-27BF 27C0-27EF 27F0-27FF 2800-28FF 2641 2900-297F 2980-29FF 2A00-2AFF 2B00-2BFF 2E9A 2EF4-2EFF 2642 2FF0-2FFF 303B-303D 3040 3095-3098 309F-30A0 30FF-3104 2643 312D-3130 318F 31B8-31FF 321D-321F 3244-325F 327C-327E 2644 32B1-32BF 32CC-32CF 32FF 3377-337A 33DE-33DF 33FF 4DB6-4DFF 2645 9FA6-9FFF A48D-A48F A4A2-A4A3 A4B4 A4C1 A4C5 A4C7-ABFF 2646 D7A4-D7FF FA2E-FAFF FFE0-FFEE FFFC 10000-1007F 10080-100FF 2647 10100-1013F 1D000-1D0FF 1D100-1D1FF 1D300-1D35F 1D400-1D7FF 2649 Other characters 2650 E0100-E01EF 2652 Full Copyright Statement 2654 Copyright (C) The Internet Society (2007). 2656 This document is subject to the rights, licenses and restrictions 2657 contained in BCP 78, and except as set forth therein, the authors 2658 retain all their rights. 2660 This document and the information contained herein are provided on an 2661 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2662 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2663 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2664 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2665 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2666 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.