.pl 10.0i
   .po 0
   .ll 7.2i
   .lt 7.2i
   .nr LL 7.2i
   .nr LT 7.2i
   .ds LF Riikonen
   .ds RF FORMFEED[Page %]
   .ds CF
  .ds LH Internet Draft
  .ds RH 13 September 2000
  .ds CH
  .na
  .hy 0
  .in 0
  .nf
  Network Working Group                                      P. Riikonen
  Internet-Draft
  draft-riikonen-silc-spec-00.txt                      13 September 2000
  Expires: 13 May 2001
  
  .in 3
  
  .ce 3
  Secure Internet Live Conferencing (SILC),
  Protocol Specification
  <draft-riikonen-silc-spec-00.txt>
  
  .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.   
  
  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 Internet-Draft Shadow Directories can be accessed at   
  http://www.ietf.org/shadow.html   
  
  The distribution of this memo is unlimited.  
  
  
  .ti 0
  Abstract
  
  This memo describes a Secure Internet Live Conferencing (SILC)
  protocol which provides secure conferencing services over insecure
  network channel.  SILC is IRC [IRC] like protocol, however, it is 
  not equivalent to IRC and does not support IRC.  Strong cryptographic
  methods are used to protect SILC packets inside SILC network.  Two
  other Internet Drafts relates very closely to this memo;  SILC Packet
  Protocol [SILC2] and SILC Key Exchange and Authentication Protocols
  [SILC3].
  
  
  
  
  
  
  
  
  .ti 0
  Table of Contents
  
  .nf
  1 Introduction ..................................................  3
  2 SILC Concepts .................................................  3
    2.1 SILC Network Topology .....................................  4
    2.2 Communication Inside a Cell ...............................  5
    2.3 Communication in the Network ..............................  6
    2.4 Channel Communication .....................................  7
  3 SILC Specification ............................................  7
    3.1 Client ....................................................  7
        3.1.1 Client ID ...........................................  8
    3.2 Server ....................................................  9
        3.2.1 Server's Local ID List ..............................  9
        3.2.2 Server ID ........................................... 10
        3.2.3 SILC Server Ports ................................... 11
    3.3 Router .................................................... 11
        3.3.1 Router's Local ID List .............................. 11
        3.3.2 Router's Global ID List ............................. 12
        3.3.3 Router's Server ID .................................. 13
    3.4 Channels .................................................. 13
        3.4.1 Channel ID .......................................... 14
    3.5 Operators ................................................. 14
    3.6 SILC Commands ............................................. 15
    3.7 SILC Packets .............................................. 15
    3.8 Packet Encryption ......................................... 16
        3.8.1 Determination of the Source and the Destination ..... 16
        3.8.2 Client To Client .................................... 17
       3.8.3 Client To Channel ................................... 18
       3.8.4 Server To Server .................................... 19
   3.9 Key Exchange And Authentication ........................... 19
   3.10 Algorithms ............................................... 19
       3.10.1 Ciphers ............................................ 19
       3.10.2 Public Key Algorithms .............................. 20
       3.10.3 MAC Algorithms ..................................... 20
       3.10.4 Compression Algorithms ............................. 21
   3.11 SILC Public Key .......................................... 21
   3.12 SILC Version Detection ................................... 24
 4 SILC Procedures ............................................... 24
   4.1 Creating Client Connection ................................ 24
   4.2 Creating Server Connection ................................ 25
   4.3 Joining to a Channel ...................................... 26
   4.4 Channel Key Generation .................................... 27
   4.5 Private Message Sending and Reception ..................... 27
   4.6 Private Message Key Generation ............................ 28
   4.7 Channel Message Sending and Reception ..................... 29
   4.8 Session Key Regeneration .................................. 29
   4.9 Command Sending and Reception ............................. 29
 5 SILC Commands ................................................. 30
   5.1 SILC Commands Syntax ...................................... 30
   5.2 SILC Commands List ........................................ 32
   5.3 SILC Command Status Types ................................. 53
       5.3.1 SILC Command Status Payload ......................... 53
       5.3.2 SILC Command Status List ............................ 54
 6 Security Considerations ....................................... 59
 7 References .................................................... 59
 8 Author's Address .............................................. 60
 
 
 .ti 0
 List of Figures
 
 .nf
 Figure 1:  SILC Network Topology
 Figure 2:  Communication Inside cell
 Figure 3:  Communication Between Cells
 Figure 4:  SILC Public Key
 Figure 5:  SILC Command Status Payload
 
 
 .ti 0
 1. Introduction
 
 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.
 
 Strong cryptographic methods are used to protect SILC packets inside
 SILC network.  Two other Internet Drafts relates very closely to this
 memo; SILC Packet Protocol [SILC2] and SILC Key Exchange and
 Authentication Protocols [SILC3].
 
 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
 and decryption in detail.
 
 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 SILC protocol has been developed to work on TCP/IP network
 protocol, although it could be made to work on other network protocols
 with only minor changes.  However, it is recommended that TCP/IP
 protocol is used under SILC protocol.  Typical implementation would
 be made in client-server model.
 
 
 .ti 0
 2. SILC Concepts
 
 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 
 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 
 clear.
 
 
 .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.
 
 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 cellular like network, where routers 
 are in the centrum on the cell and servers are connected to the router.
 
 Following diagram represents SILC network topology.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 .in 8
 .nf
   ---- ---- ----         ---- ---- ----
  | S8 | S5 | S4 |       | S7 | S5 | S6 |
  ----- ---- -----       ----- ---- -----
 | S7 | S/R1 | S2 | --- | S8 | S/R2 | S4 |
  ---- ------ ----       ---- ------ ----
  | S6 | S3 | S1 |       | S1 | S3 | S2 |         ---- ----
   ---- ---- ----         ---- ---- ----         | S3 | S1 |
      Cell 1.   \\             Cell 2.  | \\____  ----- -----
                 |                     |        | S4 | S/R4 |
     ---- ---- ----         ---- ---- ----       ---- ------
    | S7 | S4 | S2 |       | S1 | S3 | S2 |      | S2 | S5 |
    ----- ---- -----       ----- ---- -----       ---- ----
   | S6 | S/R3 | S1 | --- | S4 | S/R5 | S5 |       Cell 4.
    ---- ------ ----       ---- ------ ----
    | S8 | S5 | S3 |       | S6 | S7 | S8 |     ... etc ...
     ---- ---- ----         ---- ---- ----
        Cell 3.                Cell 5.
 .in 3
 
 .ce
 Figure 1:  SILC Network Topology
 
 
 A cell is formed when a server or servers connect to one router.  In
 SILC network normal server cannot directly connect to other normal
 server.  Normal server may only connect to SILC router which then
 routes the messages to the other servers in the cell.  Router servers
 on the other hand may connect to other routers to form the actual SILC 
 network, as seen in above figure.  However, router is also normal SILC 
 server; clients may connect to it the same way as to normal SILC 
 servers.  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 
 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 will be written.
 
 
 .ti 0
 2.2 Communication Inside a Cell
 
 It is always guaranteed that inside a cell message is delivered to the 
 recipient with at most two server hops.  Client who 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 
 to the other server in the cell.  Following diagram represents this 
 scenario.
 
 
 .in 25
 .nf
 1 --- S1     S4 --- 5
          S/R
  2 -- S2     S3
      /        |
     4         3
 .in 3
 
 
 .ce
 Figure 2:  Communication Inside cell
 
 
 Example:  Client 1. connected to Server 1. message sent to
           Client 4. connected to Server 2. travels from Server 1.
           first to Router which routes the message to Server 2.
           which then sends it to the Client 4.  All the other
           servers in the cell will not see the routed message.
 
 
 If 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 
 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 
 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.  Following diagram
 represents message sending between cells.
 
 
 .in 16
 .nf
 1 --- S1     S4 --- 5            S2 --- 1
          S/R - - - - - - - - S/R
  2 -- S2     S3           S1
      /        |             \\
     4         3              2
 
    Cell 1.               Cell 2.
 .in 3
 
 
 .ce
 Figure 3:  Communication Between Cells
 
 
 Example:  Client 5. connected to Server 4. in Cell 1. message sent
           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 
           Server 1.  All the other servers and routers in the
           network will not see the routed message.
 
 
 The optimal case of message delivery from client point of view is
 when clients are connected directly to the routers and the messages
 are delivered from one router to the other router.
 
 
 .ti 0 
 2.4 Channel Communication
 
 Messages may be sent to group of clients as well.  Sending messages to
 many clients works the same way as sending messages point to point, from
 message delivery point of view.  Security issues are another matter
 which are not discussed in this section.
 
 Router server handles the message routing to multiple recipients.  If 
 any recipient is not in the same cell as the sender the messages are 
 routed further.
 
 Server distributes the channel message to its local clients who are 
 joined to the channel.  Also, router distributes the message to its 
 local clients on the channel.
 
 
 .ti 0
 3. SILC Specification
 
 This section describes the SILC protocol.  However, [SILC2] and
 [SILC3] describes other important protocols that are part of this SILC
 specification and must be read.
 
 
 .ti 0
 3.1 Client
 
 A client is a piece of software connecting to SILC server.  SILC client 
 cannot be SILC server.  Purpose of clients is to provide the user 
 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
 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
 end user.
 
 Clients provide other information about the end user as well. Information
 such as the nickname of the user, username and the hostname 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 causes the server 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.  Another difference is that there are no limit of the length
 of the nickname in the SILC.
 
 
 .ti 0
 3.1.1 Client ID
 
 Client ID is used to identify users in the SILC network.  The Client ID
 is unique to the extent that there can be 2^128 different Client 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:
 
 32 bit  ServerID IP address (bits 1-32)
  8 bit  Random number
 88 bit  Truncated MD5 hash value of the nickname
 
 o Server ID IP address - Indicates the server where this
   client is coming from.  The IP address hence equals the
   server IP address where to the client has connected.
 
 o Random number - Random number to further randomize the
   Client ID.  This makes it possible to have 2^8 same
   nicknames from the same server IP address.
 
 o MD5 hash - MD5 hash value of the nickname is truncated
   taking 88 bits from the start of the hash value.  This
   hash value is used to search the user's Client ID from
   the ID lists.
 
 .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 
 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.
 
 
 .ti 0
 3.2 Server
 
 Servers are the most important parts of the SILC network.  They form the
 basis of the SILC, providing a point to which clients may connect to.
 There are two kinds of servers in SILC; normal servers and router servers.
 This section focuses on the normal server and router server is described
 in the section 3.3 Router.
 
 Normal servers may not directly connect to other normal server.  Normal
 servers may only directly connect to router server.  If the message sent
 by the client is destined outside the local server it is always sent to
 the router server for further routing.  Server may only have one active
 connection to router on same port.  Normal server may not connect to other
 cell's router except in situations where its cell's router is unavailable.
 
 Servers and routers in the SILC network are considered to be trusted.
 With out a doubt, servers that are set to work on ports above 1023 are
 not considered to be trusted.  Also, the service provider acts important
 role in the server's trustworthy.
 
 
 .ti 0
 3.2.1 Server's Local ID List
 
 Normal server keeps various information about the clients and their end
 users connected to it.  Every normal server must keep list of all locally
 connected clients, Client ID's, nicknames, usernames and hostnames and
 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
 of creating the Client ID's for their clients.
 
 Normal server also keeps information about locally created channels and
 their Channel ID's.
 
 
 
 
 
 
 
 
 Hence, local list for normal server includes:
 
 .in 6
 server list        - Router connection
    o Server name
    o Server IP address
    o Server ID
    o Sending key
    o Receiving key
    o Public key
 
 client list        - All clients in server
    o Nickname
    o Username@host
    o Real name
    o Client ID
    o Sending key
    o Receiving key
 
 channel list       - All channels in server
    o Channel name
    o Channel ID
    o Client ID's on channel
    o Client ID modes on channel
    o Channel key
 .in 3
 
 
 
 .ti 0
 3.2.2 Server ID
 
 Servers are distinguished from other servers by unique 64 bit Server ID.
 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 defined as follows.
 
 .in 6
 64 bit Server ID based on IPv4 addresses:
 
 32 bit  IP address of the server
 16 bit  Port
 16 bit  Random number
 
 o IP address of the server - This is the real IP address of
   the server.
 
 o Port - This is the port the server is binded to.
 
 o Random number - This is used to further randomize the Server ID.
 
 .in 3
 Collisions are not expected to happen in any conditions.  The Server ID
 is always created by the server itself and server is resposible of
 distributing it to the router.
 
 
 .ti 0
 3.2.3 SILC Server Ports
 
 Following ports has been assigned by IANA for the SILC protocol:
 
 .in 10
 silc            706/tcp    SILC
 silc            706/udp    SILC
 .in 3
 
 If there are needs to create new SILC networks in the future the port
 numbers must be officially assigned by the IANA.
 
 Server on network above privileged ports (>1023) should not be trusted
 as they could have been set up by untrusted party.
 
 
 .ti 0
 3.3 Router
 
 Router server in SILC network is responsible for keeping the cell together
 and routing messages to other servers and to other routers.  Router server
 is also a normal server thus clients may connect to it as it would be
 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.
 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.
 
 
 .ti 0
 3.3.1 Router's Local ID List
 
 Router server as well must keep local list of connected clients and
 locally created channels.  However, this list is extended to include all
 the informations of the entire cell, not just the server itself as for
 normal servers.
 
 However, on router this list is a lot smaller since routers do not keep
 information about user's nickname, username and hostname and real name
 since these are not needed by the router.  Router keeps only information
 that it needs.
 
 
 
 
 
 Hence, local list for router includes:
 
 .in 6
 server list        - All servers in the cell
    o Server name
    o Server ID
    o Router's Server ID
    o Sending key
    o Receiving key
 
 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
    o Client ID modes on channel
    o Channel key
 .in 3
 
 
 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.
 
 
 .ti 0
 3.3.2 Router's Global ID List
 
 Router server must also keep global list.  Normal servers do not have
 global list as they know only about local information.  Global list
 includes all the clients on SILC, their Client ID's, all created channels
 and their Channel ID's and all servers and routers on SILC and their
 Server ID's.  That is said, global list is for global information and the
 list must not include the local information already on the router's local
 list.
 
 Note that the global list does not include information like nicknames,
 usernames and hostnames or user's real names.  Router does not 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.
 
 Hence, global list includes:
 
 .in 6
 server list        - All servers in SILC
    o Server name
    o Server ID
    o Router's Server ID
 
 
 client list        - All clients in SILC
    o Client ID
 
 channel list       - All channels in SILC
    o Channel ID
    o Client ID's on channel
    o Client ID modes on channel
 .in 3
 
 
 .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.  Server ID's for routers are always
 created by the remote router where the router is connected to.
 
 
 .ti 0
 3.4 Channels
 
 A channel is a named group of one or more clients which will all receive
 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 leaves it.  When channel exists, any client
 can reference it using the name of the channel.
 
 Channel names are unique although the real uniqueness comes from 64 bit
 Channel ID that unifies each channel.  However, channel names are still
 unique and no two global channels with same name may exist.  Channel name
 is a string which begins with `#' character.  There is no limit on the
 length of the channel name.  Channel names may not contain any spaces
 (`  '), any non-printable ASCII characters, commas (`,') and wildcard
 characters.
 
 Channels can have operators that can administrate the channel and
 operate all of its modes.  Following operators on channel exist on SILC
 network.
 
 .in 6
 o Channel founder - When channel is created the joining client becomes
   channel founder.  Channel founder is channel operator with some more
   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 founder privileges cannot be removed by any other operator on
   channel.  When channel founder leaves the channel there is no channel
   founder on the channel.  Channel founder also cannot be removed by
   force from the channel.
 
 o Channel operator - When client joins to channel that has not existed
   previously it will become automatically channel operator (and channel
   founder discussed above).  Channel operator is able administrate the
   channel, set some modes on channel, remove a badly behaving client from
   the channel and promote other clients to become channel operator.
   The privileges are limited only to the particular channel.
 
   Normal channel user may be promoted (opped) to channel operator
   gaining channel operator privileges.  Channel founder or other channel
   operator may also demote (deop) channel operator to normal channel
   user.
 .in 3
 
 
 .ti 0
 3.4.1 Channel ID
 
 Channels are distinguished from other channels by unique Channel ID.
 The Channel ID is a 64 bit ID and collisions are not expected to happen
 in any conditions.  Channel names are just for logical use of channels.
 The Channel ID is created by the server where the channel is created.
 The Channel ID is defined as follows.
 
 .in 6
 64 bit Channel ID based on IPv4 addresses:
 
 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
 
 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 
   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.
 .in 3
 
 
 .ti 0
 3.5 Operators
 
 Operators are normal users with extra privileges to their server or
 router.  Usually these people are SILC server and router administrators
 that take care of their own server and clients on them.  The purpose of
 operators is to administrate the SILC server or router.  However, even
 an operator with highest privileges is not able to enter invite-only
 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
 their server or router.
 
 
 .ti 0
 3.6 SILC Commands
 
 Commands are very important part on SILC network especially for client
 which uses commands to operate on the SILC network.  Commands are used
 to set nickname, join to channel, change modes and many other things.
 
 Client usually sends the commands and server replies by sending a reply
 packet to the command.  Server may also send commands usually to serve
 the original client's request.  However, server may not send command
 to client and there are some commands that server must not send.  Server
 is also able to send the forwarded command packets.  For example, 
 SILC_COMMAND_JOIN is always forwarded packet.  See [SILC2] for more
 about packet forwarding.
 
 Note that the command reply is usually sent only after client has sent
 the command request but server is allowed to send command reply packet
 to client even if client has not requested the command.  Client may,
 however, choose not to accept the command reply, but there are some
 command replies that the client should accept.  Example of a such
 command reply is reply to SILC_COMMAND_CMODE command that the server
 uses to distribute the channel mode on all clients on the channel
 when the mode has changed.
 
 It is expected that some of the commands may be miss-used by clients
 resulting various problems on the server side.  Every implementation
 should assure that commands may not be executed more than once, say,
 in two (2) seconds.  This should be sufficient to prevent the miss-use
 of commands.
 
 SILC commands are described in section 5 SILC Commands.
 
 
 .ti 0
 3.7 SILC Packets
 
 Packets are naturally the most important part of the protocol and the
 packets are what actually makes the protocol.  Packets in SILC network
 are always encrypted using, usually, the shared secret session key
 or some other key, for example, channel key, when encrypting channel
 messages.  The SILC Packet Protocol is a wide protocol and is described
 in [SILC2].  This document does not define or describe details of
 SILC packets.
 
 
 
 
 .ti 0
 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].
 
 Client and its server shares secret symmetric session key which is
 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.
 
 Channels has their own key that are shared by every client on the channel.
 However, the channel keys are cell specific thus one cell does not know
 the channel key of the other cell, even if that key is for same channel.
 Channel key is also known by the routers and all servers that has clients
 on the channel.  However, channels may have channel private keys that
 are entirely local setting for client.  All clients on the channel must
 know the channel private key before hand to be able to talk on the
 channel.  In this case, no server or router knows the key for channel.
 
 Server shares secret symmetric session key with router which is
 established by the SILC Key Exchange Protocol.  Every packet passed from
 server to router, with exception of packets for channels, are encrypted
 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.
 
 
 .ti 0
 3.8.1 Determination of the Source and the Destination
 
 The source and the destination of the packet needs to be determined
 to be able to route the packets to correct receiver.  This information
 is available in the SILC Packet Header which is included in all packets
 sent in SILC network.  The SILC Packet Header is described in [SILC2].
 
 The header is always encrypted with the session key who is next receiver
 of the packet along the route.  The receiver of the packet, for example
 a router along the route, is able to determine the sender and the
 destination of the packet by decrypting the SILC Packet Header and
 checking the ID's attached to the header.  The ID's in the header will
 tell to where the packet needs to be sent and where it is coming from.
 
 The header in the packet does not change during the routing of the
 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 that the packet and the packet header may be encrypted with
 different keys.  For example, packets to channels are encrypted with
 the channel key, however, the header is encrypted with the session key
 as described above.  However, the header and the packet may be encrypted
 with same key.  This is case, for example, with command packets.
 
 
 .ti 0
 3.8.2 Client To Client
 
 Process of message delivery and encryption from client to another
 client is as follows.
 
 Example:  Private message from client to another client on different
           servers.  Clients do not share private message delivery
           keys; normal session keys are used.
 
 o Client 1. sends encrypted packet to its server.  The packet is
   encrypted with the session key shared between client and its
   server.
 
 o Server determines the destination of the packet and decrypts
   the packet.  Server encrypts the packet with session key shared
   between the server and its router, and sends the packet to the
   router.
 
 o Router determines the destination of the packet and decrypts
   the packet.  Router encrypts the packet with session key 
   shared between the router and the destination server, and sends
   the packet to the server.
 
 o Server determines the client to which the packet is destined
   to and decrypts the packet.  Server encrypts the packet with
   session key shared between the server and the destination client,
   and sends the packet to the client.
 
 o Client 2. decrypts the packet.
 
 
 Example:  Private message from client to another client on different
           servers.  Clients has established secret shared private
           message delivery key with each other and that is used in 
           the message encryption.
 
 o Client 1. sends encrypted packet to its server.  The packet is
   encrypted with the private message delivery key shared between
   clients.
 
 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
   packet to the server.
 
 o Server determines the client to which the packet is destined
   to and sends the packet to the client.
 
 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.
 
 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 
 packet to the destination same way as described above.
 
 
 .ti 0
 3.8.3 Client To Channel
 
 Process of message delivery from client on channel to all the clients
 on the channel.
 
 Example:  Channel of four users; two on same server, other two on
           different cells.  Client sends message to the channel.
 
 o Client 1. encrypts the packet with channel key and sends the
   packet to its server.
 
 o Server determines local clients on the channel and sends the
   packet to the Client on the same server.  Server then sends
   the packet to its router for further routing.
 
 o Router determines local clients on the channel, if found
   sends packet to the local clients.  Router determines global
   clients on the channel and sends the packet to its primary
   router or fastest route.
 
 o (Other router(s) do the same thing and sends the packet to
    the server(s))
 
 o Server determines local clients on the channel and sends the
   packet to the client.
 
 o All clients receiving the packet decrypts the packet.
 
 
 .ti 0
 3.8.4 Server To Server
 
 Server to server packet delivery and encryption is described in above
 examples. Router to router packet delivery is analogous to server to
 server.  However, some packets, such as channel packets, are processed
 differently.  These cases are described later in this document and
 more in detail in [SILC2].
 
 
 .ti 0
 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
 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, Usually clients are 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.  The
 connection authentication protocol is described in detail in [SILC3].
 
 
 .ti 0
 3.10 Algorithms
 
 This section defines all the allowed algorithms that can be used in
 the SILC protocol.  This includes mandatory cipher, mandatory public
 key algorithm and MAC algorithms.
 
 
 .ti 0
 3.10.1 Ciphers
 
 Cipher is the encryption algorithm that is used to protect the data
 in the SILC packets.  See [SILC2] of the actual encryption process and
 definition of how it must be done.  SILC has a mandatory algorithm that
 must be supported in order to be compliant with this protocol.
 
 
 
 
 
 
 Following ciphers are defined in SILC protocol:
 
 .in 6
 blowfish-cbc    Blowfish in CBC mode  (mandatory)
 twofish-cbc     Twofish in CBC mode   (optional)
 rc6-cbc         RC6 in CBC mode       (optional)
 rc5-cbc         RC5 in CBC mode       (optional)
 mars-cbc        Mars in CBC mode      (optional)
 none            No encryption         (optional)
 .in 3
 
 
 All algorithms must use minimum of 128 bit key, by default.  Several
 algorithms, however, supports longer keys and it is recommended to use
 longer keys if they are available.
 
 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.
 
 Additional ciphers may be defined to be used in SILC by using the
 same name format as above.
 
 
 .ti 0
 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 
 public keys are also used in the SILC Key Exchange protocol [SILC3].
 
 Following public key algorithms are defined in SILC protocol:
 
 .in 6
 rsa        RSA  (mandatory)
 dss        DSS  (optional)
 .in 3
 
 Both of the algorithms are described in [Scheneir] and [Menezes].
 
 Additional public key algorithms may be defined to be used in SILC.
 
 
 .ti 0
 3.10.3 MAC Algorithms
 
 Data integrity is protected by computing a message authentication code
 (MAC) of the packet data.  See [SILC2] for details how to compute the
 MAC.
 
 
 
 
 
 Following MAC algorithms are defined in SILC protocol:
 
 .in 6
 hmac-sha1        HMAC-SHA1, length = 20  (mandatory)
 hmac-md5         HMAC-MD5, length = 16   (optional)
 none             No MAC                  (optional)
 .in 3
 
 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]
 
 Additional MAC algorithms may be defined to be used in SILC.
 
 
 .ti 0
 3.10.4 Compression Algorithms
 
 SILC protocol supports compression that may be applied to unencrypted
 data.  It is recommended to use compression on slow links as it may
 significantly speed up the data transmission.  By default, SILC does not
 use compression which is the mode that must be supported by all SILC
 implementations.
 
 Following compression algorithms are defined:
 
 .in 6
 none        No compression               (mandatory)
 zlib        GBU ZLIB (LZ77) compression  (optional)
 .in 3
 
 Additional compression algorithms may be defined to be used in SILC.
 
 
 .ti 0
 3.11 SILC Public Key
 
 This section defines the type and format of the SILC public key.  All
 implementations must support this public key type.  See [SILC3] for
 other optional public key and certificate types allowed in SILC
 protocol.  Public keys in SILC may be used to authenticate entities
 and to perform other tasks related to public key cryptography.
 
 The format of the SILC Public Key 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Public Key Length                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Algorithm Name Length     |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+