.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 29 July 2003
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-07.txt XXX
-Expires: XXX
+draft-riikonen-silc-spec-07.txt 29 July 2003
+Expires: 29 January 2004
.in 3
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
-not equivalent to IRC and does not support IRC. Strong cryptographic
+network channel. SILC provides advanced and feature rich conferencing
+services with security as main design principal. Strong cryptographic
methods are used to protect SILC packets inside the SILC network.
-Three other Internet Drafts relates very closely to this memo;
+Three other specifications relates very closely to this memo;
SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication
Protocols [SILC3] and SILC Commands [SILC4].
2 SILC Concepts ................................................. 4
2.1 SILC Network Topology ..................................... 4
2.2 Communication Inside a Cell ............................... 6
- 2.3 Communication in the Network .............................. 6
+ 2.3 Communication in the Network .............................. 7
2.4 Channel Communication ..................................... 7
2.5 Router Connections ........................................ 8
-3 SILC Specification ............................................ 8
+3 SILC Specification ............................................ 9
3.1 Client .................................................... 9
3.1.1 Client ID ........................................... 9
3.2 Server .................................................... 10
- 3.2.1 Server's Local ID List .............................. 10
- 3.2.2 Server ID ........................................... 11
+ 3.2.1 Server's Local ID List .............................. 11
+ 3.2.2 Server ID ........................................... 12
3.2.3 SILC Server Ports ................................... 12
- 3.3 Router .................................................... 12
+ 3.3 Router .................................................... 13
3.3.1 Router's Local ID List .............................. 13
- 3.3.2 Router's Global ID List ............................. 13
+ 3.3.2 Router's Global ID List ............................. 14
3.3.3 Router's Server ID .................................. 14
3.4 Channels .................................................. 14
- 3.4.1 Channel ID .......................................... 15
+ 3.4.1 Channel ID .......................................... 16
3.5 Operators ................................................. 16
- 3.6 SILC Commands ............................................. 16
+ 3.6 SILC Commands ............................................. 17
3.7 SILC Packets .............................................. 17
3.8 Packet Encryption ......................................... 17
3.8.1 Determination of the Source and the Destination ..... 18
- 3.8.2 Client To Client .................................... 18
+ 3.8.2 Client To Client .................................... 19
3.8.3 Client To Channel ................................... 20
- 3.8.4 Server To Server .................................... 20
- 3.9 Key Exchange And Authentication ........................... 20
+ 3.8.4 Server To Server .................................... 21
+ 3.9 Key Exchange And Authentication ........................... 21
3.9.1 Authentication Payload .............................. 21
3.10 Algorithms ............................................... 23
3.10.1 Ciphers ............................................ 23
3.10.1.1 CBC Mode .................................. 24
3.10.1.2 CTR Mode .................................. 24
- 3.10.1.3 Randomized CBC Mode ....................... 25
+ 3.10.1.3 Randomized CBC Mode ....................... 26
3.10.2 Public Key Algorithms .............................. 26
- 3.10.2.1 Multi-Precision Integers .................. XXX
- 3.10.3 Hash Functions ..................................... 26
+ 3.10.2.1 Multi-Precision Integers .................. 27
+ 3.10.3 Hash Functions ..................................... 27
3.10.4 MAC Algorithms ..................................... 27
- 3.10.5 Compression Algorithms ............................. 27
- 3.11 SILC Public Key .......................................... 28
- 3.12 SILC Version Detection ................................... 30
+ 3.10.5 Compression Algorithms ............................. 28
+ 3.11 SILC Public Key .......................................... 29
+ 3.12 SILC Version Detection ................................... 31
3.13 Backup Routers ........................................... 31
- 3.13.1 Switching to Backup Router ......................... 32
- 3.13.2 Resuming Primary Router ............................ 33
+ 3.13.1 Switching to Backup Router ......................... 33
+ 3.13.2 Resuming Primary Router ............................ 34
4 SILC Procedures ............................................... 36
- 4.1 Creating Client Connection ................................ 36
+ 4.1 Creating Client Connection ................................ 37
4.2 Creating Server Connection ................................ 38
- 4.2.1 Announcing Clients, Channels and Servers ............ 38
- 4.3 Joining to a Channel ...................................... 39
+ 4.2.1 Announcing Clients, Channels and Servers ............ 39
+ 4.3 Joining to a Channel ...................................... 40
4.4 Channel Key Generation .................................... 41
- 4.5 Private Message Sending and Reception ..................... 41
+ 4.5 Private Message Sending and Reception ..................... 42
4.6 Private Message Key Generation ............................ 42
4.7 Channel Message Sending and Reception ..................... 43
- 4.8 Session Key Regeneration .................................. 43
+ 4.8 Session Key Regeneration .................................. 44
4.9 Command Sending and Reception ............................. 44
4.10 Closing Connection ....................................... 45
- 4.11 Detaching and Resuming a Session ......................... 45
+ 4.11 Detaching and Resuming a Session ......................... 46
5 Security Considerations ....................................... 47
6 References .................................................... 48
-7 Author's Address .............................................. 49
-
+7 Author's Address .............................................. 50
+8 Full Copyright Statement ...................................... 50
.ti 0
List of Figures
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
-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)
+network channel. SILC can be used as a secure conferencing service
+that provides rich conferencing features. Some of the SILC features
+are found in traditional chat protocols such as IRC [IRC] but many
+of the SILC features can also be found in Instant Message (IM) style
protocols. SILC combines features from both of these chat protocol
-styles, and SILC can be implemented as either IRC-like system or
-IM-like system.
+styles, and can be implemented as either IRC-like system or IM-like
+system. Some of the more advanced and secure features of the
+protocol are new to all conferencing protocols. SILC also supports
+multimedia messages and can also be implemented as a video and audio
+conferencing system.
Strong cryptographic methods are used to protect SILC packets inside
-the SILC network. Three other Internet Drafts relates very closely
+the SILC network. Three other specifications relates very closely
to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and
Authentication Protocols [SILC3] and SILC Commands [SILC4].
requirements such as mobile networks. All packet payloads in SILC
can be also compressed.
-The security of SILC protocol, and for any security protocol for that
-matter, is based on strong and secure key exchange protocol. The SILC
-Key Exchange protocol is described in [SILC3] along with connection
-authentication protocol and should be read to fully comprehend this
-document and protocol.
+The security of SILC protocol sessions are based on strong and secure
+key exchange protocol. The SILC Key Exchange protocol is described
+in [SILC3] along with connection authentication protocol and should
+be read to fully comprehend this document and protocol.
The SILC protocol has been developed to work on TCP/IP network
protocol, although it could be made to work on other network protocols
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
+constructed from a 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.
+SILC servers and SILC router 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
-keep global information up to date at all time.
-
-This, on the other hand, leads to kind of a cellular like network, where
+knows all global information and keep the global network state up to date.
+They also do the actual routing of the messages to the correct receiver
+between other cells. Normal servers knows only local information and
+receive global information only when it is needed. They do not need to
+keep the global network state up to date. This makes the network faster
+and scalable as there are less servers that needs to maintain global
+network state.
+
+This, on the other hand, leads into a cellular like network, where
routers are in the center of the cell and servers are connected to the
router.
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
-router connections as needed.
+network, as seen in above figure. However, router is also able to act
+as 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. Other direct routes between
+other routers is also possible in addition of the mandatory ring
+connections. This leads into a hybrid ring-mesh network topology.
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
-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.
+about. Issues like routing, 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
.ti 0
2.3 Communication in the Network
-If the message is destined to server that does not belong to local cell
+If the message is destined to client 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.
+client 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
represents message sending between cells.
local clients on the channel.
-
.ti 0
2.5 Router Connections
The issue of router connections are very important especially with SILC
broadcast packets. Usually all router wide information in the network is
distributed by SILC broadcast packets. This sort of ring network, with
-ability to have other direct routes in the network cause interesting
+ability to have other direct routes in the network can cause interesting
routing problems. The [SILC2] discusses the routing of packets in this
sort of network in more detail.
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
-based on the nickname selected by the user. User uses logical nicknames
+based on the user's IP address and nickname. User use 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.
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.
+there can always be someone else with the same nickname. Also, any kind
+of nickname registering service becomes obsolete. The maximum length of
+nickname is 128 bytes.
.ti 0
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.
+ server IP address where the client is connected.
o Random number or counter - Random number to further
randomize the Client ID. Another choice is to use
anymore of that nickname.
Another possible collision may happen with the truncated hash value of
-the nickname. It could be possible to have same truncated hash value for
-two different nicknames. However, this is not expected to happen nor
-cause any problems if it would occur. Nicknames are usually logical and
-it is unlikely to have two distinct logical nicknames produce same
-truncated hash value.
+the nickname. It could be possible to have same truncated hash value
+for two different nicknames. However, this is not expected to happen
+nor cause any serious problems if it would occur. Nicknames are usually
+logical and it is unlikely to have two distinct logical nicknames
+produce same truncated hash value.
.ti 0
user's real name. Normal servers only keeps local information and it
does not keep any global information. Hence, normal servers knows only
about their locally connected clients. This makes servers efficient as
-they don't have to worry about global clients. Server is also responsible
+they do not have to worry about global clients. Server is also responsible
of creating the Client ID's for their clients.
Normal server also keeps information about locally created channels and
.in 3
+
.ti 0
3.2.2 Server ID
as they could have been set up by untrusted party.
+
.ti 0
3.3 Router
just normal SILC server.
However, router servers has a lot of important tasks that normal servers
-do not have. Router server knows everything about everything in the SILC.
+do not have. Router server knows everything and keeps the global state.
They know all clients currently on SILC, all servers and routers and all
channels in SILC. Routers are the only servers in SILC that care about
-global information and keeping them up to date at all time. And, this
-is what they must do.
+global information and keeping them up to date at all time.
.ti 0
Note that locally connected clients and other information include all the
same information as defined in section section 3.2.1 Server's Local ID
-List.
+List. Router MAY also cache same detailed information for other clients
+if needed.
.ti 0
3.3.3 Router's Server ID
Router's Server ID's are equivalent to normal Server ID's. As routers
-are normal servers as well same types of ID's applies for routers as well.
-Thus, see section 3.2.2 Server ID.
+are normal servers same types of ID's applies for routers as well. See
+section 3.2.2 Server ID.
.ti 0
messages addressed to that channel. The channel is created when first
client requests JOIN command to the channel, and the channel ceases to
exist when the last client has left it. When channel exists, any client
-can reference it using the name of the channel. If the channel has
+can reference it using the Channel ID of the channel. If the channel has
a founder mode set and last client leaves the channel the channel does
not cease to exist. The founder mode can be used to make permanent
channels in the network. The founder of the channel can regain the
privileges. Basically, channel founder can fully operate the channel
and all of its modes. The privileges are limited only to the
particular channel. There can be only one channel founder per
- channel. Channel founder supersedes channel operator's privileges.
+ channel. Channel founder supersedes channel operator's privileges.
Channel founder privileges cannot be removed by any other operator on
channel. When channel founder leaves the channel there is no channel
.in 3
+
+
.ti 0
3.4.1 Channel ID
32 bit Router's Server ID IP address (bits 1-32)
16 bit Router's Server ID port (bits 33-48)
-16 bit Random number
+16 bit Random number or counter
160 bit Channel ID based on IPv6 addresses:
128 bit Router's Server ID IP address (bits 1-128)
16 bit Router's Server ID port (bits 129-144)
- 16 bit Random number
+ 16 bit Random number or counter
o Router's Server ID IP address - Indicates the IP address of
the router of the cell where this channel is created. This is
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
- sure that there are no collisions. This also means that
- in a cell there can be 2^16 channels.
+o Random number or counter - To further randomize the Channel ID.
+ Another choice is to use a counter starting from zero (0).
+ This makes sure that there are no collisions. This also means
+ that in a cell there can be 2^16 different channels.
.in 3
channel, to gain access to the contents of a encrypted and authenticated
packets traveling in the SILC network or to gain channel operator
privileges on public channels without being promoted. They have the
-same privileges as everyone else except they are able to administrate
+same privileges as any normal else except they are able to administrate
their server or router.
3.8 Packet Encryption
All packets passed in SILC network MUST be encrypted. This section
-defines how packets must be encrypted in the SILC network. The detailed
-description of the actual encryption process of the packets are
-described in [SILC2].
+gives generic description how packets must be encrypted in the SILC
+network. The detailed 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].
with the shared session key. Same way, router server shares secret
symmetric key with its primary route. However, every packet passed
from router to other router, including packets for channels, are
-encrypted with the shared session key. Every router connection has
-their own session keys.
+encrypted with the shared session key. Every router connection MUST
+have their own session keys.
.ti 0
receiver MUST NOT change the packet header. Note however, that some
packets such as commands may be resent by a server to serve the client's
original command. In this case the command packet sent by the server
-includes the server's IDs.
+includes the server's IDs as it is a different packet. When server
+or router receives a packet it MUST verify that the Source ID is
+valid and correct ID for that sender.
Note that the packet and the packet header may be encrypted with
different keys. For example, packets to channels are encrypted with
message delivery key shared between clients.
o Server determines the destination of the packet and sends the
- packet to the router.
+ packet to the router. Header is encrypted with the session key.
o Router determines the destination of the packet and sends the
- packet to the server.
+ packet to the server. Header is encrypted with the session key.
o Server determines the client to which the packet is destined
- to and sends the packet to the client.
+ to and sends the packet to the client. Header is encrypted with
+ the session key.
o Client 2. decrypts the packet with the secret shared key.
If clients share secret key with each other the private message
delivery is much simpler since servers and routers between the
-clients do not need to decrypt and re-encrypt the packet.
+clients do not need to decrypt and re-encrypt the entire packet.
+The packet header however is always encrypted with session key and
+is decrypted and re-encrypted with the session key of next recipient.
-The process for clients on same server is much simpler as there are
+The process for clients on same server is much simpler as there is
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
Example: Channel of four users; two on same server, other two on
different cells. Client sends message to the channel.
+ Packet header is encrypted with the session key, message
+ data is encrypted with channel key.
o Client 1. encrypts the packet with channel key and sends the
packet to its server.
3.9 Key Exchange And Authentication
Key exchange is done always when for example client connects to server
-but also when server and router, and router and router connects to each
-other. The purpose of key exchange protocol is to provide secure key
-material to be used in the communication. The key material is used to
-derive various security parameters used to secure SILC packets. The
+but also when server and router, and router and another router connects
+to each other. The purpose of key exchange protocol is to provide secure
+key material to be used in the communication. The key material is used
+to derive various security parameters used to secure SILC packets. The
SILC Key Exchange protocol is described in detail in [SILC3].
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
+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
+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
3.9.1 Authentication Payload
Authentication payload is used separately from the SKE and the Connection
-Authentication protocol. It can be used during the session to authenticate
-with the remote. For example, the client can authenticate itself to the
-server to become server operator. In this case, Authentication Payload is
-used.
+Authentication protocols. It can be used during the session to
+authenticate with a remote. For example, a client can authenticate
+itself to a server to become server operator. In this case,
+Authentication Payload is used.
The format of the Authentication Payload is as follows:
The receiver will compute the signature using the random data received
in the payload, the ID associated to the connection and the public key
(or certificate) received in the SKE protocol. After computing the
-receiver MUST verify the signature. In case of public key authentication
-also this payload is encrypted.
+receiver MUST verify the signature. Also in case of public key
+authenticatio this payload is encrypted.
.ti 0
none No encryption (OPTIONAL)
The <mode> is either "cbc", "ctr" or "rcbc". Other encryption modes MAY
-be defined as to be used in SILC using the same format. The <len> is
+be defined to be used in SILC using the same name format. The <len> 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.
one ciphertext block. Note also that some data payloads in SILC are
capable of delivering the IV to the recipient. When explicitly
encrypting these payloads with randomized CBC the IV MUST NOT be appended
-at the end of the ciphertext. When encrypting these payloads with
-"cbc" mode they implicitly become randomized CBC since the IV is
-usually selected random and included in the ciphertext. In these
-cases using either CBC or randomized CBC is actually equivalent.
+at the end of the ciphertext, but is placed at the specified location
+in the payload. However, Message Payload for example has the IV at
+the location which is equivalent to placing it after the last ciphertext
+block. When using CBC mode with such payloads it is actually equivalent
+to using randomized CBC since the IV is selected in random and included
+in the ciphertext.
.ti 0
client or server would accept none MAC except in special debugging
mode.
-The HMAC algorithm is described in [HMAC] and hash algorithms that
-are used as part of the HMACs are described in [Scheneir] and in
-[Menezes].
+The HMAC algorithm is described in [HMAC]. The hash algorithms used
+in HMACs, the SHA-1 is described in [RFC3174] and MD5 is described
+in [RFC1321].
Additional MAC algorithms MAY be defined to be used in SILC.
Additional compression algorithms MAY be defined to be used in SILC.
-
.ti 0
3.11 SILC Public Key
The format of the SILC Public Key is as follows:
+
+
+
+
+
+
.in 5
.nf
1 2 3
At least user name (UN) and host name (HN) MUST be provided as
identifier. The fields are separated by commas (`,'). If
- comma is in the identifier string it must be written as `\\,',
- for example, `O=Company XYZ\\, Inc.'.
+ comma is in the identifier string it must be escaped as `\\,',
+ for example, `O=Company XYZ\\, Inc.'. Other characters that
+ require escaping are listed in [RFC2253] and are to be escaped
+ as defined therein.
o Public Data (variable length) - Includes the actual
public data of the public key.
.in 3
All fields in the public key are in MSB (most significant byte first)
-order. All strings in the public key are UTF-8 encoded.
+order. All strings in the public key MUST be 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
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
-understand the order of the backup routers. It is not required that
+The order of the backup routers are decided at the local configuration
+phase. 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
+may be a redundant server in the cell that does not accept normal client
connections at all. It may be reserved purely for the backup purposes.
-These, however, are cell management issues.
If also the first backup router is down as well and there is another
backup router in the cell then it will start acting as the primary
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
-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_PACKET_FAILURE with type value 21 (4 bytes, MSB first order) 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
-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.
+clients, channels, channel users, channel user modes, channel modes,
+topics and other information 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.
The backup router too must announce its servers, clients, channels
and other information to the new primary router. The primary router
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 (4 bytes, MSB first)
- 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
+ order) 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 1 to its current primary router to indicate that it will
update their local database to understand that the clients are
not originated from the backup router but from the locally connected
servers. After that they MUST announce their channels, channel
- users, modes etc. to the primary router. They must not use the
+ users, modes etc. to the primary router. They MUST NOT use the
backup router connection after this and the connection is considered
- to be passive connection. The implementations SHOULD be able
+ to be passive connection. The implementation SHOULD be able
to disable the connection without closing the actual link.
After this protocol is executed the backup router is now again normal
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).
-When the router receives this packet it must not use the connection
+When the router receives this packet it MUST NOT use the connection
as active connection but to understand that it cannot act as primary
router in the cell. It must wait that the backup router connects to
it, and the backup resuming protocol is executed.
20 SILC_SERVER_BACKUP_START_REPLACED
21 SILC_SERVER_BACKUP_START_USE
-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].
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].
+so on. The [SILC2], [SILC3] and [SILC4] permeate this section's
+definitions.
+
+
.ti 0
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, a 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
in [SILC3].
After successful key exchange and authentication protocol the client
-registers itself by sending SILC_PACKET_NEW_CLIENT packet to the
+MUST register itself by sending SILC_PACKET_NEW_CLIENT packet to the
server. This packet includes various information about the client
that the server uses to create the client. Server creates the client
and sends SILC_PACKET_NEW_ID to the client which includes the created
way to get the true information about client if it is available.
The nickname of client is initially set to the username sent in the
-SILC_PACKET_NEW_CLIENT packet. User should set the nickname to more
+SILC_PACKET_NEW_CLIENT packet. User may set the nickname to more
suitable by sending SILC_COMMAND_NICK command. However, this is not
required as part of registration process.
digital signatures.
After server and router has successfully performed the key exchange
-and connection authentication protocol, the server register itself
+and connection authentication protocol, the server MUST register itself
to the router by sending SILC_PACKET_NEW_SERVER packet. This packet
includes the server's Server ID that it has created by itself and
-other relevant information about the server.
+other relevant information about the server. The router receiving the
+ID MUST verify that the IP address in the Server ID is same as the
+server's real IP address.
After router has received the SILC_PACKET_NEW_SERVER packet it
distributes the information about newly registered server to all routers
the join command MUST start using the received Channel ID in the channel
message communication thereafter. Client also receives the key for the
channel in the command reply. Note that the channel key is never
-generated if the SILC_CMODE_PRIVKEY mode is set.
+generated or distributed if the SILC_CMODE_PRIVKEY mode is set.
.ti 0
how channel messages must be encrypted and decrypted when router is
processing them.
+If the key changes very often due to joining traffic on the channel it
+is RECOMMENDED that client implementation would cache some of the old
+channel keys for short period of time so that it is able to decrypt all
+channel messages it receives. It is possible that on heavy traffic
+channel a message encrypted with channel key that was just changed
+is received by client after the new key was set into use. This is
+possible because not all clients may receive the new key at the same
+time, and may still be sending messages encrypted with the old key.
+
When client receives the SILC_PACKET_CHANNEL_KEY packet with the
Channel Key Payload it MUST process the key data to create encryption
and decryption key, and to create the HMAC key that is used to compute
Private messages are sent point to point. Client explicitly destine
a private message to specific client that is delivered to only to that
client. No other client may receive the private message. The receiver
-of the private message is destined in the SILC Packet Header as any
-other packet as well.
+of the private message is destined in the SILC Packet Header as in any
+other packet as well. The Source ID in the SILC Packet Header MUST be
+the ID of the sender of the message.
If the sender of a private message does not know the receiver's Client
ID, it MUST resolve it from server. There are two ways to resolve the
from its own server.
-
.ti 0
4.10 Closing Connection
the network has the SILC_UMODE_REJECT_WATCHING user mode set.
+
+
.ti 0
4.11 Detaching and Resuming a Session
MUST send SILC_PACKET_RESUME_CLIENT packet. This packet is used to
perform the resuming procedure. The packet MUST include the detached
client's Client ID, which the client must know. It also includes
-Authentication Payload which includes signature made with the client's
-private key. The signature is computed as defined in the section
-3.9.1. Thus, the authentication method MUST be based in public key
-authentication.
+Authentication Payload which includes signature computed with the
+client's private key. The signature is computed as defined in the
+section 3.9.1. Thus, the authentication method MUST be based in
+public key authentication.
When server receives the SILC_PACKET_RESUME_CLIENT packet it MUST
do the following: Server checks that the Client ID is valid client
packet to the client. Only after this the client is resumed back
to the network and may start sending packets and messages.
-It is also possible that the server does not know about the global
-channels that the client has joined. In this case it join the client
-internally to the channels, generate new channel keys and distribute the
-keys to the channels as described in section 4.4.
+It is also possible that the server did not know about the global
+channels before the client resumed. In this case it join the client
+to the channels, generate new channel keys and distribute the keys
+to the channels as described in section 4.4.
It is implementation issue for how long servers keep detached client
sessions. It is RECOMMENDED that the detached sessions would be
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
+[RFC1321] Rivest R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+[RFC3174] Eastlake, F., et al., "US Secure Hash Algorithm 1 (SHA1)",
+ RFC 3174, September 2001.
+
[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
Version 1.5", RFC 2315, March 1998.
+[RFC2253] Wahl, M., et al., "Lightweight Directory Access Protocol
+ (v3): UTF-8 String Representation of Distinguished Names",
+ RFC 2253, December 1997.
+
.ti 0
7 Author's Address
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+
+.ti 0
+8 Full Copyright Statement
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
projects / silc.git / commitdiff