.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 26 November 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-06.txt XXX
-Expires: XXX
+draft-riikonen-silc-spec-06.txt 26 November 2002
+Expires: 26 April 2003
.in 3
1.1 Requirements Terminology .................................. 4
2 SILC Concepts ................................................. 4
2.1 SILC Network Topology ..................................... 4
- 2.2 Communication Inside a Cell ............................... 5
+ 2.2 Communication Inside a Cell ............................... 6
2.3 Communication in the Network .............................. 6
2.4 Channel Communication ..................................... 7
- 2.5 Router Connections ........................................ 7
+ 2.5 Router Connections ........................................ 8
3 SILC Specification ............................................ 8
- 3.1 Client .................................................... 8
+ 3.1 Client .................................................... 9
3.1.1 Client ID ........................................... 9
3.2 Server .................................................... 10
3.2.1 Server's Local ID List .............................. 10
3.9.1 Authentication Payload .............................. 21
3.10 Algorithms ............................................... 23
3.10.1 Ciphers ............................................ 23
- 3.10.2 Public Key Algorithms .............................. 24
- 3.10.3 Hash Functions ..................................... 24
- 3.10.4 MAC Algorithms ..................................... 25
- 3.10.5 Compression Algorithms ............................. 25
- 3.11 SILC Public Key .......................................... 26
- 3.12 SILC Version Detection ................................... 28
- 3.13 Backup Routers ........................................... 28
- 3.13.1 Switching to Backup Router ......................... 30
- 3.13.2 Resuming Primary Router ............................ 31
- 3.13.3 Discussion on Backup Router Scheme ................. 33
-4 SILC Procedures ............................................... 34
- 4.1 Creating Client Connection ................................ 34
- 4.2 Creating Server Connection ................................ 35
- 4.2.1 Announcing Clients, Channels and Servers ............ 36
- 4.3 Joining to a Channel ...................................... 37
- 4.4 Channel Key Generation .................................... 38
- 4.5 Private Message Sending and Reception ..................... 39
- 4.6 Private Message Key Generation ............................ 39
- 4.7 Channel Message Sending and Reception ..................... 40
- 4.8 Session Key Regeneration .................................. 40
- 4.9 Command Sending and Reception ............................. 41
- 4.10 Closing Connection ....................................... 42
- 4.11 Detaching and Resuming a Session ......................... 42
-5 Security Considerations ....................................... 44
-6 References .................................................... 45
-7 Author's Address .............................................. 47
-
+ 3.10.1.1 CBC Mode .................................. 24
+ 3.10.1.2 CTR Mode .................................. 24
+ 3.10.1.3 Randomized CBC Mode ....................... 25
+ 3.10.2 Public Key Algorithms .............................. 26
+ 3.10.3 Hash Functions ..................................... 26
+ 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.13 Backup Routers ........................................... 31
+ 3.13.1 Switching to Backup Router ......................... 32
+ 3.13.2 Resuming Primary Router ............................ 33
+ 3.13.3 Discussion on Backup Router Scheme ................. 36
+4 SILC Procedures ............................................... 36
+ 4.1 Creating Client Connection ................................ 36
+ 4.2 Creating Server Connection ................................ 38
+ 4.2.1 Announcing Clients, Channels and Servers ............ 38
+ 4.3 Joining to a Channel ...................................... 39
+ 4.4 Channel Key Generation .................................... 41
+ 4.5 Private Message Sending and Reception ..................... 41
+ 4.6 Private Message Key Generation ............................ 42
+ 4.7 Channel Message Sending and Reception ..................... 43
+ 4.8 Session Key Regeneration .................................. 43
+ 4.9 Command Sending and Reception ............................. 44
+ 4.10 Closing Connection ....................................... 45
+ 4.11 Detaching and Resuming a Session ......................... 45
+5 Security Considerations ....................................... 47
+6 References .................................................... 48
+7 Author's Address .............................................. 49
.ti 0
Figure 3: Communication Between Cells
Figure 4: Router Connections
Figure 5: SILC Public Key
+Figure 6: Counter Block
.ti 0
.ti 0
2.1 SILC Network Topology
-SILC network is a cellular network as opposed to tree style network
-topology. 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 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
+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
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 cellular like network, where routers
-are in the center of the cell and servers are connected to the router.
-
+This, on the other hand, leads to kind of a cellular like network, where
+routers are in the center of the cell and servers are connected to the
+router.
The following diagram represents SILC network topology.
-
-
.in 16
.nf
1 --- S1 S4 --- 5 S2 --- 1
local clients on the channel.
+
.ti 0
2.5 Router Connections
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 must not be seen by the
+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
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 causes the server names or client's host names
-to be used along with the nicknames 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 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.
.ti 0
ID's. Collisions are not expected to happen. The Client ID is defined
as follows.
-
-
.in 6
128 bit Client ID based on IPv4 addresses:
Normal server also keeps information about locally created channels and
their Channel ID's.
-
Hence, local list for normal server includes:
.in 6
name since these are not needed by the router. The router keeps only
information that it needs.
-
Hence, local list for router includes:
.in 6
client list - All clients in the cell
o Client ID
-
channel list - All channels in the cell
o Channel ID
o Client ID's on channel
packet. The original sender, for example client, assembles the packet
and the packet header and server or router between the sender and the
receiver MUST NOT change the packet header. Note however, that some
-packets such as commands may resent by a server to serve the client's
-original command. In this case the command packet send by the server
+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.
Note that the packet and the packet header may be encrypted with
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.
o Server determines local clients on the channel and sends the
packet to the client.
-o All clients receiving the packet decrypts the packet.
+o All clients receiving the packet decrypts it.
.ti 0
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, usually clients are accepted
+client connecting to the server. However, clients may be accepted
to connect to server without explicit authentication. Servers are
-required use authentication protocol when connecting. The authentication
-may be based on passphrase (pre-shared-secret) or public key. All
-passphrases sent in SILC protocol MUST be UTF-8 [RFC2279] encoded.
-The connection authentication protocol is described in detail in [SILC3].
+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].
.ti 0
The format of the Authentication Payload is as follows:
-
.in 5
.nf
1 2 3
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
-this payload is also encrypted.
+also this payload is encrypted.
.ti 0
The following ciphers are defined in SILC protocol:
+aes-256-cbc AES in CBC mode, 256 bit key (REQUIRED)
+aes-256-ctr AES in CTR mode, 256 bit key (RECOMMENDED)
+aes-256-rcbc AES in randomized CBC mode, 256 bit key (OPTIONAL)
+aes-192-<mode> AES in <mode> mode, 192 bit key (OPTIONAL)
+aes-128-<mode> AES in <mode> mode, 128 bit key (RECOMMENDED)
+twofish-256-<mode> Twofish in <mode> mode, 256 bit key (OPTIONAL)
+twofish-192-<mode> Twofish in <mode> mode, 192 bit key (OPTIONAL)
+twofish-128-<mode> Twofish in <mode> mode, 128 bit key (OPTIONAL)
+cast-256-<mode> CAST-256 in <mode> mode, 256 bit key (OPTIONAL)
+cast-192-<mode> CAST-256 in <mode> mode, 192 bit key (OPTIONAL)
+cast-128-<mode> CAST-256 in <mode> mode, 128 bit key (OPTIONAL)
+serpent-<len>-<mode> Serpent in <mode> mode, <len> bit key (OPTIONAL)
+rc6-<len>-<mode> RC6 in <mode> mode, <len> bit key (OPTIONAL)
+mars-<len>-<mode> MARS in <mode> mode, <len> bit key (OPTIONAL)
+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
+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
+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.
+
+
+.ti 0
+3.10.1.1 CBC Mode
+
+The "cbc" encryption mode is CBC mode with inter-packet chaining. This
+means that the Initial Vector (IV) for the next encryption block is
+the previous ciphertext block. The very first IV MUST be random and is
+generated as described in [SILC3].
+
+
+.ti 0
+3.10.1.2 CTR Mode
+
+The "ctr" encryption mode is CTR mode. The CTR mode in SILC is stateful
+in encryption and decryption. Both sender and receiver maintain the
+counter for the CTR mode and thus can precompute the key stream for
+encryption and decryption. By default, CTR mode does not require
+plaintext padding, however implementations MAY apply padding to the
+packets. If the last key block is larger than the last plaintext block
+the resulted value is truncated to the size of the plaintext block and
+the most significant bits are used. When sending authentication data
+inside packets the maximum amount of padding SHOULD be applied with
+CTR mode as well.
+
+In CTR mode only the encryption operation of the cipher is used. The
+decryption operation is not needed since both encryption and decryption
+process is simple XOR with the plaintext block and the key stream block.
+
+The counter block is used to create the key for the CTR mode. When
+SILC specifications refer to Initial Vector (IV) in general cases, in
+case of CTR mode it refers to the counter block. The format of the
+128 bit counter block is as follows:
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Truncated HASH from SKE |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Sending/Receiving IV from SKE |
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Block Counter |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 6: Counter Block
+
.in 6
-aes-256-cbc AES in CBC mode, 256 bit key (REQUIRED)
-aes-192-cbc AES in CBC mode, 192 bit key (OPTIONAL)
-aes-128-cbc AES in CBC mode, 128 bit key (OPTIONAL)
-twofish-256-cbc Twofish in CBC mode, 256 bit key (OPTIONAL)
-twofish-192-cbc Twofish in CBC mode, 192 bit key (OPTIONAL)
-twofish-128-cbc Twofish in CBC mode, 128 bit key (OPTIONAL)
-blowfish-128-cbc Blowfish in CBC mode, 128 bit key (OPTIONAL)
-cast-256-cbc CAST-256 in CBC mode, 256 bit key (OPTIONAL)
-cast-192-cbc CAST-256 in CBC mode, 192 bit key (OPTIONAL)
-cast-128-cbc CAST-256 in CBC mode, 128 bit key (OPTIONAL)
-rc6-256-cbc RC6 in CBC mode, 256 bit key (OPTIONAL)
-rc6-192-cbc RC6 in CBC mode, 192 bit key (OPTIONAL)
-rc6-128-cbc RC6 in CBC mode, 128 bit key (OPTIONAL)
-mars-256-cbc Mars in CBC mode, 256 bit key (OPTIONAL)
-mars-192-cbc Mars in CBC mode, 192 bit key (OPTIONAL)
-mars-128-cbc Mars in CBC mode, 128 bit key (OPTIONAL)
-none No encryption (OPTIONAL)
+o Truncated HASH from SKE (4 bytes) - This value is the first 4
+ bytes from the HASH value that was computed as a result of SKE
+ protocol. This acts as session identifier and each rekey MUST
+ produce a new HASH value.
+
+o Sending/Receiving IV from SKE (8 bytes) - This value is the
+ first 8 bytes from the Sending IV or Receiving IV generated in
+ the SKE protocol. When this mode is used to encrypt sending
+ traffic the Sending IV is used, when used to decrypt receiving
+ traffic the Receiving IV is used. This assures that two parties
+ of the protocol use different IV for sending traffic. Each rekey
+ MUST produce a new value.
+
+o Block Counter (4 bytes) - This is the counter value for the
+ counter block and is MSB ordered number starting from one (1)
+ value for first block and incrementing for subsequent blocks.
+ The same value MUST NOT be used twice. The rekey MUST be
+ performed before this counter value wraps.
.in 3
+CTR mode MUST NOT be used with "none" MAC. Implementations also MUST
+assure that the same counter block is not used to encrypt more than
+one block. Also, the key material used with CTR mode MUST be fresh
+key material. Static keys (pre-shared keys) MUST NOT be used with
+CTR mode. For this reason using CTR mode to encrypt for example
+channel messages or private messages with a pre-shared key is
+inappropriate. For private messages, the Key Agreement could be
+performed to produce fresh key material.
-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 algorithms except in special
-debugging mode.
+If the IV Included flag was negotiated in SKE, implementations SHOULD
+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
+not stateful and receiver cannot precompute the key stream.
-Additional ciphers MAY be defined to be used in SILC by using the
-same name format as above.
+
+.ti 0
+3.10.1.3 Randomized CBC Mode
+
+The "rcbc" encryption mode is CBC mode with randomized IV. This means
+that each IV for each packet MUST be chosen randomly. When encrypting
+more than one block the normal inter-packet chaining is used, but for
+the first block new random IV is selected in each packet. In this mode
+the IV is appended at the end of the last ciphertext block and thus
+delivered to the recipient. This mode increases the ciphertext size by
+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.
.ti 0
represented as sign(). The signature computing procedure is dependent
of the public key algorithm, and the public key or certificate encoding.
When using SILC public key the signature is computed as described in
-previous section for RSA and DSS keys. When using SSH2 public keys
-the signature is computed as described in [SSH-TRANS]. When using
-X.509 version 3 certificates the signature is computed as described
-in [PKCS7]. When using OpenPGP certificates the signature is computed
-as described in [PGP].
+previous paragraph for RSA and DSS keys. If the hash function is not
+specified separately for signing process sha1 MUST be used. When using
+SSH2 public keys the signature is computed as described in [SSH-TRANS].
+When using X.509 version 3 certificates the signature is computed as
+described in [PKCS7]. When using OpenPGP certificates the signature is
+computed as described in [PGP].
.ti 0
.in 6
sha1 SHA-1, length = 20 (REQUIRED)
-md5 MD5, length = 16 (OPTIONAL)
+md5 MD5, length = 16 (RECOMMENDED)
.in 3
+
.ti 0
3.10.4 MAC Algorithms
The following MAC algorithms are defined in SILC protocol:
.in 6
-hmac-sha1-96 HMAC-SHA1, length = 12 (REQUIRED)
-hmac-md5-96 HMAC-MD5, length = 12 (OPTIONAL)
-hmac-sha1 HMAC-SHA1, length = 20 (OPTIONAL)
-hmac-md5 HMAC-MD5, length = 16 (OPTIONAL)
-none No MAC (OPTIONAL)
+hmac-sha1-96 HMAC-SHA1, length = 12 bytes (REQUIRED)
+hmac-md5-96 HMAC-MD5, length = 12 bytes (OPTIONAL)
+hmac-sha1 HMAC-SHA1, length = 20 bytes (OPTIONAL)
+hmac-md5 HMAC-MD5, length = 16 bytes (OPTIONAL)
+none No MAC (OPTIONAL)
.in 3
-The none MAC is not recommended to be used as the packet is not
+The "none" MAC is not recommended to be used as the packet is not
authenticated when MAC is not computed. It is recommended that no
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]
+[Menezes].
Additional MAC algorithms MAY be defined to be used in SILC.
-
-
.ti 0
3.10.5 Compression Algorithms
Additional compression algorithms MAY be defined to be used in SILC.
+
.ti 0
3.11 SILC Public Key
All fields in the public key are in MSB (most significant byte first)
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
+to use SILC Public Key).
+
.ti 0
3.12 SILC Version Detection
software version = <major>[.<minor>[.<build or vendor string>]]
.in 3
-Protocol version MAY provide both major and minor version. Currently
+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.1-<software version>. If new protocol version
+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.
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:
.in 6
SILC-1.1-2.0.2
SILC-1.0-1.2
-SILC-1.1-1.0.VendorXYZ
-SILC-1.1-2.4.5 Vendor Limited
+SILC-1.2-1.0.VendorXYZ
+SILC-1.2-2.4.5 Vendor Limited
.in 3
database to understand that the route to the primary router will now go
to the backup router.
-The servers connected to the backup router must 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
+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
+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.
+
+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.
all of its channels, channel users, modes etc. to 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 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
resign as being primary router. Then, backup router sends the
5. Backup router MUST wait for all packets with type value 3 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 send earlier.
+ 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
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
- the backup router should still route all packets it is receiving
+ the backup router must still route all packets it is receiving
from server connections.
6. The primary router receives the packet and send the
3 SILC_SERVER_BACKUP_START_CONNECTED
4 SILC_SERVER_BACKUP_START_ENDING
5 SILC_SERVER_BACKUP_START_RESUMED
- 6 SILC_SERVER_BACKUP_START_GLOBAL
+ 6 SILC_SERVER_BACKUP_START_RESUMED_GLOBAL
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
discarded. The SILC_PACKET_RESUME_ROUTER packet and its payload
is defined in [SILC2].
+
+
.ti 0
3.13.3 Discussion on Backup Router Scheme
One difference is that server MUST perform connection authentication
protocol with proper authentication. A proper authentication is based
-on passphrase or public key authentication.
+on passphrase authentication or public key authentication based on
+digital signatures.
After server and router has successfully performed the key exchange
and connection authentication protocol, the server register itself
ID Payloads into the SILC_PACKET_NEW_ID packet.
Also, clients' modes (user modes in SILC) MUST be announced. This is
-done by compiling a list of Notify Payloads with the
-SILC_NOTIFY_UMODE_CHANGE nofity type into the SILC_PACKET_NOTIFY packet.
-
-Also, channel's topics MUST be announced by compiling a list of Notify
-Payloads with the SILC_NOTIFY_TOPIC_SET notify type into the
-SILC_PACKET_NOTIFY packet.
+done by compiling a list of Notify Payloads with SILC_NOTIFY_UMODE_CHANGE
+notify type into the SILC_PACKET_NOTIFY packet. Also, channel's topics
+MUST be announced by compiling a list of Notify Payloads with the
+SILC_NOTIFY_TOPIC_SET notify type into the SILC_PACKET_NOTIFY packet.
The router which receives these lists MUST process them and broadcast
-the packets to its primary route.
-
-When processing the announced channels and channel users the router MUST
-check whether a channel exists already with the same name. If channel
-exists with the same name it MUST check whether the Channel ID is
-different. If the Channel ID is different the router MUST send the notify
-type SILC_NOTIFY_TYPE_CHANNEL_CHANGE to the server to force the channel ID
-change to the ID the router has. If the mode of the channel is different
-the router MUST send the notify type SILC_NOTIFY_TYPE_CMODE_CHANGE to the
-server to force the mode change to the mode that the router has.
+the packets to its primary route. When processing the announced channels
+and channel users the router MUST check whether a channel exists already
+with the same name. If channel exists with the same name it MUST check
+whether the Channel ID is different. If the Channel ID is different the
+router MUST send the notify type SILC_NOTIFY_TYPE_CHANNEL_CHANGE to the
+server to force the channel ID change to the ID the router has. If the
+mode of the channel is different the router MUST send the notify type
+SILC_NOTIFY_TYPE_CMODE_CHANGE to the server to force the mode change
+to the mode that the router has.
The router MUST also generate new channel key and distribute it to the
channel. The key MUST NOT be generated if the SILC_CMODE_PRIVKEY mode
The raw key data is the key data received in the Channel Key Payload.
The hash() function is the hash function used in the HMAC of the channel.
-Note that the server MUST also save the channel key.
+Note that the server also MUST save the channel key.
.ti 0
4.5 Private Message Sending and Reception
-Private messages are sent point to point. Client explicitly destines
+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
.ti 0
4.6 Private Message Key Generation
-Private message MAY be protected by the key generated by the client.
+Private message MAY be protected with a key generated by the client.
The key may be generated and sent to the other client by sending packet
SILC_PACKET_PRIVATE_MESSAGE_KEY which travels through the network
and is secured by session keys. After that the private message key
is used in the private message communication between those clients.
+The key sent inside the payload SHOULD be randomly generated. This
+packet MUST NOT be used to send pre-shared keys.
Other choice is to entirely use keys that are not sent through
the SILC network at all. This significantly adds security. This key
-would be pre-shared-key that is known by both of the clients. Both
+could be a pre-shared-key that is known by both of the clients. Both
agree about using the key and starts sending packets that indicate
-that the private message is secured using private message key.
-
-The key material used as private message key is implementation issue.
-However, SILC_PACKET_KEY_AGREEMENT packet MAY be used to negotiate
-the key material. If the key is normal pre-shared-key or randomly
-generated key, and the SILC_PACKET_KEY_AGREEMENT was not used, then
-the key material SHOULD be processed as defined in the [SILC3]. In
-the processing, however, the HASH, as defined in [SILC3] MUST be
-ignored. After processing the key material it is employed as defined
-in [SILC3], however, the HMAC key material MUST be discarded.
-
-If the key is pre-shared-key or randomly generated the implementations
-SHOULD use the SILC protocol's mandatory cipher as the cipher. If the
-SKE was used to negotiate key material the cipher was negotiated as well,
-and may be different from default cipher.
+that the private message is secured using private message key. In
+case of pre-shared keys (static keys) the IV used in encryption SHOULD
+be chosen randomly.
+
+It is also possible to negotiate fresh key material by performing
+Key Agreement. The SILC_PACKET_KEY_AGREEMENT packet MAY be used to
+negotiate the fresh key material. In this case the resulted key
+material is used to secure the private messages. Also, the IV used
+in encryption is used as defined in [SILC3], unless otherwise stated
+by the encryption mode used. By performing Key Agreement the clients
+may negotiate the cipher and HMAC to be used in the private message
+encryption and to negotiate additional security parameters.
+
+If the key is pre-shared key or other key material not generated by
+Key Agreement, then the key material SHOULD be processed as defined
+in [SILC3]. In the processing, however, the HASH, as defined in
+[SILC3] MUST be ignored. After processing the key material it is
+employed as defined in [SILC3]. In this case also, implementations
+SHOULD use the SILC protocol's mandatory cipher and HMAC in private
+message encryption.
.ti 0
from its own server.
+
.ti 0
4.10 Closing Connection
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 26 April 2003
projects / silc.git / blobdiff