From: Pekka Riikonen Date: Fri, 13 Jun 2003 15:00:51 +0000 (+0000) Subject: updates. X-Git-Tag: silc.toolkit.0.9.10~103 X-Git-Url: http://git.silcnet.org/gitweb/?a=commitdiff_plain;h=f3f86a21a6ef82b9196641665fb47a8a9d384548;p=silc.git updates. --- diff --git a/doc/draft-riikonen-silc-spec-07.nroff b/doc/draft-riikonen-silc-spec-07.nroff index ac6a6dc1..3e276382 100644 --- a/doc/draft-riikonen-silc-spec-07.nroff +++ b/doc/draft-riikonen-silc-spec-07.nroff @@ -29,24 +29,24 @@ Protocol Specification .ti 0 Status of this Memo -This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC 2026. Internet-Drafts are -working documents of the Internet Engineering Task Force (IETF), its -areas, and its working groups. Note that other groups may also -distribute working documents as Internet-Drafts. +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference -material or to cite them other than as "work in progress." +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html -The distribution of this memo is unlimited. +The distribution of this memo is unlimited. .ti 0 @@ -54,7 +54,7 @@ Abstract This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure -network channel. SILC is IRC [IRC] like protocol, however, it is +network channel. SILC is IRC [IRC] like protocol, however, it is not equivalent to IRC and does not support IRC. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other Internet Drafts relates very closely to this memo; @@ -152,7 +152,7 @@ Figure 6: Counter Block This document describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure -network channel. SILC is IRC [IRC] like protocol, however, it is +network channel. SILC is IRC [IRC] like protocol, however, it is not equivalent to IRC and does not support IRC. Some of the SILC's features are not found in IRC but in traditional Instant Message (IM) protocols. SILC combines features from both of these chat protocol @@ -164,7 +164,7 @@ the SILC network. Three other Internet Drafts relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4]. -The protocol uses extensively packets as conferencing protocol +The protocol uses extensively packets as conferencing protocol requires message and command sending. The SILC Packet Protocol is described in [SILC2] and should be read to fully comprehend this document and protocol. [SILC2] also describes the packet encryption @@ -190,7 +190,7 @@ be made in client-server model. .ti 0 1.1 Requirements Terminology -The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. @@ -198,15 +198,15 @@ interpreted as described in [RFC2119]. .ti 0 2. SILC Concepts -This section describes various SILC protocol concepts that forms the +This section describes various SILC protocol concepts that forms the actual protocol, and in the end, the actual SILC network. The mission -of the protocol is to deliver messages from clients to other clients -through routers and servers in secure manner. The messages may also -be delivered from one client to many clients forming a group, also +of the protocol is to deliver messages from clients to other clients +through routers and servers in secure manner. The messages may also +be delivered from one client to many clients forming a group, also known as a channel. -This section does not focus to security issues. Instead, basic network -concepts are introduced to make the topology of the SILC network +This section does not focus to security issues. Instead, basic network +concepts are introduced to make the topology of the SILC network clear. @@ -214,19 +214,19 @@ clear. 2.1 SILC Network Topology SILC network forms a ring as opposed to tree style network topology that -conferencing protocols usually have. The network has a cells which are -constructed from router and zero or more servers. The servers are -connected to the router in a star like network topology. Routers in the -network are connected to each other forming a ring. The rationale for -this is to have servers that can perform specific kind of tasks what -other servers cannot perform. This leads to two kinds of servers; normal +conferencing protocols usually have. The network has a cells which are +constructed from router and zero or more servers. The servers are +connected to the router in a star like network topology. Routers in the +network are connected to each other forming a ring. The rationale for +this is to have servers that can perform specific kind of tasks what +other servers cannot perform. This leads to two kinds of servers; normal SILC servers and SILC routers. -A difference between normal server and router server is that routers -knows everything about everything in the network. They also do the -actual routing of the messages to the correct receiver. Normal servers +A difference between normal server and router server is that routers +knows everything about everything in the network. They also do the +actual routing of the messages to the correct receiver. Normal servers knows only about local information and nothing about global information. -This makes the network faster as there are less servers that needs to +This makes the network faster as there are less servers that needs to keep global information up to date at all time. This, on the other hand, leads to kind of a cellular like network, where @@ -264,16 +264,16 @@ A cell is formed when a server or servers connect to one router. In SILC network normal server cannot directly connect to other normal server. Normal server may only connect to SILC router which then routes the messages to the other servers in the cell. Router servers -on the other hand may connect to other routers to form the actual SILC -network, as seen in above figure. However, router is also normal SILC -server; clients may connect to it the same way as to normal SILC -server. Normal server also cannot have active connections to more -than one router. Normal server cannot be connected to two different -cells. Router servers, on the other hand, may have as many router to +on the other hand may connect to other routers to form the actual SILC +network, as seen in above figure. However, router is also normal SILC +server; clients may connect to it the same way as to normal SILC +server. Normal server also cannot have active connections to more +than one router. Normal server cannot be connected to two different +cells. Router servers, on the other hand, may have as many router to router connections as needed. There are many issues in this network topology that needs to be careful -about. Issues like the size of the cells, the number of the routers in +about. Issues like the size of the cells, the number of the routers in the SILC network and the capacity requirements of the routers. These issues should be discussed in the Internet Community and additional documents on the issue may be written. @@ -282,11 +282,11 @@ documents on the issue may be written. .ti 0 2.2 Communication Inside a Cell -It is always guaranteed that inside a cell message is delivered to the +It is always guaranteed that inside a cell message is delivered to the recipient with at most two server hops. A client which is connected to -server in the cell and is talking on channel to other client connected -to other server in the same cell, will have its messages delivered from -its local server first to the router of the cell, and from the router +server in the cell and is talking on channel to other client connected +to other server in the same cell, will have its messages delivered from +its local server first to the router of the cell, and from the router to the other server in the cell. The following diagram represents this scenario: @@ -314,8 +314,8 @@ Example: Client 1. connected to Server 1. send message to If the client is connected directly to the router, as router is also normal -SILC server, the messages inside the cell are always delivered only with -one server hop. If clients communicating with each other are connected +SILC server, the messages inside the cell are always delivered only with +one server hop. If clients communicating with each other are connected to the same server, no router interaction is needed. This is the optimal situation of message delivery in the SILC network. @@ -323,8 +323,8 @@ situation of message delivery in the SILC network. .ti 0 2.3 Communication in the Network -If the message is destined to server that does not belong to local cell -the message is routed to the router server to which the destination +If the message is destined to server that does not belong to local cell +the message is routed to the router server to which the destination server belongs, if the local router is connected to destination router. If there is no direct connection to the destination router, the local router routes the message to its primary route. The following diagram @@ -351,7 +351,7 @@ Figure 3: Communication Between Cells Example: Client 5. connected to Server 4. in Cell 1. sends message to Client 2. connected to Server 1. in Cell 2. travels from Server 4. to Router which routes the message to - Router in Cell 2, which then routes the message to + Router in Cell 2, which then routes the message to Server 1. All the other servers and routers in the network will not see the routed message. @@ -361,7 +361,7 @@ when clients are connected directly to the routers and the messages are delivered from one router to the other. -.ti 0 +.ti 0 2.4 Channel Communication Messages may be sent to group of clients as well. Sending messages to @@ -369,12 +369,12 @@ many clients works the same way as sending messages point to point, from message delivery point of view. Security issues are another matter which are not discussed in this section. -Router server handles the message routing to multiple recipients. If -any recipient is not in the same cell as the sender the messages are +Router server handles the message routing to multiple recipients. If +any recipient is not in the same cell as the sender the messages are routed further. -Server distributes the channel message to its local clients which are -joined to the channel. Router also distributes the message to its +Server distributes the channel message to its local clients which are +joined to the channel. Router also distributes the message to its local clients on the channel. @@ -438,29 +438,29 @@ specification and must be read. .ti 0 3.1 Client -A client is a piece of software connecting to SILC server. SILC client -cannot be SILC server. Purpose of clients is to provide the user +A client is a piece of software connecting to SILC server. SILC client +cannot be SILC server. Purpose of clients is to provide the user interface of the SILC services for end user. Clients are distinguished from other clients by unique Client ID. Client ID is a 128 bit ID that -is used in the communication in the SILC network. The client ID is +is used in the communication in the SILC network. The client ID is based on the nickname selected by the user. User uses logical nicknames in communication which are then mapped to the corresponding Client ID. Client ID's are low level identifications and should not be seen by the end user. Clients provide other information about the end user as well. Information -such as the nickname of the user, username and the host name of the end -user and user's real name. See section 3.2 Server for information of +such as the nickname of the user, username and the host name of the end +user and user's real name. See section 3.2 Server for information of the requirements of keeping this information. The nickname selected by the user is not unique in the SILC network. -There can be 2^8 same nicknames for one IP address. As for comparison to -IRC [IRC] where nicknames are unique this is a fundamental difference -between SILC and IRC. This typically causes the server names or client's -host names to be used along with the nicknames on user interface to -identify specific users when sending messages. This feature of SILC -makes IRC style nickname-wars obsolete as no one owns their nickname; -there can always be someone else with the same nickname. The maximum +There can be 2^8 same nicknames for one IP address. As for comparison to +IRC [IRC] where nicknames are unique this is a fundamental difference +between SILC and IRC. This typically causes the server names or client's +host names to be used along with the nicknames on user interface to +identify specific users when sending messages. This feature of SILC +makes IRC style nickname-wars obsolete as no one owns their nickname; +there can always be someone else with the same nickname. The maximum length of nickname is 128 bytes. @@ -490,7 +490,7 @@ o Server ID IP address - Indicates the server where this client is coming from. The IP address hence equals the server IP address where to the client has connected. -o Random number or counter - Random number to further +o Random number or counter - Random number to further randomize the Client ID. Another choice is to use a counter starting from the zero (0). This makes it possible to have 2^8 same nicknames from the same @@ -504,8 +504,8 @@ o MD5 hash - MD5 hash value of the lowercase nickname is .in 3 Collisions could occur when more than 2^8 clients using same nickname -from the same server IP address is connected to the SILC network. -Server MUST be able to handle this situation by refusing to accept +from the same server IP address is connected to the SILC network. +Server MUST be able to handle this situation by refusing to accept anymore of that nickname. Another possible collision may happen with the truncated hash value of @@ -581,7 +581,7 @@ channel list - All channels in server .ti 0 3.2.2 Server ID -Servers are distinguished from other servers by unique 64 bit Server ID +Servers are distinguished from other servers by unique 64 bit Server ID (for IPv4) or 160 bit Server ID (for IPv6). The Server ID is used in the SILC to route messages to correct servers. Server ID's also provide information for Client ID's, see section 3.1.1 Client ID. Server ID is @@ -699,7 +699,7 @@ list. Note that the global list does not include information like nicknames, usernames and host names or user's real names. Router does not need to -keep these informations as they are not needed by the router. This +keep these informations as they are not needed by the router. This information is available from the client's server which maybe queried when needed. @@ -807,12 +807,12 @@ follows. 16 bit Router's Server ID port (bits 129-144) 16 bit Random number -o Router's Server ID IP address - Indicates the IP address of - the router of the cell where this channel is created. This is - taken from the router's Server ID. This way SILC router knows +o Router's Server ID IP address - Indicates the IP address of + the router of the cell where this channel is created. This is + taken from the router's Server ID. This way SILC router knows where this channel resides in the SILC network. -o Router's Server ID port - Indicates the port of the channel on +o Router's Server ID port - Indicates the port of the channel on the server. This is taken from the router's Server ID. o Random number - To further randomize the Channel ID. This makes @@ -860,7 +860,7 @@ resulting various problems on the server side. Every implementation SHOULD assure that commands may not be executed more than once, say, in two (2) seconds. However, to keep response rate up, allowing for example five (5) commands before limiting is allowed. It is RECOMMENDED -that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN, +that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN, SILC_COMMAND_LEAVE and SILC_COMMAND_KILL SHOULD be limited in all cases as they require heavy operations. This should be sufficient to prevent the miss-use of commands. @@ -890,7 +890,7 @@ description of the actual encryption process of the packets are described in [SILC2]. Client and its server shares secret symmetric session key which is -established by the SILC Key Exchange Protocol, described in [SILC3]. +established by the SILC Key Exchange Protocol, described in [SILC3]. Every packet sent from client to server, with exception of packets for channels, are encrypted with this session key. @@ -963,7 +963,7 @@ o Server determines the destination of the packet and decrypts router. o Router determines the destination of the packet and decrypts - the packet. Router encrypts the packet with session key + the packet. Router encrypts the packet with session key shared between the router and the destination server, and sends the packet to the server. @@ -977,7 +977,7 @@ o Client 2. decrypts the packet. Example: Private message from client to another client on different servers. Clients has established secret shared private - message delivery key with each other and that is used in + message delivery key with each other and that is used in the message encryption. o Client 1. sends encrypted packet to its server. The packet header @@ -985,7 +985,7 @@ o Client 1. sends encrypted packet to its server. The packet header server, and the private message is encrypted with the private message delivery key shared between clients. -o Server determines the destination of the packet and sends the +o Server determines the destination of the packet and sends the packet to the router. o Router determines the destination of the packet and sends the @@ -1001,9 +1001,9 @@ delivery is much simpler since servers and routers between the clients do not need to decrypt and re-encrypt the packet. The process for clients on same server is much simpler as there are -no need to send the packet to the router. The process for clients -on different cells is same as above except that the packet is routed -outside the cell. The router of the destination cell routes the +no need to send the packet to the router. The process for clients +on different cells is same as above except that the packet is routed +outside the cell. The router of the destination cell routes the packet to the destination same way as described above. @@ -1061,9 +1061,9 @@ Authentication is done after key exchange protocol has been successfully completed. The purpose of authentication is to authenticate for example client connecting to the server. However, clients may be accepted to connect to server without explicit authentication. Servers are -required to use authentication protocol when connecting. The -authentication may be based on passphrase (pre-shared-secret) or public -key based on digital signatures. All passphrases sent in SILC protocol +required to use authentication protocol when connecting. The +authentication may be based on passphrase (pre-shared-secret) or public +key based on digital signatures. All passphrases sent in SILC protocol MUST be UTF-8 [RFC2279] encoded. The connection authentication protocol is described in detail in [SILC3]. @@ -1099,7 +1099,7 @@ The format of the Authentication Payload is as follows: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .in 3 - + .ce Figure 5: Authentication Payload @@ -1109,7 +1109,7 @@ o Payload Length (2 bytes) - Length of the entire payload. o Authentication Method (2 bytes) - The method of the authentication. The authentication methods are defined - in [SILC2] in the Connection Auth Request Payload. The NONE + in [SILC2] in the Connection Auth Request Payload. The NONE authentication method SHOULD NOT be used. o Public Data Length (2 bytes) - Indicates the length of @@ -1127,10 +1127,10 @@ o Public Data (variable length) - This is defined only if o Authentication Data Length (2 bytes) - Indicates the length of the Authentication Data field. If zero (0) - value is found in this field the payload MUST be + value is found in this field the payload MUST be discarded. -o Authentication Data (variable length) - Authentication +o Authentication Data (variable length) - Authentication method dependent authentication data. .in 3 @@ -1205,7 +1205,7 @@ be defined as to be used in SILC using the same format. The is either 256, 192 or 128 bit key length. Also, additional ciphers MAY be defined to be used in SILC by using the same name format as above. -Algorithm "none" does not perform any encryption process at all and +Algorithm "none" does not perform any encryption process at all and thus is not recommended to be used. It is recommended that no client or server implementation would accept none algorithm except in special debugging mode. @@ -1291,7 +1291,7 @@ inappropriate. For private messages, the Key Agreement could be performed to produce fresh key material. If the IV Included flag was negotiated in SKE, implementations SHOULD -still use the same counter block format as defined above. However, +still use the same counter block format as defined above. However, implementations are RECOMMENDED to replace the Truncated HASH field with a 32 bit random value for each IV (counter block) per encrypted SILC packet. Also note, that in this case the decryption process is @@ -1320,7 +1320,7 @@ cases using either CBC or randomized CBC is actually equivalent. 3.10.2 Public Key Algorithms Public keys are used in SILC to authenticate entities in SILC network -and to perform other tasks related to public key cryptography. The +and to perform other tasks related to public key cryptography. The public keys are also used in the SILC Key Exchange protocol [SILC3]. The following public key algorithms are defined in SILC protocol: @@ -1546,8 +1546,8 @@ order. All strings in the public key are UTF-8 encoded. If an external protocol need to refer to SILC Public Key by name, the name "silc-rsa" and "silc-dss" for SILC Public Key based on RSA algorithm and SILC Public Key based on DSS algorithm, respectively, are to be used. -However, this SILC specification does not use these names directly, and -they are defined here for external protocols (protocols that may like +However, this SILC specification does not use these names directly, and +they are defined here for external protocols (protocols that may like to use SILC Public Key). @@ -1571,14 +1571,14 @@ software version = [.[.]] .in 3 Protocol version MUST provide both major and minor version. Currently -implementations MUST set the protocol version and accept at least the -protocol version as SILC-1.2-. If new protocol version -causes incompatibilities with older version the version number -MUST be incremented. The is incremented if new protocol version +implementations MUST set the protocol version and accept at least the +protocol version as SILC-1.2-. If new protocol version +causes incompatibilities with older version the version number +MUST be incremented. The is incremented if new protocol version is fully incompatible. Software version MAY provide major, minor and build (vendor) version. -The software version MAY be freely set and accepted. The version string +The software version MAY be freely set and accepted. The version string MUST consist of printable US-ASCII characters. Thus, the version strings could be, for example: @@ -1661,7 +1661,7 @@ several servers in the cell. Large cells can easily have several backup routers in the cell. The order of the backup routers are decided at the configuration phase. -All the parties of this protocol must be configured accordingly to +All the parties of this protocol must be configured accordingly to understand the order of the backup routers. It is not required that the backup server is actually active server in the cell. Backup router may be a spare server in the cell that does not accept normal client @@ -1693,18 +1693,20 @@ database to understand that the route to the primary router will now go to the backup router. Servers connected to the backup router MUST send SILC_PACKET_RESUME_ROUTER -packet with type number 21, to indicate that the server will start using +packet with type value 21, to indicate that the server will start using the backup router as primary router. The backup router MUST NOT allow this action if it detects that primary is still up and running. If -backup router knows that primary is up and running it MUST send type -number 22 back to the server. The server then MUST NOT use the backup -as primary router, but must try to establish connection back to the -primary router. If the action is allowed type number 21 is sent back -to the server from the backup router. +backup router knows that primary is up and running it MUST send +SILC_PACKET_FAILURE with type value 21 (4 bytes, MSB first) back to the +server. The server then MUST NOT use the backup as primary router, but +must try to establish connection back to the primary router. If the +action is allowed type value 21 is sent back to the server from the +backup router. It is recommended that implementations use the +SILC_COMMAND_PING command to detect whether primary router is responsive. The servers connected to the backup router must then announce their clients, channels, channel users, channel user modes and channel modes -to the backup router. This is to assure that none of the important notify +to the backup router. This is to assure that none of the important notify packets were lost during the switch to the backup router. The backup router must check which of these announced entities it already have and distribute the new ones to the primary route. @@ -1714,7 +1716,8 @@ and other information to the new primary router. The primary router of the backup router too must announce its informations to the backup router. Both must process only the ones they do not know about. If any of the announced modes does not match then they are enforced in -normal manner defined later in this specification. +normal manner as defined in section 4.2.1 Announcing Clients, Channels +and Servers. .ti 0 @@ -1741,38 +1744,37 @@ resuming protocol is executed. The protocol is advanced as follows: If the primary knows that it has not been replaced (for example the backup itself disconnected from the primary router and thinks that it is now primary in the cell) the primary router send - SILC_PACKET_FAILURE with the type value 1 back to the backup - router. If backup receives this it MUST NOT continue with the - backup resuming protocol. + SILC_PACKET_FAILURE with the type value 1 (4 bytes, MSB first) + back to the backup router. If backup receives this it MUST NOT + continue with the backup resuming protocol. 2. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type - value 2 to its current primary router to indicate that it will + value 1 to its current primary router to indicate that it will resign as being primary router. Then, backup router sends the SILC_PACKET_RESUME_ROUTER packet with type value 1 to all connected servers to also indicate that it will resign as being primary router. 3. Backup router also send SILC_PACKET_RESUME_ROUTER packet with - type value 2 to the router that is using the backup router + type value 1 to the router that is using the backup router currently as its primary router. 4. Any server and router that receives the SILC_PACKET_RESUME_ROUTER - with type value 1 or 2 must reconnect immediately to the - primary router of the cell that came back online. After they - have created the connection they MUST NOT use that connection - as active primary route but still route all packets to the - backup router. After the connection is created they MUST send - SILC_PACKET_RESUME_ROUTER with type value 3 back to the - backup router. The session ID value found in the first packet - MUST be set in this packet. - - 5. Backup router MUST wait for all packets with type value 3 before + with type value 1 must reconnect immediately to the primary + router of the cell that came back online. After they have created + the connection they MUST NOT use that connection as active primary + route but still route all packets to the backup router. After + the connection is created they MUST send SILC_PACKET_RESUME_ROUTER + with type value 2 back to the backup router. The session ID value + found in the first packet MUST be set in this packet. + + 5. Backup router MUST wait for all packets with type value 2 before it continues with the protocol. It knows from the session ID values set in the packet when it have received all packets. The session value should be different in all packets it have sent earlier. After the packets is received the backup router sends the - SILC_PACKET_RESUME_ROUTER packet with type value 4 to the - primary router that came back online. This packet will indicate + SILC_PACKET_RESUME_ROUTER packet with type value 3 to the + primary router that came back online. This packet will indicate that the backup router is now ready to resign as being primary router. The session ID value in this packet MUST be the same as in first packet sent to the primary router. During this time @@ -1780,15 +1782,15 @@ resuming protocol is executed. The protocol is advanced as follows: from server connections. 6. The primary router receives the packet and send the - SILC_PACKET_RESUME_ROUTER with type value 5 to all connected servers + SILC_PACKET_RESUME_ROUTER with type value 4 to all connected servers including the backup router. It also sends the packet with type - value 6 to its primary router, and to the router that is using + value 4 to its primary router, and to the router that is using it as its primary router. The Session ID value in this packet SHOULD be zero (0). 7. Any server and router that receives the SILC_PACKET_RESUME_ROUTER - with type value 5 or 6 must switch their primary route to the - new primary router and remove the route for the backup router, since + with type value 4 must switch their primary route to the new + primary router and remove the route for the backup router, since it is not anymore the primary router of the cell. They must also update their local database to understand that the clients are not originated from the backup router but from the locally connected @@ -1805,7 +1807,7 @@ All server connections in the backup router are considered passive connections. When the primary router of the cell comes back online and connects -to its primary router, the remote primary router must send the +to its primary router, the remote primary router must send the SILC_PACKET_RESUME_ROUTER with type value 20 indicating that the connection is not allowed since the router has been replaced by an backup router. The session ID value in this packet SHOULD be zero (0). @@ -1818,16 +1820,13 @@ The following type values has been defined for SILC_PACKET_RESUME_ROUTER packet: 1 SILC_SERVER_BACKUP_START - 2 SILC_SERVER_BACKUP_START_GLOBAL - 3 SILC_SERVER_BACKUP_START_CONNECTED - 4 SILC_SERVER_BACKUP_START_ENDING - 5 SILC_SERVER_BACKUP_START_RESUMED - 6 SILC_SERVER_BACKUP_START_RESUMED_GLOBAL + 2 SILC_SERVER_BACKUP_START_CONNECTED + 3 SILC_SERVER_BACKUP_START_ENDING + 4 SILC_SERVER_BACKUP_START_RESUMED 20 SILC_SERVER_BACKUP_START_REPLACED 21 SILC_SERVER_BACKUP_START_USE - 22 SILC_SERVER_BACKUP_START_USE_DENIED -If any other value is found in the type field the packet must be +If any other value is found in the type field the packet must be discarded. The SILC_PACKET_RESUME_ROUTER packet and its payload is defined in [SILC2]. @@ -1865,7 +1864,7 @@ is written on the subject. .ti 0 4 SILC Procedures -This section describes various SILC procedures such as how the +This section describes various SILC procedures such as how the connections are created and registered, how channels are created and so on. The section describes the procedures only generally as details are described in [SILC2] and [SILC3]. @@ -1877,7 +1876,7 @@ are described in [SILC2] and [SILC3]. This section describes the procedure when client connects to SILC server. When client connects to server the server MUST perform IP address lookup and reverse IP address lookup to assure that the origin host really is -who it claims to be. Client, host, connecting to server SHOULD have +who it claims to be. Client, host, connecting to server SHOULD have both valid IP address and fully qualified domain name (FQDN). After that the client and server performs SILC Key Exchange protocol @@ -1921,7 +1920,7 @@ or to send SILC_COMMAND_INFO command and receive the Server ID as command reply. Server MAY choose not to use the information received in the -SILC_PACKET_NEW_CLIENT packet. For example, if public key or +SILC_PACKET_NEW_CLIENT packet. For example, if public key or certificate were used in the authentication, server MAY use those informations rather than what it received from client. This is suitable way to get the true information about client if it is available. @@ -1936,7 +1935,7 @@ client to its router (or if the server is router, to all routers in the SILC network). More information about this in [SILC2]. Router server MUST also check whether some client in the local cell -is watching for the nickname this new client has, and send the +is watching for the nickname this new client has, and send the SILC_NOTIFY_TYPE_WATCH to the watcher. @@ -1965,7 +1964,7 @@ in the SILC network. More information about this in [SILC2]. As client needed to resolve the destination ID this MUST be done by the server that connected to the router, as well. The way to resolve it is -to get the ID from previously received packet. The server MAY also +to get the ID from previously received packet. The server MAY also use SILC_COMMAND_INFO command to resolve the ID. Server MUST also start using its own Server ID as Source ID in SILC Packet Header and the router's Server ID as Destination when communicating with the router. @@ -1986,8 +1985,8 @@ Channels' mode and founder public key and other channel mode specific data is announced by sending SILC_NOTIFY_TYPE_CMODE_CHANGE notify list. Also, the channel users on the channels must be announced by compiling a list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into -the SILC_PACKET_NOTIFY packet. The users' modes on the channel must -also be announced by compiling list of Notify Payloads with the +the SILC_PACKET_NOTIFY packet. The users' modes on the channel must +also be announced by compiling list of Notify Payloads with the SILC_NOTIFY_TYPE_CUMODE_CHANGE notify type into the SILC_PACKET_NOTIFY packet. @@ -2017,7 +2016,7 @@ is set. If the channel has channel founder on the router the router MUST send the notify type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server to force -the mode change for the channel founder on the server. The channel +the mode change for the channel founder on the server. The channel founder privileges MUST be removed. The router processing the channels MUST also compile a list of @@ -2070,12 +2069,12 @@ channel is made automatically channel founder and both channel founder and channel operator privileges is set for the client. If the router created the channel in the process, information about the -new channel MUST be broadcasted to all routers. This is done by +new channel MUST be broadcasted to all routers. This is done by broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary route. When the router joins the client to the channel it MUST also send information about newly joined client to all routers in the SILC network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify -type to the router's primary route. +type to the router's primary route. It is important to note that new channel key is created always when new client joins to channel, whether the channel has existed previously @@ -2224,7 +2223,7 @@ will perform the SKE protocol. If PFS flag was set the resulted key material is processed as described in the section Processing the Key Material in [SILC3]. The difference -with re-key in the processing is that the initial data for the hash +with re-key in the processing is that the initial data for the hash function is just the resulted key material and not the HASH as it is not computed at all with re-key. Other than that, the key processing it equivalent to normal SKE negotiation. @@ -2252,7 +2251,7 @@ the client simply sends the command packet to server and the server processes it and replies with command reply packet. See the [SILC3] for detailed description of all commands. -However, if the server is not able to process the command, it is sent +However, if the server is not able to process the command, it is sent to the server's router. This is case for example with commands such as, SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there are other commands as well. For example, if client sends the WHOIS @@ -2292,11 +2291,11 @@ When remote server or router connection is closed the server or router MUST also remove all the clients that was behind the server or router from the SILC Network. The server or router MUST also send the notify type SILC_NOTIFY_TYPE_SERVER_SIGNOFF to its primary router and to all -local clients that are joined on the same channels with the remote +local clients that are joined on the same channels with the remote server's or router's clients. Router server MUST also check whether some client in the local cell -is watching for the nickname this client has, and send the +is watching for the nickname this client has, and send the SILC_NOTIFY_TYPE_WATCH to the watcher, unless the client which left the network has the SILC_UMODE_REJECT_WATCHING user mode set. @@ -2417,7 +2416,7 @@ It however must be noted that if the client requires absolute security by not trusting any of the servers or routers in the SILC Network, it can be accomplished by negotiating private keys outside the SILC Network, either using SKE or some other key exchange protocol, or to use some -other external means for distributing the keys. This applies for all +other external means for distributing the keys. This applies for all messages, private messages and channel messages. It is important to note that SILC, like any other security protocol is @@ -2450,7 +2449,7 @@ should have a forum to discuss the cell management issues. [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, May 2002. -[SILC3] Riikonen, P., "SILC Key Exchange and Authentication +[SILC3] Riikonen, P., "SILC Key Exchange and Authentication Protocols", Internet Draft, May 2002. [SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002. @@ -2470,7 +2469,7 @@ should have a forum to discuss the cell management issues. [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000. -[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", +[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet Draft. [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, @@ -2479,7 +2478,7 @@ should have a forum to discuss the cell management issues. [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, September 1999. -[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key +[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.