.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 25 November 2002
+.ds RH 26 November 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-06.txt 25 November 2002
-Expires: 25 April 2003
+draft-riikonen-silc-spec-06.txt 26 November 2002
+Expires: 26 April 2003
.in 3
3.10.3 Hash Functions ..................................... 26
3.10.4 MAC Algorithms ..................................... 27
3.10.5 Compression Algorithms ............................. 27
- 3.11 SILC Public Key .......................................... 27
+ 3.11 SILC Public Key .......................................... 28
3.12 SILC Version Detection ................................... 30
- 3.13 Backup Routers ........................................... 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 ................. 35
+ 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.7 Channel Message Sending and Reception ..................... 43
4.8 Session Key Regeneration .................................. 43
4.9 Command Sending and Reception ............................. 44
- 4.10 Closing Connection ....................................... 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
List of Figures
.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
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
Figure 6: Counter Block
.in 6
-o Truncated HASH from SKE (4 bytes) - This value is the 32 most
- significant bits 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 64
- most significant bits 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 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)
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 (same IV is used
-to encrypt all blocks in the given 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.
+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
Additional compression algorithms MAY be defined to be used in SILC.
+
.ti 0
3.11 SILC Public Key
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.2-<software version>. If new protocol version
causes incompatibilities with older version the <minor> version number
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
is defined in [SILC2].
+
+
.ti 0
3.13.3 Discussion on Backup Router Scheme
generated if the SILC_CMODE_PRIVKEY mode is set.
-
.ti 0
4.4 Channel Key Generation
from its own server.
+
.ti 0
4.10 Closing Connection
EMail: priikone@iki.fi
-This Internet-Draft expires 25 April 2003
+This Internet-Draft expires 26 April 2003
projects / crypto.git / blobdiff