.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
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;
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
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
.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].
.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.
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
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.
.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:
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.
.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
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.
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
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.
.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.
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
.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
.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
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.
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
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.
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.
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.
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
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
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.
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].
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
-
+
.ce
Figure 5: Authentication 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
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
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.
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
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:
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).
.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-<software version>. If new protocol version
-causes incompatibilities with older version the <minor> version number
-MUST be incremented. The <major> is incremented if new protocol version
+implementations MUST set the protocol version and accept at least the
+protocol version as SILC-1.2-<software version>. If new protocol version
+causes incompatibilities with older version the <minor> version number
+MUST be incremented. The <major> 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:
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
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.
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
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
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
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).
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].
.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].
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
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.
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.
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.
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.
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
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
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.
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
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.
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
[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.
[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,
[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.
projects / silc.git / commitdiff