From: Pekka Riikonen <priikone@silcnet.org>
Date: Wed, 7 May 2014 16:24:11 +0000 (+0200)
Subject: updates.
X-Git-Url: http://git.silcnet.org/gitweb/?p=website.git;a=commitdiff_plain;h=4deb84ef17e789147fa9f7f35a302c5a38999817

updates.
---

diff --git a/client.html b/client.html
index 4767910..7e6a2e5 100644
--- a/client.html
+++ b/client.html
@@ -69,9 +69,7 @@
 
         <footer>
                 <nav>
-<!--
                 <a href="info.html">INFO</a>
--->
                 <a href="client.html">CLIENT</a>
                 <a href="server.html">SERVER</a>
                 <a href="dev.html">DEVELOPMENT</a>
diff --git a/css/main.css b/css/main.css
index 60f8304..7cb1c50 100644
--- a/css/main.css
+++ b/css/main.css
@@ -144,6 +144,12 @@ code {
 	font-size: 18px;
 }
 
+.list {
+	width: 70%;
+	text-align: left;
+	font-size: 80%;
+}
+
 .downloadbutton {
 	display: inline-block;
 	color: #fff !important;
diff --git a/dev.html b/dev.html
index b45f357..cb4fbdd 100644
--- a/dev.html
+++ b/dev.html
@@ -72,9 +72,7 @@
 
         <footer>
                 <nav>
-<!--
                 <a href="info.html">INFO</a>
--->
                 <a href="client.html">CLIENT</a>
                 <a href="server.html">SERVER</a>
                 <a href="dev.html">DEVELOPMENT</a>
diff --git a/docs/protocol/draft-riikonen-presence-attrs-04.txt b/docs/protocol/draft-riikonen-presence-attrs-04.txt
new file mode 100644
index 0000000..2f4e2b0
--- /dev/null
+++ b/docs/protocol/draft-riikonen-presence-attrs-04.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                        P. Riikonen
+Internet-Draft
+draft-riikonen-presence-attrs-04.txt                     15 January 2007
+Expires: 15 July 2007
+
+
+              User Online Presence and Information Attributes
+                  <draft-riikonen-presence-attrs-04.txt>
+
+Status of this Draft
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+   This document defines set of attributes that can represent the online
+   user's presence in a network, and to provide general information about
+   the user.  The purpose is to provide a generic mechanism to share
+   online presence and status, and general information about the user
+   to be used in several kind of network protocols and applications.
+   These attributes could be used by for example chat and conferencing
+   protocols (such as Instant Message protocols), network games, and
+   other similar network protocols and applications that has online
+   users in a network.
+
+
+
+
+
+
+
+
+
+Riikonen                                                        [Page 1]
+
+Internet Draft                                           15 January 2007
+
+
+Table of Contents
+
+   1 Introduction ..................................................  2
+     1.1 Requirements Terminology ..................................  2
+   2 Attributes Concept ............................................  3
+     2.1 Requesting Attributes .....................................  3
+     2.2 Replying Attributes .......................................  3
+     2.3 Attribute Data Types ......................................  4
+     2.4 Attribute Payload .........................................  4
+     2.5 Attributes ................................................  5
+   3 Security Considerations .......................................  12
+   4 References ....................................................  12
+   5 Author's Address ..............................................  13
+   6 Full Copyright Statement ......................................  13
+
+
+1. Introduction
+
+   This document defines set of attributes that can represent the online
+   user's presence in a network, and to provide general information about
+   the user.  The purpose is to provide a generic mechanism to share
+   online presence and status, and general information about the user
+   to be used in several kind of network protocols and applications.
+   These attributes could be used by for example chat and conferencing
+   protocols (such as Instant Message protocols), network games, and
+   other similar network protocols and applications that has online
+   users in a network.
+
+   This document does not define these attributes to be used in any
+   specific protocol, but assumes that they can be used generally in
+   any kind of online network protocol.  Furthermore, the document
+   pays attention to special needs of various protocols, such as
+   mobile network protocols, which requires the attributes to be
+   both robust and compact.  The attributes are also considered to be
+   easily implementable and for this reason a clear and robust structure
+   was chosen for the attributes.
+
+   This document is strongly influenced by Wireless Village Initiative
+   where similar attributes are defined, and credits for the ideas are
+   due there.  However, they are defined only in the context of the
+   Wireless Village, and the format of the attributes used is not
+   suitable for general purpose usage.
+
+
+1.1 Requirements Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+   MAY, and OPTIONAL, when they appear in this document, are to be
+
+
+
+Riikonen                                                        [Page 2]
+
+Internet Draft                                           15 January 2007
+
+
+   interpreted as described in [RFC2119].
+
+
+2 Attributes Concept
+
+   Many network protocols needs a way to transfer and retrieve status
+   information about users in a network.  For example, many chat and
+   conferencing protocols such as IRC, and all Instant Message (IM)
+   protocols, such as ICQ has a way to retrieve presence and status
+   information about the users in the network.  This could be added to
+   several other kind of network protocols as well, and for this reason
+   a defined mechanism to provide these informations is needed.
+
+   The attributes are usually requested by an entity in the network
+   from other entity, usually a user or end user's device in the network.
+   The recipient then replies to each of the requested attributes and
+   sends the reply to the requester.
+
+   This document does not define the actual transport for requesting and
+   providing the replies to the requests, since this is irrelevant.
+   This document defines a payload for requesting, and providing the
+   information, but how the payload is transported is not defined in
+   this document.  In a client-server network model the user requesting
+   attributes usually destine the request to a remote user and the
+   server relays the attributes to the remote user.  It is also possible
+   that the concept is not user-to-user, but the server replies to the
+   requested attributes on behalf of the user.
+
+
+2.1 Requesting Attributes
+
+   When an entity requests attributes from a user in the network,
+   it assembles a list of Attribute Payloads, and sets the requested
+   attribute value into the payload.  Each requested attribute is a separate
+   Attribute Payload and they MUST be appended one after the other.  The
+   requester need to understand that the recipient may not understand all
+   the requested attributes, and may not reply to all of the requested
+   attributes.  The requester also need to understand that the recipient
+   may reply with additional attributes that were not requested.
+
+
+2.2 Replying Attributes
+
+   When en entity receives the Attribute Payloads it parses them one after
+   the other.  The entity can parse each of the Attribute Payload separately
+   since it knows the length of the current attribute; next attribute
+   begins after the current attribute ends.  The entity then checks the
+   requested attribute and SHOULD reply either with valid value or with
+
+
+
+Riikonen                                                        [Page 3]
+
+Internet Draft                                           15 January 2007
+
+
+   an indication that the attribute is unsupported or unknown.  It is
+   also possible to reply with additional attributes that were not
+   requested.
+
+   When replying to the requested attributes the entity assembles a list
+   of Attribute Payloads, each including the attribute type and the
+   actual attribute data.
+
+
+2.3 Attribute Data Types
+
+   This section defines basic data types that can appear in the attributes
+   in this document.
+
+   All integer values are stored in the MSB first order.  The size of the
+   integer is provided separately with the attribute.  Integer is
+   represented as "integer" in this documentation.
+
+   Strings MUST be UTF-8 [RFC2279] encoded, and include 2 bytes length
+   field indicating the length of the string.  Hence, when "string" value
+   appears in this documentation it is encoded as:
+
+      Length       Type       Value
+      2 bytes      integer    Length of String field
+      variable     UTF-8      String
+
+   If string is not present then the length field includes zero (0)
+   value.
+
+   Boolean value is represented as "boolean" and its size is 1 byte.
+   Value 0x00 indicates false value and value 0x01 indicates true value.
+
+
+2.4 Attribute Payload
+
+   The Attribute Payload is used to request an attribute, and to reply
+   to the requested attribute.  One payload includes one attribute.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Attribute   |   Attr Flags  |        Attribute Length       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                        Attribute Data                         ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Riikonen                                                        [Page 4]
+
+Internet Draft                                           15 January 2007
+
+
+                       Figure 1:  Attribute Payload
+
+
+      o Attribute (1 byte) - Indicates the attribute included in this
+        Attribute Payload.
+
+      o Attribute Flags (1 byte) - Indicates the flags associated
+        with this attribute.  The following flags are defined:
+
+          0x01        ATTRIBUTE_FLAG_INVALID
+
+            The attribute value in Attribute Data is invalid, or
+            unknown.  This may be set to indicate that a requested
+            attribute is not available, its value is unknown, or
+            sender does not understand it.
+
+          0x02        ATTRIBUTE_FLAG_VALID
+
+            The attribute value is included in the Attribute Data.
+
+        When sending this payload to request attributes this value
+        MUST be set to zero (0) value.  When sending a reply to the
+        request this field MUST NOT include a zero (0) value.
+
+      o Attribute Length (2 bytes) - Indicates the length of the
+        Attribute Data field, not including any other field.
+
+      o Attribute Data (variable length) - The Attribute Data.
+        The contents of this field is attribute specific, defined
+        subsequently.
+
+
+2.5 Attributes
+
+   The following values can appear in the Attribute field in the
+   Attribute Payload to indicate the content of the attribute.  The
+   format of the attribute data is represented as length, type and
+   value.  Example:
+
+      Length       Type       Value
+      2 bytes      integer    Some integer value
+      variable     string     Some string
+      1 byte       boolean    Boolean value
+
+   When sending multiple Attribute Payloads it is possible to include
+   multiple same attributes in the packet.
+
+
+
+
+
+Riikonen                                                        [Page 5]
+
+Internet Draft                                           15 January 2007
+
+
+      0    ATTRIBUTE_NONE
+
+           This attribute is reserved and it is never sent.
+
+
+      1    ATTRIBUTE_USER_INFO
+
+           This attribute includes general information about the user, their
+           name and contact information.  The content of this attribute is
+           a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425
+           [RFC2425].  Note that some of the information that VCard provides
+           can be also provided in the means of providing other attributes.
+           The rationale for this is that the VCard does not provide all the
+           information, or with the required precision that may be desired in
+           some applications.  It is therefore RECOMMENDED that this attribute
+           would be used to provide only basic and constant user information,
+           such as name and contact information, but not online status
+           information.
+
+           Length       Type       Value
+           variable     VCard      Basic user information
+
+
+      2    ATTRIBUTE_SERVICE
+
+           This attribute indicates a service in the Internet that the user
+           is currently using or has logged in.  It also shows when the user
+           started using the service, and how long user has been idle in the
+           service.  The value of this attribute is as follows:
+
+           Length       Type       Value
+           4 bytes      integer    Service Port (IANA specified)
+           variable     string     Service Address
+           1 byte       boolean    Online status.  If this is set to
+                                   0x01 (true) it means the user is online
+                                   in the service.  Set to 0x00 (false) when
+                                   out of reach.
+           variable     string     Signon date and time, UTC date, format as
+                                   in ISO 8601
+           4 bytes      integer    Idle time
+
+
+      3    ATTRIBUTE_STATUS_MOOD
+
+           This attribute indicates the mood of the user.  It can indicate
+           whether the user is eager to participate in the network.  The
+           value of this attribute is as follows:
+
+
+
+
+Riikonen                                                        [Page 6]
+
+Internet Draft                                           15 January 2007
+
+
+           Length       Type       Value
+           4 bytes      integer    Mood mask (values ORed together)
+
+           The following mood values are defined:
+
+           0x00000000   MOOD_NORMAL       No specific mood, normal mood
+           0x00000001   MOOD_HAPPY        The user feels happy
+           0x00000002   MOOD_SAD          The user feels sad
+           0x00000004   MOOD_ANGRY        The user feels angry
+           0x00000008   MOOD_JEALOUS      The user feels jealous
+           0x00000010   MOOD_ASHAMED      The user feels ashamed
+           0x00000020   MOOD_INVINCIBLE   The user feels invincible
+           0x00000040   MOOD_INLOVE       The user feels being in love
+           0x00000080   MOOD_SLEEPY       The user feels sleepy
+           0x00000100   MOOD_BORED        The user feels bored
+           0x00000200   MOOD_EXCITED      The user feels excited
+           0x00000400   MOOD_ANXIOUS      The user feels anxious
+
+
+      4    ATTRIBUTE_STATUS_FREETEXT
+
+           This attribute includes the user's online status free text.  It
+           can provide personal status as a text message.  The contents of
+           this attribute is a UTF-8 encoded free text string.
+
+           Length       Type       Value
+           variable     string     Free text status string
+
+
+      5    ATTRIBUTE_STATUS_MESSAGE
+
+           This attribute includes the user's online status message.  It
+           could provide for example a multi media message showing the status
+           of the user.  The contents of this attribute is a MIME object,
+           which can be used to provide for example video, audio, image or
+           other similar status message.  It could also provide a reference
+           to the message, for example an URL address.
+
+           Length       Type       Value
+           variable     MIME       Status message as MIME object
+
+
+      6    ATTRIBUTE_PREFERRED_LANGUAGE
+
+           This attribute indicates the preferred language to be used when
+           communicating.  The encoding of this attribute is as follows:
+
+           Length       Type       Value
+
+
+
+Riikonen                                                        [Page 7]
+
+Internet Draft                                           15 January 2007
+
+
+           variable     string     ISO 639-2/T three letter code
+
+
+      7    ATTRIBUTE_PREFERRED_CONTACT
+
+           This attribute indicates the preferred contact methods.  It can
+           indicate the method the user prefers when contacting.  The value
+           of this attribute is as follows:
+
+           Length       Type       Value
+           4 bytes      integer    Contact mask (values ORed together)
+
+           The following contact methods are defined:
+
+           0x00000000   CONTACT_NONE     No specific preferred contact method
+           0x00000001   CONTACT_EMAIL    Email is preferred
+           0x00000002   CONTACT_CALL     Phone call is preferred
+           0x00000004   CONTACT_PAGE     Paging is preferred
+           0x00000008   CONTACT_SMS      SMS is preferred
+           0x00000010   CONTACT_MMS      MMS is preferred
+           0x00000020   CONTACT_CHAT     Chatting is preferred
+           0x00000040   CONTACT_VIDEO    Video conferencing is preferred
+
+
+      8    ATTRIBUTE_TIMEZONE
+
+           This attribute can be used to provide the current local time for
+           the user.  The contents of this attribute is a UTF-8 encoded
+           string and the format of the string is UTC time zone defined
+           in the ISO 8601.
+
+           Length       Type       Value
+           variable     string     UTC date, format as in ISO 8601
+
+           Note that ATTRIBUTE_USER_INFO may also provide this information.
+           However it is RECOMMENDED that this attribute is used when
+           current time zone information is provided.
+
+
+      9    ATTRIBUTE_GEOLOCATION
+
+           This attribute can be used to provide measured global location of
+           the user.  How this information is gathered is out of scope of
+           this document.  The attribute can provide latitude and longitude
+           lateral positions, but also a vertical position.  A parameter
+           describing the accuracy of the information can also be provided.
+
+           Length       Type       Value
+
+
+
+Riikonen                                                        [Page 8]
+
+Internet Draft                                           15 January 2007
+
+
+           variable     string     Longitude (ex. 31 17 14.321W)
+           variable     string     Latitude (ex. 12 11 21.2N)
+           variable     string     Altitude
+           variable     string     Accuracy in meters
+
+           Note that ATTRIBUTE_USER_INFO may also provide this information,
+           however it does not have the vertical position, or the accuracy
+           parameter.  It is RECOMMENDED that this attribute is used when
+           providing current global position information.
+
+
+      10   ATTRIBUTE_DEVICE_INFO
+
+           This attribute includes information about the user's device.
+           The encoding of this attribute is as follows:
+
+           Length       Type       Value
+           4 bytes      integer    Device type
+           variable     string     Name of the device manufacturer
+           variable     string     Device version
+           variable     string     Device model
+           variable     string     Device language (ISO 639-2/T)
+
+           The following Device types are defined:
+
+           0    DEVICE_COMPUTER        Device is a computer
+           1    DEVICE_MOBILE_PHONE    Device is a mobile phone
+           2    DEVICE_PDA             Device is a PDA
+           3    DEVICE_TERMINAL        Device is a terminal
+
+
+      11   ATTRIBUTE_EXTENSION
+
+           This attribute indicates that the attribute value is vendor,
+           application or service specific attribute extension.  This field
+           MUST include a MIME object, which is the extension value.  This
+           document does not specify any explicit MIME objects for this
+           attribute.
+
+           Length       Type       Value
+           variable     MIME       Attribute extension as MIME object
+
+
+      12   ATTRIBUTE_USER_PUBLIC_KEY
+
+           This attribute includes the user's public key or certificate.
+           As the public key and certificate format depends on which sort
+           of algorithm or certificate encoding user is using we need to
+
+
+
+Riikonen                                                        [Page 9]
+
+Internet Draft                                           15 January 2007
+
+
+           define a mechanism to differentiate the public key types from
+           each other.  This document specifies the most common public keys
+           and certificates.  This attribute can be used to deliver the
+           user's public key, and it MUST be present if also the
+           ATTRIBUTE_USER_DIGITAL_SIGNATURE is present.  Note that the
+           recipient of this attribute SHOULD verify the public key from
+           a third party, for example from Certification Authority.  If
+           there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
+           and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
+           signature SHOULD be verifiable with the first set public key.
+
+           Length       Type       Value
+           variable     string     Public key/certificate type
+           variable     data       Public key/certificate data
+
+           The following public key/certificate types are defined:
+
+           ssh-rsa           SSH RSA public key [SSH-TRANS]
+           ssh-dss           SSH DSS public key [SSH-TRANS]
+           silc-rsa          SILC RSA public key [SILC1]
+           silc-dss          SILC DSS public key [SILC1]
+           pgp-sign-rsa      OpenPGP RSA certificate [RFC2440]
+           pgp-sign-dss      OpenPGP DSS certificate [RFC2440]
+           x509v3-sign-rsa   X.509 Version 3 RSA certificate [RFC2459]
+           x509v3-sign-dss   X.509 Version 3 DSS certificate [RFC2459]
+
+           Most of these public key/certificate types are equivalent to
+           the types specified for SSH protocol [SSH-TRANS] and are expected
+           to be officially assigned by IANA.
+
+           The encoding of the public key/certificate data in the attribute
+           is done in the manner defined in their respective definitions.
+
+           Note that these public keys are intended for signing.  Some
+           certificates may have a key usage restrictions and same key cannot
+           be used for both encryption and signing.  Therefore, the name
+           of the certificate type indicates if they are intended for
+           signing only.
+
+
+      13   ATTRIBUTE_SERVER_PUBLIC_KEY
+
+           This attribute includes a third party server or authority public
+           key or CA certificate and MUST be present if the attribute
+           ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present.  The format
+           for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
+           attribute.  If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
+           attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
+
+
+
+Riikonen                                                       [Page 10]
+
+Internet Draft                                           15 January 2007
+
+
+           the digital signature SHOULD be verifiable with the first set public
+           key.
+
+
+      14   ATTRIBUTE_USER_DIGITAL_SIGNATURE
+
+           This attribute value includes digital signature of all Attribute
+           Payloads except this attribute.  This signature can be provided by
+           the user.  This attribute SHOULD be last attribute provided in the
+           reply so that it is easier for the receiver to compute the signature
+           data to be verified.  The format and encoding of this attribute
+           depends on the public key or certificate used to produce the
+           signature.  See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
+           and certificates that can be used to produce a signature.
+
+           Length       Type       Value
+           variable     data       Digital signature data
+
+           The encodings are as follows per public key/certificate type:
+
+           ssh-rsa and ssh-dss                   Defined in [SSH-TRANS]
+           silc-rsa and silc-dss                 Defined in [SILC1]
+           pgp-sign-rsa and pgp-sign-dss         Defined in [RFC2440]
+           x509v3-sign-rsa and x509v3-sign-dss   Defined in [PKCS7]
+
+           The procedure producing the signature and encoding it are done
+           in the manner defined in their respective definitions, see the
+           provided references.  Also the hash function used with the
+           signature procedure is defined by the public key/certificate type.
+
+
+      15   ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
+
+           This attribute value includes digital signature of all Attribute
+           Payloads except this attribute, but including the attribute
+           ATTRIBUTE_USER_DIGITAL_SIGNATURE.  This signature can be provided
+           by a third party server or an authority which has verified the
+           information provided by the user.  How it verifies this information
+           is out of scope of this document, however it may base its
+           information to a previous registration information and current
+           online status of the user in a service.  This attribute SHOULD be
+           last when provided, so that it is easier for the receiver to
+           compute the signature data to be verified.  The format for this
+           attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
+           attribute.
+
+
+      16   ATTRIBUTE_USER_ICON
+
+
+
+Riikonen                                                       [Page 11]
+
+Internet Draft                                           15 January 2007
+
+
+           This attribute includes the user's icon or picture that can be
+           associated with the user in the application's user interface.
+           The attribute is a MIME object of which content MUST be one of
+           the MIME image media types.
+
+           Length       Type       Value
+           variable     MIME       Icon as MIME image message
+
+
+3 Security Considerations
+
+   The use of these attributes dictates whether the attributes need to
+   be secured or not.  However, as the attributes are considered to provide
+   accurate status information about specific user, it is suggested that
+   the attributes would be secured.  The attributes should be digitally
+   signed whenever it is possible.  Attributes can also be encrypted
+   if it is provided by the protocol using the attributes.  A third party,
+   like a server in the network, could also verify the information and provide
+   digital signature in case the information is accurate.
+
+   Even though the attributes would be digitally signed by the sender of
+   the attributes, the information contained in the attribute may still
+   be incorrect.  The third party server should not apply digital signature
+   unless it can verify every attribute.  The receiver of the attributes
+   should also not trust that the information in fact is correct.
+
+   However, it is possible that the context where these attributes are used
+   the attributes are provided by a party that can provide the accurate
+   information.  For example a server in the network could reply to the
+   attributes on behalf of the actual user for some of the attributes.
+
+
+4 References
+
+   [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", RFC 2279, January 1998.
+
+   [RFC2425]    Howes, T., et al, "A MIME Content-Type for Directory
+                Information", RFC 2425, September 1998.
+
+   [RFC2426]    Dawson, F., et al, "vCard MIME Directory Profile",
+                RFC 2426, September 1998.
+
+   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
+                Protocol Specification", Internet Draft, January 2007.
+
+
+
+Riikonen                                                       [Page 12]
+
+Internet Draft                                           15 January 2007
+
+
+   [RFC2440]    Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+                November 1998.
+
+   [RFC2459]    Housley, R., et al, "Internet X.509 Public Key
+                Infrastructure, Certificate and CRL Profile", RFC 2459,
+                January 1999.
+
+   [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
+                Internet Draft.
+
+   [PKCS7]      Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
+                Version 1.5", RFC 2315, March 1998.
+
+
+
+
+5 Author's Address
+
+   Pekka Riikonen
+   Helsinki
+   Finland
+
+   EMail: priikone@iki.fi
+
+
+6 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                       [Page 13]
+
diff --git a/docs/protocol/draft-riikonen-silc-commands-07.txt b/docs/protocol/draft-riikonen-silc-commands-07.txt
new file mode 100644
index 0000000..9166ecf
--- /dev/null
+++ b/docs/protocol/draft-riikonen-silc-commands-07.txt
@@ -0,0 +1,3027 @@
+
+
+
+
+
+
+Network Working Group                                        P. Riikonen
+Internet-Draft
+draft-riikonen-silc-commands-07.txt                      15 January 2007
+Expires: 15 July 2007
+
+
+                               SILC Commands
+                   <draft-riikonen-silc-commands-07.txt>
+
+Status of this Draft
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+   This memo describes the commands used in the Secure Internet Live
+   Conferencing (SILC) protocol, specified in the Secure Internet Live
+   Conferencing, Protocol Specification [SILC1].  The SILC Commands are
+   very important part of the SILC protocol.  Usually the commands are used
+   by SILC clients to manage the SILC session, but also SILC servers may
+   use the commands.  This memo specifies detailed command messages and
+   command reply messages.
+
+
+
+
+
+
+
+
+Table of Contents
+
+
+
+Riikonen                                                        [Page 1]
+
+Internet Draft                                           15 January 2007
+
+
+   1 Introduction ..................................................  2
+     1.1 Requirements Terminology ..................................  2
+   2 SILC Commands .................................................  2
+     2.1 SILC Commands Syntax ......................................  4
+     2.2 SILC Command Argument Idioms ..............................  4
+     2.3 SILC Commands List ........................................  5
+     2.4 SILC Command Status Payload ............................... 43
+   3 SILC Status Types ............................................. 44
+   4 Security Considerations ....................................... 51
+   5 References .................................................... 51
+   6 Author's Address .............................................. 52
+   Appendix A ...................................................... 52
+   Full Copyright Statement ........................................ 54
+
+
+1. Introduction
+
+   This document describes the commands used in the Secure Internet Live
+   Conferencing (SILC) protocol, specified in the Secure Internet Live
+   Conferencing, Protocol Specification [SILC1].  This document specifies
+   detailed command messages and command reply messages.
+
+   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.
+
+   See the [SILC1] for the requirements and the restrictions for the usage
+   of the SILC commands.  The [SILC2] defines the command packet type and
+   the Command Payload which is actually used to deliver the commands and
+   command reply messages.
+
+
+1.1 Requirements Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+   MAY, and OPTIONAL, when they appear in this document, are to be
+   interpreted as described in [RFC2119].
+
+
+2 SILC Commands
+
+2.1 SILC Commands Syntax
+
+   This section briefly describes the syntax of the command notions
+   in this document.  Every field in command is separated from each
+   other by whitespaces (` ') indicating that each field is independent
+   argument and each argument MUST have own Command Argument Payload.
+   The number of maximum arguments are defined with each command
+
+
+
+Riikonen                                                        [Page 2]
+
+Internet Draft                                           15 January 2007
+
+
+   separately.  The Command Argument Payload is described in [SILC2].
+
+   Every command defines specific number for each argument.  Currently,
+   they are defined in ascending order; first argument has number one
+   (1), second has number two (2) and so on.  This number is set into the
+   Argument Type field in the Command Argument Payload.  This makes it
+   possible to send the arguments in free order as the number MUST be
+   used to identify the type of the argument.  This makes is it also
+   possible to have multiple optional arguments in commands and in
+   command replies.  The number of argument is marked in parentheses
+   before the actual argument.
+
+
+
+      Example:  Arguments:  (1) <nickname> (2) <username@host>
+
+
+   Every command replies with Status Payload.  This payload tells the
+   sender of the command whether the command was completed successfully or
+   whether there was an error.  If error occurred the payload includes the
+   error type.  In the next section the Status Payload is not described
+   as it is common to all commands and has been described here.  Commands
+   MAY reply with other arguments as well.  These arguments are command
+   specific and are described in the next section.
+
+   Example command:
+
+      EXAMPLE_COMMAND
+
+        Max Arguments:  3
+            Arguments:  (1) <nickname>[@<server>]  (2) <message>
+                        (3) [<count>]
+
+        The command has maximum of 3 arguments.  However, only first
+        and second arguments are mandatory.
+
+        First argument <nickname> is mandatory but may have optional
+        <nickname@server> format as well.  Second argument is mandatory
+        <message> argument.  Third argument is optional <count> argument.
+
+        The numbers in parentheses are the argument specific numbers
+        that specify the type of the argument in Command Argument Payload.
+        The receiver always knows that, say, argument number two (2) is
+        <message> argument, regardless of the ordering of the arguments in
+        the Command Payload.
+
+        Reply messages to the command:
+
+
+
+
+Riikonen                                                        [Page 3]
+
+Internet Draft                                           15 January 2007
+
+
+        Max Arguments:  4
+            Arguments:  (1) <Status Payload>  (2) [<channel list>]
+                        (3) <idle time>       (4) [<away message>]
+
+        This command may reply with maximum of 4 arguments.  However,
+        only the first and third arguments are mandatory.  The numbers
+        in the parentheses have the same meaning as in the upper
+        command sending specification.
+
+        Every command reply with <Status Payload>, it is mandatory
+        argument for all command replies and for this reason it is not
+        described in the command reply descriptions.
+
+
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_NICK
+
+        Every command reply also defines set of status message that it
+        may return inside the <Status Payload>.  All status messages
+        are defined in the section 2.3 SILC Command Status Payload
+        The status messages defined with the command are recommendations.
+        It is possible to return other status messages not listed with
+        the command reply definition.
+
+
+2.2 SILC Command Argument Idioms
+
+   All commands that has an ID as argument (for example <Client ID>) are
+   actually ID Payloads, defined in [SILC2] that includes the type of the
+   ID, length of the ID and the actual ID data.  This way variable length
+   ID's can be sent as arguments.
+
+   All passphrases that may be sent in commands as arguments MUST be
+   UTF-8 [RFC3629] encoded.  All strings sent as arguments in command and
+   command reply are also UTF-8 encoded, unless otherwise defined.  See
+   the [SILC1] for general UTF-8 definition in SILC protocol.
+
+   All public keys and certificates that are sent as arguments are actually
+   Public Key Payloads [SILC2].  This way it is possible to send different
+   kind of public keys and certificate types as arguments.
+
+
+
+
+
+
+
+Riikonen                                                        [Page 4]
+
+Internet Draft                                           15 January 2007
+
+
+2.3 SILC Commands List
+
+   This section lists all SILC commands, however, it is expected that a
+   implementation and especially client implementation has many more
+   commands that has only local affect.  These commands are official
+   SILC commands that has both client and server sides and cannot be
+   characterized as local commands.
+
+   List of all defined commands in SILC follows.
+
+   0    SILC_COMMAND_NONE
+
+        None.  This is reserved command and MUST NOT be sent.
+
+
+   1    SILC_COMMAND_WHOIS
+
+        Max Arguments:  256
+            Arguments:  (1) [<nickname>[@<server>]]   (2) [<count>]
+                        (3) [<Requested Attributes>]  (4) [<Client ID>]
+                        (n) [...]
+
+        Whois command is used to query various information about specific
+        user.  The user may be requested by their nickname and server name.
+        The query may find multiple matching users as there are no unique
+        nicknames in the SILC.  The <count> option may be given to narrow
+        down the number of accepted results.  If this is not defined there
+        are no limit of accepted results.  The query may also be narrowed
+        down by defining the server name of the nickname.  The <count> is
+        32 bit MSB first order integer.
+
+        It is also possible to search the user by Client ID.  If the
+        <Client ID> is provided server MUST use it as the search value
+        instead of the <nickname>.  It is also possible to define multiple
+        Client ID's to search multiple users sending only one WHOIS
+        command.  In this case the Client ID's are appended as normal
+        arguments.
+
+        The <Requested Attributes> is defined in [ATTRS] and can be used
+        to request various information about the client.  See Appendix A
+        for definition of using these attributes in SILC.  If neither the
+        <nickname> or <Client ID> arguments are present but the attributes
+        are, the server MUST use the attributes to do the searching.  If
+        none of the arguments, <nickname>, <Client ID> and <Requested
+        Attributes> are present, error MUST be retuned.  Server MAY
+        use the <Requested Attributes> to narrow down the search if they
+        present at any time.
+
+
+
+
+Riikonen                                                        [Page 5]
+
+Internet Draft                                           15 January 2007
+
+
+        To prevent miss-use of this command wildcards in the nickname
+        or in the server name are not permitted.  It is not allowed
+        to request all users on some server.  The WHOIS requests MUST
+        be based on explicit nickname request.
+
+        The WHOIS request MUST be always sent to the router by normal
+        server so that all users are searched.  However, the server still
+        MUST search its locally connected clients.  The router MUST send
+        this command to the server which owns the requested client, if
+        the router is unable to provide all mandatory information about
+        the client.  That server MUST reply to the command.  Server MUST
+        NOT send whois replies to the client until it has received the
+        reply from its router.
+
+        Reply messages to the command:
+
+        Max Arguments:  11
+            Arguments:  (1) <Status Payload>       (2) <Client ID>
+                        (3) <nickname>[@<server>]  (4) <username@host>
+                        (5) <real name>            (6) [<Channel Payload
+                                                         list>]
+                        (7) [<user mode>]          (8) [<idle time>]
+                        (9) [<fingerprint>]        (10) <channel user
+                                                         mode list>
+                        (11) [<Attributes>]
+
+
+        This command may reply with several command reply messages to
+        form a list of results.  In this case the status payload will
+        include STATUS_LIST_START status in the first reply and
+        STATUS_LIST_END in the last reply to indicate the end of the
+        list.  If there are only one reply the status is set to normal
+        STATUS_OK.  If multiple Client IDs was requested then each found
+        and unfound client MUST cause successful or error reply,
+        respectively.
+
+        The command replies include the Client ID of the nickname,
+        nickname and server name, user name and host name and user's real
+        name.  Client should process these replies only after the last
+        reply has been received with the STATUS_LIST_END status.  If the
+        <count> option were defined in the query there will be only
+        <count> many replies from the server.
+
+        The server returns the list of channels if the client has
+        joined channels.  In this case the list is list of Channel
+        Payloads.  The Mode Mask in the Channel Payload is the channel's
+        mode.  The list is encoded by adding the Channel Payloads one
+        after the other.  Private and secret channels MUST NOT be sent,
+
+
+
+Riikonen                                                        [Page 6]
+
+Internet Draft                                           15 January 2007
+
+
+        except if the sender of this command is on those channels, or
+        the sender is server.  The <channel user mode list> MUST also
+        be sent if client is joined channels.  This list includes 32 bit
+        MSB first order values one after the other and each indicate
+        the user's mode on a channel.  The order of these values MUST
+        be same as the channel order in the <Channel Payload list>.
+
+        The server also returns client's user mode, idle time, and the
+        fingerprint of the client's public key.  The <fingerprint> is the
+        binary hash digest of the public key.  The fingerprint MUST NOT
+        be sent if the server has not verified the proof of possession of
+        the corresponding private key.  Server can do this during the
+        SILC Key Exchange protocol.  The <fingerprint> is SHA1 digest.
+
+        The <Attributes> is the reply to the <Requested Attributes>.
+        See the Appendix A for more information.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_LIST_START
+            SILC_STATUS_LIST_END
+            SILC_STATUS_ERR_NO_SUCH_NICK
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
+   2    SILC_COMMAND_WHOWAS
+
+        Max Arguments:  2
+            Arguments:  (1) <nickname>[@<server>]  (2) [<count>]
+
+        Whowas.  This command is used to query history information about
+        specific user.  The user may be requested by their nickname and
+        server name.  The query may find multiple matching users as there
+        are no unique nicknames in the SILC.  The <count> option may be
+        given to narrow down the number of accepted results.  If this
+        is not defined there are no limit of accepted results.  The query
+        may also be narrowed down by defining the server name of the
+        nickname.  The <count> is 32 bit MSB first order integer.
+
+        To prevent miss-use of this command wildcards in the nickname
+        or in the server name are not permitted.  The WHOWAS requests MUST
+        be based on specific nickname request.
+
+        The WHOWAS request MUST be always sent to the router by server
+
+
+
+Riikonen                                                        [Page 7]
+
+Internet Draft                                           15 January 2007
+
+
+        so that all users are searched.  However, the server still must
+        search its locally connected clients.
+
+        Reply messages to the command:
+
+        Max Arguments:  5
+            Arguments:  (1) <Status Payload>        (2) <Client ID>
+                        (3) <nickname>[@<server>]   (4) <username@host>
+                        (5) [<real name>]
+
+        This command may reply with several command reply messages to form
+        a list of results.  In this case the status payload will include
+        STATUS_LIST_START status in the first reply and STATUS_LIST_END in
+        the last reply to indicate the end of the list.  If there are only
+        one reply the status is set to normal STATUS_OK.
+
+        The command replies with nickname and user name and host name.
+        Every server MUST keep history for some period of time of its
+        locally connected clients.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_LIST_START
+            SILC_STATUS_LIST_END
+            SILC_STATUS_ERR_NO_SUCH_NICK
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
+   3    SILC_COMMAND_IDENTIFY
+
+        Max Arguments:  256
+            Arguments:  (1) [<nickname>[@<server>]]  (2) [<server name>]
+                        (3) [<channel name>]         (4) [<count>]
+                        (5) [<ID Payload>]           (n) [...]
+
+        Identify command is used to query information about an entity by
+        the entity's name or ID.  This command can be used to query
+        information about clients, servers and channels.
+
+        The query may find multiple matching entities.  The <count> option
+        may be given to narrow down the number of accepted results.  If
+        this is not defined there are no limit of accepted results.  The
+        <count> is 32 bit MSB first order integer.
+
+        It is also possible to search the entity by its ID.  If the
+
+
+
+Riikonen                                                        [Page 8]
+
+Internet Draft                                           15 January 2007
+
+
+        <ID Payload> is provided server must use it as the search value
+        instead of the entity's name.  One of the arguments MUST be given.
+        It is also possible to define multiple ID Payloads to search
+        multiple entities sending only one IDENTIFY command.  In this case
+        the ID Payloads are appended as normal arguments.  The type of the
+        entity is defined by the type of the ID Payload.
+
+        To prevent miss-use of this command wildcards in the names are
+        not permitted.  It is not allowed to request for example all users
+        on server.
+
+        Implementations may not want to give interface access to this
+        command as it is hardly a command that would be used by an end
+        user.  However, it must be implemented as it is most likely used
+        with private message sending.
+
+        The IDENTIFY command MUST be always sent to the router by server
+        so that all users are searched.  However, server MUST still search
+        its locally connected clients.
+
+        Reply messages to the command:
+
+        Max Arguments:  4
+            Arguments:  (1) <Status Payload>   (2) <ID Payload>
+                        (3) [<entity's name>]  (4) [<info>]
+
+        This command may reply with several command reply messages to form
+        a list of results.  In this case the status payload will include
+        STATUS_LIST_START status in the first reply and STATUS_LIST_END in
+        the last reply to indicate the end of the list.  If there are only
+        one reply the status is set to normal STATUS_OK.  If multiple Client
+        IDs was requested then each found and unfound client must cause
+        successful or error reply, respectively.
+
+        When querying clients the <entity's name> must include the client's
+        nickname in the following format: nickname[@server].  The
+        <info> must include the client's username and host in the following
+        format: username@host.
+
+        When querying servers the <entity's name> must include the server's
+        full name.  The <info> may be omitted.
+
+        When querying channels the <entity's name> must include the
+        channel's name.  The <info> may be omitted.
+
+        If the <count> option were defined in the query there will be only
+        <count> many replies from the server.
+
+
+
+
+Riikonen                                                        [Page 9]
+
+Internet Draft                                           15 January 2007
+
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_LIST_START
+            SILC_STATUS_LIST_END
+            SILC_STATUS_ERR_NO_SUCH_NICK
+            SILC_STATUS_ERR_NO_SUCH_SERVER
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
+   4    SILC_COMMAND_NICK
+
+        Max Arguments:  1
+            Arguments:  (1) <nickname>
+
+        Set/change nickname.  This command is used to set nickname for
+        user.  See [SILC1] for definition of correctly formatted
+        nickname.
+
+        When nickname is changed new Client ID is generated.  Server MUST
+        distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
+        channels (if any) the client is joined on.  Then it MUST send
+        SILC_NOTIFY_TYPE_NICK_CHANGE notify to its primary route to
+        notify about nickname and Client ID change.
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>  (2) <New ID Payload>
+                        (3) <nickname>
+
+        This command replies always with <New ID Payload> that is
+        generated by the server every time user changes their nickname.
+        Client receiving this payload MUST start using the received
+        Client ID as its current valid Client ID.  The New ID Payload
+        is described in [SILC2].  The <nickname> is the user's new
+        nickname.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_WILDCARDS
+
+
+
+Riikonen                                                       [Page 10]
+
+Internet Draft                                           15 January 2007
+
+
+            SILC_STATUS_ERR_NICKNAME_IN_USE
+            SILC_STATUS_ERR_BAD_NICKNAME
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
+   5    SILC_COMMAND_LIST
+
+        Max Arguments:  1
+            Arguments:  (1) [<Channel ID>]
+
+        The list command is used to list channels and their topics on the
+        current server.  If the <Channel ID> parameter is used, only the
+        status of that channel is displayed.  Secret channels are not
+        listed at all.  Private channels are listed with status indicating
+        that the channel is private.  Router MAY reply with all channels
+        it knows about.
+
+        Reply messages to the command:
+
+        Max Arguments:  5
+            Arguments:  (1) <Status Payload>  (2) <Channel ID>
+                        (3) <channel>         (4) [<topic>]
+                        (5) [<user count>]
+
+        This command may reply with several command reply messages to form
+        a list of results.  In this case the status payload will include
+        STATUS_LIST_START status in the first reply and STATUS_LIST_END in
+        the last reply to indicate the end of the list.  If there are only
+        one reply the status is set to normal STATUS_OK.
+
+        This command replies with Channel ID, name and the topic of the
+        channel.  If the channel is private channel the <topic> SHOULD
+        include the "*private*" string.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_LIST_START
+            SILC_STATUS_LIST_END
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+            SILC_STATUS_ERR_NO_SUCH_SERVER
+
+
+
+
+Riikonen                                                       [Page 11]
+
+Internet Draft                                           15 January 2007
+
+
+   6    SILC_COMMAND_TOPIC
+
+        Max Arguments:  2
+            Arguments:  (1) <Channel ID>  (2) [<topic>]
+
+        This command is used to change or view the topic of a channel.
+        The topic for channel <Channel ID> is returned if there is no
+        <topic> given.  If the <topic> parameter is present, the topic
+        for that channel will be changed, if the channel modes permit
+        this action.
+
+        After setting the topic the server MUST send the notify type
+        SILC_NOTIFY_TYPE_TOPIC_SET to its primary router and then to
+        the channel which topic was changed.
+
+        Reply messages to the command:
+
+        Max Arguments:  2
+            Arguments:  (1) <Status Payload>  (2) <Channel ID>
+                        (3) [<topic>]
+
+        The command may reply with the topic of the channel if it is
+        set.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ON_CHANNEL
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+            SILC_STATUS_ERR_BAD_CHANNEL_ID
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_CHANNEL_PRIV
+
+
+   7    SILC_COMMAND_INVITE
+
+        Max Arguments:  4
+            Arguments:  (1) <Channel ID>       (2) [<Client ID>]
+                        (3) [<add | del>]      (4) [<invite list>]
+
+        This command can be used to invite other clients to join to a
+        channel, and to manage the channel's invite list.  The <Client
+        ID> argument is the target client's ID that is being invited.
+
+
+
+Riikonen                                                       [Page 12]
+
+Internet Draft                                           15 January 2007
+
+
+        The <Channel ID> is the Channel ID of the requested channel.
+        The sender of this command MUST be on the channel.  The server
+        MUST also send the notify type SILC_NOTIFY_TYPE_INVITE to its
+        primary router and then to the client indicated by the <Client
+        ID>.
+
+        The <add | del> is an argument of size of 1 byte where 0x00 means
+        adding a client to invite list, and 0x01 means deleting a client
+        from invite list.  The <invite list>, if present, indicates
+        the information to be added to or removed from the invite list.
+        It may include a string for matching clients, public key of a
+        client (Public Key Payload) or Client ID of a client.  The
+        <invite list> is an Argument List Payload.
+
+        The following Argument Types has been defined for invite list
+        Argument Payloads:
+
+          0x01 - Argument is an invite string of following format:
+
+            [<nickname>[@<server>]!][<username>]@[<hostname or IP/MASK>]
+
+            The <hostname> may also be in format of IP/MASK to indicate
+            a network, for example 10.2.1.0/255.255.0.0.
+
+          0x02 - Argument is the public key of a client
+          0x03 - Argument is the Client ID of a client
+
+        If unknown type value is received or there is invalid amount of
+        Argument Payloads present in the list, the command MUST be
+        discarded.  When argument that is to be deleted from the invite
+        list does not exist in the list the argument is ignored.
+
+        When adding to or removing from the invite list the server MUST
+        send the notify type SILC_NOTIFY_TYPE_INVITE to its primary router.
+        When the SILC_CHANNEL_MODE_INVITE is set the client which executes
+        this command MUST have at least channel operator privileges to be
+        able to add to or remove from the invite list.  If this channel
+        mode is not set the list manipulation is allowed for all clients.
+        Wildcards MAY be used with this command.  When this command is
+        used to invite explicit client with <Client ID> the ID MUST be
+        added to the invite list by the server.
+
+        When this command is given with only <Channel ID> argument then
+        the command merely returns the invite list of the channel.   This
+        command MUST fail if the requested channel does not exist, the
+        requested <Client ID> is already on the channel or if the channel
+        is invite only channel and the caller of this command does not
+        have at least channel operator privileges on the channel.
+
+
+
+Riikonen                                                       [Page 13]
+
+Internet Draft                                           15 January 2007
+
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>  (2) <Channel ID>
+                        (3) [<invite list>]
+
+     This command replies with the invite list of the channel if it
+     exists.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_NO_CLIENT_ID
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+            SILC_STATUS_ERR_NOT_ON_CHANNEL
+            SILC_STATUS_ERR_USER_ON_CHANNEL
+            SILC_STATUS_ERR_NO_CHANNEL_PRIV
+            SILC_STATUS_ERR_RESOURCE_LIMIT
+
+
+   8    SILC_COMMAND_QUIT
+
+        Max Arguments:  1
+            Arguments:  (1) [<quit message>]
+
+        This command is used by client to end SILC session.  The server
+        must close the connection to a client which sends this command.
+        if <quit message> is given it will be sent to other clients on
+        channel if the client is on channel when quitting.
+
+        Reply messages to the command:
+
+        This command does not reply anything.
+
+
+    9   SILC_COMMAND_KILL
+
+        Max Arguments:  3
+            Arguments:  (1) <Client ID>          (2) [<comment>]
+                        (3) [<auth payload>]
+
+        This command can be used by SILC operators to remove a client from
+        SILC network.  It also can be used by a normal client to remove
+
+
+
+Riikonen                                                       [Page 14]
+
+Internet Draft                                           15 January 2007
+
+
+        its own client from network by providing correct authentication
+        data.
+
+        Router operator killing a client:
+
+        The removing has temporary effects and client may reconnect to
+        SILC network.  The <Client ID> is the client to be removed from SILC.
+        The <comment> argument may be provided to give to the removed client
+        some information why it was removed from the network.  The killer
+        MUST have SILC operator privileges.
+
+        When killing a client the router MUST first send notify type
+        SILC_NOTIFY_TYPE_KILLED to all channels the client has joined.
+        The packet MUST NOT be sent to the killed client on the channels.
+        Then, the router MUST send the same notify type to its primary
+        router.  Finally, the router MUST send the same notify type
+        destined directly to the client which was killed.  The killed
+        client MUST also be removed from the invite lists of joined
+        channels if it is explicitly added in the invite lists.
+
+        Normal client killing by authentication:
+
+        When normal client executes this command the <Client ID> is the
+        destination client to be removed from the network.  The client
+        MUST provide the <auth payload> which includes a digital signature
+        that MUST be verified with the public key of the client indicated
+        by <Client ID>.  The <Client ID> MUST be local client to the server.
+        If the signature verification is successful the server sends
+        SILC_NOTIFY_TYPE_SIGNOFF to network and to the destination client.
+        The SILC_NOTIFY_TYPE_KILLED MUST NOT be used in this case.  If the
+        verification fails the destination client remains in network.
+        The hash function used in <auth payload> computing is selected
+        by user or SHA1 otherwise.
+
+        Reply messages to the command:
+
+        Max Arguments:  2
+            Arguments:  (1) <Status Payload>  (2) <Client ID>
+
+        This command returns with the requested Client ID.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+
+
+Riikonen                                                       [Page 15]
+
+Internet Draft                                           15 January 2007
+
+
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_NO_CLIENT_ID
+            SILC_STATUS_ERR_NO_ROUTER_PRIV
+
+
+   10   SILC_COMMAND_INFO
+
+        Max Arguments:  2
+            Arguments:  (1) [<server>]  (2) [<Server ID>]
+
+        This command is used to fetch various information about a server.
+        If <server> argument is specified the command MUST be sent to
+        the requested server.
+
+        If the <Server ID> is specified the server information if fetched
+        by the provided Server ID.  One of the arguments MUST always be
+        present.
+
+        Reply messages to the command:
+
+        Max Arguments:  4
+            Arguments:  (1) <Status Payload>  (2) <Server ID>
+                        (3) <server name>     (4) <string>
+
+        This command replies with the Server ID of the server and a
+        string which tells the information about the server.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_SERVER
+            SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+            SILC_STATUS_ERR_NO_SERVER_ID
+
+
+   11   SILC_COMMAND_STATS
+
+        Max Arguments:  1
+            Arguments:  (1) <Server ID>
+
+        This command is used to fetch various statistical information
+        from the server indicated by <Server ID>, which is the ID of
+        server where sender is connected to.  Server receiving this
+        command MAY also send this further to its router for fetching
+
+
+
+Riikonen                                                       [Page 16]
+
+Internet Draft                                           15 January 2007
+
+
+        other cell and network wide statistics to accompany the reply.
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>          (2) <Server ID>
+                        (3) [<statistics structure>]
+
+        This command replies with the Server ID of the server and
+        optional statistics structure which includes 32 bit MSB first
+        ordered integer values to represent various statistical
+        information.  The structure is as follows:
+
+          starttime      - time when server was started
+          uptime         - uptime of the server
+          my clients     - number of locally connected clients
+          my channels    - number of locally created channels
+          my server ops  - number of local server operators
+          my router ops  - number of local router operators
+          cell clients   - number of clients in local cell
+          cell channels  - number of channels in local cell
+          cell servers   - number of servers in local cell
+          clients        - number of client in SILC network
+          channels       - number of channels in SILC network
+          servers        - number of servers in SILC network
+          routers        - number of routers in SILC network
+          server ops     - number of server operators in SILC network
+          router ops     - number of router operators in SILC network
+
+        If some value is unknown it is set to zero (0) value.  The
+        "starttime" is the start time of the server, and is seconds
+        since Epoch (POSIX.1).  The "uptime" is time difference of
+        current time and "starttime" in the server, and is seconds
+        in value.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+            SILC_STATUS_ERR_NO_SUCH_SERVER
+            SILC_STATUS_ERR_NO_SERVER_ID
+
+
+   12   SILC_COMMAND_PING
+
+
+
+
+Riikonen                                                       [Page 17]
+
+Internet Draft                                           15 January 2007
+
+
+        Max Arguments:  1
+            Arguments:  (1) <Server ID>
+
+        This command is used by client and server to test the communication
+        channel to its server if one suspects that the communication is not
+        working correctly.  The <Server ID> is the ID of the server the
+        sender is connected to.
+
+        Reply messages to the command:
+
+        Max Arguments:  1
+            Arguments:  (1) <Status Payload>
+
+        This command replies only with Status Payload.  Server returns
+        SILC_STATUS_OK in Status Payload if pinging was successful.
+
+
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SERVER_ID
+            SILC_STATUS_ERR_NO_SUCH_SERVER
+            SILC_STATUS_ERR_NOT_REGISTERED
+
+
+   13   SILC_COMMAND_OPER
+
+        Max Arguments:  2
+            Arguments:  (1) <username>  (2) <authentication payload>
+
+        This command is used by normal client to obtain server operator
+        privileges on some server or router.  Note that router operator
+        has router privileges that supersedes the server operator
+        privileges and this does not obtain those privileges.  Client
+        MUST use SILCOPER command to obtain router level privileges.
+
+        The <username> is the username set in the server configurations
+        as operator.  The <authentication payload> is the data that the
+        client is authenticated against.  It may be passphrase prompted
+        for user on client's screen or it may be public key authentication
+        based on digital signatures.  The public key used to verify the
+        signature should be locally saved in the server, and server should
+        not use public key received during the SKE to verify this signature.
+
+        After changing the mode the server MUST send the notify type
+
+
+
+Riikonen                                                       [Page 18]
+
+Internet Draft                                           15 January 2007
+
+
+        SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
+        Reply messages to the command:
+
+        Max Arguments:  1
+            Arguments:  (1) <Status Payload>
+
+        This command replies only with Status Payload.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_AUTH_FAILED
+
+
+   14   SILC_COMMAND_JOIN
+
+        Max Arguments:  7
+            Arguments:  (1) <channel>         (2) <Client ID>
+                        (3) [<passphrase>]    (4) [<cipher>]
+                        (5) [<hmac>]          (6) [<founder auth>]
+                        (7) [<channel auth>]
+
+        Join to channel/create new channel.  This command is used to
+        join to a channel.  If the channel does not exist the channel is
+        created.  If server is normal server this command MUST be sent
+        to router which will create the channel.  The channel MAY be
+        protected with passphrase.  If this is the case the passphrase
+        MUST be sent along the join command.  See the [SILC1] for
+        definition of correctly formatted channel name, <channel>.
+
+        The second argument <Client ID> is the Client ID of the client
+        which is joining to the client.  When client sends this command
+        to the server the <Client ID> MUST be the client's own ID.
+
+        Cipher to be used to secure the traffic on the channel MAY be
+        requested by sending the name of the requested <cipher>.  This
+        is used only if the channel does not exist and is created.  If
+        the channel already exists the cipher set previously for the
+        channel will be used to secure the traffic.  The computed MACs
+        of the channel message are produced by the default HMAC or by
+        the <hmac> provided for the command.
+
+        The <founder auth> is Authentication Payload providing the
+        authentication for gaining founder privileges on the channel
+
+
+
+Riikonen                                                       [Page 19]
+
+Internet Draft                                           15 January 2007
+
+
+        when joining the channel.  The client may provide this if it
+        knows that it is the founder of the channel and that the
+        SILC_CMODE_FOUNDER_AUTH mode is set on the channel.  The server
+        MUST verify whether the client is able to gain the founder
+        privileges the same way as the client had given the
+        SILC_COMMAND_CUMODE command to gain founder privileges.  The
+        client is still able to join the channel even if the founder
+        privileges could not be gained.  The hash function used with
+        the <founder payload> is selected by user or SHA1 otherwise.
+
+        If the <channel auth> is present and the channel mode
+        SILC_CMODE_CHANNEL_AUTH is set the server MUST verify the
+        <channel auth> with channel public key(s).  If public key that
+        can verify <channel auth> does not exist on the channel public
+        key list the client MUST NOT be allowed to join the channel.
+        Because more than one public key may be set on channel the
+        <channel auth> Authentication Payload's Public Data field
+        MUST include an indication of the public key to be used.  The
+        first 20 bytes of the Public Data field MUST be SHA-1 digest of
+        the public key that must be used in verification.  The digest
+        is the SILC Public Key fingerprint.  Rest of thePublic Data field
+        are set as defined in [SILC1].  This way server can determine from
+        the digest whether that public key exist on the channel and then
+        use that key in verification.  The hash function used with
+        <channel auth> is selected by user or SHA1 otherwise.
+
+        The server MUST check whether the user is allowed to join to
+        the requested channel.  Various modes set to the channel affect
+        the ability of the user to join the channel.  These conditions
+        are:
+
+            o  The user MUST be invited to the channel if the channel
+               is invite-only channel.
+
+            o  The Client ID/nickname/username/host name/public key
+               MUST NOT match any active bans.
+
+            o  The correct passphrase MUST be provided if passphrase
+               is set to the channel, and/or digital signature verification
+               with channel public key MUST be successful if public keys
+               has been set to the channel.
+
+            o  The user count limit, if set, MUST NOT be reached.
+
+        If the client provided correct <founder auth> payload it can
+        override these conditions, except the condition for the passphrase.
+        The correct passphrase MUST be provided even if <founder auth>
+        payload is provided.
+
+
+
+Riikonen                                                       [Page 20]
+
+Internet Draft                                           15 January 2007
+
+
+        Reply messages to the command:
+
+        Max Arguments:  17
+            Arguments:  (1) <Status Payload>        (2) <channel>
+                        (3) <Channel ID>            (4) <Client ID>
+                        (5) <channel mode mask>     (6) <created>
+                        (7) [<Channel Key Payload>] (8) [<ban list>]
+                        (9) [<invite list>]         (10) [<topic>]
+                        (11) [<hmac>]               (12) <list count>
+                        (13) <Client ID list>       (14) <client mode list>
+                        (15) [<founder pubkey>]     (16) [<channel pubkeys>]
+                        (17) [<user limit>]
+
+        This command replies with the channel name requested by the
+        client, channel ID of the channel and topic of the channel
+        if it exists.  The <Client ID> is the Client ID which was joined
+        to the channel.  It also replies with the channel mode mask
+        which tells all the modes set on the channel.  If the channel
+        is created the mode mask is zero (0) and <created> is 0x01.
+        If ban mask and/or invite list is set they are sent as well.
+        The <user limit> is the user limit on the channel, if one is set.
+
+        The <list count>, <Client ID list> and <client mode list> are
+        the clients currently on the channel and their modes on the
+        channel.  The <Client ID list> is formed by adding the ID Payloads
+        one after the other.  The <client mode list> is formed by adding
+        32 bit MSB first order values one after the other.  The <founder
+        pubkey> is the public key (or certificate) of the channel founder.
+        The <channel pubkeys> is Argument List Payload containing the
+        channel public keys that has been set for the channel.
+
+        Client receives the channel key in the reply message as well
+        inside <Channel Key Payload>.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_BAD_PASSWORD
+            SILC_STATUS_ERR_CHANNEL_IS_FULL
+            SILC_STATUS_ERR_NOT_INVITED
+            SILC_STATUS_ERR_BANNED_FROM_CHANNEL
+            SILC_STATUS_ERR_BAD_CHANNEL
+            SILC_STATUS_ERR_USER_ON_CHANNEL
+
+
+
+
+Riikonen                                                       [Page 21]
+
+Internet Draft                                           15 January 2007
+
+
+   15   SILC_COMMAND_MOTD
+
+        Max Arguments:  1
+            Arguments:  (1) <server>
+
+        This command is used to query the Message of the Day of the server.
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>  (2) <Server ID>
+                        (3) [<motd>]
+
+        This command replies with the motd message if it exists.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NO_SUCH_SERVER
+
+
+   16   SILC_COMMAND_UMODE
+
+        Max Arguments:  2
+            Arguments:  (1) <Client ID>  (2) [<client mode mask>]
+
+        This command is used by client to set/unset modes for itself.
+        However, there are some modes that the client MUST NOT set itself,
+        but they will be set by server.  However, client MAY unset any
+        mode.  Modes may be masked together ORing them thus having
+        several modes set.  Client MUST keep its client mode mask
+        locally so that the mode setting/unsetting would work without
+        problems.  Client may change only its own modes.
+
+        After changing the mode server MUST send the notify type
+        SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
+        The following client modes are defined:
+
+           0x00000000    SILC_UMODE_NONE
+
+              No specific mode for client.  This is the initial
+              setting when new client is created.  The client is
+              normal client and is present in the network.
+
+
+
+
+Riikonen                                                       [Page 22]
+
+Internet Draft                                           15 January 2007
+
+
+           0x00000001    SILC_UMODE_SERVER_OPERATOR
+
+              Marks the user as server operator.  Client MUST NOT
+              set this mode itself.  Server sets this mode to the
+              client when client attains the server operator
+              privileges by SILC_COMMAND_OPER command.  Client
+              MAY unset the mode itself.
+
+
+           0x00000002    SILC_UMODE_ROUTER_OPERATOR
+
+              Marks the user as router (SILC) operator.  Client
+              MUST NOT set this mode itself.  Router sets this mode
+              to the client when client attains the router operator
+              privileges by SILC_COMMAND_SILCOPER command.  Client
+              MAY unset the mode itself.
+
+
+           0x00000004    SILC_UMODE_GONE
+
+              Marks that the user is not currently present in the
+              SILC Network.  Client MAY set and unset this mode.
+
+
+           0x00000008    SILC_UMODE_INDISPOSED
+
+              Marks that the user is currently indisposed and may
+              not be able to receive any messages, and that user may
+              not be present in the network.  Client MAY set and
+              unset this mode.
+
+
+           0x00000010    SILC_UMODE_BUSY
+
+              Marks that the user is currently busy and may not
+              want to receive any messages, and that user may not
+              be present in the network.  Client MAY set and unset
+              this mode.
+
+
+           0x00000020    SILC_UMODE_PAGE
+
+              User is not currently present or is unable to receive
+              messages, and prefers to be paged in some mechanism
+              if the user needs to be reached.  Client MAY set and
+              unset this mode.
+
+
+
+
+
+Riikonen                                                       [Page 23]
+
+Internet Draft                                           15 January 2007
+
+
+           0x00000040    SILC_UMODE_HYPER
+
+              Marks that the user is hyper active and is eager to
+              receive and send messages.   Client MAY set and unset
+              this mode.
+
+
+           0x00000080    SILC_UMODE_ROBOT
+
+              Marks that the client is actually a robot program.
+              Client MAY set and unset this mode.
+
+
+           0x00000100    SILC_UMODE_ANONYMOUS
+
+              Marks that the client is anonymous client.  Server
+              that specifically is designed for anonymous services
+              can set and unset this mode.  Client MUST NOT set or
+              unset this mode itself.  A client with this mode set
+              would have the username and the hostname information
+              scrambled by the server which set this mode.
+
+
+           0x00000200    SILC_UMODE_BLOCK_PRIVMSG
+
+              Marks that the client wishes to block private
+              messages sent to the client, unless the Private
+              Message Key flag is set in the SILC packet header.
+              If this mode is set server MUST NOT deliver private
+              messages to the client without the Private Message
+              Key flag being set.  The Private Message Key flag set
+              indicates that the private message is protected with
+              a key shared between the sender and the recipient.
+
+              A separate service could provide additional filtering
+              features for accepting private messages from certain
+              sender.  However, this document does not specify such
+              service.
+
+              The client MAY set and unset this mode.
+
+
+           0x00000400    SILC_UMODE_DETACHED
+
+              Marks that the client is detached from the SILC network.
+              This means that the actual network connection to the
+              client is lost but the client entry is still valid.  The
+              detached client can be resumed at a later time.  This
+
+
+
+Riikonen                                                       [Page 24]
+
+Internet Draft                                           15 January 2007
+
+
+              mode MUST NOT be set by client.  It can only be set when
+              client has issued command SILC_COMMAND_DETACH.  The server
+              sets this mode.  This mode cannot be unset with this
+              command.  It is unset when the client is resuming back to
+              the network and SILC_PACKET_RESUME_CLIENT packet is
+              received.
+
+              This flag MUST NOT be used to determine whether a packet
+              can be sent to the client or not.  Only the server that
+              had the original client connection can make the decision
+              by knowing that the network connection is not active.
+              In this case the default case is to discard the packet.
+
+
+           0x00000800    SILC_UMODE_REJECT_WATCHING
+
+              Marks that the client rejects that it could be watched
+              by someone else.  If this mode is set notifications about
+              this client is not send, even if someone is watching the
+              same nickname this client has.  Client MAY set and unset
+              this mode.  Any changes for this client MUST NOT be
+              notified to any watcher when this mode is set.
+
+              A separate service could provide additional filtering
+              features for rejecting and accepting the watching from
+              certain users.  However, this document does not specify
+              such service.
+
+
+           0x00001000    SILC_UMODE_BLOCK_INVITE
+
+              Marks that the client wishes to block incoming invite
+              notifications.  Client MAY set and unset this mode.
+              When set server does not deliver invite notifications
+              to the client.  Note that this mode may make it harder
+              to join invite-only channels.
+
+        If the <client mode mask> was not provided this command merely
+        returns the mode mask to the client.
+
+
+        Reply messages to the command:
+
+        Max Arguments:  2
+            Arguments:  (1) <Status Payload>  (2) <client mode mask>
+
+        This command replies with the changed client mode mask that
+        the client MUST to keep locally.
+
+
+
+Riikonen                                                       [Page 25]
+
+Internet Draft                                           15 January 2007
+
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_BAD_CLIENT_ID
+            SILC_STATUS_ERR_NOT_YOU
+            SILC_STATUS_ERR_PERM_DENIED
+            SILC_STATUS_ERR_UNKNOWN_MODE
+            SILC_STATUS_ERR_NO_CLIENT_ID
+
+
+   17   SILC_COMMAND_CMODE
+
+        Max Arguments:  9
+            Arguments:  (1) <Channel ID>      (2) [<channel mode mask>]
+                        (3) [<user limit>]    (4) [<passphrase>]
+                        (5) [<cipher>]        (6) [<hmac>]
+                        (7) [<auth payload>]  (8) [<founder pubkey>]
+                        (9) [<channel pubkey>]
+
+        This command is used by client to set or change channel flags on
+        a channel.  Channel has several modes that set various properties
+        of a channel.  Modes may be masked together by ORing them thus
+        having several modes set.  The <Channel ID> is the ID of the
+        target channel.  The client changing channel mode MUST be on
+        the same channel and posses sufficient privileges to be able to
+        change the mode.
+
+        When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
+        type MUST be distributed to the channel.
+
+        The following channel modes are defined:
+
+           0x00000000    SILC_CMODE_NONE
+
+              No specific mode on channel.  This is the default when
+              channel is created.  This means that channel is just plain
+              normal channel.
+
+
+           0x00000001    SILC_CMODE_PRIVATE
+
+              Channel is private channel.  Private channels are shown
+              in the channel list listed with SILC_COMMAND_LIST command
+              with indication that the channel is private.  Also,
+
+
+
+Riikonen                                                       [Page 26]
+
+Internet Draft                                           15 January 2007
+
+
+              client on private channel will no be detected to be on
+              the channel as the channel is not shown in the client's
+              currently joined channel list.  Channel founder and
+              channel operator MAY set/unset this mode.
+
+
+           0x00000002    SILC_CMODE_SECRET
+
+              Channel is secret channel.  Secret channels are not shown
+              in the list listed with SILC_COMMAND_LIST command.  Secret
+              channels can be considered to be invisible channels.
+              Channel founder and channel operator MAY set/unset this
+              mode.
+
+
+           0x00000004    SILC_CMODE_PRIVKEY
+
+              Channel uses private channel key to protect the traffic
+              on the channel.  When this mode is set the client will be
+              responsible to set the key it wants to use to encrypt and
+              decrypt the traffic on channel.  Server generated channel
+              keys are not used at all.  This mode provides additional
+              security as clients on channel may agree to use private
+              channel key that even servers do not know.  Naturally,
+              this requires that every client on the channel knows
+              the key before hand (it is considered to be pre-shared-
+              key).  The key material SHOULD be processed as stated
+              in the [SILC3] in the section Processing the Key Material.
+
+              As it is local setting it is possible to have several
+              private channel keys on one channel.  In this case several
+              clients can talk on same channel but only those clients
+              that share the key with the message sender will be able
+              to hear the talking.  Client SHOULD NOT display those
+              message for the end user that it is not able to decrypt
+              when this mode is set.
+
+              Only channel founder MAY set/unset this mode.  If this
+              mode is unset the server will distribute new channel
+              key to all clients on the channel which will be used
+              thereafter.
+
+
+           0x00000008    SILC_CMODE_INVITE
+
+              Channel is invite only channel.  Client may join to this
+              channel only if it is invited to the channel.  Channel
+              founder and channel operator MAY set/unset this mode.
+
+
+
+Riikonen                                                       [Page 27]
+
+Internet Draft                                           15 January 2007
+
+
+           0x00000010    SILC_CMODE_TOPIC
+
+              The topic of the channel may only be set by client that
+              is channel founder or channel operator.  Normal clients
+              on channel will not be able to set topic when this mode
+              is set.  Channel founder and channel operator MAY set/
+              unset this mode.
+
+
+           0x00000020    SILC_CMODE_ULIMIT
+
+              User limit has been set to the channel.  New clients
+              may not join to the channel when the limit set is
+              reached.  Channel founder and channel operator MAY set/
+              unset the limit.  The <user limit> argument is the
+              number of limited users.
+
+
+           0x00000040    SILC_CMODE_PASSPHRASE
+
+              Passphrase has been set to the channel.  Client may
+              join to the channel only if it is able to provide the
+              correct passphrase.  Setting passphrases to channel
+              is entirely safe as all commands are protected in the
+              SILC network.  Only channel founder MAY set/unset
+              the passphrase.  The <passphrase> argument is the
+              set passphrase.
+
+
+           0x00000080    SILC_CMODE_CIPHER
+
+              Sets specific cipher to be used to protect channel
+              traffic.  The <cipher> argument is the requested cipher.
+              When set or unset the server must re-generate new
+              channel key.  Only channel founder MAY set the cipher of
+              the channel.  When unset the new key is generated using
+              default cipher for the channel.
+
+
+           0x00000100    SILC_CMODE_HMAC
+
+              Sets specific hmac to be used to compute the MACs of the
+              channel message.  The <hmac> argument is the requested hmac.
+              Only channel founder may set the hmac of the channel.
+
+
+           0x00000200    SILC_CMODE_FOUNDER_AUTH
+
+
+
+
+Riikonen                                                       [Page 28]
+
+Internet Draft                                           15 January 2007
+
+
+              Channel founder may set this mode to be able to regain
+              channel founder rights even if the client leaves the
+              channel.  The <auth payload> is the Authentication Payload
+              consisting of the public key authentication method and the
+              digital signature for that method.  The passphrase or NONE
+              authentication methods MUST NOT be accepted.
+
+              The server does not save <auth payload> but MUST verify it.
+              The public key used to verify the payload is the <founder
+              pubkey> if present, or the public key of the client sending
+              this command.  If <founder pubkey> is present also that
+              public key MUST be saved as founder's public key.  This
+              mode may be set only if the <auth payload> was verified
+              successfully.  The hash function used with the <auth
+              payload> is selected by user or SHA1 otherwise.
+
+              The public key of the founder is sent in the
+              SILC_NOTIFY_TYPE_CMODE_CHANGE notify type so that other
+              routers and servers in the network may save the public key.
+              This way the founder can reclaim the founder rights back
+              to the channel from any server in the network.  The founder
+              rights can be regained by the SILC_CUMODE_FOUNDER channel
+              user mode, or during joining procedure with the command
+              SILC_COMMAND_JOIN.
+
+              If this mode is already set but the <founder pubkey> is
+              different the new key will replace the old founder key and
+              the new key is distributed in the network with the
+              SILC_NOTIFY_TYPE_CMODE_CHANGE notify.  Only the original
+              founder may set this mode multiple times and the client
+              MUST have SILC_CUMODE_FOUNDER mode on the channel.
+
+              When this channel mode is set the channel also becomes
+              permanent.  If all clients leave the channel while this
+              mode is set the channel MUST NOT be destroyed.  The founder
+              can reclaim the founder mode back on these empty channels
+              at any time.  Implementations MAY limit the number of how
+              many channels a user can own and how long they remain
+              persistent.
+
+
+           0x00000400    SILC_CMODE_SILENCE_USERS
+
+              Channel founder may set this mode to silence normal users
+              on the channel.  Users with operator privileges are not
+              affected by this mode.  Messages sent by normal users
+              are dropped by servers when this mode is set.  This mode
+              can be used to moderate the channel.  Only channel founder
+
+
+
+Riikonen                                                       [Page 29]
+
+Internet Draft                                           15 January 2007
+
+
+              may set/unset this mode.
+
+
+           0x00000800    SILC_CMODE_SILENCE_OPERS
+
+              Channel founder may set this mode to silence operators
+              on the channel.  When used with SILC_CMODE_SILENCE_USERS
+              mode this can be used to set the channel in state where only
+              the founder of the channel may send messages to the channel.
+              Messages sent by operators are dropped by servers when this
+              mode is set.  Only channel founder may set/unset this mode.
+
+
+           0x00001000    SILC_CMODE_CHANNEL_AUTH
+
+              When this mode is set the channel has one or more public keys
+              or certificates set, and ability to join the channel requires
+              a client to provide digital signature that can be successfully
+              verified with one of the channel public keys.  This mode is
+              equivalent to the SILC_MODE_PASSPHRASE except that digital
+              signatures are used to gain access to the channel.  Both
+              modes MAY be set at the same time.  Channel founder may set
+              and unset this mode.
+
+              The <channel pubkey> argument is an Argument List Payload
+              where each argument is Public Key Payload including public
+              key to be added or removed from the channel public key list.
+              To add a public key to channel this mode is set and the
+              argument type is 0x00, and the argument is the public key.
+              To remove a public key from channel public key list the
+              argument type is 0x01, and the argument is the public key
+              to be removed from the list.  To remove all public keys at
+              once this mode is unset.  An implementation MAY limit the
+              number of public keys that can be set for the channel.
+              This mode MUST NOT be set if <channel pubkey> is not present
+              when the mode is set for the first time.  Implementation MAY
+              add and remove multiple public keys at the same time by
+              including multiple arguments to the <channel pubkey>
+              Argument List Payload.
+
+
+        To make the mode system work, client MUST keep the channel mode
+        mask locally so that the mode setting and unsetting would work
+        without problems.  The client receives the initial channel mode
+        mask when it joins to the channel.  When the mode changes on
+        channel the server MUST distribute the changed channel mode mask
+        to all clients on the channel by sending the notify type
+        SILC_NOTIFY_TYPE_CMODE_CHANGE.  The notify type MUST also be sent
+
+
+
+Riikonen                                                       [Page 30]
+
+Internet Draft                                           15 January 2007
+
+
+        to the server's primary router.  If the <channel mode mask> was
+        not provided this command returns the mode mask, founder key,
+        channel public key list and the current user limit to the client.
+
+        Reply messages to the command:
+
+        Max Arguments:  6
+            Arguments:  (1) <Status Payload>    (2) <Channel ID>
+                        (3) <channel mode mask> (4) [<founder pubkey>]
+                        (5) [<channel pubkeys>] (6) [<user limit>]
+
+        This command replies with the changed channel mode mask that
+        client MUST keep locally.  It may also return the channel
+        founder's public key if it is set.  It may also return list of
+        channel public keys when the list was altered.  The <channel
+        pubkeys> is Argument List Payload and each argument includes
+        one public key.  The <user limit> is the current user limit
+        on the channel, if one is set.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ON_CHANNEL
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_BAD_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_PRIV
+            SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+            SILC_STATUS_ERR_UNKNOWN_MODE
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_AUTH_FAILED
+
+
+   18   SILC_COMMAND_CUMODE
+
+        Max Arguments:  4
+            Arguments:  (1) <Channel ID>    (2) <mode mask>
+                        (3) <Client ID>     (4) [<auth payload>]
+
+        This command is used by client to change channel user modes on
+        channel.  Users on channel may have some special modes and this
+        command is used by channel operators to set or change these modes.
+        The <Channel ID> is the ID of the target channel.  The <mode mask>
+        is OR'ed mask of modes.  The <Client ID> is the target client.
+        The client changing channel user modes MUST be on the same channel
+
+
+
+Riikonen                                                       [Page 31]
+
+Internet Draft                                           15 January 2007
+
+
+        as the target client and posses sufficient privileges to be able to
+        change the mode.
+
+        When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
+        type is distributed to the channel.
+
+        The following channel modes are defined:
+
+           0x00000000    SILC_CUMODE_NONE
+
+              No specific mode.  This is the normal situation for client.
+              Also, this is the mode set when removing all modes from
+              the target client.
+
+
+           0x00000001    SILC_CUMODE_FOUNDER
+
+              The client is channel founder of the channel.  Usually this
+              mode is set only by the server when the channel was created.
+              However, if the SILC_CMODE_FOUNDER_AUTH channel mode has
+              been set, the client can claim channel founder privileges
+              by providing the <auth payload> that the server will use
+              to authenticate the client.  The public key that server will
+              use to verify the <auth payload> MUST be the same public key
+              that was saved when the SILC_CMODE_FOUNDER_AUTH channel
+              mode was set.  The client MAY remove this mode at any time.
+
+
+           0x00000002    SILC_CUMODE_OPERATOR
+
+              Sets channel operator privileges on the channel for a
+              client on the channel.  Channel founder and channel operator
+              MAY set/unset this mode.  The client MAY remove this mode
+              at any time.
+
+
+           0x00000004    SILC_CUMODE_BLOCK_MESSAGES
+
+              Marks that the client wishes not to receive any channel
+              messages sent for the channel.  Client MAY set and unset
+              this mode to itself.  Client MUST NOT set it to anyone else.
+              When this mode is set server MUST NOT deliver channel
+              messages to this client.  Other packets such as channel
+              key packets are still sent to the client.
+
+              A separate service could provide additional filtering
+              features for accepting channel messages from certain
+              sender.  However, this document does not specify such
+
+
+
+Riikonen                                                       [Page 32]
+
+Internet Draft                                           15 January 2007
+
+
+              service.
+
+
+           0x00000008    SILC_CUMODE_BLOCK_MESSAGES_USERS
+
+              Marks that the client wishes not to receive any channel
+              messages sent from normal users.  Only messages sent by
+              channel founder or channel operator is accepted.  Client
+              MAY set and unset this mode to itself.  Client MUST NOT
+              set it to anyone else.  When this mode is set server MUST
+              NOT deliver channel messages that are sent by normal users
+              to this client.
+
+              A separate service could provide additional filtering
+              features for accepting channel messages from certain
+              sender.  However, this document does not specify such
+              service.
+
+
+           0x00000010    SILC_CUMODE_BLOCK_MESSAGES_ROBOTS
+
+              Marks that the client wishes not to receive any channel
+              messages sent from robots.  Messages sent by users with
+              the SILC_UMODE_ROBOT user mode set are not delivered.
+              Client MAY set and unset this mode to itself.  Client MUST
+              NOT set it to anyone else.  When this mode is set server
+              MUST NOT deliver channel messages that are sent by robots
+              to this client.
+
+
+           0x00000020    SILC_CUMODE_QUIET
+
+              Marks that the client cannot talk on the channel.  This
+              mode can be set by channel operator or channel founder to
+              some other user that is not operator or founder.  The
+              target client MUST NOT unset this mode.  When this mode
+              is set the server MUST drop messages sent by this client
+              to the channel.
+
+
+        Reply messages to the command:
+
+        Max Arguments:  4
+            Arguments:  (1) <Status Payload>  (2) <channel user mode mask>
+                        (3) <Channel ID>      (4) <Client ID>
+
+        This command replies with the changed channel user mode mask that
+        client MUST keep locally. The <Channel ID> is the specified
+
+
+
+Riikonen                                                       [Page 33]
+
+Internet Draft                                           15 January 2007
+
+
+        channel.  The <Client ID> is the target client.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ON_CHANNEL
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_BAD_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_PRIV
+            SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+            SILC_STATUS_ERR_UNKNOWN_MODE
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_AUTH_FAILED
+
+
+   19   SILC_COMMAND_KICK
+
+        Max Arguments:  3
+            Arguments:  (1) <Channel ID>      (2) <Client ID>
+                        (3) [<comment>]
+
+        This command is used by channel operators to remove a client from
+        channel.  The <channel> argument is the channel the client to be
+        removed is on currently.  Note that the "kicker" must be on the same
+        channel.  If <comment> is provided it will be sent to the removed
+        client.
+
+        After kicking the client the server MUST send the notify type
+        SILC_NOTIFY_TYPE_KICKED to the channel and to its primary router.
+        The client is removed from the channel after sending this notify.
+        The kicked client MUST be removed from the invite list of the
+        channel if it is explicitly added in the list.  The channel key
+        MUST also be re-generated after kicking, unless the
+        SILC_CMODE_PRIVKEY mode is set.
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>  (2) <Channel ID>
+                        (3) <Client ID>
+
+        This command returns the Channel ID and Client ID that was kicked
+        from the channel.
+
+
+
+
+Riikonen                                                       [Page 34]
+
+Internet Draft                                           15 January 2007
+
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_NO_CHANNEL_PRIV
+            SILC_STATUS_ERR_NO_CLIENT_ID
+
+
+
+   20   SILC_COMMAND_BAN
+
+        Max Arguments:  3
+            Arguments:  (1) <Channel ID>         (2) [<add | del>]
+                        (3) [<ban list>]
+
+        This command is used to manage the ban list of the channel
+        indicated by the <Channel ID>.  A client that is banned from
+        channel is no longer able to join the channel.  The client which
+        is executing this command MUST have at least channel operator
+        privileges on the channel.
+
+        The <add | del> is an argument of size of 1 byte where 0x00 means
+        adding a client to ban list, and 0x01 means deleting a client
+        from ban list.  The <ban list>, if present, indicates the
+        information to be added to or removed from the ban list.  It
+        may include a string for matching clients, public key of a
+        client (Public Key Payload) or Client ID of a client.  The
+        <ban list> is an Argument List Payload.
+
+        The following Argument Types has been defined for ban list
+        Argument Payloads:
+
+          0x01 - Argument is an ban string of following format:
+
+            [<nickname>[@<server>]!][<username>]@[<hostname or IP/MASK>]
+
+            The <hostname> may also be in format of IP/MASK to indicate
+            a network.
+
+          0x02 - Argument is the public key of a client
+          0x03 - Argument is the Client ID of a client
+
+        If unknown type value is received or there is invalid amount of
+        Argument Payloads present in the list, the command MUST be
+
+
+
+Riikonen                                                       [Page 35]
+
+Internet Draft                                           15 January 2007
+
+
+        discarded.  When argument that is to be deleted from the ban
+        list does not exist in the list the argument is ignored.
+
+        The server MUST send the notify type SILC_NOTIFY_TYPE_BAN to its
+        primary router after adding to or removing from the ban list.
+        The wildcards MAY be used with this command.  If this command
+        is executed without the ban arguments the command merely replies
+        with the current ban list.
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>  (2) <Channel ID>
+                        (3) [<ban list>]
+
+        This command replies with the <Channel ID> of the channel and
+        the current <ban list> of the channel if it exists.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+            SILC_STATUS_ERR_NOT_ON_CHANNEL
+            SILC_STATUS_ERR_NO_CHANNEL_PRIV
+            SILC_STATUS_ERR_RESOURCE_LIMIT
+
+
+
+
+   21   SILC_COMMAND_DETACH
+
+        Max Arguments:  0
+            Arguments:
+
+        This command is used to detach from the network.  Client can
+        send this command to its server to indicate that it will be
+        detached.  By detaching the client remains in the network but
+        the actual network connection to the server is closed.  The
+        client may then later resume the old session back.
+
+        When this command is received the server MUST check that the
+        client is locally connected client, and set the user mode
+        SILC_UMODE_DETACHED flag.  The SILC_NOTIFY_TYPE_UMODE_CHANGE
+        MUST be also sent to routers.  The server then sends command
+        reply to this command and closes the network connection.
+
+
+
+Riikonen                                                       [Page 36]
+
+Internet Draft                                           15 January 2007
+
+
+        The server MUST NOT remove the client from its lists, or send
+        any signoff notifications for this client.  See the [SILC1]
+        for detailed information about detaching.
+
+        Reply messages to the command:
+
+        Max Arguments:  1
+            Arguments:  (1) <Status Payload>
+
+        This command replies only with the status indication.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+
+
+
+   22   SILC_COMMAND_WATCH
+
+        Max Arguments:  4
+            Arguments:  (1) <Client ID>       (2) [<add nickname>]
+                        (3) [<del nickname>]  (4) [<public key>]
+
+        This command is used to set up a watch for <add nickname>
+        nickname.  When a user in the network appears with the
+        nickname, or signoffs the network or user's mode is changed
+        the client which set up the watch will be notified about
+        this change.  This can be used to watch for certain nicknames
+        in the network and receive notifications when for example a
+        friend appears in the network or leaves the network.
+
+        The <del nickname> is a nickname that has been previously
+        added to watch list and is now removed from it.  Notifications
+        for that nickname will not be delivered anymore.  The nickname
+        set to watch MUST NOT include any wildcards.  Note also that a
+        nickname may match several users since nicknames are not unique.
+        Implementations MAY set limits for how many nicknames client
+        can watch.
+
+        OPTIONALLY this command may also be set to watch clients' actions
+        in the network using their public key or certificate.  The
+        <public key> MAY be present, and it is an Argument List Payload
+        where each argument is a Public Key Payload including public key
+        to be added or removed from the watch list.  To To add a public
+        key to watch list the argument type is 0x00, and the argument is
+        the public key.  To remove a public key from watch list list the
+        argument type is 0x01, and the argument is the public key to be
+
+
+
+Riikonen                                                       [Page 37]
+
+Internet Draft                                           15 January 2007
+
+
+        removed from the list.  An implementation MAY limit the number of
+        public keys that can be set on the watch list.  Implementation MAY
+        add and remove multiple public keys at the same time by including
+        multiple arguments to the <public key> Argument List Payload.
+
+        The <Client ID> is the Client ID of the sender of this command.
+
+        When normal server receives this command from client it
+        MUST send it to its router.  Router will process the command
+        and actually keeps the watch list.
+
+        Reply messages to the command:
+
+        Max Arguments:  1
+            Arguments:  (1) <Status Payload>
+
+        This command replies only with the status indication.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_BAD_NICKNAME
+            SILC_STATUS_ERR_WILDCARDS
+            SILC_STATUS_ERR_RESOURCE_LIMIT
+            SILC_STATUS_ERR_NO_SUCH_NICK
+            SILC_STATUS_ERR_NICKNAME_IN_USE
+
+
+   23   SILC_COMMAND_SILCOPER
+
+        Max Arguments:  2
+            Arguments:  (1) <username>  (2) <authentication payload>
+
+        This command is used by normal client to obtain router operator
+        privileges (also known as SILC operator) on the router.  Note
+        that router operator has privileges that supersedes the server
+        operator privileges.
+
+        The <username> is the username set in the server configurations
+        as operator.  The <authentication payload> is the data that the
+        client is authenticated against.  It may be passphrase prompted
+        for user on client's screen or it may be public key or certificate
+        authentication data (data signed with private key).  The public
+        key that router will use to verify the signature found in the
+        payload should be verified.  It is recommended that the public
+
+
+
+Riikonen                                                       [Page 38]
+
+Internet Draft                                           15 January 2007
+
+
+        key is saved locally in the router and router would not use
+        any public keys received during the SKE.
+
+        Difference between router operator and server operator is that
+        router operator is able to handle cell level properties while
+        server operator (even on router server) is able to handle only
+        local properties, such as, local connections and normal server
+        administration.  The router operator is also able to use the
+        SILC_COMMAND_KILL command.
+
+        After changing the mode server MUST send the notify type
+        SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
+        Reply messages to the command:
+
+        Max Arguments:  1
+            Arguments:  (1) <Status Payload>
+
+        This command replies only with Status Payload.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_AUTH_FAILED
+
+
+
+
+   24   SILC_COMMAND_LEAVE
+
+        Max Arguments:  1
+            Arguments:  (1) <Channel ID>
+
+        This command is used by client to leave a channel the client is
+        joined to.
+
+        When leaving channel the server MUST send the notify type
+        SILC_NOTIFY_TYPE_LEAVE to its primary router and to the channel.
+        The channel key MUST also be re-generated when leaving the channel
+        and distribute it to all clients still currently on the channel.
+        The key MUST NOT be re-generated if the SILC_CMODE_PRIVKEY mode
+        is set.
+
+        Reply messages to the command:
+
+
+
+
+Riikonen                                                       [Page 39]
+
+Internet Draft                                           15 January 2007
+
+
+        Max Arguments:  2
+            Arguments:  (1) <Status Payload>  (2) <Channel ID>
+
+        The <Channel ID> is the ID of left channel.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_BAD_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+
+
+   25   SILC_COMMAND_USERS
+
+        Max Arguments:  2
+            Arguments:  (1) [<Channel ID>]  (2) [<channel name>]
+
+        This command is used to list user names currently on the requested
+        channel; either the argument <Channel ID> or the <channel name>.
+        One of these arguments must be present.  The server MUST resolve
+        the joined clients and reply with a lists of users on the channel
+        and with list of user modes on the channel.
+
+        If the requested channel is a private or secret channel, this
+        command MUST NOT send the list of users, except if the sender is
+        on the channel, or the sender is a server.  Otherwise, error is
+        returned to the sender.
+
+        Reply messages to the command:
+
+        Max Arguments:  5
+            Arguments:  (1) <Status Payload>  (2) <Channel ID>
+                        (3) <list count>      (4) <Client ID list>
+                        (5) <client mode list>
+
+        This command replies with the Channel ID of the requested channel
+        Client ID list of the users on the channel and list of their modes.
+        The Client ID list has Client ID's of all users in the list.  The
+        <Client ID list> is formed by adding Client ID's one after another.
+        The <client mode list> is formed by adding client's user modes on
+        the channel one after another (4 bytes (32 bits) each).  The <list
+        count> of length of 4 bytes (32 bits), tells the number of entries
+        in the lists.  Both lists MUST have equal number of entries.
+
+
+
+
+Riikonen                                                       [Page 40]
+
+Internet Draft                                           15 January 2007
+
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+            SILC_STATUS_ERR_BAD_CHANNEL_ID
+            SILC_STATUS_ERR_NO_CHANNEL_ID
+            SILC_STATUS_ERR_NOT_ON_CHANNEL
+
+
+   26   SILC_COMMAND_GETKEY
+
+        Max Arguments:  1
+            Arguments:  (1) <ID Payload>
+
+        This command is used to fetch the public key of the client or
+        server indicated by the <ID Payload>.  The public key is fetched
+        from the server where to the client is connected.
+
+        Reply messages to the command:
+
+        Max Arguments:  3
+            Arguments:  (1) <Status Payload>      (2) <ID Payload>
+                        (3) [<Public Key Payload>]
+
+        This command replies with the client's or server's ID and with
+        the <Public Key Payload>.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+            SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+
+
+   27   SILC_COMMAND_SERVICE
+
+        Max Arguments:  256
+            Arguments:  (1) [<service name>]    (2) [<auth payload>]
+                        (n) [...]
+
+        This command is used to negotiate a service agreement with a
+        remote server.  If this command is given without arguments it
+
+
+
+Riikonen                                                       [Page 41]
+
+Internet Draft                                           15 January 2007
+
+
+        MAY return the service list, if it is publicly available.  The
+        <service name> is a service specific identifier, and the
+        <auth payload> MAY be used to authenticate the requester to the
+        remote service.  The authentication to a service may be based
+        on previous agreement with the requester and the service
+        provider.  The command MAY also take additional service
+        specific arguments.
+
+        This document does not specify any services.  How the services
+        are configured and put available in a server is also out of
+        scope of this document.
+
+        This command MAY be used by client to start using some service
+        in a server, but it also MAY be used by server to negotiate
+        to start using a service in some other server or router.
+
+        After the negotiation is done both of the parties need to know
+        from the service identifier how the service can be used.  The
+        service can be considered to be a protocol which both of the
+        parties need to support.
+
+        Reply messages to the command:
+
+        Max Arguments:  256
+            Arguments:  (1) <Status Payload>      (2) [<service list>]
+                        (3) [<service name>]      (n) [...]
+
+
+        This command MAY reply with the <service list> when command is
+        given without arguments, and the list is a comma separated list
+        of service identifiers.  The <service name> is the service that
+        the sender requested and this is provided when the server has
+        accepted the sender to use the <service name>.  The command
+        reply MAY also have additional service specific arguments.
+
+        Status messages:
+
+            SILC_STATUS_OK
+            SILC_STATUS_ERR_NOT_REGISTERED
+            SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+            SILC_STATUS_ERR_TOO_MANY_PARAMS
+            SILC_STATUS_ERR_NO_SUCH_SERVICE
+            SILC_STATUS_ERR_AUTH_FAILED
+            SILC_STATUS_ERR_PERM_DENIED
+
+
+
+   28 - 199
+
+
+
+Riikonen                                                       [Page 42]
+
+Internet Draft                                           15 January 2007
+
+
+        Currently undefined commands.
+
+
+   200 - 254
+
+        These commands are reserved for private use and will not be defined
+        in this document.
+
+
+   255  SILC_COMMAND_MAX
+
+        Reserved command.  This must not be sent.
+
+
+2.4 SILC Command Status Payload
+
+   Command Status Payload is sent in command reply messages to indicate
+   the status of the command.  The payload is one of argument in the
+   command thus this is the data area in Command Argument Payload described
+   in [SILC2].  The payload is only 2 bytes in length.  The following
+   diagram represents the Command Status Payload (fields are always in
+   MSB first order).
+
+
+                                          1
+                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     |     Status    |     Error     |
+                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 6:  SILC Command Status Payload
+
+
+      o Status (1 byte) - Indicates the status message type,
+        error, start of list, entry of list or end of list.
+
+      o Error (1 byte) - Indicates the error if the Status
+        field is some list status, which means there are list
+        of errors.
+
+   The values in Status and Error fields are set according
+   the following rules:
+
+      o If there is single reply and error has not occurred
+        then Status field includes value SILC_STATUS_OK, and
+        the Error field MUST be ignored (and set to zero
+        value).
+
+
+
+
+Riikonen                                                       [Page 43]
+
+Internet Draft                                           15 January 2007
+
+
+      o If there is single error, then Status field includes
+        one of the error values, and the Error field MUST be
+        ignored (and set to zero value).
+
+      o If there will be multiple successful command replies
+        then Status field includes SILC_STATUS_LIST_START,
+        SILC_STATUS_LIST_ITEM or SILC_STATUS_LIST_END value,
+        and Error field is set to SILC_STATUS_OK.
+
+      o If there are multiple error replies then Status field
+        includes SILC_STATUS_LIST_START, SILC_STATUS_LIST_ITEM
+        or SILC_STATUS_LIST_END value, and the Error field
+        includes the error value.
+
+   This way it is possible to send single successful or
+   single error reply, but also multiple successful and
+   multiple error replies.  Note that it is possible to
+   send both list of successful replies and list of error
+   replies at the same time, however in this case the
+   list of error replies MUST be sent after the successful
+   replies.  This way the recipient may ignore the multiple
+   errors if it wishes to do so.  Also note that in this
+   case the successful and error replies belong to the
+   same list.
+
+   All Status messages are described in the next section.
+
+
+3 SILC Status Types
+
+   Status messages are returned in SILC protocol in command reply
+   packet and in notify packet.  The SILC_PACKET_COMMAND_REPLY is
+   the command reply packet and status types are sent inside the
+   Status Payload as one of command reply argument, as defined in
+   previous sections.  For SILC_PACKET_NOTIFY packet they can be sent
+   as defined in [SILC2] for SILC_NOTIFY_TYPE_ERROR type.  The same
+   types defined in this section are used in both cases.
+
+   When returning status messages in the command reply message they
+   indicate whether the command was executed without errors.  If error
+   occurred the status indicates which error occurred.  If error
+   occurred the arguments to the command replies are dictated by the
+   error type.  If arguments are to be sent, they are defined below
+   with the error status types.
+
+   When sending status messages in SILC_NOTIFY_TYPE_ERROR notify type
+   they always send some error status.  Usually they are sent to
+   indicate that error occurred while processing some SILC packet.
+
+
+
+Riikonen                                                       [Page 44]
+
+Internet Draft                                           15 January 2007
+
+
+   Please see the [SILC1] and [SILC2] for more information sending
+   status types in SILC_NOTIFY_TYPE_ERROR notify.
+
+   The Status Types are only numeric values and the receiver must
+   convert the numeric values into human readable messages if this
+   is desired in the application.
+
+   List of all defined status types:
+
+   Generic status messages:
+
+   0    SILC_STATUS_OK
+
+        Ok status.  Everything went Ok.  The status payload maybe
+        safely ignored in this case.
+
+   1    SILC_STATUS_LIST_START
+
+        Start of the list.  There will be several command replies and
+        this reply is the start of the list.
+
+   2    SILC_STATUS_LIST_ITEM
+
+        Item in the list.  This is one of the item in the list but not the
+        first or last one.
+
+   3    SILC_STATUS_LIST_END
+
+        End of the list.  There were several command replies and this
+        reply is the last of the list.  There won't be other replies
+        belonging to this list after this one.
+
+   4 - 9
+
+        Currently undefined and has been reserved for the future.
+
+
+   Error status message:
+
+
+
+   10   SILC_STATUS_ERR_NO_SUCH_NICK
+
+        "No such nickname".  Requested nickname does not exist.
+         The next argument MUST be the requested nickname.
+
+   11   SILC_STATUS_ERR_NO_SUCH_CHANNEL
+
+
+
+
+Riikonen                                                       [Page 45]
+
+Internet Draft                                           15 January 2007
+
+
+        "No such channel".  Requested channel name does not exist.
+         The next argument MUST be the requested channel name.
+
+   12   SILC_STATUS_ERR_NO_SUCH_SERVER
+
+        "No such server".  Requested server name does not exist.
+         The next argument MUST be the requested server name.
+
+   13   SILC_STATUS_ERR_INCOMPLETE_INFORMATION
+
+        "Incomplete registration information".  Information remote
+        sent was incomplete.
+
+   14   SILC_STATUS_ERR_NO_RECIPIENT
+
+        "No recipient given".  Command required recipient which was
+        not provided.
+
+   15   SILC_STATUS_ERR_UNKNOWN_COMMAND
+
+        "Unknown command".  Command sent to server is unknown by the
+        server.
+
+   16   SILC_STATUS_ERR_WILDCARDS
+
+        "Wildcards cannot be used".  Wildcards were provided but they
+        weren't permitted.
+
+   17   SILC_STATUS_ERR_NO_CLIENT_ID
+
+        "No Client ID given".  Client ID were expected as command
+        parameter but were not found.
+
+   18   SILC_STATUS_ERR_NO_CHANNEL_ID
+
+        "No Channel ID given".  Channel ID were expected as command
+        parameter but were not found.
+
+   19   SILC_STATUS_ERR_NO_SERVER_ID
+
+        "No Serve ID given".  Server ID were expected as command
+        parameter but were not found.
+
+   20   SILC_STATUS_ERR_BAD_CLIENT_ID
+
+        "Bad Client ID".  Client ID provided were erroneous.
+         The next argument MUST be the provided ID.
+
+
+
+
+Riikonen                                                       [Page 46]
+
+Internet Draft                                           15 January 2007
+
+
+   21   SILC_STATUS_ERR_BAD_CHANNEL_ID
+
+        "Bad Channel ID".  Channel ID provided were erroneous.
+         The next argument MUST be the provided ID.
+
+   22   SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+
+        "No such Client ID".  Client ID provided does not exist.
+        The unknown Client ID MUST be provided as next argument
+        in the reply.
+
+   23   SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+
+        "No such Channel ID".  Channel ID provided does not exist.
+        The unknown Channel ID MUST be provided as next argument
+        in the reply.
+
+   24   SILC_STATUS_ERR_NICKNAME_IN_USE
+
+        "Nickname already exists".  Nickname created could not be
+        registered because number of same nicknames were already set to
+        maximum.  This is not expected to happen in real life but is
+        possible to occur.
+
+   25   SILC_STATUS_ERR_NOT_ON_CHANNEL
+
+        "You are not on that channel".  The command were specified for
+        channel user is not currently on.  The next argument MUST be the
+        Channel ID.
+
+   26   SILC_STATUS_ERR_USER_NOT_ON_CHANNEL
+
+        "They are not on channel".  The requested target client is not
+        on requested channel.  The next two arguments, in this order,
+        MUST be the requested Client ID and Channel ID.
+
+   27   SILC_STATUS_ERR_USER_ON_CHANNEL
+
+        "User already on channel".  User were invited on channel they
+        already are on.  The next two arguments, in this order, MUST be
+        the  requested Client ID and Channel ID.
+
+   28   SILC_STATUS_ERR_NOT_REGISTERED
+
+        "You have not registered".  User executed command that requires
+        the client to be registered on the server before it may be
+        executed.
+
+
+
+
+Riikonen                                                       [Page 47]
+
+Internet Draft                                           15 January 2007
+
+
+   29   SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
+
+        "Not enough parameters".  Command requires more parameters
+        than provided.
+
+   30   SILC_STATUS_ERR_TOO_MANY_PARAMS
+
+        "Too many parameters".  Too many parameters were provided
+        for the command.
+
+   31   SILC_STATUS_ERR_PERM_DENIED
+
+        "Permission denied".  Generic permission denied error status
+        to indicate disallowed access.
+
+   32   SILC_STATUS_ERR_BANNED_FROM_SERVER
+
+        "You are banned from this server".  The client tried to register
+        on server that has explicitly denied this host to connect.
+
+   33   SILC_STATUS_ERR_BAD_PASSWORD
+
+        "Cannot join channel. Incorrect password".  Password provided for
+        channel were not accepted.  The next argument MUST be the
+        Channel ID.
+
+   34   SILC_STATUS_ERR_CHANNEL_IS_FULL
+
+        "Cannot join channel. Channel is full".  The channel is full
+        and client cannot be joined to it.  The next argument MUST be
+        the Channel ID.
+
+   35   SILC_STATUS_ERR_NOT_INVITED
+
+        "Cannot join channel. You have not been invited".  The channel
+        is invite only channel and client has not been invited.  The next
+        argument MUST be the Channel ID.
+
+   36   SILC_STATUS_ERR_BANNED_FROM_CHANNEL
+
+        "Cannot join channel. You have been banned".  The client has
+        been banned from the channel.  The next argument MUST be the
+        Channel ID.
+
+   37   SILC_STATUS_ERR_UNKNOWN_MODE
+
+        "Unknown mode".  Mode provided by the client were unknown to
+        the server.
+
+
+
+Riikonen                                                       [Page 48]
+
+Internet Draft                                           15 January 2007
+
+
+   38   SILC_STATUS_ERR_NOT_YOU
+
+        "Cannot change mode for other users".  User tried to change
+        someone else's mode.
+
+   39   SILC_STATUS_ERR_NO_CHANNEL_PRIV
+
+        "Permission denied. You are not channel operator".  Command may
+        be executed only by channel operator.  The next argument MUST be
+        the Channel ID.
+
+   40   SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
+
+        "Permission denied. You are not channel founder".  Command may
+        be executed only by channel operator.  The next argument MUST be
+        the Channel ID.
+
+   41   SILC_STATUS_ERR_NO_SERVER_PRIV
+
+        "Permission denied. You are not server operator".  Command may
+        be executed only by server operator.
+
+   42   SILC_STATUS_ERR_NO_ROUTER_PRIV
+
+        "Permission denied. You are not SILC operator".  Command may be
+        executed only by router (SILC) operator.
+
+   43   SILC_STATUS_ERR_BAD_NICKNAME
+
+        "Bad nickname".  Nickname requested contained illegal characters
+        or were malformed.
+
+   44   SILC_STATUS_ERR_BAD_CHANNEL
+
+        "Bad channel name".  Channel requested contained illegal characters
+        or were malformed.
+
+   45   SILC_STATUS_ERR_AUTH_FAILED
+
+        "Authentication failed".  The authentication data sent as
+        argument were wrong and thus authentication failed.
+
+   46   SILC_STATUS_ERR_UNKOWN_ALGORITHM
+
+        "The algorithm was not supported."  The server does not support the
+        requested algorithm.  The next argument MUST be the algorithm name
+        string.
+
+
+
+
+Riikonen                                                       [Page 49]
+
+Internet Draft                                           15 January 2007
+
+
+   47   SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+
+        "No such Server ID".  Server ID provided does not exist.
+        The unknown Server ID MUST be provided as next argument
+        in the reply.
+
+   48   SILC_STATUS_ERR_RESOURCE_LIMIT
+
+        "No more resources available".  This can mean that server cannot
+        or will not accept something due to resource limitations.
+
+   49   SILC_STATUS_ERR_NO_SUCH_SERVICE
+
+        "Service does not exist".  Requested service identifier is
+        unknown.  The next argument MUST be the service identifier.
+
+   50   SILC_STATUS_ERR_NOT_AUTHENTICATED
+
+        "You have not been authenticated".  Remote connection is not
+        authenticated even though it is supposed to be.
+
+   51   SILC_STATUS_ERR_BAD_SERVER_ID
+
+        "Server ID is not valid".  Provided server ID is not valid.
+        The next argument MUST be the provided ID.
+
+   52   SILC_STATUS_ERR_KEY_EXCHANGE_FAILED
+
+        "Key exchange failed".  Key Exchange protocol failed.
+
+   53   SILC_STATUS_ERR_BAD_VERSION
+
+        "Bad version".  Protocol or software version mismatch.
+
+   54   SILC_STATUS_ERR_TIMEDOUT
+
+        "Operation timed out".  Operation or service request timed
+        out, and thus was not processed.
+
+   55   SILC_STATUS_ERR_UNSUPPORTED_PUBLIC_KEY
+
+        "Unsupported public key type".  The public key or certificate
+        type is not supported in this implementation.
+
+   56   SILC_STATUS_ERR_OPERATION_ALLOWED
+
+        "Operation is not allowed".  A operation, for example a command,
+        is not allowed or it's execution is not allowed.
+
+
+
+Riikonen                                                       [Page 50]
+
+Internet Draft                                           15 January 2007
+
+
+4 Security Considerations
+
+   Security is central to the design of this protocol, and these security
+   considerations permeate the specification.  Common security considerations
+   such as keeping private keys truly private and using adequate lengths for
+   symmetric and asymmetric keys must be followed in order to maintain the
+   security of this protocol.
+
+
+5 References
+
+   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
+                Protocol Specification", Internet Draft, January 2007.
+
+   [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
+                January 2007.
+
+   [SILC3]      Riikonen, P., "SILC Key Exchange and Authentication
+                Protocols", Internet Draft, January 2007.
+
+   [IRC]        Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+                RFC 1459, May 1993.
+
+   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+                April 2000.
+
+   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
+                2811, April 2000.
+
+   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+                2812, April 2000.
+
+   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+                2813, April 2000.
+
+   [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
+                Internet Draft.
+
+   [PGP]        Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+                November 1998.
+
+   [SPKI]       Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+                September 1999.
+
+   [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+                Infrastructure, Certificate and CRL Profile", RFC 2459,
+                January 1999.
+
+
+
+
+Riikonen                                                       [Page 51]
+
+Internet Draft                                           15 January 2007
+
+
+   [Schneier]   Schneier, B., "Applied Cryptography Second Edition",
+                John Wiley & Sons, New York, NY, 1996.
+
+   [Menezes]    Menezes, A., et al, "Handbook of Applied Cryptography",
+                CRC Press 1997.
+
+   [OAKLEY]     Orman, H., "The OAKLEY Key Determination Protocol",
+                RFC 2412, November 1998.
+
+   [ISAKMP]     Maughan D., et al, "Internet Security Association and
+                Key Management Protocol (ISAKMP)", RFC 2408, November
+                1998.
+
+   [IKE]        Harkins D., and Carrel D., "The Internet Key Exchange
+                (IKE)", RFC 2409, November 1998.
+
+   [HMAC]       Krawczyk, H., "HMAC: Keyed-Hashing for Message
+                Authentication", RFC 2104, February 1997.
+
+   [PKCS1]      Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+                Specifications, Version 2.0", RFC 2437, October 1998.
+
+   [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", RFC 3629, November 2003.
+
+   [ATTRS]      Riikonen, P., "User Online Presence and Information
+                Attributes", Internet Draft, May 2002.
+
+
+6 Author's Address
+
+   Pekka Riikonen
+   Helsinki
+   Finland
+
+   EMail: priikone@iki.fi
+
+
+Appendix A
+
+   This appendix defines the usage of the <Requested Attributes> argument in
+   the SILC_COMMAND_WHOIS command.  The attributes are defined in [ATTRS],
+   and may be used to request additional information about the user.  Since
+   the information that may be requested using the attributes is something
+   that server cannot deliver to the sender, it is possible to send the WHOIS
+
+
+
+Riikonen                                                       [Page 52]
+
+Internet Draft                                           15 January 2007
+
+
+   command directly to the destination client whom will then provide the
+   requested attributes.  This requires the servers to relay the WHOIS
+   command to the client, and it requires capability for handling the WHOIS
+   command in the client end.
+
+   The <Requested Attributes> MAY include several attributes that are
+   requested.  The format and encoding of the <Requested Attributes> is as
+   defined in [ATTRS].  When <Requested Attributes> argument is set the
+   server MAY process the attributes to see whether it can narrow down
+   the WHOIS search, for example when searching with a nickname.  The
+   normal servers MUST process the WHOIS command as normal WHOIS command,
+   that is to send the command directly to the router.  The router MAY
+   process the attributes, but it MUST send the command to the server
+   that owns the requested client.
+
+   The server that owns the client and receives the command MUST check
+   whether the client is detached from the network.  If it is detached,
+   that is the user mode has the SILC_UMODE_DETACHED mode set, it SHOULD
+   process the attributes and provide as many of the requested attributes
+   as possible and then send reply back to the sender.  If the client is
+   active in the network it MUST send the command to the client for
+   processing.
+
+   The client receiving WHOIS command SHOULD check whether the
+   <Requested Attributes> argument is set.  If it is not set then the
+   WHOIS command SHOULD be discarded.  The client processes the requested
+   attributes and SHOULD reply to each of the requested attribute with
+   either valid value, or with an indication that the requested attribute
+   is not known or supported.  This is to be done as defined in [ATTRS].
+   The client always MUST send a reply to the command when some attributes
+   were requested.  The client MAY also add additional attributes to the
+   reply even if they were not requested.  The client MAY also digitally
+   sign the attributes with ATTRIBUTE_USER_DIGITAL_SIGNATURE as defined
+   in [ATTRS].  Then the client sends the reply back to the sender of
+   the command.  The command reply that client assembles does not need
+   to include any other argument but the <Status Payload> (1), and the
+   <Attributes> (11).  The server receiving reply from client MUST allow
+   this sort of command reply for WHOIS command.
+
+   The information received from the client MAY be cached in the
+   server's end.  The caching may be desired for example if the client
+   can be detached from the network.  This way the server is then able
+   to provide at least partial information for a requester.  The
+   server MAY also process the command reply and verify whether the
+   attributes provided in the reply are actually valid.  If it can do
+   this, and verify that they indeed are valid values it MAY append
+   a digital signature at the end of the attributes with the
+   ATTRIBUTE_SERVER_DIGITAL_SIGNATURE as defined in [ATTRS].  The
+
+
+
+Riikonen                                                       [Page 53]
+
+Internet Draft                                           15 January 2007
+
+
+   server then MUST provide valid WHOIS command reply to the sender
+   of the command.   Other servers and routers that receive the command
+   reply en route to the original sender MAY also cache the information.
+
+   The client which receives the command reply to the WHOIS command
+   SHOULD verify the ATTRIBUTE_USER_DIGITAL_SIGNATURE and the
+   ATTRIBUTE_SERVER_DIGITAL_SIGNATURE if they are provided.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                       [Page 54]
+
diff --git a/docs/protocol/draft-riikonen-silc-flags-payloads-04.txt b/docs/protocol/draft-riikonen-silc-flags-payloads-04.txt
new file mode 100644
index 0000000..158f3cc
--- /dev/null
+++ b/docs/protocol/draft-riikonen-silc-flags-payloads-04.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        P. Riikonen
+Internet-Draft
+draft-riikonen-flags-payloads-04.txt                     2 December 2003
+Expires: 2 June 2004
+
+
+                        SILC Message Flag Payloads
+                  <draft-riikonen-flags-payloads-04.txt>
+
+Status of this Draft
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+   This memo describes the data payloads associated with the SILC Message
+   Flags, as defined in the SILC Packet Protocol specification [SILC2].  The
+   purpose of the Message Flags is to augment the function of the Message
+   Payload used to send both private and channel messages, by allowing the
+   sender to tell the receiver what type of data the payload includes, and
+   how the data should be processed.  Some of the Message Flags may define
+   additional payloads to be associated with the flag, and this memo
+   describes these payloads.
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                        [Page 1]
+
+Internet Draft                                           2 December 2003
+
+
+Table of Contents
+
+   1 Introduction ..................................................  2
+     1.1 Requirements Terminology ..................................  2
+   2 SILC Message Flags ............................................  3
+   3 SILC Message Flag Payloads ....................................  3
+     3.1 SILC_MESSAGE_FLAG_REQUEST .................................  3
+     3.2 SILC_MESSAGE_FLAG_REPLY ...................................  4
+     3.3 SILC_MESSAGE_FLAG_SIGNED ..................................  4
+     3.4 SILC_MESSAGE_FLAG_DATA ....................................  7
+     3.5 SILC_MESSAGE_FLAG_ACK .....................................  8
+   4 Security Considerations .......................................  9
+   5 References ....................................................  9
+   6 Author's Address .............................................. 10
+   7 Full Copyright Statement ...................................... 10
+
+
+1. Introduction
+
+   The Secure Internet Live Conferencing [SILC1] supports sending binary
+   messages between users in the network.  To make the data sending, and
+   processing at the receiver's end as simple as possible the SILC defines
+   Message Flags to the Message Payload [SILC2] that is used to send private
+   and channel messages, which can help the receiver to decide how the data
+   is encoded, and how it should be interpreted.  Some of the Message Flags
+   may define additional payloads to be associated with the flag, but the
+   [SILC2] does not define them.  This memo defines the payloads for those
+   Message Flags that was marked to include additional payloads in [SILC2].
+
+   By defining the payloads for the Message Flags the Message Payload
+   can be augmented to support any kind of data, which can be easily
+   interpreted at the receiver end.  For example, it would be possible to
+   send audio stream, video stream, image files and HTML pages as messages,
+   and the receiver can either choose to ignore the message or to process
+   it, or to perhaps pass the message to some application for processing.
+   Without specific payloads for Message Flags it is almost impossible for
+   the receiver to interpret binary data from the payload.
+
+
+1.1 Requirements Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+   MAY, and OPTIONAL, when they appear in this document, are to be
+   interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+Riikonen                                                        [Page 2]
+
+Internet Draft                                           2 December 2003
+
+
+2 SILC Message Flags
+
+   The Message Flags was added to the SILC protocol for the reason that SILC
+   provides sending binary data as messages between users, and entities in
+   the network, and interpreting pure binary data is almost impossible.
+   With the Message Flags the purpose, the reason, and the method for how
+   the message must be interpreted can be told to the recipient.  Other
+   conferencing protocols which are usually ASCII based protocols do not have
+   such problems since they do not generally support sending of binary data
+   at all, or require specific encoding of the data before it can be sent
+   over the network.
+
+   The Message Payload in SILC can have flags that can augment the function
+   of the payload.  The flags can tell for example that the message is a
+   request, or a reply to an earlier received request.  They can tell that
+   the message is some action that the sender is performing, or they can tell
+   that the message is an auto reply, or that it is explicitly digitally
+   signed by the sender.
+
+   The problem of Message Flags is that the space for flags mask is only 16
+   bits, so there is a limited number of flags available.  For this reason
+   having a flag that defines a generic way of sending any kind of data as
+   a message, and can be easily interpreted at the receiver's end is important.
+   For this reason the flag SILC_MESSAGE_FLAG_DATA was added to the protocol
+   which can represent any data.  This memo describe how this flag is used
+   and how the associated payload is constructed and processed.  This memo
+   also describes payloads for all the other flags that can have associated
+   payloads.
+
+
+3 SILC Message Flag Payloads
+
+   The [SILC2] defines the flags which may have associated payloads.  This
+   section will list these flags and define the payloads.
+
+
+3.1 SILC_MESSAGE_FLAG_REQUEST
+
+   Currently this flag can be used in the context of application specific,
+   service specific or vendor specific requests, and the data payload type is
+   dependent of this context.  Therefore, payload is not defined for this
+   flag in this memo.  This flag may also be masked with some other flag in
+   the message payload, including with some other flag that defines
+   additional payload.
+
+
+
+
+
+
+
+Riikonen                                                        [Page 3]
+
+Internet Draft                                           2 December 2003
+
+
+3.2 SILC_MESSAGE_FLAG_REPLY
+
+   Currently this flag can be used in the context of application specific,
+   service specific or vendor specific replies, and the data payload type is
+   dependent of this context.  Therefore, payload is not defined for this
+   flag in this memo.  This flag may also be masked with some other flag in
+   the message payload, including with some other flag that defines
+   additional payload.
+
+
+3.3 SILC_MESSAGE_FLAG_SIGNED
+
+   This flag is used to tell the recipient that the sent message is
+   digitally signed by the sender, and that the recipient should verify
+   the signature to verify the true authenticity of the received message.
+   All message payloads in SILC provides message authentication code (MAC)
+   which can be used to verify that the sender produced and sent the message.
+   Even so, signing messages digitally can be used to verify the authenticity
+   of the message when recipient trusts the sender and to provide
+   non-repudiation.
+
+   This flag defines a payload which is used to deliver the actual message,
+   sender's public key and the digital signature.  The payload for
+   SILC_MESSAGE_FLAG_SIGNED is as follows:
+
+   (*) indicates that the field is not encrypted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                        [Page 4]
+
+Internet Draft                                           2 December 2003
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                   Start of Message Payload                    ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                      Public Key Payload *                     ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Signature Data Length *   |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                        Signature Data *                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                       Initial Vector *                        ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                              MAC *                            ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 1:  SILC_MESSAGE_FLAG_SIGNED Payload
+
+
+      o Start of Message Payload (variable length) - This is the
+        start of the Message Payload without the IV and MAC fields,
+        since those fields are appended at the end of this payload.
+
+      o Public Key Payload (variable length) - This includes the
+        Public Key Payload [SILC2] which can be used to deliver the
+        sender's public key (or certificate).  It also indicates the
+        type of the public key (or certificate) which the recipient
+        use to identify how the signature must be verified.  This
+        payload must always be present but it is not required to
+        include the public key data.  The Public Key Type field in
+        the Public Key Payload MUST be set to the correct type of
+        the key, even if the actual public key data is not included.
+        This field is not encrypted but is authenticated.
+
+      o Signature Data Length (2 bytes) - Indicates the length of
+        the Signature Data field not including any other field.
+        This field is not encrypted but is authenticated.
+
+
+
+
+Riikonen                                                        [Page 5]
+
+Internet Draft                                           2 December 2003
+
+
+      o Signature Data (variable length) - Includes the actual
+        signature data.  The signature computation and encoding
+        is key type specific.  See [SILC3] for all key types, and
+        their respective references for how to compute and encode
+        the signature.  This field is not encrypted but is
+        authenticated.
+
+      o Initial Vector (variable length) - the IV of the Message
+        Payload as defined in [SILC2].  This field is not encrypted
+        but is authenticated.
+
+      o MAC (variable length) - the MAC of the Message Payload as
+        defined in [SILC2].  The MAC is computed after encryption
+        and after signature computation.  All data in the Message
+        Payload and this payload, including the IV field are
+        included in the MAC computation.  This field is not
+        encrypted.
+
+   How the data is processed before it is signed is key type specific.
+   The actual data that to be signed MUST be the plaintext message
+   payload before encryption.  The data to be signed is concatenation
+   of the Start of Message Payload field and the Public Key Payload,
+   in that order.  Any other fields are not included for signature data.
+   Before signing, the data is always processed, usually hashed.  The
+   hash function to be used is defined in the key type specific
+   definitions.  See the key type specific references in [SILC3].
+
+   If the public key of the sender is included in the payload the
+   recipient SHOULD verify it before accepting the public key.  Recipient
+   SHOULD verify the signature before accepting and caching the public key.
+   With certificates the certificate verification may be done before
+   verifying the signature.  If the signature verification fails the
+   message should still be displayed.  The end user should also be
+   notified about the result of the signature verification.
+
+   To make the packet size smaller implementations may not want to
+   include the actual public key in all signed messages.  Sending the
+   public key in the first message is usually sufficient.  Subsequent
+   messages may include empty Public Key Payload with an indication of
+   the public key type.
+
+   Implementations that do not support this flag can still process the
+   message payload in normal manner.  These implementations merely parse
+   the decrypted payload in normal manner and ignore the extra data in
+   the payload.  They can do this by extracting the MAC and the IV from
+   the end of the data buffer and thus ignoring the data between start of
+   the Message Payload and the Initial Vector field.
+
+
+
+
+Riikonen                                                        [Page 6]
+
+Internet Draft                                           2 December 2003
+
+
+   This flag MAY be masked with any other Message Flag including those that
+   define additional payloads.  As long as the defined payload resides in
+   the data area of the message payload this flag may be masked with the
+   other flags.
+
+
+3.4 SILC_MESSAGE_FLAG_DATA
+
+   This flag is used to represent any data as a message in the way that it
+   can be easily interpreted by the recipient.  This flag is used to send
+   MIME objects as messages from the sender to the receiver.  The MIME as
+   defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is
+   well established protocol for sending different kind of data with many
+   applications and protocols.  It support dozens of different media types
+   and encodings, and for this reason is ideal for sending data in SILC
+   message payloads as well.
+
+   When the receiver has checked that the message payload includes the
+   SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header.
+   It would also be possible to pass the message to some application which
+   can already interpret MIME objects.  If the receiver does not support the
+   media type received in the MIME header, it SHOULD be treated as
+   "application/octet-stream".  The receiver MAY also ignore and discard
+   messages that it does not support.
+
+   The MIME header MUST be at the start of the data area of the Message
+   Payload.  The MIME header received in the data area of the payload SHOULD
+   have the MIME-Version field at first and then Content-Type field.  The
+   MIME-Version field is not required to be present in each body part of
+   multipart entity.  Additionally the header MAY also include any other
+   MIME compliant headers.  The character encoding for the MIME Header
+   strings inside the message payload is US-ASCII, as defined in [RFC2045].
+   The actual MIME object may define additional character sets or encodings
+   for the data it delivers.
+
+   Hence, the MIME Header in the message payload may be as follows:
+
+        MIME-Version: 1.0\r\n
+        Content-Type: discrete/composite\r\n
+        Content-Transfer-Encoding: binary\r\n
+        \r\n
+
+   The Content-Transfer-Encoding field behaves as defined in [RFC2045] and
+   defines the encoding of the data in the MIME object.  The preferred data
+   encoding with SILC is "binary".  However, many MIME media types defines
+   their preferred encoding and they may be used if binary encoding is not
+   suitable.
+
+
+
+
+Riikonen                                                        [Page 7]
+
+Internet Draft                                           2 December 2003
+
+
+   When sending large amounts of traffic or large files as MIME objects the
+   limits of the SILC Packet needs to be taken into consideration.  The
+   maximum length of SILC Packet is 2^16 bytes, and larger messages would
+   need to be fragmented.  MIME provides way of fragmenting and reassembling
+   messages, and it is to be done with SILC as defined in [RFC2046].  The
+   MIME fragmentation is defined for gateway usage, but in case of SILC the
+   sender (for example, a client) may also start sending fragmented MIME
+   objects.
+
+   This flag SHOULD NOT be masked with some other Message Flag that defines
+   payloads for message data.  Generally this sort of setting would be
+   impossible for the receiver to interpret.  However, flags that does not
+   define any specific payloads MAY be masked with this flag as well.  For
+   example, this flag could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
+   It also can be masked with SILC_MESSAGE_FLAG_SIGNED flag since it does not
+   define data specific payload.
+
+
+3.5 SILC_MESSAGE_FLAG_ACK
+
+   This flag is used to send acknowledgement messages.  When sender of a
+   message requires the recipient to acknowledge the received message, the
+   sender MUST set the SILC_MESSAGE_FLAG_ACK and MUST NOT set the
+   SILC_MESSAGE_FLAG_NOREPLY.  When a message with this flag set is received
+   an acknowledgement message MUST be sent back.  In the acknowledgement
+   message the sender MUST set the SILC_MESSAGE_FLAG_ACK,
+   SILC_MESSAGE_FLAG_AUTOREPLY and SILC_MESSAGE_FLAG_NOREPLY flags.  The
+   receiver MUST NOT acknowledge the acknowledgement message.  This flag
+   MUST NOT be used with channel messages, and MUST be ignored if received
+   in a channel message.
+
+   The construction of the acknowledgement reply message is normal Message
+   Payload where the Message Data field includes a computed MAC of the
+   original received Message Payload MAC.  Hence, the MAC is computed as
+   follows:
+
+        ack_mac = mac(key, MAC);
+
+   Where the 'key' is the MAC key used to compute MACs for the Message
+   Payload, and the 'MAC' is the MAC taken from the received Message Payload.
+   The 'ack_mac' is placed in the Message Data field in a new Message
+   Payload, and the payload is encrypted in normal manner.  After this the
+   message is sent back to the original sender of the message.
+
+   The receiver of the acknowledgement reply message SHOULD verify the MAC
+   from the Message Data field to assure that acknowledgement was received to
+   an earlier sent message.  Implementation needs to keep the old message
+   MACs stored until acknowledgement is received.  It is left for
+
+
+
+Riikonen                                                        [Page 8]
+
+Internet Draft                                           2 December 2003
+
+
+   implementation to decide any possible retransmission strategy if
+   acknowledgement messages are not received.
+
+
+4 Security Considerations
+
+   In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special
+   attention to the security implications of any media type that can cause
+   the remote execution of any actions in the receiver's environment.  The
+   [RFC2046] and [RFC2048] discusses more MIME specific security
+   considerations.  Even though SILC provides secured messages, in case of
+   MIME which can be used to transfer files and documents which are stored in
+   the receiver's local environment, securing separately the MIME object may
+   be desired.  For example, augmenting the MIME support in SILC messages to
+   support S/MIME may be desired in some implementations.
+
+
+5 References
+
+   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
+                Protocol Specification", Internet Draft, June 2003.
+
+   [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
+                June 2003.
+
+   [SILC3]      Riikonen, P., "SILC Key Exchange and Authentication
+                Protocols", Internet Draft, June 2003.
+
+   [RFC2045]    Freed, N., et al., "Multipurpose Internet Mail Extensions
+                (MIME) Part One: Format of Internet Message Bodies",
+                Standards Track, RFC 2045, November 1996.
+
+   [RFC2046]    Freed, N., et al., "Multipurpose Internet Mail Extensions
+                (MIME) Part Two: Media Types", Standards Track, RFC 2045,
+                November 1996.
+
+   [RFC2047]    Moore K., "MIME (Multipurpose Internet Mail Extensions)
+                Part Three: Message Header Extensions for Non-ASCII Text"
+                Standards Track, RFC 2047, November 1996.
+
+   [RFC2048]    Freed, N., et al., "Multipurpose Internet Mail Extensions
+                (MIME) Part Four: Registration Procedures", Standards
+                Track, RFC 2048, November 1996.
+
+   [RFC2049]    Freed, N., et al., "Multipurpose Internet Mail Extensions
+                (MIME) Part Five: Conformance Criteria and Examples",
+                Standards Track, RFC 2049, November 1996.
+
+
+
+
+Riikonen                                                        [Page 9]
+
+Internet Draft                                           2 December 2003
+
+
+   [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+6 Author's Address
+
+   Pekka Riikonen
+   Snellmaninkatu 34 A 15
+   70100 Kuopio
+   Finland
+
+   EMail: priikone@iki.fi
+
+
+
+7 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                       [Page 10]
+
diff --git a/docs/protocol/draft-riikonen-silc-ke-auth-09.txt b/docs/protocol/draft-riikonen-silc-ke-auth-09.txt
new file mode 100644
index 0000000..cb42868
--- /dev/null
+++ b/docs/protocol/draft-riikonen-silc-ke-auth-09.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                        P. Riikonen
+Internet-Draft
+draft-riikonen-silc-ke-auth-09.txt                       15 January 2007
+Expires: 15 July 2007
+
+
+              SILC Key Exchange and Authentication Protocols
+                   <draft-riikonen-silc-ke-auth-09.txt>
+
+Status of this Draft
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+   This memo describes two protocols used in the Secure Internet Live
+   Conferencing (SILC) protocol, specified in the Secure Internet Live
+   Conferencing, Protocol Specification [SILC1].  The SILC Key Exchange
+   (SKE) protocol provides secure key exchange between two parties
+   resulting into shared secret key material.  The protocol is based
+   on Diffie-Hellman key exchange algorithm and its functionality is
+   derived from several key exchange protocols.
+
+   The second protocol, SILC Connection Authentication protocol provides
+   user level authentication used when creating connections in SILC
+   network.  The protocol supports passphrase (pre-shared secret)
+   authentication and public key (and certificate) authentication based
+   on digital signatures.
+
+
+
+
+
+
+Riikonen                                                        [Page 1]
+
+Internet-Draft                                           15 January 2007
+
+
+Table of Contents
+
+   1 Introduction ..................................................  2
+     1.1 Requirements Terminology ..................................  3
+   2 SILC Key Exchange Protocol ....................................  3
+     2.1 Key Exchange Payloads .....................................  4
+         2.1.1 Key Exchange Start Payload ..........................  4
+         2.1.2 Key Exchange Payload ................................  9
+     2.2 Key Exchange Procedure .................................... 11
+     2.3 Processing the Key Material ............................... 13
+     2.4 SILC Key Exchange Groups .................................. 15
+         2.4.1 diffie-hellman-group1 ............................... 15
+         2.4.2 diffie-hellman-group2 ............................... 15
+         2.4.3 diffie-hellman-group3 ............................... 16
+     2.5 Key Exchange Status Types ................................. 16
+   3 SILC Connection Authentication Protocol ....................... 18
+     3.1 Connection Auth Payload ................................... 19
+     3.2 Connection Authentication Types ........................... 20
+         3.2.1 Passphrase Authentication ........................... 20
+         3.2.2 Public Key Authentication ........................... 21
+     3.3 Connection Authentication Status Types .................... 21
+   4 Security Considerations ....................................... 22
+   5 References .................................................... 22
+   6 Author's Address .............................................. 23
+   7 Full Copyright Statement ...................................... 24
+
+
+List of Figures
+
+   Figure 1:  Key Exchange Start Payload
+   Figure 2:  Key Exchange Payload
+   Figure 3:  Connection Auth Payload
+
+
+1 Introduction
+
+   This memo describes two protocols used in the Secure Internet Live
+   Conferencing (SILC) protocol specified in the Secure Internet Live
+   Conferencing, Protocol Specification [SILC1].  The SILC Key Exchange
+   (SKE) protocol provides secure key exchange between two parties
+   resulting into shared secret key material.  The protocol is based on
+   Diffie-Hellman key exchange algorithm and its functionality is derived
+   from several key exchange protocols, such as SSH2 Key Exchange protocol,
+   Station-To-Station (STS) protocol and the OAKLEY Key Determination
+   protocol [OAKLEY].
+
+   The second protocol, SILC Connection Authentication protocol provides
+   user level authentication used when creating connections in SILC
+
+
+
+Riikonen                                                        [Page 2]
+
+Internet-Draft                                           15 January 2007
+
+
+   network.  The protocol supports passphrase (pre-shared secret)
+   authentication and public key (and certificate) authentication based
+   on digital signatures.
+
+   The basis of secure SILC session requires strong and secure key exchange
+   protocol and authentication.  The authentication protocol is secured and
+   no authentication data is ever sent in the network without encrypting
+   and authenticating it first.  Thus, authentication protocol may be used
+   only after the key exchange protocol has been successfully completed.
+
+   This document constantly refers to other SILC protocol specifications
+   that should be read to be able to fully understand the functionality
+   and purpose of these protocols.  The most important references are
+   the Secure Internet Live Conferencing, Protocol Specification [SILC1]
+   and the SILC Packet Protocol [SILC2].
+
+   The protocol is intended to be used with the SILC protocol thus it
+   does not define own framework that could be used.  The framework is
+   provided by the SILC protocol.
+
+
+1.1 Requirements Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+   MAY, and OPTIONAL, when they appear in this document, are to be
+   interpreted as described in [RFC2119].
+
+
+2 SILC Key Exchange Protocol
+
+   SILC Key Exchange Protocol (SKE) is used to exchange shared secret
+   material used to secure the communication channel.  The protocol use
+   Diffie-Hellman key exchange algorithm and its functionality is derived
+   from several key exchange protocols, such as SSH2 Key Exchange protocol,
+   Station-To-Station (STS) protocol and the OAKLEY Key Determination
+   protocol [OAKLEY].  The protocol does not claim any conformance
+   to any of these protocols, they were only used as a reference when
+   designing this protocol.  The protocol can mutually authenticate the
+   negotiating parties during the key exchange.
+
+   The purpose of SILC Key Exchange protocol is to create session keys to
+   be used in current SILC session.  The keys are valid only for some period
+   of time (usually an hour) or at most until the session ends.  These keys
+   are used to protect packets traveling between the two entities.
+   Usually all traffic is secured with the key material derived from this
+   protocol.
+
+   The Diffie-Hellman implementation used in the SILC SHOULD be compliant
+
+
+
+Riikonen                                                        [Page 3]
+
+Internet-Draft                                           15 January 2007
+
+
+   to the PKCS #3.
+
+
+2.1 Key Exchange Payloads
+
+   During the key exchange procedure public data is sent between initiator
+   and responder.  This data is later used in the key exchange procedure.
+   There are several payloads used in the key exchange.  As for all SILC
+   packets, SILC Packet Header, described in [SILC2], is at the beginning
+   of all packets sent in during this protocol.  All the fields in the
+   following payloads are in MSB (most significant byte first) order.
+
+
+2.1.1 Key Exchange Start Payload
+
+   The key exchange between two entities MUST be started by sending the
+   SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
+   Initiator sends the Key Exchange Start Payload to the responder filled
+   with all security properties it supports.  The responder then checks
+   whether it supports the security properties.
+
+   It then sends a Key Exchange Start Payload to the initiator filled with
+   security properties it selected from the original payload.  The payload
+   sent by responder MUST include only one chosen property per list.  The
+   character encoding for the security property values as defined in [SILC1]
+   SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
+
+   The Key Exchange Start Payload is used to tell connecting entities what
+   security properties and algorithms should be used in the communication.
+   The Key Exchange Start Payload is sent only once per session.  Even if
+   the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
+   Payload is not re-sent.  When PFS is desired the Key Exchange Payloads
+   are sent to negotiate new key material.  The procedure is equivalent to
+   the very first negotiation except that the Key Exchange Start Payload
+   is not sent.
+
+   As this payload is used only with the very first key exchange the payload
+   is never encrypted, as there are no keys to encrypt it with.
+
+   A cookie is also sent in this payload.  A cookie is used to randomize the
+   payload so that none of the key exchange parties can determine this
+   payload before the key exchange procedure starts.  The cookie MUST be
+   returned to the original sender unmodified by the responder.
+
+   Following diagram represents the Key Exchange Start Payload.  The lists
+   mentioned below are always comma (`,') separated and the list MUST NOT
+   include white spaces (` ').
+
+
+
+
+Riikonen                                                        [Page 4]
+
+Internet-Draft                                           15 January 2007
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   RESERVED    |     Flags     |         Payload Length        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                            Cookie                             +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Version String Length     |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                         Version String                        ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Key Exchange Grp Length     |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                      Key Exchange Groups                      ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        PKCS Alg Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                         PKCS Algorithms                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Encryption Alg Length     |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                      Encryption Algorithms                    ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Hash Alg Length         |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                         Hash Algorithms                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         HMAC Length           |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                             HMACs                             ~
+     |                                                               |
+
+
+
+Riikonen                                                        [Page 5]
+
+Internet-Draft                                           15 January 2007
+
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Compression Alg Length     |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                     Compression Algorithms                    ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 1:  Key Exchange Start Payload
+
+
+      o RESERVED (1 byte) - Reserved field.  Sender fills this with
+        zero (0) value.
+
+      o Flags (1 byte) - Indicates flags to be used in the key
+        exchange.  Several flags can be set at once by ORing the
+        flags together.  The following flags are reserved for this
+        field:
+
+           No flags                 0x00
+
+             In this case the field is ignored.
+
+           IV Included              0x01
+
+             This flag is used to indicate that Initialization
+             Vector (IV) in encryption will be included in the
+             ciphertext which the recipient must use in decryption.
+             At the beginning of the SILC packet, before the SILC
+             Packet header an 8-bit Security ID (SID) MUST be
+             placed.  After the SID, the IV MUST be placed.  After
+             the IV, a 32-bit MSB first ordered packet sequence
+             number MUST be placed.  The SID and IV MUST NOT be
+             encrypted, but the sequence number MUST be included
+             in encryption.  The recipient MUST use the sequence
+             number during MAC verification [SILC2].  All fields
+             however are authenticated with MAC.
+
+             The Security ID is set to value 0 when the key
+             exchange is performed for the first time.  It is
+             monotonically increased after each re-key, wrapping
+             eventually.  The SID in combination with the current
+             session can be used to identify which key has been
+             used to encrypt an incoming packet.  This is especially
+             important after rekey when using UDP/IP protocol,
+             where packets may be lost or reordered.  A packet with
+             unknown SID will result into discarding the packet as
+             it cannot be decrypted.  After rekey, implementation
+
+
+
+Riikonen                                                        [Page 6]
+
+Internet-Draft                                           15 January 2007
+
+
+             should understand that it may still receive packets
+             with old SID and be prepared to decrypt them with the
+             old key.
+
+             With this flag it is possible to use SILC protocol on
+             unreliable transport such as UDP/IP which may cause
+             packet reordering and packet losses.  By default,
+             this flag is not set and thus IV is not included
+             in the ciphertext.  Setting this flag increases the
+             packet length by one ciphertext block plus 1 byte for
+             the Security ID and 32 bits for the sequence number.
+             Responder MAY override this flag for the initiator,
+             however without this flag UDP connection cannot be
+             used.  The flag MAY also be used in TCP connection.
+
+             When using with UDP/IP implementations SHOULD use
+             anti-replay methods where an anti-replay window
+             defines what packets are replays.  An example of
+             anti-window protocol is in [RFC2406] Section 3.4.2
+             with example source code in [RFC2401] Appendix C.
+             While [RFC2401] and [RFC2406] does not relate to SILC,
+             the anti-replay method used is applicable in SILC.
+
+           PFS                      0x02
+
+             Perfect Forward Secrecy (PFS) to be used in the
+             key exchange protocol.  If not set, re-keying
+             is performed using the old key.  See the [SILC1]
+             for more information on this issue.  When PFS is
+             used, re-keying and creating new keys for any
+             particular purpose MUST cause new key exchange with
+             new Diffie-Hellman exponent values.  In this key
+             exchange only the Key Exchange Payload is sent and
+             the Key Exchange Start Payload MUST NOT be sent.
+             When doing PFS the Key Exchange Payloads are
+             encrypted with the old keys.
+
+           Mutual Authentication    0x04
+
+             Both of the parties will perform authentication
+             by providing signed data for the other party to
+             verify.  By default, only responder will provide
+             the signature data.  If this is set then the
+             initiator must also provide it.  Initiator MAY
+             set this but also responder MAY set this even if
+             initiator did not set it.
+
+           Rest of the flags are reserved for the future and
+
+
+
+Riikonen                                                        [Page 7]
+
+Internet-Draft                                           15 January 2007
+
+
+           MUST NOT be set.
+
+      o Payload Length (2 bytes) - Length of the entire Key Exchange
+        Start payload, not including any other field.
+
+      o Cookie (16 bytes) - Cookie that randomize this payload so
+        that each of the party cannot determine the payload before
+        hand.  This field MUST be present.
+
+      o Version String Length (2 bytes) - The length of the Version
+        String field, not including any other field.
+
+      o Version String (variable length) - Indicates the version of
+        the sender of this payload.  Initiator sets this when sending
+        the payload and responder sets this when it replies by sending
+        this payload.  See [SILC1] for definition for the version
+        string format.  This field MUST be present and include valid
+        version string.
+
+      o Key Exchange Grp Length (2 bytes) - The length of the
+        key exchange group list, not including any other field.
+
+      o Key Exchange Group (variable length) - The list of
+        key exchange groups.  See the section 2.4 SILC Key Exchange
+        Groups for definitions of these groups.  This field MUST
+        be present.
+
+      o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
+        list, not including any other field.
+
+      o PKCS Algorithms (variable length) - The list of PKCS
+        algorithms.  This field MUST be present.
+
+      o Encryption Alg Length (2 bytes) - The length of the encryption
+        algorithms list, not including any other field.
+
+      o Encryption Algorithms (variable length) - The list of
+        encryption algorithms.  This field MUST be present.
+
+      o Hash Alg Length (2 bytes) - The length of the Hash algorithm
+        list, not including any other field.
+
+      o Hash Algorithms (variable length) - The list of Hash
+        algorithms.  The hash algorithms are mainly used in the
+        SKE protocol.  This field MUST be present.
+
+      o HMAC Length (2 bytes) - The length of the HMAC list, not
+        including any other field.
+
+
+
+Riikonen                                                        [Page 8]
+
+Internet-Draft                                           15 January 2007
+
+
+      o HMACs (variable length) - The list of HMACs.  The HMAC's
+        are used to compute the Message Authentication Code (MAC)
+        of the SILC packets.  This field MUST be present.
+
+      o Compression Alg Length (2 bytes) - The length of the
+        compression algorithms list, not including any other field.
+
+      o Compression Algorithms (variable length) - The list of
+        compression algorithms.  This field MAY be omitted.
+
+
+2.1.2 Key Exchange Payload
+
+   Key Exchange payload is used to deliver the public key (or certificate),
+   the computed Diffie-Hellman public value and possibly signature data
+   from one party to the other.  When initiator is using this payload
+   and the Mutual Authentication flag is not set then the initiator MUST
+   NOT provide the signature data.  If the flag is set then the initiator
+   MUST provide the signature data so that the responder can verify it.
+
+   The Mutual Authentication flag is usually used when a separate
+   authentication protocol will not be executed for the initiator of the
+   protocol.  This is case for example when the SKE is performed between
+   two SILC clients.  In normal case, where client is connecting to a
+   server, or server is connecting to a router the Mutual Authentication
+   flag MAY be omitted.  However, if the connection authentication protocol
+   for the connecting entity is not based on digital signatures (it is
+   based on pre-shared key or there is no authentication) then the Mutual
+   Authentication flag SHOULD be enabled.  This way the connecting entity
+   has to provide proof of possession of the private key for the public key
+   it will provide in this protocol.
+
+   When performing re-key with PFS selected this is the only payload that
+   is sent in the SKE protocol.  The Key Exchange Start Payload MUST NOT
+   be sent at all.  However, this payload does not have all the fields
+   present.  In the re-key with PFS the public key and a possible signature
+   data SHOULD NOT be present.  If they are present they MUST be ignored.
+   The only field that is present is the Public Data that is used to create
+   the new key material.  In the re-key the Mutual Authentication flag, that
+   may be set in the initial negotiation, MUST also be ignored.
+
+   This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
+   SILC_PACKET_KEY_EXCHANGE_2 packet types.  The initiator uses the
+   SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
+
+   The following diagram represent the Key Exchange Payload.
+
+
+
+
+
+Riikonen                                                        [Page 9]
+
+Internet-Draft                                           15 January 2007
+
+
+                          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       |        Public Key Type        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~            Public Key of the party (or certificate)           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Public Data Length      |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                          Public Data                          ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Signature Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                        Signature Data                         ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 2:  Key Exchange Payload
+
+
+      o Public Key Length (2 bytes) - The length of the Public Key
+        (or certificate) field, not including any other field.
+
+      o Public Key Type (2 bytes) - The public key (or certificate)
+        type.  This field indicates the type of the public key in
+        the packet.  Following types are defined:
+
+           1    SILC style public key (mandatory)
+           2    SSH2 style public key (optional)
+           3    X.509 Version 3 certificate (optional)
+           4    OpenPGP certificate (optional)
+           5    SPKI certificate (optional)
+
+        The only required type to support is type number 1.  See
+        [SILC1] for the SILC public key specification.  See
+        SSH2 public key specification in [SSH-TRANS].  See X.509v3
+        certificate specification in [PKIX-Part1].  See OpenPGP
+        certificate specification in [PGP].  See SPKI certificate
+        specification in [SPKI].  If this field includes zero (0)
+        or unsupported type number the protocol MUST be aborted
+        sending SILC_PACKET_FAILURE message and the connection SHOULD
+        be closed immediately.
+
+
+
+
+Riikonen                                                       [Page 10]
+
+Internet-Draft                                           15 January 2007
+
+
+      o Public Key (or certificate) (variable length) - The
+        public key or certificate of the party.  This public key
+        may be used to verify the digital signature.  The public key
+        or certificate in this field is encoded in the manner as
+        defined in their respective definitions; see previous field.
+
+      o Public Data Length (2 bytes) - The length of the Public Data
+        field, not including any other field.
+
+      o Public Data (variable length) - The public data to be
+        sent to the receiver (computed Diffie-Hellman public values).
+        See section 2.2 Key Exchange Procedure for detailed description
+        how this field is computed.  This field is MP integer and is
+        encoded as defined in [SILC1].
+
+      o Signature Length (2 bytes) - The length of the signature,
+        not including any other field.
+
+      o Signature Data (variable length) - The signature signed
+        by the sender.  The receiver of this signature MUST
+        verify it.  The verification is done using the sender's
+        public key.  See section 2.2 Key Exchange Procedure for
+        detailed description how to produce the signature.  If
+        the Mutual Authentication flag is not set then initiator
+        MUST NOT provide this field and the Signature Length field
+        MUST be set to zero (0) value.  If the flag is set then
+        also the initiator MUST provide this field.  The responder
+        always MUST provide this field.  The encoding for signature
+        is defined in [SILC1].
+
+
+
+2.2 Key Exchange Procedure
+
+   The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
+   Key Exchange Start Payload to select the security properties to be used
+   in the key exchange and later in the communication.
+
+   After Key Exchange Start Payload has been processed by both of the
+   parties the protocol proceeds as follows:
+
+
+   Setup:  p is a large and public safe prime.  This is one of the
+           Diffie Hellman groups.  q is order of subgroup (largest
+           prime factor of p).  g is a generator and is defined
+           along with the Diffie Hellman group.
+
+       1.  Initiator generates a random number x, where 1 < x < q,
+
+
+
+Riikonen                                                       [Page 11]
+
+Internet-Draft                                           15 January 2007
+
+
+           and computes e = g ^ x mod p.  The result e is then
+           encoded into Key Exchange Payload, with the public key
+           (or certificate) and sent to the responder.
+
+           If the Mutual Authentication flag is set then initiator
+           MUST also produce signature data SIGN_i which the responder
+           will verify.  The initiator MUST compute a hash value
+           HASH_i = hash(Initiator's Key Exchange Start Payload |
+           public key (or certificate) | e).  The '|' stands for
+           concatenation.  It then signs the HASH_i value with its
+           private key resulting a signature SIGN_i.
+
+       2.  Responder generates a random number y, where 1 < y < q,
+           and computes f = g ^ y mod p.  It then computes the
+           shared secret KEY = e ^ y mod p, and, a hash value
+           HASH = hash(Initiator's Key Exchange Start Payload |
+           public key (or certificate) | Initiator's public key
+           (or certificate) | e | f | KEY).  It then signs
+           the HASH value with its private key resulting a signature
+           SIGN.
+
+           It then encodes its public key (or certificate), f and
+           SIGN into Key Exchange Payload and sends it to the
+           initiator.
+
+           If the Mutual Authentication flag is set then the responder
+           SHOULD verify that the public key provided in the payload
+           is authentic, or if certificates are used it verifies the
+           certificate.  The responder MAY accept the public key without
+           verifying it, however, doing so may result to insecure key
+           exchange (accepting the public key without verifying may be
+           desirable for practical reasons on many environments.  For
+           long term use this is never desirable, in which case
+           certificates would be the preferred method to use).  It then
+           computes the HASH_i value the same way initiator did in the
+           phase 1.  It then verifies the signature SIGN_i from the
+           payload with the hash value HASH_i using the received public
+           key.
+
+       3.  Initiator verifies that the public key provided in
+           the payload is authentic, or if certificates are used
+           it verifies the certificate.  The initiator MAY accept
+           the public key without verifying it, however, doing
+           so may result to insecure key exchange (accepting the
+           public key without verifying may be desirable for
+           practical reasons on many environments.  For long term
+           use this is never desirable, in which case certificates
+           would be the preferred method to use).
+
+
+
+Riikonen                                                       [Page 12]
+
+Internet-Draft                                           15 January 2007
+
+
+           Initiator then computes the shared secret KEY =
+           f ^ x mod p, and, a hash value HASH in the same way as
+           responder did in phase 2.  It then verifies the
+           signature SIGN from the payload with the hash value
+           HASH using the received public key.
+
+
+   If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
+   to indicate that the key exchange protocol has failed, and the connection
+   SHOULD be closed immediately.  Any other packets MUST NOT be sent or
+   accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
+   SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
+
+   The result of this protocol is a shared secret key material KEY and
+   a hash value HASH.  The key material itself is not fit to be used as
+   a key, it needs to be processed further to derive the actual keys to be
+   used.  The key material is also used to produce other security parameters
+   later used in the communication.  See section 2.3 Processing the Key
+   Material for detailed description how to process the key material.
+
+   If the Mutual Authentication flag was set the protocol produces also
+   a hash value HASH_i.  This value, however, must be discarded.
+
+   After the keys are processed the protocol is ended by sending the
+   SILC_PACKET_SUCCESS packet.  Both entities send this packet to
+   each other.  After this both parties MUST start using the new keys.
+
+
+2.3 Processing the Key Material
+
+   Key Exchange protocol produces secret shared key material KEY.  This
+   key material is used to derive the actual keys used in the encryption
+   of the communication channel.  The key material is also used to derive
+   other security parameters used in the communication.  Key Exchange
+   protocol produces a hash value HASH as well.
+
+   The keys MUST be derived from the key material as follows:
+
+      Sending Initial Vector (IV)     = hash(0x0 | KEY | HASH)
+      Receiving Initial Vector (IV)   = hash(0x1 | KEY | HASH)
+      Sending Encryption Key          = hash(0x2 | KEY | HASH)
+      Receiving Encryption Key        = hash(0x3 | KEY | HASH)
+      Sending HMAC Key                = hash(0x4 | KEY | HASH)
+      Receiving HMAC Key              = hash(0x5 | KEY | HASH)
+
+
+   The Initial Vector (IV) is used in the encryption when doing for
+   example CBC mode.  As many bytes as needed are taken from the start of
+
+
+
+Riikonen                                                       [Page 13]
+
+Internet-Draft                                           15 January 2007
+
+
+   the hash output for IV.  Sending IV is for sending key and receiving IV
+   is for receiving key.  For receiving party, the receiving IV is actually
+   sender's sending IV, and, the sending IV is actually sender's receiving
+   IV.  Initiator uses IV's as they are (sending IV for sending and
+   receiving IV for receiving).
+
+   The Encryption Keys are derived as well from the hash().  If the hash()
+   output is too short for the encryption algorithm more key material MUST
+   be produced in the following manner:
+
+      K1 = hash(0x2 | KEY | HASH)
+      K2 = hash(KEY | HASH | K1)
+      K3 = hash(KEY | HASH | K1 | K2)  ...
+
+      Sending Encryption Key = K1 | K2 | K3 ...
+
+
+      K1 = hash(0x3 | KEY | HASH)
+      K2 = hash(KEY | HASH | K1)
+      K3 = hash(KEY | HASH | K1 | K2)  ...
+
+      Receiving Encryption Key = K1 | K2 | K3 ...
+
+
+   The key is distributed by hashing the previous hash with the original
+   key material.  The final key is a concatenation of the hash values.
+   For Receiving Encryption Key the procedure is equivalent.  Sending key
+   is used only for encrypting data to be sent.  The receiving key is used
+   only to decrypt received data.  For receiving party, the receive key is
+   actually sender's sending key, and, the sending key is actually sender's
+   receiving key.  Initiator uses generated keys as they are (sending key
+   for sending and receiving key for receiving).
+
+   The HMAC keys are used to create MAC values to packets in the
+   communication channel.  As many bytes as needed are taken from the start
+   of the hash output to generate the MAC keys.
+
+   These procedures are performed by all parties of the key exchange
+   protocol.  This MUST be done before the protocol has been ended by
+   sending the SILC_PACKET_SUCCESS packet, to assure that parties can
+   successfully process the key material.
+
+   This same key processing procedure MAY be used in the SILC in some
+   other circumstances as well.  Any changes to this procedure is defined
+   separately when this procedure is needed.  See the [SILC1] and the
+   [SILC2] for these circumstances.
+
+
+
+
+
+Riikonen                                                       [Page 14]
+
+Internet-Draft                                           15 January 2007
+
+
+2.4 SILC Key Exchange Groups
+
+   The Following groups may be used in the SILC Key Exchange protocol.
+   The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
+   negotiated to be used in the connection with Key Exchange Start Payload
+   and SILC_PACKET_KEY_EXCHANGE packet.  However, the first group MUST be
+   proposed in the Key Exchange Start Payload regardless of any other
+   requested group (however, it does not have to be the first in the list).
+
+
+2.4.1 diffie-hellman-group1
+
+   The length of this group is 1024 bits.  This is REQUIRED group.
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+
+   Its hexadecimal value is
+
+      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+      FFFFFFFF FFFFFFFF
+
+
+   The generator used with this prime is g = 2.  The group order q is
+   (p - 1) / 2.
+
+   This group was taken from RFC 2412.
+
+
+2.4.2 diffie-hellman-group2
+
+   The length of this group is 1536 bits.  This is OPTIONAL group.
+   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
+
+   Its hexadecimal value is
+
+      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+      670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+
+   The generator used with this prime is g = 2.  The group order q is
+
+
+
+Riikonen                                                       [Page 15]
+
+Internet-Draft                                           15 January 2007
+
+
+   (p - 1) / 2.
+
+   This group was taken from RFC 3526.
+
+
+2.4.3 diffie-hellman-group3
+
+   The length of this group is 2048 bits.  This is OPTIONAL group.
+   This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
+
+   Its hexadecimal value is
+
+      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+      670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
+      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
+      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
+      15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
+
+   The generator used with this prime is g = 2.  The group order q is
+   (p - 1) / 2.
+
+   This group was taken from RFC 3526.
+
+   Additional larger groups are defined in RFC 3526 and may be used in SKE
+   by defining name for them using the above name format.
+
+
+2.5 Key Exchange Status Types
+
+   This section defines all key exchange protocol status types that may
+   be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+   to indicate the status of the protocol.  Implementations may map the
+   status types to human readable error message.  All types except the
+   SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+   The length of status is 32 bits (4 bytes).  The following status types
+   are defined:
+
+      0   SILC_SKE_STATUS_OK
+
+          Protocol were executed successfully.
+
+
+
+
+
+Riikonen                                                       [Page 16]
+
+Internet-Draft                                           15 January 2007
+
+
+      1   SILC_SKE_STATUS_ERROR
+
+          Unknown error occurred.  No specific error type is defined.
+
+
+      2   SILC_SKE_STATUS_BAD_PAYLOAD
+
+          Provided KE payload were malformed or included bad fields.
+
+
+      3   SILC_SKE_STATUS_UNSUPPORTED_GROUP
+
+          None of the provided groups were supported.
+
+
+      4   SILC_SKE_STATUS_UNSUPPORTED_CIPHER
+
+          None of the provided ciphers were supported.
+
+
+      5   SILC_SKE_STATUS_UNSUPPORTED_PKCS
+
+          None of the provided public key algorithms were supported.
+
+
+      6   SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
+
+          None of the provided hash functions were supported.
+
+
+      7   SILC_SKE_STATUS_UNSUPPORTED_HMAC
+
+          None of the provided HMACs were supported.
+
+
+      8   SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
+
+          Provided public key type is not supported.
+
+
+      9   SILC_SKE_STATUS_INCORRECT_SIGNATURE
+
+          Provided signature was incorrect.
+
+
+      10  SILC_SKE_STATUS_BAD_VERSION
+
+          Provided version string was not acceptable.
+
+
+
+Riikonen                                                       [Page 17]
+
+Internet-Draft                                           15 January 2007
+
+
+      11  SILC_SKE_STATUS_INVALID_COOKIE
+
+          The cookie in the Key Exchange Start Payload was malformed,
+          because responder modified the cookie.
+
+
+3 SILC Connection Authentication Protocol
+
+   Purpose of Connection Authentication protocol is to authenticate the
+   connecting party with server.  Usually connecting party is client but
+   server may connect to router server as well.  Its other purpose is to
+   provide information for the server about which type of entity the
+   connection is.  The type defines whether the connection is client,
+   server or router connection.  Server use this information to create the
+   ID for the connection.
+
+   Server MUST verify the authentication data received and if it is to fail
+   the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+   If authentication is successful the protocol is ended by server by sending
+   SILC_PACKET_SUCCESS packet.
+
+   The protocol is executed after the SILC Key Exchange protocol.  It MUST
+   NOT be executed in any other time.  As it is performed after key exchange
+   protocol all traffic in the connection authentication protocol is
+   encrypted with the exchanged keys.
+
+   The protocol MUST be started by the connecting party by sending the
+   SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
+   described in the next section.  This payload MUST include the
+   authentication data.  The authentication data is set according
+   authentication method that MUST be known by both parties.  If connecting
+   party does not know what is the mandatory authentication method it MAY
+   request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
+   packet.  This packet is not part of this protocol and is described in
+   section Connection Auth Request Payload in [SILC2].  However, if
+   connecting party already knows the mandatory authentication method
+   sending the request is not necessary.
+
+   See [SILC1] and section Connection Auth Request Payload in [SILC2] also
+   for the list of different authentication methods.  Authentication method
+   MAY also be NONE, in which case the server does not require
+   authentication.  However, in this case the protocol still MUST be
+   executed; the authentication data is empty indicating no authentication
+   is required.
+
+   If authentication method is passphrase the authentication data is
+   plaintext passphrase.  As the payload is encrypted it is safe to have
+   plaintext passphrase.  It is also provided as plaintext passphrase
+
+
+
+Riikonen                                                       [Page 18]
+
+Internet-Draft                                           15 January 2007
+
+
+   because the receiver may need to pass the entire passphrase into a
+   passphrase verifier, and a message digest of the passphrase would
+   prevent this.  See the section 3.2.1 Passphrase Authentication for
+   more information.
+
+   If authentication method is public key authentication the authentication
+   data is a digital signature of the hash value of hash HASH and Key
+   Exchange Start Payload, established by the SILC Key Exchange protocol.
+   This signature MUST then be verified by the server.  See the section
+   3.2.2 Public Key Authentication for more information.
+
+   See the section 4 SILC Procedures in [SILC1] for more information about
+   client creating connection to server, and server creating connection
+   to router, and how to register the session in the SILC Network after
+   successful Connection Authentication protocol.
+
+
+3.1 Connection Auth Payload
+
+   Client sends this payload to authenticate itself to the server.  Server
+   connecting to another server also sends this payload.  Server receiving
+   this payload MUST verify all the data in it and if something is to fail
+   the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+
+   The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
+   It MUST NOT be sent in any other packet type.  The following diagram
+   represent the Connection Auth Payload.
+
+
+
+
+
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Payload Length         |        Connection Type        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                     Authentication Data                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 3:  Connection Auth Payload
+
+
+      o Payload Length (2 bytes) - Length of the entire Connection
+
+
+
+Riikonen                                                       [Page 19]
+
+Internet-Draft                                           15 January 2007
+
+
+        Auth Payload.
+
+      o Connection Type (2 bytes) - Indicates the type of the
+        connection.  See section Connection Auth Request Payload
+        in [SILC2] for the list of connection types.  This field MUST
+        include valid connection type or the packet MUST be discarded
+        and authentication MUST be failed.
+
+      o Authentication Data (variable length) - The actual
+        authentication data.  Contents of this depends on the
+        authentication method known by both parties.  If no
+        authentication is required this field does not exist.
+
+
+3.2 Connection Authentication Types
+
+   SILC supports two authentication types to be used in the connection
+   authentication protocol; passphrase authentication or public key
+   authentication based on digital signatures.  The following sections
+   defines the authentication methods.  See [SILC2] for defined numerical
+   authentication method types.
+
+
+3.2.1 Passphrase Authentication
+
+   Passphrase authentication or pre-shared key based authentication is
+   simply an authentication where the party that wants to authenticate
+   itself to the other end sends the passphrase that is required by
+   the other end, for example server.  The plaintext passphrase is put
+   to the payload, that is then encrypted.  The plaintext passphrase
+   MUST be in UTF-8 [RFC2279] encoding.  If the passphrase is in the
+   sender's system in some other encoding it MUST be UTF-8 encoded
+   before transmitted.  The receiver MAY change the encoding of the
+   passphrase to its system's default character encoding before verifying
+   the passphrase.
+
+   If the passphrase matches with the one in the server's end the
+   authentication is successful.  Otherwise SILC_PACKET_FAILURE MUST be
+   sent to the sender and the protocol execution fails.
+
+   This is REQUIRED authentication method to be supported by all SILC
+   implementations.
+
+   When password authentication is used it is RECOMMENDED that maximum
+   amount of padding is applied to the SILC packet.  This way it is not
+   possible to approximate the length of the password from the encrypted
+   packet.
+
+
+
+
+Riikonen                                                       [Page 20]
+
+Internet-Draft                                           15 January 2007
+
+
+3.2.2 Public Key Authentication
+
+   Public key authentication may be used if passphrase based authentication
+   is not desired.  The public key authentication works by sending a
+   digital signature as authentication data to the other end, say, server.
+   The server MUST then verify the signature by the public key of the sender,
+   which the server has received earlier in SKE protocol, or which the
+   server has cached locally at some previous time.
+
+   The signature is computed using the private key of the sender by signing
+   the HASH value provided by the SKE protocol previously, and the Key
+   Exchange Start Payload from SKE protocol that was sent to the server.
+   These are concatenated and hash function is used to compute a hash value
+   which is then signed.
+
+     auth_hash = hash(HASH | Key Exchange Start Payload);
+     signature = sign(auth_hash);
+
+   The hash() function used to compute the value is the hash function
+   negotiated in the SKE protocol.  The server MUST verify the data, thus
+   it must keep the HASH and the Key Exchange Start Payload saved during
+   SKE and authentication protocols.  These values can be discarded after
+   Connection Authentication protocol is completed.
+
+   If the verified signature matches the sent signature, the authentication
+   were successful and SILC_PACKET_SUCCESS is sent.  If it failed the
+   protocol execution is stopped and SILC_PACKET_FAILURE is sent.
+
+   This is REQUIRED authentication method to be supported by all SILC
+   implementations.
+
+
+
+3.3 Connection Authentication Status Types
+
+   This section defines all connection authentication status types that
+   may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+   to indicate the status of the protocol.  Implementations may map the
+   status types to human readable error message.  All types except the
+   SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+   The length of status is 32 bits (4 bytes).  The following status types
+   are defined:
+
+   0   SILC_AUTH_OK
+
+       Protocol was executed successfully.
+
+
+
+
+
+Riikonen                                                       [Page 21]
+
+Internet-Draft                                           15 January 2007
+
+
+   1   SILC_AUTH_FAILED
+
+       Authentication failed.
+
+
+4 Security Considerations
+
+   Security is central to the design of this protocol, and these security
+   considerations permeate the specification.  Common security considerations
+   such as keeping private keys truly private and using adequate lengths for
+   symmetric and asymmetric keys must be followed in order to maintain the
+   security of this protocol.
+
+
+5 References
+
+   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
+                Protocol Specification", Internet Draft, January 2007.
+
+   [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
+                January 2007.
+
+   [SILC4]      Riikonen, P., "SILC Commands", Internet Draft, January 2007.
+
+   [IRC]        Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+                RFC 1459, May 1993.
+
+   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+                April 2000.
+
+   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
+                2811, April 2000.
+
+   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+                2812, April 2000.
+
+   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+                2813, April 2000.
+
+   [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
+                Internet Draft.
+
+   [PGP]        Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+                November 1998.
+
+   [SPKI]       Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+                September 1999.
+
+
+
+
+Riikonen                                                       [Page 22]
+
+Internet-Draft                                           15 January 2007
+
+
+   [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+                Infrastructure, Certificate and CRL Profile", RFC 2459,
+                January 1999.
+
+   [Schneier]   Schneier, B., "Applied Cryptography Second Edition",
+                John Wiley & Sons, New York, NY, 1996.
+
+   [Menezes]    Menezes, A., et al, "Handbook of Applied Cryptography",
+                CRC Press 1997.
+
+   [OAKLEY]     Orman, H., "The OAKLEY Key Determination Protocol",
+                RFC 2412, November 1998.
+
+   [ISAKMP]     Maughan D., et al, "Internet Security Association and
+                Key Management Protocol (ISAKMP)", RFC 2408, November
+                1998.
+
+   [IKE]        Harkins D., and Carrel D., "The Internet Key Exchange
+                (IKE)", RFC 2409, November 1998.
+
+   [HMAC]       Krawczyk, H., "HMAC: Keyed-Hashing for Message
+                Authentication", RFC 2104, February 1997.
+
+   [PKCS1]      Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+                Specifications, Version 2.0", RFC 2437, October 1998.
+
+   [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", RFC 2279, January 1998.
+
+   [RFC2401]    Kent, S., et al, "Security Architecture for the Internet
+                Protocol", RFC 2401, November 1998.
+
+   [RFC2406]    Kent, S., et al, "Security Architecture for the Internet
+                Protocol", RFC 2406, November 1998.
+
+
+6 Author's Address
+
+   Pekka Riikonen
+   Helsinki
+   Finland
+
+   EMail: priikone@iki.fi
+
+
+
+
+
+Riikonen                                                       [Page 23]
+
+Internet-Draft                                           15 January 2007
+
+
+7 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                       [Page 24]
+
diff --git a/docs/protocol/draft-riikonen-silc-multimedia-session-00.txt b/docs/protocol/draft-riikonen-silc-multimedia-session-00.txt
new file mode 100644
index 0000000..c6c7719
--- /dev/null
+++ b/docs/protocol/draft-riikonen-silc-multimedia-session-00.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        P. Riikonen
+Internet-Draft
+draft-riikonen-silc-multimedia-session-00.txt            15 January 2007
+Expires: 15 July 2007
+
+
+                   Multimedia Sessions in SILC protocol
+              <draft-riikonen-silc-multimedia-session-00.txt>
+
+Status of this Draft
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+   This document defines the use of multimedia protocols and the set up
+   of multimedia sessions in the Secure Internet Live Conferencing (SILC)
+   protocol [SILC1].
+
+
+Table of Contents
+
+   1 Introduction ..................................................  2
+     1.1 Requirements Terminology ..................................  2
+   2 Recommended Protocol ..........................................  2
+   3 Session Description Protocol (SDP) ............................  2
+     3.1 SDP field usage in SILC ...................................  3
+     3.2 SDP Examples ..............................................  5
+   4 Session Initiation Protocol (SIP) .............................  6
+   5 Other Protocols ...............................................  6
+   6 Security Considerations .......................................  7
+
+
+
+Riikonen                                                        [Page 1]
+
+Internet-Draft                                           15 January 2007
+
+
+   7 References ....................................................  7
+   8 Author's Address ..............................................  7
+   9 Full Copyright Statement ......................................  7
+
+
+1 Introduction
+
+   This document defines the use of multimedia protocols and the set up
+   of multimedia sessions in the Secure Internet Live Conferencing (SILC)
+   protocol [SILC1].  The SILC protocol supports multimedia messages
+   with the Message Payload [SILC2] and SILC_MESSAGE_FLAG_DATA which
+   has the ability to define what type of content is delievered within
+   the payload.  The Message Payload is used to encapsulate the multimedia
+   session set up procedure and the actual multimedia session data.  We
+   define the recommended multimedia session protocol for SILC and also
+   consider some other protocols in the scope of SILC.
+
+
+1.1 Requirements Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+   MAY, and OPTIONAL, when they appear in this document, are to be
+   interpreted as described in [RFC2119].
+
+
+2 Recommended Protocol
+
+   Since SILC protocol can encapsulate practically any protocol for setting
+   up a multimedia session we have selected the Session Description Protocol
+   (SDP) as RECOMMENDED protocol.  It was chosen for its maturity, simplicity
+   and versatility.  If multimedia features are implemented in SILC
+   application it is recommended that at least support for SDP is added.
+
+
+3 Session Description Protocol (SDP)
+
+   The SDP [SDP] protocol defines a general purpose multimedia session
+   description protocol.  SDP is one of the simplest protocols to negotiate
+   multimedia sessions and is suited perfectly for SILC protocol.  Since SDP
+   does not itself define how it is used to set up the session, we define it
+   here for SILC.  The definition is based on the [RFC3264] and [RFC4145].
+
+   In SILC the SDP messages are sent as data messages (MIME message).  They
+   can be destined directly to a client for direct conferencing, or to a
+   channel for group conferencing.  It is also possible to send the message
+   directly to client to invite them to group conferencing before they have
+   joined the channel.  The MIME type used is application/sdp.
+
+
+
+
+Riikonen                                                        [Page 2]
+
+Internet-Draft                                           15 January 2007
+
+
+   To set up a multimedia session a client sends SILC message with
+   SILC_MESSAGE_FLAG_DATA and SILC_MESSAGE_FLAG_REQUEST flags set and with
+   MIME SDP message in the message payload.  If the receiver wants to
+   participate in the multimedia session it sends MIME SDP message back with
+   SILC_MESSAGE_FLAG_DATA and SILC_MESSAGE_FLAG_REPLY flags set to the
+   sender.  If reply is not received after an application defined period of
+   time the message may be retransmitted or the session set up may be
+   terminated.
+
+   After reply has been received the multimedia session is started according
+   to the SDP and all multimedia data is sent using SILC data messages.  When
+   performing peer-to-peer connection the SDP defines which party initiates
+   the connection.  After initiation the SILC Key Exchange protocol MUST be
+   performed.  The resulted key material will be used to protect the multimedia
+   session.  Multimedia data transmission may start after the key exchange
+   has been performed.  When performing group conferencing all parties
+   independently connect to the SILC server specified in the SDP.  In other
+   cases when performing the multimedia session inside the SILC network, any
+   party may start transmitting the multimedia data after the SDPs have been
+   exchanged.
+
+   To terminate the session, or to reject incoming request, an MD5 digest
+   MUST be computed from the original SDP data, and the digest is sent back
+   with the SILC_MESSAGE_FLAG_DATA and SILC_MESSAGE_FLAG_STOP flags set.
+   The receiver of such message should verify the MD5 digest and terminate
+   the session if it matches any active session.  The session may also be
+   terminated by closing network connection.  In group sessions simply by
+   leaving the channel terminates the session.  The original sender of the
+   SDP message may send the terminating message to notify all clients on the
+   channel to terminate the session.  If the original sender on channel
+   receives the terminating message it takes no action on it.
+
+3.1 SDP field usage in SILC
+
+   The Encryption Keys (k=) field describes encryption key to protect the
+   multimedia session.  As SILC protocol transport and the multimedia session
+   is secured by default this field SHOULD NOT be used.
+
+
+   The Origin (o=) field describes from where the session originates.  The
+   <username> sub-field is the sender's SILC nickname.  Examples:
+
+        o=foobar 2890844521 2890842804 IN IP4 10.2.1.7
+
+
+   The Connection Data (c=) field describes the connection information for
+   the multimedia session.  When performing peer-to-peer multimedia session
+   the <network type> is 'IN', indicating Internet connection.  When
+
+
+
+Riikonen                                                        [Page 3]
+
+Internet-Draft                                           15 January 2007
+
+
+   performing multimedia session inside SILC network it is 'SILC'.  When
+   the 'SILC' network type is used the <address type> and <connection address>
+   sub-fields are omitted.  Examples:
+
+        c=SILC
+        c=IN IP4 10.2.1.7
+
+
+   The Media Announcements (m=) field describes the media information for the
+   multimedia session.  If the network type in c= field is 'SILC' the <port>
+   sub-field MUST be set to 9 (discard).  The <transport> for RTP over UDP
+   is 'RTP/AVP', for RTP over TCP it is 'TCP/RTP/AVP', and for non-RTP protocol
+   over UDP it is 'udp' and over TCP it is 'tcp'.  The <fmt> sub-field
+   includes the RTP media payload number when using RTP.  When using non-RTP
+   protocol it includes MIME subtype.  Examples:
+
+        c=SILC
+        m=audio 9 TCP/RTP/AVP 3
+        a=rtpmap:3 GSM/8000
+
+        c=SILC
+        m=audio 9 tcp mpeg
+
+
+   The Attributes (a=) field can be used to set various session and media
+   specific attributes.  For SILC we define attribute "silc".
+
+        a=silc:<session type> <parameters>
+
+   The <session type> is either "direct" or "group".  When it is "direct"
+   and the c= field defines a connection point the connection will be
+   peer-to-peer connection to the remote client.  If it is "group" and the
+   the c= field defines a connection point the connection will be to a remote
+   SILC server for group conferencing.  If c= field includes "SILC" network
+   type, then "direct" is for direct session with a client in SILC network
+   and "group" is for group conferencing in SILC network.  If the "silc"
+   attribute is omitted the session type is expected to be "direct".  The
+   following parameters are defined for attribute "silc".
+
+        channel        The name of the channel for group conferencing.
+                           Can be used only with "group" session type.
+                           More than one channel parameters may be defined.
+
+
+   The [RFC4145] specifies a "setup" attribute that defines which party of the
+   session will initiate the connection when performing peer-to-peer session.
+   Its use in SILC is as specified in [RFC4145] and MUST be present in SDP
+   when the c= field includes an actual connection point and when the "silc"
+
+
+
+Riikonen                                                        [Page 4]
+
+Internet-Draft                                           15 January 2007
+
+
+   attribute session type is "direct", or if the attribute is not present at
+   all.  When performing group conferencing each party always need to create
+   the connection to the server and the "setup" attribute need not be present
+   in SDP.
+
+3.2 SDP Examples
+
+        v=0
+        o=foobar 2890844521 2890842804 IN IP4 10.2.1.100
+        s=peer-to-peer example
+        t=0 0
+        m=audio 5000 TCP/RTP/AVP 3
+        c=IN IP4 10.2.1.100
+        a=rtpmap:3 GSM/8000
+        a=silc:direct
+        a=setup:active
+
+   This example sets up a peer-to-peer session to remote client at
+   10.2.1.100 at port 5000.
+
+        v=0
+        o=foobar 2890844521 2890842804 IN IP4 10.2.1.32
+        s=Group conferencing example
+        c=IN IP4 10.2.1.7
+        t=0 0
+        a=silc:group channel=foobar
+        m=audio 706 TCP/RTP/AVP 3
+        a=rtpmap:3 GSM/8000
+
+   This example sets up a session to a remote SILC server 10.2.1.7 at port
+   706.  Once connected the channel "foobar" will be joined for group
+   conferencing.
+
+        v=0
+        o=foobar 2890844521 2890842804 IN IP4 10.2.1.32
+        s=SILC network chat example
+        c=SILC
+        t=0 0
+        m=audio 9 TCP/RTP/AVP 3
+        a=rtpmap:3 GSM/8000
+
+   This example sets up a session inside SILC network with the remote user
+   "foobar".
+
+        v=0
+        o=foobar 2890844521 2890842804 IN IP4 10.2.1.32
+        s=SILC network group conferencing example
+        t=0 0
+
+
+
+Riikonen                                                        [Page 5]
+
+Internet-Draft                                           15 January 2007
+
+
+        m=audio 9 TCP/RTP/AVP 3
+        c=SILC
+        a=rtpmap:3 GSM/8000
+        a=silc:group channel=group-chat
+
+   This example sets up a group conferencing session inside SILC network on
+   channel "group-chat".
+
+
+4 Session Initiation Protocol (SIP)
+
+   The SIP [SIP] protocol is a general purpose protocol for setting up,
+   modifying and terminating different kinds of sessions, including
+   multimedia sessions.  The SIP protocol use the SDP to describe the
+   multimedia session.
+
+   In SILC the SIP messages are sent as data messages (MIME message).  They
+   can be destined directly to a client for direct conferencing, or to a
+   channel for group conferencing.  It is also possible to send the message
+   directly to client to invite them to group conferencing before they have
+   joined the channel.  The MIME type used is application/sip.  The
+   SILC_MESSAGE_FLAG_DATA flag must be set in each message and the message
+   payload includes a MIME SIP message.  The actual SIP session set up and
+   termination is described in the SIP protocol specification, and SILC
+   protocol merely provides a secure transport for the session.  After the
+   session is set up all multimedia data is sent using SILC data messages.
+   The MIME type for the multimedia data messages is defined during the SIP
+   session set up.
+
+   The rules for SDP fields described in previous section also applies for
+   SDP with SIP in the context of SILC.
+
+   Proxy and redirection servers usually would not be used in the context of
+   SILC, unless the sessions are redirected to outside SILC network.  This
+   may compromise the security of the session.
+
+   The S/MIME need not be used when using SIP in SILC protocol.  The SILC
+   protocol transport and the created multimedia session is secured by
+   default.
+
+
+5 Other Protocols
+
+   There are other open and proprietary protocols for setting up multimedia
+   sessions.  One important is H.323 using the H.225 to set up the session.
+   This document should later define the use of H.323 with SILC.
+   Practically any protocol to set up multimedia sessions may be used with
+   SILC by using SILC as a secure transport to set up the session, and to use
+
+
+
+Riikonen                                                        [Page 6]
+
+Internet-Draft                                           15 January 2007
+
+
+   SILC data messages (MIME messages) to secure and deliver the actual
+   multimedia data once the session has been established.
+
+
+6 Security Considerations
+
+   Security is central to the design of this protocol, and these security
+   considerations permeate the specification.  Common security considerations
+   such as keeping private keys truly private and using adequate lengths for
+   symmetric and asymmetric keys must be followed in order to maintain the
+   security of this protocol.
+
+
+7 References
+
+   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
+                Protocol Specification", Internet Draft, June 2003.
+
+   [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
+                June 2003.
+
+   [RFC3264]    Rosenberg, J., et. al., "An Offer/Answer Model with the
+                Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+   [RFC4145]    Yon, D., et. al., "TCP-Based Media Transport in the
+                Session Description Protocol (SDP)", RFC 4145, September
+                2005.
+
+   [SIP]        Rosenberg, J., et. al., "SIP: Session Initiation Protocol",
+                RFC 3261, June 2002.
+
+
+
+8 Author's Address
+
+   Pekka Riikonen
+   Helsinki
+   Finland
+
+   EMail: priikone@iki.fi
+
+
+9 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+
+
+
+Riikonen                                                        [Page 7]
+
+Internet-Draft                                           15 January 2007
+
+
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                        [Page 8]
+
diff --git a/docs/protocol/draft-riikonen-silc-pp-09.txt b/docs/protocol/draft-riikonen-silc-pp-09.txt
new file mode 100644
index 0000000..b9499ae
--- /dev/null
+++ b/docs/protocol/draft-riikonen-silc-pp-09.txt
@@ -0,0 +1,3307 @@
+
+
+
+
+
+
+Network Working Group                                        P. Riikonen
+Internet-Draft
+draft-riikonen-silc-pp-09.txt                            15 January 2007
+Expires: 15 July 2007
+
+
+                           SILC Packet Protocol
+                      <draft-riikonen-silc-pp-09.txt>
+
+Status of this Draft
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+   This memo describes a Packet Protocol used in the Secure Internet Live
+   Conferencing (SILC) protocol, specified in the Secure Internet Live
+   Conferencing, Protocol Specification [SILC1].  This protocol describes
+   the packet types and packet payloads which defines the contents of the
+   packets.  The protocol provides secure binary packet protocol that
+   assures that the contents of the packets are secured and authenticated.
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                        [Page 1]
+
+Internet Draft                                           15 January 2007
+
+
+Table of Contents
+
+   1 Introduction ..................................................  3
+     1.1 Requirements Terminology ..................................  4
+   2 SILC Packet Protocol ..........................................  4
+     2.1 SILC Packet ...............................................  4
+     2.2 SILC Packet Header ........................................  5
+     2.3 SILC Packet Types .........................................  8
+         2.3.1 SILC Packet Payloads ................................ 15
+         2.3.2 Generic payloads .................................... 16
+               2.3.2.1 ID Payload .................................. 16
+               2.3.2.2 Argument Payload ............................ 17
+               2.3.2.3 Argument List Payload ....................... 17
+               2.3.2.4 Channel Payload ............................. 18
+               2.3.2.5 Public Key Payload .......................... 19
+               2.3.2.6 Message Payload ............................. 20
+         2.3.3 Disconnect Payload .................................. 23
+         2.3.4 Success Payload ..................................... 24
+         2.3.5 Failure Payload ..................................... 25
+         2.3.6 Reject Payload ...................................... 25
+         2.3.7 Notify Payload ...................................... 26
+         2.3.8 Error Payload ....................................... 35
+         2.3.9 Channel Message Payload ............................. 35
+         2.3.10 Channel Key Payload ................................ 36
+         2.3.11 Private Message Payload ............................ 38
+         2.3.12 Private Message Key Payload ........................ 38
+         2.3.13 Command Payload .................................... 40
+         2.3.14 Command Reply Payload .............................. 41
+         2.3.15 Connection Auth Request Payload .................... 41
+         2.3.16 New ID Payload ..................................... 42
+         2.3.17 New Client Payload ................................. 43
+         2.3.18 New Server Payload ................................. 44
+         2.3.19 New Channel Payload ................................ 45
+         2.3.20 Key Agreement Payload .............................. 45
+         2.3.21 Resume Router Payload .............................. 47
+         2.3.22 File Transfer Payload .............................. 47
+         2.3.23 Resume Client Payload .............................. 48
+         2.3.24 Acknowledgement Payload ............................ 50
+     2.4 SILC ID Types ............................................. 50
+     2.5 Packet Encryption And Decryption .......................... 51
+         2.5.1 Normal Packet Encryption And Decryption ............. 51
+         2.5.2 Channel Message Encryption And Decryption ........... 52
+         2.5.3 Private Message Encryption And Decryption ........... 53
+     2.6 Packet MAC Generation ..................................... 53
+     2.7 Packet Padding Generation ................................. 54
+     2.8 Packet Compression ........................................ 54
+     2.9 Packet Sending ............................................ 55
+     2.10 Packet Reception ......................................... 55
+
+
+
+Riikonen                                                        [Page 2]
+
+Internet Draft                                           15 January 2007
+
+
+     2.11 Packet Routing ........................................... 55
+     2.12 Packet Broadcasting ...................................... 57
+   3 Security Considerations ....................................... 57
+   4 References .................................................... 57
+   5 Author's Address .............................................. 59
+   6 Full Copyright Statement ...................................... 59
+
+List of Figures
+
+   Figure 1:   Typical SILC Packet
+   Figure 2:   SILC Packet Header
+   Figure 3:   ID Payload
+   Figure 4:   Argument Payload
+   Figure 5:   Argument List Payload
+   Figure 6:   Channel Payload
+   Figure 7:   Public Key Payload
+   Figure 8:   Message Payload
+   Figure 9:   Disconnect Payload
+   Figure 10:  Success Payload
+   Figure 11:  Failure Payload
+   Figure 12:  Reject Payload
+   Figure 13:  Notify Payload
+   Figure 14:  Error Payload
+   Figure 15:  Channel Key Payload
+   Figure 16:  Private Message Key Payload
+   Figure 17:  Command Payload
+   Figure 18:  Connection Auth Request Payload
+   Figure 19:  New Client Payload
+   Figure 20:  New Server Payload
+   Figure 21:  Key Agreement Payload
+   Figure 22:  Resume Router Payload
+   Figure 23:  File Transfer Payload
+   Figure 24:  Resume Client Payload
+
+
+1. Introduction
+
+   This document describes a Packet Protocol used in the Secure Internet
+   Live Conferencing (SILC) protocol specified in the Secure Internet Live
+   Conferencing, Protocol Specification [SILC1].  This protocol describes
+   the packet types and packet payloads which defines the contents of the
+   packets.  The protocol provides secure binary packet protocol that
+   assures that the contents of the packets are secured and authenticated.
+   The packet protocol is designed to be compact to avoid unnecessary
+   overhead as much as possible.  This makes the SILC suitable also in
+   environment of low bandwidth requirements such as mobile networks.  All
+   packet payloads can also be compressed to further reduce the size of
+   the packets.
+
+
+
+Riikonen                                                        [Page 3]
+
+Internet Draft                                           15 January 2007
+
+
+   All packets in SILC network are always encrypted and their integrity
+   is assured by computed MACs.  The protocol defines several packet types
+   and packet payloads.  Each packet type usually has a specific packet
+   payload that actually defines the contents of the packet.  Each packet
+   also includes a default SILC Packet Header that provides sufficient
+   information about the origin and the destination of the packet.
+
+
+1.1 Requirements Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+   MAY, and OPTIONAL, when they appear in this document, are to be
+   interpreted as described in [RFC2119].
+
+
+2 SILC Packet Protocol
+
+2.1 SILC Packet
+
+   SILC packets deliver messages from sender to receiver securely by
+   encrypting important fields of the packet.  The packet consists of
+   default SILC Packet Header, Padding, Packet Payload data, and, packet
+   MAC.
+
+   The following diagram illustrates typical SILC packet.
+
+      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+     |   n bytes   | 1 - n bytes |      n bytes       |  n bytes
+     | SILC Header |   Padding   |    Data Payload    |    MAC
+      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+
+                      Figure 1:  Typical SILC Packet
+
+
+   SILC Header is always the first part of the packet and its purpose
+   is to provide information about the packet.  It provides for example
+   the packet type, origin of the packet and the destination of the packet.
+   The header is variable in length.  See the following section for
+   description of SILC Packet header.  Packets without SILC header or
+   with malformed SILC header MUST be dropped.
+
+   Padding follows the packet header.  The purpose of the padding is to
+   make the packet multiple by eight (8) or by the block size of the
+   cipher used in the encryption, which ever is larger.  The maximum
+   length of padding is currently 128 bytes.  The padding is always
+   encrypted.  The padding is applied always, even if the packet is
+   not encrypted.  See the section 2.7 Padding Generation for more
+   detailed information.
+
+
+
+Riikonen                                                        [Page 4]
+
+Internet Draft                                           15 January 2007
+
+
+   Data payload area follows padding and it is the actual data of the
+   packet.  The packet data is the packet payloads defined in this
+   protocol.  The data payload area is always encrypted.
+
+   The last part of SILC packet is the packet MAC that assures the
+   integrity of the packet.  See the section 2.6 Packet MAC Generation
+   for more information.  If compression is used the compression is
+   always applied before encryption.
+
+   All fields in all packet payloads are always in MSB (most significant
+   byte first) order.
+
+
+2.2 SILC Packet Header
+
+   The SILC packet header is applied to all SILC packets and it is
+   variable in length.  The purpose of SILC Packet header is to provide
+   detailed information about the packet.  The receiver of the packet
+   uses the packet header to parse the packet and gain other relevant
+   parameters of the packet.
+
+   The following diagram represents the SILC packet header.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Payload Length        |     Flags     |  Packet Type  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Pad Length  |    RESERVED   | Source ID Len |  Dest ID Len  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Src ID Type  |                                               |
+     +-+-+-+-+-+-+-+-+                                               +
+     |                                                               |
+     ~                           Source ID                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Dst ID Type  |                                               |
+     +-+-+-+-+-+-+-+-+                                               +
+     |                                                               |
+     ~                         Destination ID                        ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 2:  SILC Packet Header
+
+      o Payload Length (2 bytes) - Indicates the length of the
+        packet not including the padding of the packet.
+
+
+
+
+Riikonen                                                        [Page 5]
+
+Internet Draft                                           15 January 2007
+
+
+      o Flags (1 byte) - Indicates flags to be used in packet
+        processing.  Several flags may be set by ORing the flags
+        together.
+
+        The following flags are reserved for this field:
+
+
+           No flags                  0x00
+
+             In this case the field is ignored.
+
+
+           Private Message Key       0x01
+
+             Indicates that the packet data MUST include private
+             message that is encrypted using private key set by
+             client.  Servers does not know this key and cannot
+             decrypt the payload, but simply passes it along.  See
+             section 2.5.3 Private Message Encryption And Decryption
+             for more information.
+
+
+           List                      0x02
+
+             Indicates that the packet consists of list of
+             packet payloads indicated by the Packet Type field.
+             The payloads are added one after the other.  Note that
+             there are packet types that must not be used as
+             list.  Parsing of list packet is done by calculating
+             the length of each payload and parsing them one by
+             one.
+
+
+           Broadcast                 0x04
+
+             Marks the packet to be broadcasted.  Client and normal
+             server cannot send broadcast packets.  Only router server
+             may send broadcast packet.  The router receiving of packet
+             with this flag set MUST send (broadcast) the packet to
+             its primary route.  If router has several router connections
+             the packet may be sent only to the primary route.  See
+             section 2.12 Packet Broadcasting for description of
+             packet broadcasting.
+
+
+           Compressed                0x08
+
+             Marks that the payload of the packet is compressed.
+
+
+
+Riikonen                                                        [Page 6]
+
+Internet Draft                                           15 January 2007
+
+
+             The sender of the packet marks this flag when it
+             compresses the payload, and any server or router
+             en route to the recipient MUST NOT unset this flag.
+             See section 2.8 Packet Compression for description of
+             packet compressing.
+
+
+           Acknowledgement           0x10
+
+             Marks that the packet needs to be acknowledged by the
+             recipient.  The ACK packet MUST NOT have this flag set.
+             The acknowledgement packet is SILC_PACKET_ACK packet.
+             If the packet is not acknowledged the packet may be
+             retransmitted.  This flag is especially useful when
+             using UDP/IP and SHOULD NOT be used with TCP/IP.  The
+             flag MUST NOT be used with message packets.  The
+             SILC_MESSAGE_FLAG_ACK can be used instead.  Broadcast
+             packets MUST NOT set this flag.  Retransmission
+             may use for example exponential backoff algorithm.
+
+
+   o Packet Type (1 byte) - Indicates the type of the packet.
+     Receiver uses this field to parse the packet.  See section
+     2.3 SILC Packets for list of defined packet types.
+
+   o Pad Length (1 byte) - Indicates the length of the padding
+     applied after the SILC Packet header.  Maximum length for
+     padding is 128 bytes.
+
+   o RESERVED (1 byte) - Reserved field and must include a
+     zero (0) value.
+
+   o Source ID Length (1 byte) - Indicates the length of the
+     Source ID field in the header, not including this or any
+     other fields.
+
+   o Destination ID Length (1 byte) - Indicates the length of the
+     Destination ID field in the header, not including this or
+     any other fields.
+
+   o Src ID Type (1 byte) - Indicates the type of ID in the
+     Source ID field.  See section 2.4 SILC ID Types for
+     defined ID types.
+
+   o Source ID (variable length) - The actual source ID that
+     indicates which is the original sender of the packet.
+
+   o Dst ID Type (1 byte) - Indicates the type of ID in the
+
+
+
+Riikonen                                                        [Page 7]
+
+Internet Draft                                           15 January 2007
+
+
+     Destination ID field.  See section 2.4 SILC ID Types for
+     defined ID types.
+
+   o Destination ID (variable length) - The actual destination
+     ID that indicates which is the end receiver of the packet.
+
+
+
+2.3 SILC Packet Types
+
+   SILC packet types defines the contents of the packet and it is used by
+   the receiver to parse the packet.  The packet type is 8 bits in length.
+   The range for the packet types are from 0 - 255, where 0 is never sent and
+   255 is currently reserved for future extensions and MUST NOT be defined to
+   any other purpose.  Every SILC specification compliant implementation
+   SHOULD support all the following packet types.
+
+   The below list of the SILC Packet types includes reference to the packet
+   payload as well.  Packet payloads are the actual packet data area.  Each
+   packet type defines packet payload which usually may only be sent with
+   the specific packet type.
+
+   Most of the packets are packets that must be destined directly to entity
+   that is connected to the sender.  It is not allowed, for example, for a
+   router to send SILC_PACKET_DISCONNECT packet to client that is not
+   directly connected to the router.  However, there are some special packet
+   types that may be destined to some entity that the sender does not have
+   direct connection with.  These packets are for example private message
+   packets, channel message packets, command packets and some other packets
+   that may be broadcasted in the SILC network.  The following packet
+   desription list will define it separately if a packet is allowed to be
+   sent to indirectly connected entity.  Other packets MUST NOT be sent or
+   accepted, if sent, to indirectly connected entities.
+
+   Some packets MAY be sent as lists by adding the List flag to the Packet
+   Header and constructing multiple packet payloads one after the other.
+   When this is allowed it is separately defined in the following list.
+   Other packets MUST NOT be sent as list and the List flag MUST NOT be set.
+
+
+   List of SILC Packet types are defined as follows.
+
+      0    SILC_PACKET_NONE
+
+           This type is reserved and it is never sent.
+
+
+      1    SILC_PACKET_DISCONNECT
+
+
+
+Riikonen                                                        [Page 8]
+
+Internet Draft                                           15 January 2007
+
+
+           This packet is sent to disconnect the remote end.  Reason of
+           the disconnection is sent inside the packet payload.
+
+           Payload of the packet:  See section 2.3.3 Disconnect Payload
+
+
+      2    SILC_PACKET_SUCCESS
+
+           This packet is sent upon successful execution of a protocol.
+           The status of the success is sent in the packet payload.
+
+           Payload of the packet:  See section 2.3.4 Success Payload
+
+
+      3    SILC_PACKET_FAILURE
+
+           This packet is sent upon failure of a protocol.  The status
+           of the failure is sent in the packet payload.
+
+           Payload of the packet:  See section 2.3.5 Failure Payload
+
+
+      4    SILC_PACKET_REJECT
+
+           This packet MAY be sent upon rejection of a protocol.  The
+           status of the rejection is sent in the packet payload.
+
+           Payload of the packet:  See section 2.3.6 Reject Payload
+
+
+      5    SILC_PACKET_NOTIFY
+
+           This packet is used to send notify message.  The packet is
+           usually sent between server and client, but also between
+           server and router.  Client MUST NOT send this packet.  Server
+           MAY destine this packet to channel as well when the packet is
+           distributed to all clients on the channel.  This packet MAY
+           be sent as list.
+
+           Payload of the packet:  See section 2.3.7 Notify Payload.
+
+
+      6    SILC_PACKET_ERROR
+
+           This packet is sent when an error occurs.  Server MAY
+           send this packet.  Client MUST NOT send this packet.  The
+           client MAY entirely ignore the packet, however, server is
+           most likely to take action anyway.  This packet MAY be sent
+
+
+
+Riikonen                                                        [Page 9]
+
+Internet Draft                                           15 January 2007
+
+
+           to entity that is indirectly connected to the sender.
+
+           Payload of the packet:  See section 2.3.8 Error Payload.
+
+
+      7    SILC_PACKET_CHANNEL_MESSAGE
+
+           This packet is used to send messages to channels.  The packet
+           includes Channel ID of the channel and the actual message to
+           the channel.  Messages sent to the channel are always protected
+           by channel specific keys.  This packet MAY be sent to entity
+           that is indirectly connected to the sender.
+
+           Payload of the packet:  See section 2.3.9 Channel Message
+                                   Payload
+
+
+      8    SILC_PACKET_CHANNEL_KEY
+
+           This packet is used to distribute new key for particular
+           channel when server generates it.  Each channel has their own
+           independent keys that is used to protect the traffic on the
+           channel.  It is also possible to use channel private keys that
+           are not server generated.  In this case this packet is not used.
+           Client MUST NOT send this packet.  This packet MAY be sent to
+           entity that is indirectly connected to the sender.
+
+           Payload of the packet:  See section 2.3.10 Channel Key Payload
+
+
+      9    SILC_PACKET_PRIVATE_MESSAGE
+
+           This packet is used to send private messages from client
+           to another client.  By default, private messages are protected
+           by session keys established by normal key exchange protocol.
+           However, it is possible to use specific key to protect private
+           messages.  See [SILC1] for private message key generation.
+           This packet MAY be sent to entity that is indirectly connected
+           to the sender.
+
+           Payload of the packet:  See section 2.3.11 Private Message
+                                   Payload
+
+
+      10   SILC_PACKET_PRIVATE_MESSAGE_KEY
+
+           This packet is OPTIONAL and sender of the packet can indicate
+           that a private message key should be used in private message
+
+
+
+Riikonen                                                       [Page 10]
+
+Internet Draft                                           15 January 2007
+
+
+           communication.  The actual key material is not sent in this
+           packet but must be either static or pre-shared key.  The
+           receiver of the packet is considered to be the responder
+           when processing the static or pre-shared key material as
+           defined in [SILC1] and [SILC3] for private message keys.
+           This packet MAY be sent to entity that is indirectly connected
+           to the sender.
+
+           Payload of the packet:  See section 2.3.12 Private Message
+                                   Key Payload
+
+
+      11   SILC_PACKET_COMMAND
+
+           This packet is used to send commands from client to server.
+           Server MAY send this packet to other servers as well.  All
+           commands are listed in their own section SILC Command Types
+           in [SILC4].  The contents of this packet is command specific.
+           This packet MAY be sent to entity that is indirectly connected
+           to the sender.
+
+           Payload of the packet:  See section 2.3.13 Command Payload
+
+
+      12   SILC_PACKET_COMMAND_REPLY
+
+           This packet is sent as reply to the SILC_PACKET_COMMAND packet.
+           The contents of this packet is command specific.  This packet
+           MAY be sent to entity that is indirectly connected to the
+           sender.  This packet MAY be sent as list.
+
+           Payload of the packet:  See section 2.3.14 Command Reply
+                                   Payload and section 2.3.13 Command
+                                   Payload
+
+
+      13   SILC_PACKET_KEY_EXCHANGE
+
+           This packet is used to start SILC Key Exchange Protocol,
+           described in detail in [SILC3].
+
+           Payload of the packet:  Payload of this packet is described
+                                   in the section SILC Key Exchange
+                                   Protocol and its sub sections in
+                                   [SILC3].
+
+
+      14   SILC_PACKET_KEY_EXCHANGE_1
+
+
+
+Riikonen                                                       [Page 11]
+
+Internet Draft                                           15 January 2007
+
+
+           This packet is used as part of the SILC Key Exchange Protocol.
+
+           Payload of the packet:  Payload of this packet is described
+                                   in the section SILC Key Exchange
+                                   Protocol and its sub sections in
+                                   [SILC3].
+
+
+      15   SILC_PACKET_KEY_EXCHANGE_2
+
+           This packet is used as part of the SILC Key Exchange Protocol.
+
+           Payload of the packet:  Payload of this packet is described
+                                   in the section SILC Key Exchange
+                                   Protocol and its sub sections in
+                                   [SILC3].
+
+
+      16   SILC_PACKET_CONNECTION_AUTH_REQUEST
+
+           This packet is used to request an authentication method to
+           be used in the SILC Connection Authentication Protocol.  If
+           initiator of the protocol does not know the mandatory
+           authentication method this packet MAY be used to determine it.
+           The party receiving this payload SHOULD respond with the same
+           packet including the mandatory authentication method.
+
+           Payload of the packet:  See section 2.3.15 Connection Auth
+                                   Request Payload
+
+
+      17   SILC_PACKET_CONNECTION_AUTH
+
+           This packet is used to start and perform the SILC Connection
+           Authentication Protocol.  This protocol is used to authenticate
+           the connecting party.  The protocol is described in detail in
+           [SILC3].
+
+           Payload of the packet:  Payload of this packet is described
+                                   in the section SILC Authentication
+                                   Protocol and it sub sections in [SILC].
+
+
+      18   SILC_PACKET_NEW_ID
+
+           This packet is used to distribute new IDs from server to
+           router and from router to all other routers in SILC network.
+           This is used when for example new client is registered to
+
+
+
+Riikonen                                                       [Page 12]
+
+Internet Draft                                           15 January 2007
+
+
+           SILC network.  The newly created IDs of these operations are
+           distributed by this packet.  Only server may send this packet,
+           however, client MUST be able to receive this packet.  This
+           packet MAY be sent to entity that is indirectly connected
+           to the sender.  This packet MAY be sent as list.
+
+           Payload of the packet:  See section 2.3.16 New ID Payload
+
+
+      19   SILC_PACKET_NEW_CLIENT
+
+           This packet is used by client to register itself to the
+           SILC network.  This is sent after key exchange and
+           authentication protocols has been completed.  Client sends
+           various information about itself in this packet to the server.
+
+           Payload of the packet:  See section 2.3.17 New Client Payload
+
+
+      20   SILC_PACKET_NEW_SERVER
+
+           This packet is used by server to register itself to the
+           SILC network.  This is sent after key exchange and
+           authentication protocols has been completed.  Server sends
+           this to the router it connected to, or, if router was
+           connecting, to the connected router.  Server sends its
+           Server ID and other information in this packet.  The client
+           MUST NOT send or receive this packet.
+
+           Payload of the packet:  See section 2.3.18 New Server Payload
+
+
+      21   SILC_PACKET_NEW_CHANNEL
+
+           This packet is used to notify routers about newly created
+           channel.  Channels are always created by the router and it MUST
+           notify other routers about the created channel.  Router sends
+           this packet to its primary route.  Client MUST NOT send this
+           packet.  This packet MAY be sent to entity that is indirectly
+           connected to the sender.  This packet MAY be sent as list.
+
+           Payload of the packet:  See section 2.3.19 New Channel Payload
+
+
+      22   SILC_PACKET_REKEY
+
+           This packet is used to indicate that re-key must be performed
+           for session keys.  See section Session Key Regeneration in
+
+
+
+Riikonen                                                       [Page 13]
+
+Internet Draft                                           15 January 2007
+
+
+           [SILC1] for more information.  This packet does not have
+           a payload.
+
+
+      23   SILC_PACKET_REKEY_DONE
+
+           This packet is used to indicate that re-key is performed and
+           new keys must be used hereafter.  This packet does not have a
+           payload.
+
+
+      24   SILC_PACKET_HEARTBEAT
+
+           This packet is used by clients, servers and routers to keep the
+           connection alive.  It is RECOMMENDED that all servers implement
+           keepalive actions and perform it to both direction in a link.
+           This packet does not have a payload.
+
+
+      25   SILC_PACKET_KEY_AGREEMENT
+
+           This packet is used by clients to request key negotiation
+           between another client in the SILC network.  If the negotiation
+           is started it is performed using the SKE protocol.  The result of
+           the negotiation, the secret key material, can be used for
+           example as private message key.  The server and router MUST NOT
+           send this packet.
+
+           Payload of the packet:  See section 2.3.20 Key Agreement Payload
+
+
+      26   SILC_PACKET_RESUME_ROUTER
+
+           This packet is used during backup router protocol when the
+           original primary router of the cell comes back online and wishes
+           to resume the position as being the primary router of the cell.
+
+           Payload of the packet:  See section 2.3.21 Resume Router Payload
+
+
+      27   SILC_PACKET_FTP
+
+           This packet is used to perform an file transfer protocol in the
+           SILC session with some entity in the network.  The packet is
+           multi purpose.  The packet is used to tell other entity in the
+           network that the sender wishes to perform an file transfer
+           protocol.  The packet is also used to actually tunnel the
+           file transfer protocol stream.  The file transfer protocol
+
+
+
+Riikonen                                                       [Page 14]
+
+Internet Draft                                           15 January 2007
+
+
+           stream is always protected with the SILC binary packet protocol.
+
+           Payload of the packet:  See section 2.3.22 File Transfer Payload
+
+
+      28   SILC_PACKET_RESUME_CLIENT
+
+           This packet is used to resume a client back to the network
+           after it has been detached.  A client is able to detach from
+           the network but the client is still valid client in the network.
+           The client may then later resume its session back by sending
+           this packet to a server.  Routers also use this packet to notify
+           other routers in the network that the detached client has resumed.
+
+           Payload of the packet:  See section 2.3.23 Resume Client Payload
+
+
+      29   SILC_PACKET_ACK
+
+           This packet is used to acknowledge a packet that had the
+           Acknowledgement packet flag set.
+
+           Payload of the packet:  See section 2.3.24 Acknowledgement
+           Payload
+
+
+      30 - 199
+
+           Currently undefined commands.
+
+
+      200 - 254
+
+           These packet types are reserved for private use and they will
+           not be defined by this document.
+
+
+      255  SILC_PACKET_MAX
+
+           This type is reserved for future extensions and currently it
+           MUST NOT be sent.
+
+
+2.3.1 SILC Packet Payloads
+
+   All payloads resides in the main data area of the SILC packet.  However
+   all payloads MUST be at the start of the data area after the SILC
+   packet header and padding.  All fields in the packet payload are always
+
+
+
+Riikonen                                                       [Page 15]
+
+Internet Draft                                           15 January 2007
+
+
+   encrypted, as they reside in the data area of the packet which is
+   always encrypted.  Most of the payloads may only be sent with specific
+   packet type which is defined in the description of the payload.
+
+   There are some other payloads in SILC as well.  However, they are not
+   common in the sense that they could be sent at any time.  These payloads
+   are not described in this section.  These are payloads such as SILC
+   Key Exchange payloads and so on.  These are described in [SILC1],
+   [SILC3] and [SILC4].
+
+
+2.3.2 Generic payloads
+
+   This section describes generic payloads that are not associated to any
+   specific packet type.  They can be used for example inside some other
+   packet payload.
+
+
+2.3.2.1 ID Payload
+
+   This payload can be used to send an ID.  ID's are variable in length
+   thus this payload provides a way to send variable length ID.
+
+   The following diagram represents the ID Payload.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |             ID Type           |           ID Length           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                           ID Data                             ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                           Figure 3:  ID Payload
+
+
+      o ID Type (2 bytes) - Indicates the type of the ID.  See
+        section 2.4 SILC ID Types for list of defined ID types.
+
+      o ID Length (2 bytes) - Length of the ID Data area not
+        including the length of any other fields in the payload.
+
+      o ID Data (variable length) - The actual ID data.  The encoding
+        of the ID data is defined in section 2.4 SILC ID Types.
+
+
+
+
+
+Riikonen                                                       [Page 16]
+
+Internet Draft                                           15 January 2007
+
+
+2.3.2.2 Argument Payload
+
+   Argument Payload is used to set arguments for any packet payload that
+   need and support arguments, such as commands.  Number of arguments
+   associated with a packet MUST be indicated by the packet payload which
+   need the arguments.  Argument Payloads MUST always reside right after
+   the packet payload needing the arguments.  Incorrect amount of argument
+   payloads MUST cause rejection of the packet.
+
+   The following diagram represents the Argument Payload.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          Data Length          | Argument Type |               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
+     |                                                               |
+     ~                        Argument Data                          ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 4:  Argument Payload
+
+
+      o Data Length (2 bytes) - Length of the Argument Data field
+        not including the length of any other field in the payload.
+
+      o Argument Type (1 byte) - Indicates the type of the argument.
+        Every argument can have a specific type that are defined
+        by the packet payload needing the argument.  For example
+        every command specify a number for each argument that may be
+        associated with the command.  By using this number the receiver
+        of the packet knows what type of argument this is.  If there is
+        no specific argument type this field is set to zero (0) value.
+
+      o Argument Data (variable length) - Argument data.
+
+
+2.3.2.3 Argument List Payload
+
+   Argument List Payload is a list of Argument Payloads appended one
+   after the other.  The number of arguments is indicated in the
+   payload.
+
+   The following diagram represents the Argument List Payload.
+
+                          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
+
+
+
+Riikonen                                                       [Page 17]
+
+Internet Draft                                           15 January 2007
+
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Argument Nums         |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                        Argument Payloads                      ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 5:  Argument List Payload
+
+
+      o Argument Nums (2 bytes) - Indicates the number of Argument
+        Payloads.  If zero (0) value is found in this field no
+        arguments are present.
+
+      o Argument Payloads (variable length) - The Argument Payloads
+        appended one after the other.  The payloads can be decoded
+        since the length of the payload is indicated in each of
+        the Argument Payload.
+
+
+
+
+
+2.3.2.4 Channel Payload
+
+   Generic Channel Payload may be used to send information about a channel,
+   its name, the Channel ID and a mode.
+
+   The following diagram represents the Channel Payload.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Channel Name Length      |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                         Channel Name                          ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Channel ID Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                          Channel ID                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                           Mode Mask                           |
+
+
+
+Riikonen                                                       [Page 18]
+
+Internet Draft                                           15 January 2007
+
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 6:  New Channel Payload
+
+
+      o Channel Name Length (2 bytes) - Length of the Channel Name
+        field.
+
+      o Channel Name (variable length) - The name of the channel.
+
+      o Channel ID Length (2 bytes) - Length of the Channel ID field.
+
+      o Channel ID (variable length) - The encoded Channel ID.
+
+      o Mode Mask (4 bytes) - A mode.  This can be the mode of the
+        channel but it can also be the mode of a client on the
+        channel.  The contents of this field is dependent of the
+        usage of this payload.  The usage is defined separately
+        when this payload is used.  This is a 32 bit MSB first value.
+
+
+
+
+
+
+2.3.2.5 Public Key Payload
+
+   Generic Public Key Payload may be used to send different type of
+   public keys and certificates.
+
+   The following diagram represents the Public Key Payload.
+
+                          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       |        Public Key Type        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                  Public Key (or certificate)                  ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 7:  Public Key Payload
+
+
+      o Public Key Length (2 bytes) - The length of the Public Key
+        (or certificate) field, not including any other field.
+
+
+
+
+Riikonen                                                       [Page 19]
+
+Internet Draft                                           15 January 2007
+
+
+      o Public Key Type (2 bytes) - The public key (or certificate)
+        type.  This field indicates the type of the public key in
+        the packet.  See the [SILC3] for defined public key types.
+
+      o Public Key (or certificate) (variable length) - The
+        encoded public key or certificate data.
+
+
+2.3.2.6 Message Payload
+
+   Generic Message Payload can be used to send messages in SILC.  It
+   is used to send channel messages and private messages.
+
+   The following diagram represents the Message Payload.
+
+   (*) indicates that the field is not encrypted.
+
+
+
+
+
+
+
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Message  Flags         |         Message Length        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                         Message Data                          ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Padding Length         |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                            Padding                            ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                    Initialization Vector *                    ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                              MAC *                            ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Riikonen                                                       [Page 20]
+
+Internet Draft                                           15 January 2007
+
+
+                        Figure 8:  Message Payload
+
+
+      o Message Flags (2 bytes) - Includes the Message Flags of the
+        message.  The flags can indicate a reason or a purpose for
+        the message.  The following Message Flags are defined:
+
+        0x0000  SILC_MESSAGE_FLAG_NONE
+
+                No specific flags set.
+
+        0x0001  SILC_MESSAGE_FLAG_AUTOREPLY
+
+                This message is an automatic reply to an earlier
+                received message.
+
+        0x0002  SILC_MESSAGE_FLAG_NOREPLY
+
+                There should not be reply messages to this
+                message.
+
+        0x0004  SILC_MESSAGE_FLAG_ACTION
+
+                The sender is performing an action and the message
+                is the indication of the action.
+
+        0x0008  SILC_MESSAGE_FLAG_NOTICE
+
+                The message is for example an informational notice
+                type message.
+
+        0x0010  SILC_MESSAGE_FLAG_REQUEST
+
+                This is a generic request flag to send request
+                messages.  A separate document should define any
+                payloads associated to this flag.
+
+        0x0020  SILC_MESSAGE_FLAG_SIGNED
+
+                This flag indicates that the message is signed
+                with sender's private key and thus can be verified
+                by the receiver using the sender's public key.  A
+                separate document should define the detailed procedure
+                of the signing process and any associated payloads
+                for this flag.
+
+        0x0040  SILC_MESSAGE_FLAG_REPLY
+
+
+
+
+Riikonen                                                       [Page 21]
+
+Internet Draft                                           15 January 2007
+
+
+                This is a generic reply flag to send a reply to
+                previously received request.  A separate document
+                should define any payloads associated to this flag.
+
+        0x0080  SILC_MESSAGE_FLAG_DATA
+
+                This is a generic data flag, indicating that the
+                message includes some data which can be interpreted
+                in a specific way.  Using this flag any kind of data
+                can be delivered inside message payload.  A separate
+                document should define how this flag is interpreted
+                and define any associated payloads.
+
+        0x0100  SILC_MESSAGE_FLAG_UTF8
+
+                This flag indicates that the message is UTF-8 encoded
+                textual message.  When sending text messages in SILC
+                this flag SHOULD be used.  When this flag is used the
+                text sent as message MUST be UTF-8 encoded.
+
+        0x0200  SILC_MESSAGE_FLAG_ACK
+
+                This flag indicates the sender requires the recpipient
+                to acknowledge the received message.  This same flag
+                is used in the acknowledgement.  A separate document
+                should define how the acknowledgement is performed.
+
+        0x0400 - 0x1000 RESERVED
+
+                Reserved for future flags.
+
+        0x2000 - 0x8000 PRIVATE RANGE
+
+                Private range for free use.
+
+      o Message Length (2 bytes) - Indicates the length of the
+        Message Data field in the payload, not including any
+        other field.
+
+      o Message Data (variable length) - The actual message data.
+
+      o Padding Length (2 bytes) - Indicates the length of the
+        Padding field in the payload, not including any other
+        field.
+
+      o Padding (variable length) - If this payload is used as
+        channel messages, the padding MUST be applied because
+        this payload is encrypted separately from other parts
+
+
+
+Riikonen                                                       [Page 22]
+
+Internet Draft                                           15 January 2007
+
+
+        of the packet.  If this payload is used as private
+        messages, the padding is present only when the payload
+        is encrypted with private message key.  If encrypted
+        with session keys this field MUST NOT be present and the
+        Padding Length field includes a zero (0) value.  The
+        padding SHOULD be random data.
+
+      o Initialization Vector (variable length) - This field MUST
+        be present when this payload is used as channel messages.
+        The IV SHOULD be random data for each channel message.
+
+        When encrypting private messages with session keys this
+        field MUST NOT be present.  For private messages this field
+        is present only when encrypting with a static private
+        message key (pre-shared key).  If randomly generated key
+        material is used this field MUST NOT be present.  Also,
+        If Key Agreement (SKE) was used to negotiate fresh key
+        material for private message key this field MUST NOT be
+        present.  See the section 4.6 in [SILC1] for more
+        information about IVs when encrypting private messages.
+
+        This field includes the initialization vector used in message
+        encryption.  It need to be used in the packet decryption
+        as well.  Contents of this field depends on the encryption
+        algorithm and encryption mode.  This field is not encrypted,
+        is not included in padding calculation and its length
+        equals to cipher's block size.  This field is authenticated
+        by the message MAC.
+
+      o MAC (variable length) - The MAC computed from the
+        Message Flags, Message Length, Message Data, Padding Length,
+        Padding and Initialization Vector fields in that order.
+        The MAC is computed after the payload is encrypted.  This
+        is so called Encrypt-Then-MAC order; first encrypt, then
+        compute MAC from ciphertext.  The MAC protects the integrity
+        of the Message Payload.  Also, when used as channel messages
+        it is possible to have multiple private channel keys set,
+        and receiver can use the MAC to verify which of the keys
+        must be used in decryption.  This field is not present
+        when encrypting private messages with session key.  This
+        field is not encrypted.  This field is authenticated by
+        the SILC packet MAC.
+
+
+2.3.3 Disconnect Payload
+
+   Disconnect payload is sent upon disconnection.  Reason of the
+   disconnection is sent to the disconnected party in the payload.
+
+
+
+Riikonen                                                       [Page 23]
+
+Internet Draft                                           15 January 2007
+
+
+   The payload may only be sent with SILC_PACKET_DISCONNECT packet.  It
+   MUST NOT be sent in any other packet type.  The following diagram
+   represents the Disconnect Payload.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Status     |                                               |
+     +-+-+-+-+-+-+-+-+                                               +
+     |                                                               |
+     ~                      Disconnect Message                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 9:  Disconnect Payload
+
+      o Status (1 byte) - Indicates the Status Type, defined in [SILC3]
+        for the reason of disconnection.
+
+      o Disconnect Message (variable length) - Human readable UTF-8
+        encoded string indicating reason of the disconnection.  This
+        field MAY be omitted.
+
+
+2.3.4 Success Payload
+
+   Success payload is sent when some protocol execution is successfully
+   completed.  The payload is simple; indication of the success is sent.
+   This may be any data, including binary or human readable data, and
+   it is protocol dependent.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                      Success Indication                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 10:  Success Payload
+
+
+      o Success Indication (variable length) - Indication of
+        the success.  This may be for example some flag that
+        indicates the protocol and the success status or human
+        readable success message.  The true length of this
+        payload is available by calculating it from the SILC
+
+
+
+Riikonen                                                       [Page 24]
+
+Internet Draft                                           15 January 2007
+
+
+        Packet Header.
+
+
+2.3.5 Failure Payload
+
+   This is opposite of Success Payload.  Indication of failure of
+   some protocol is sent in the payload.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                      Failure Indication                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 11:  Failure Payload
+
+
+      o Failure Indication (variable length) - Indication of
+        the failure.  This may be for example some flag that
+        indicates the protocol and the failure status or human
+        readable failure message.  The true length of this
+        payload is available by calculating it from the SILC
+        Packet Header.
+
+
+2.3.6 Reject Payload
+
+   This payload is sent when some protocol is rejected to be executed.
+   Other operations MAY send this as well that was rejected.  The
+   indication of the rejection is sent in the payload.  The indication
+   may be binary or human readable data and is protocol dependent.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                       Reject Indication                       ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 12:  Reject Payload
+
+
+      o Reject Indication (variable length) - Indication of
+        the rejection.  This maybe for example some flag that
+
+
+
+Riikonen                                                       [Page 25]
+
+Internet Draft                                           15 January 2007
+
+
+        indicates the protocol and the rejection status or human
+        readable rejection message.  The true length of this
+        payload is available by calculating it from the SILC
+        Packet Header.
+
+
+
+2.3.7 Notify Payload
+
+   Notify payload is used to send notify messages.  The payload is usually
+   sent from server to client and from server to router.  It is also used
+   by routers to notify other routers in the network.  This payload MAY also
+   be sent to a channel.  Client MUST NOT send this payload.  When this
+   packet is received by client it SHOULD process it.  Servers and routers
+   MUST process notify packets.
+
+   The payload may only be sent with SILC_PACKET_NOTIFY packet.  It MUST
+   NOT be sent in any other packet type.  The following diagram represents
+   the Notify Payload.
+
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          Notify Type          |        Payload Length         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Argument Nums |
+     +-+-+-+-+-+-+-+-+
+
+                        Figure 13:  Notify Payload
+
+
+      o Notify Type (2 bytes) - Indicates the type of the notify
+        message.
+
+      o Payload Length (2 bytes) - Length of the entire Notify Payload
+        including any associated Argument Payloads.
+
+      o Argument Nums (1 byte) - Indicates the number of Argument
+        Payloads associated to this payload.  Notify types may define
+        arguments to be sent along the notify message.
+
+   Following the list of currently defined notify types.  The format for
+   notify arguments is same as in SILC commands described in [SILC4].
+   Note that all IDs sent in arguments are sent inside ID Payload.  Also
+   note that all strings sent as arguments MUST be UTF-8 [RFC3629] encoded,
+   unless otherwise defined.  Also note that all public keys or
+
+
+
+Riikonen                                                       [Page 26]
+
+Internet Draft                                           15 January 2007
+
+
+   certificates sent inside arguments are actually Public Key Payloads.
+
+
+      0     SILC_NOTIFY_TYPE_NONE
+
+            If no specific notify type apply for the notify message this type
+            MAY be used.
+
+            Max Arguments:  1
+                Arguments:  (1) <message>
+
+            The <message> is implementation specific free text string.
+            Receiver MAY ignore this message.
+
+
+      1     SILC_NOTIFY_TYPE_INVITE
+
+            Sent when an client is invited to a channel.  This is also sent
+            when the invite list of the channel is changed.  This notify type
+            is sent to local servers on the channel, but MUST NOT be sent
+            to clients on the channel.  Router MUST broadcast this to its
+            primary router and to local servers on the channel.  When a client
+            was directly invited to the channel this is also sent to that
+            client.  In this case the packet is destined to the client.
+
+            Max Arguments:  5
+                Arguments:  (1) <Channel ID>          (2) <channel name>
+                            (3) [<sender Client ID>]  (4) [<add | del>]
+                            (5) [<invite list>]
+
+            The <Channel ID> is the channel.  The <channel name> is the name
+            of the channel and is provided because the client which receives
+            this notify packet may not have a way to resolve the name of the
+            channel from the <Channel ID>.  The <sender Client ID> is the
+            Client ID which invited the client to the channel.  The
+            <add | del> is an argument of size of 1 byte where 0x00 means
+            adding a client to invite list, and 0x01 means deleting a client
+            from invite list.  The <invite list>, if present, indicates the
+            information to be added to or removed from the invite list.
+            The <invite list> format is defined in [SILC4] with
+            SILC_COMMAND_INVITE command.  When this notify is destined to
+            a client the <add | del> and <invite list> MUST NOT be sent.
+            When <add | del> is used  to announce information during server
+            connecting phase the argument type MUST be 0x03.  See section
+            4.2.1 in [SILC1] for more information.
+
+
+      2     SILC_NOTIFY_TYPE_JOIN
+
+
+
+Riikonen                                                       [Page 27]
+
+Internet Draft                                           15 January 2007
+
+
+            Sent when client has joined to a channel.  The server MUST
+            distribute this type to the local clients on the channel and then
+            send it to its primary router.  Note that, when router is joining
+            the client on behalf of normal server then router MUST send this
+            notify type locally and globally.  The router or server receiving
+            the packet distributes this type to the local clients on the
+            channel and broadcast it to the network.  This notify is sent
+            also to the client that joined the channel.
+
+            Max Arguments:  2
+                Arguments:  (1) [<Client ID>]       (2) <Channel ID>
+
+            The <Client ID> is the client that joined to the channel
+            indicated by the <Channel ID>.
+
+
+      3     SILC_NOTIFY_TYPE_LEAVE
+
+            Sent when client has left a channel.  The server must distribute
+            this type to the local clients on the channel and then send it
+            to its primary router.  The router or server receiving the
+            packet distributes this type to the local clients on the channel
+            and broadcast it to the network.  This notify MUST NOT be sent to
+            the leaving client.
+
+            Max Arguments:  1
+                Arguments:  (1) <Client ID>
+
+            The <Client ID> is the client which left the channel.
+
+
+      4     SILC_NOTIFY_TYPE_SIGNOFF
+
+            Sent when client signoff from SILC network.  The server MUST
+            distribute this type to the local clients on the channel and
+            then send it to its primary router.  The router or server
+            receiving the packet distributes this type to the local clients
+            on the channel and broadcast it to the network.  This notify
+            MUST NOT be sent to the quitting client.  The Destination ID
+            in the packet may be any ID depending to who it is destined.
+
+            Max Arguments:  2
+                Arguments:  (1) <Client ID>  (2) <message>
+
+            The <Client ID> is the client which left SILC network.  The
+            <message> is free text string indicating the reason of the
+            signoff.
+
+
+
+
+Riikonen                                                       [Page 28]
+
+Internet Draft                                           15 January 2007
+
+
+      5     SILC_NOTIFY_TYPE_TOPIC_SET
+
+            Sent when topic is set/changed on a channel.  This type may be
+            sent only to the clients which are joined on the channel which
+            topic was just set or changed.  The packet is destined to the
+            channel.
+
+            Max Arguments:  2
+                Arguments:  (1) <ID Payload>  (2) <topic>
+
+            The <ID Payload> is the ID of the entity who set the topic.
+            It usually is Client ID but it can be Server ID and Channel ID
+            as well.
+
+
+      6     SILC_NOTIFY_TYPE_NICK_CHANGE
+
+            Sent when client changes nick on a channel.  The server MUST
+            distribute this type only to the local clients on the channel
+            and then send it to its primary router.  The router or server
+            receiving the packet distributes this type to the local clients
+            on the channel and broadcast it to the network.  This packet is
+            destined directly to the sent entity.  This MUST be sent to those
+            clients that are joined on same channels as the client that
+            changed the nickname.  This notify MUST NOT be sent multiple
+            times to the same recipient.  This notify MUST be sent also to
+            the client that changed the nickname.
+
+            Max Arguments:  3
+                Arguments:  (1) <Old Client ID>  (2) <New Client ID>
+                            (3) <nickname>
+
+            The <Old Client ID> is the old ID of the client which changed
+            the nickname.  The <New Client ID> is the new ID generated by
+            the change of the nickname.  The <nickname> is the new nickname.
+            Note that it is possible to send this notify even if the
+            nickname has not changed, but client ID was changed.
+
+
+      7     SILC_NOTIFY_TYPE_CMODE_CHANGE
+
+            Sent when channel mode has changed.  This type MUST be sent only
+            to the clients which are joined on the channel which mode was
+            changed.  This packet is destined to the channel.
+
+            Max Arguments:  8
+                Arguments:  (1) <ID Payload>       (2) <mode mask>
+                            (3) [<cipher>]         (4) <[hmac>]
+
+
+
+Riikonen                                                       [Page 29]
+
+Internet Draft                                           15 January 2007
+
+
+                            (5) [<passphrase>]     (6) [<founder public key>]
+                            (7) [<channel pubkey>] (8) [<user limit>]
+
+            The <ID Payload> is the ID (usually Client ID but it can be
+            Server ID as well when the router is enforcing channel mode
+            change) of the entity which changed the mode.  The <mode mask>
+            is the new mode mask of the channel.  The client can safely
+            ignore the <cipher> argument since the SILC_PACKET_CHANNEL_KEY
+            packet will force the new channel key change anyway.  The <hmac>
+            argument is important since the client is responsible of setting
+            the new HMAC and the hmac key into use.  The <passphrase> is
+            the passphrase of the channel, if it was now set.  The <founder
+            public key> argument is sent when the founder mode on the
+            channel was set.  All routers and servers that receive the packet
+            MUST save the founder's public key so that the founder can
+            reclaim the channel founder rights back for the channel on any
+            server in the network.  The <user limit> argument is present when
+            the user limit was set or changed on the channel.
+
+            The <channel pubkey> is an Argument List Payload and it is used
+            to add and/or remove channel public keys from the channel.  Also,
+            when announcing channel information between servers and routers
+            during connecting phase this argument includes the list of channel
+            public keys.  To add a public key to channel public key list the
+            SILC_CMODE_CHANNEL_AUTH mode is set and the argument type is 0x00,
+            and the argument is the public key.  To remove a public key from
+            the channel public key list the argument type is 0x01, and the
+            argument is the public key to be removed.  If the mode
+            SILC_CMODE_CHANNEL_AUTH is unset (and was set earlier) all public
+            keys are removed at once.  Implementation MAY add and remove
+            multiple public keys at the same time by including multiple
+            arguments to the <channel pubkey> Argument List Payload where each
+            argument is one Public Key Payload.  When <channel pubkey> is used
+            to announce information during server connecting phase the
+            argument type MUST be 0x03.  See section 4.2.1 in [SILC1] for
+            more information.
+
+
+      8     SILC_NOTIFY_TYPE_CUMODE_CHANGE
+
+            Sent when user mode on channel has changed.  This type MUST be
+            sent only to the clients which are joined on the channel where
+            the target client is on.  This packet is destined to the channel.
+
+            Max Arguments:  4
+                Arguments:  (1) <ID Payload>        (2) <mode mask>
+                            (3) <Target Client ID>  (4) [<founder pubkey>]
+
+
+
+
+Riikonen                                                       [Page 30]
+
+Internet Draft                                           15 January 2007
+
+
+            The <ID Payload> is the ID (usually Client ID but it can be
+            Server ID as well when the router is enforcing user's mode
+            change) of the entity which changed the mode.  The <mode mask>
+            is the new mode mask of the channel.  The <Target Client ID>
+            is the client which mode was changed.  The <founder pubkey>
+            is the public key of the channel founder and may be sent only
+            when first time setting the channel founder mode using the
+            SILC_COMMAND_CUMODE command, and when sending this notify.
+
+
+      9     SILC_NOTIFY_TYPE_MOTD
+
+            Sent when Message of the Day (motd) is sent to a client.
+
+            Max Arguments:  1
+                Arguments:  (1) <motd>
+
+            The <motd> is the Message of the Day.  This notify MAY be
+            ignored and is OPTIONAL.
+
+
+      10    SILC_NOTIFY_TYPE_CHANNEL_CHANGE
+
+            Sent when channel's ID has changed for a reason or another.
+            This is sent by normal server to the client.  This can also be
+            sent by router to other server to force the Channel ID change.
+            The Channel ID MUST be changed to use the new one.  When sent
+            to clients, this type MUST be sent only to the clients which are
+            joined on the channel.  This packet is destined to the sent
+            entity.
+
+            Max Arguments:  2
+                Arguments:  (1) <Old Channel ID>  (2) <New Channel ID>
+
+            The <Old Channel ID> is the channel's old ID and the <New
+            Channel ID> is the new one that MUST replace the old one.
+            Server which receives this from router MUST re-announce the
+            channel to the router by sending SILC_PACKET_NEW_CHANNEL packet
+            with the new Channel ID.
+
+
+      11    SILC_NOTIFY_TYPE_SERVER_SIGNOFF
+
+            Sent when server quits SILC network.  Those clients from this
+            server that are on channels must be removed from the channel.
+            This packet is destined to the sent entity.
+
+            Max Arguments:  256
+
+
+
+Riikonen                                                       [Page 31]
+
+Internet Draft                                           15 January 2007
+
+
+                Arguments:  (1) <Server ID>   (n) [<Client ID>]   [...]
+
+            The <Server ID> is the server's ID.  The rest of the arguments
+            are the Client IDs of the clients which are coming from this
+            server and are thus quitting the SILC network also.  If the
+            maximum number of arguments are reached another
+            SILC_NOTIFY_TYPE_SERVER_SIGNOFF notify packet MUST be sent.
+            When this notify packet is sent between routers the Client ID's
+            MAY be omitted.  Server receiving the Client ID's in the payload
+            may use them directly to remove the client.
+
+
+      12    SILC_NOTIFY_TYPE_KICKED
+
+            Sent when a client has been kicked from a channel.  This MUST
+            also be sent to the client which was kicked from the channel.
+            The client which was kicked from the channel MUST be removed
+            from the channel.  The client MUST also be removed from channel's
+            invite list if it is explicitly added in the list.  This packet
+            is destined to the channel.  The router or server receiving the
+            packet distributes this type to the local clients on the channel
+            and broadcast it to the network.
+
+            Max Arguments:  3
+                Arguments:  (1) <Client ID>           (2) [<comment>]
+                            (3) <Kicker's Client ID>
+
+            The <Client ID> is the client which was kicked from the channel.
+            The kicker may have set the <comment> string to indicate the
+            reason for the kicking.  The <Kicker's Client ID> is the kicker.
+
+
+      13    SILC_NOTIFY_TYPE_KILLED
+
+            Sent when a client has been killed from the network.  This MUST
+            also be sent to the client which was killed from the network.
+            This notify MUST be sent to those clients which are joined on
+            same channels as the killed client.  The client which was killed
+            MUST be removed from the network.  This packet is destined
+            directly to the sent entity.  The router or server receiving
+            the packet distributes this type to the local clients on the
+            channel and broadcast it to the network.  The client MUST also
+            be removed from joined channels invite list if it is explicitly
+            added in the lists.  This notify MUST NOT be sent multiple
+            times to same recipient.
+
+            Max Arguments:  3
+                Arguments:  (1) <Client ID>           (2) [<comment>]
+
+
+
+Riikonen                                                       [Page 32]
+
+Internet Draft                                           15 January 2007
+
+
+                            (3) <Killer's ID>
+
+            The <Client ID> is the client which was killed from the network.
+            The killer may have set the  <comment> string to indicate the
+            reason for the killing.  The <Killer's ID> is the killer, which
+            may be client but also router server.
+
+
+      14    SILC_NOTIFY_TYPE_UMODE_CHANGE
+
+            Sent when user's mode in the SILC changes.  This type is sent
+            only between routers as broadcast packet.
+
+            Max Arguments:  2
+                Arguments:  (1) <Client ID>  (2) <mode mask>
+
+            The <Client ID> is the client which mode was changed.  The
+            <mode mask> is the new mode mask.
+
+
+      15    SILC_NOTIFY_TYPE_BAN
+
+            Sent when the ban list of the channel is changed.  This notify
+            type is sent to local servers on the channel, but MUST NOT be
+            sent to clients on the channel.  Router MUST broadcast this to
+            its primary router and to local servers on the channel.
+
+            Max Arguments:  3
+                Arguments:  (1) <Channel ID>         (2) [<add | del>]
+                            (3) [<ban list>]
+
+            The <Channel ID> is the channel which ban list was changed.
+            The <add | del> is an argument of size of 1 byte where 0x00 means
+            adding a client to ban list, and 0x01 means deleting a client
+            from ban list.  The <ban list> indicates the information to be
+            added to or removed from the ban list.  The <ban list> format
+            format is defined in [SILC4] with SILC_COMMAND_BAN command.
+            When <add | del> is used  to announce information during server
+            connecting phase the argument type MUST be 0x03.  See section
+            4.2.1 in [SILC1] for more information.
+
+
+      16    SILC_NOTIFY_TYPE_ERROR
+
+            Sent when an error occurs during processing some SILC procedure.
+            This is not used when error occurs during command processing, see
+            [SILC4] for more information about commands and command replies.
+            This type is sent directly to the sender of the packet whose
+
+
+
+Riikonen                                                       [Page 33]
+
+Internet Draft                                           15 January 2007
+
+
+            packet caused the error.  See [SILC1] for definition when this
+            type can be sent.
+
+            Max Arguments:  256
+                Arguments:  (1) <Status Type>        (n) [...]
+
+            The <Status Type> is the error type defined in [SILC4].  Note
+            that same types are also used with command replies to indicate
+            the status of a command.  Both commands and this notify type
+            share same status types.  Rest of the arguments are status type
+            dependent and are specified with those status types that can be
+            sent currently inside this notify type in [SILC4].  The <Status
+            Type> is size of 1 byte.
+
+
+      17    SILC_NOTIFY_TYPE_WATCH
+
+            Sent to indicate change in a watched user.  Client can set
+            nicknames to be watched with SILC_COMMAND_WATCH command, and
+            receive notifications when they login to network, signoff from
+            the network or their user mode is changed.  This notify type
+            is used to deliver these notifications.  The notify type is
+            sent directly to the watching client.
+
+            Max Arguments:  5
+                Arguments:  (1) <Client ID>        (2) [<nickname>]
+                            (3) <user mode>        (4) [<Notify Type>]
+                            (5) [<public key>]
+
+            The <Client ID> is the user's Client ID which is being watched,
+            and the <nickname> is its nickname.  If the client just
+            changed the nickname, then <nickname> is the new nickname, but
+            the <Client ID> is the old client ID.  The <user mode> is the
+            user's current user mode.  The <Notify Type> can be same as the
+            Notify Payload's Notify Type, and is 16 bit MSB first order
+            value.  If provided it may indicate the notify that occurred
+            for the client.  If client logged in to the network the
+            <Notify Type> MUST NOT be present.  The <public key> MAY be
+            present, and it is the public key of the client being watched.
+
+   Notify types starting from 16384 are reserved for private notify
+   message types.
+
+   Router server which receives SILC_NOTIFY_TYPE_SIGNOFF,
+   SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED,
+   SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE
+   MUST check whether someone in the local cell is watching the nickname
+   the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the
+
+
+
+Riikonen                                                       [Page 34]
+
+Internet Draft                                           15 January 2007
+
+
+   watcher, unless the watched client in case has the user mode
+   SILC_UMODE_REJECT_WATCHING set.  If the watcher client and the client
+   that was watched is same the notify SHOULD NOT be sent.
+
+
+2.3.8 Error Payload
+
+   Error payload is sent upon error in protocol.  Error may occur in
+   various conditions when server sends this packet.  Client MUST NOT
+   send this payload but MUST be able to accept it.  However, client
+   MAY ignore the contents of the packet as server is going to take
+   action on the error anyway.  However, it is recommended that the
+   client takes error packet seriously.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                         Error Message                         ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                         Figure 14:  Error Payload
+
+
+      o Error Message (variable length) - Human readable error
+        message.
+
+
+2.3.9 Channel Message Payload
+
+   Channel Message Payload is used to send message to channels, a group
+   of users.  These messages can only be sent if client has joined to
+   some channel.  Even though this packet is very common in SILC it
+   is still special packet.  Some special handling on sending and
+   reception of channel message is required.
+
+   Padding MUST be applied into this payload since the payload is
+   encrypted separately from other parts of the packet with the
+   channel specific key.  Hence the requirement of the padding.
+   The packet MUST be made multiple by eight (8) or by the block
+   size of the cipher, which ever is larger.
+
+   The SILC header in this packet is encrypted with the session key
+   of the next receiver of the packet.  Nothing else is encrypted
+   with that key.  Thus, the actual packet and padding to be
+   encrypted with the session key is SILC Header plus padding to it.
+
+
+
+Riikonen                                                       [Page 35]
+
+Internet Draft                                           15 January 2007
+
+
+   Receiver of the the channel message packet is able to determine
+   the channel the message is destined to by checking the Destination
+   ID from the SILC Packet header which tells the destination channel.
+   The original sender of the packet is also determined by checking
+   the source ID from the header which tells the client which sent
+   the message.  The Destination ID MUST be Channel ID in the SILC
+   Packet header.
+
+   This packet use generic Message Payload as Channel Message Payload.
+   See section 2.3.2.6 for generic Message Payload.
+
+
+2.3.10 Channel Key Payload
+
+   All traffic in channels are protected by channel specific keys.
+   Channel Key Payload is used to distribute channel keys to all
+   clients on the particular channel.  Channel keys are sent when
+   the channel is created, when new user joins to the channel and
+   whenever a user has left a channel.  Server creates the new
+   channel key and distributes it to the clients by encrypting this
+   payload with the session key shared between the server and
+   the client.  After that, client MUST start using the key received
+   in this payload to protect the traffic on the channel.
+
+   The client which is joining to the channel receives its key in the
+   SILC_COMMAND_JOIN command reply message thus it is not necessary to
+   send this payload to the entity which sent the SILC_COMMAND_JOIN
+   command.
+
+   Channel keys are cell specific thus every router in the cell have
+   to create a channel key and distribute it if any client in the
+   cell has joined to a channel.  Channel traffic between cell's
+   are not encrypted using channel keys, they are encrypted using
+   normal session keys between two routers.  Inside a cell, all
+   channel traffic is encrypted with the specified channel key.
+   Channel key SHOULD expire periodically, say, in one hour, in
+   which case new channel key is created and distributed.
+
+   Note that, this packet is not used if SILC_CMODE_PRIVKEY mode is set
+   on channel.  This means that channel uses channel private keys which
+   are not server generated.  For this reason server cannot send this
+   packet as it does not know the key.
+
+   The destination ID in the packet SHOULD be the entity to whom the
+   packet is sent.  Using Channel ID as destination ID is not
+   necessary as the Channel ID is included in the Channel Key Payload.
+
+   The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet.
+
+
+
+Riikonen                                                       [Page 36]
+
+Internet Draft                                           15 January 2007
+
+
+   It MUST NOT be sent in any other packet type.  The following diagram
+   represents the Channel Key Payload.
+
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Channel ID Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                          Channel ID                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Cipher Name Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                         Cipher Name                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Channel Key Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                         Channel Key                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 15:  Channel Key Payload
+
+
+
+      o Channel ID Length (2 bytes) - Indicates the length of the
+        Channel ID field in the payload, not including any other
+        field.
+
+      o Channel ID (variable length) - The Channel ID of the
+        channel.
+
+      o Cipher Name Length (2 bytes) - Indicates the length of the
+        Cipher name field in the payload, not including any other
+        field.
+
+      o Cipher Name (variable length) - Name of the cipher used
+        in the protection of channel traffic.  This name is
+        initially decided by the creator of the channel but it
+        may change during the life time of the channel as well.
+
+      o Channel Key Length (2 bytes) - Indicates the length of the
+
+
+
+Riikonen                                                       [Page 37]
+
+Internet Draft                                           15 January 2007
+
+
+        Channel Key field in the payload, not including any other
+        field.
+
+      o Channel Key (variable length) - The actual channel key
+        material.  See [SILC1] on how to start using the key.
+
+
+2.3.11 Private Message Payload
+
+   Private Message Payload is used to send private message between
+   two clients.  The messages are sent only to the specified user
+   and no other user inside SILC network is able to see the message.
+
+   The message can be protected by the session key established by the
+   SILC Key Exchange Protocol.  However, it is also possible to agree
+   to use a private message key to protect just the private messages.
+   It is for example possible to perform Key Agreement between two
+   clients.  See section 2.3.20 Key Agreement Payload how to perform
+   key agreement.  It is also possible to use static or pre-shared keys
+   to protect private messages.  See the 2.3.12 Private Message Key
+   Payload and [SILC1] section 4.6 for detailed description for private
+   message key generation.
+
+   If normal session key is used to protect the message, every server
+   between the sender client and the receiving client MUST decrypt the
+   packet and always re-encrypt it with the session key of the next
+   receiver of the packet.  See section Client To Client in [SILC1].
+
+   When the private message key is used, and the Private Message Key
+   flag was set in the SILC Packet header no server or router en route
+   is able to decrypt or re-encrypt the packet.  In this case only the
+   SILC Packet header is processed by the servers and routers en route.
+   Section Client To Client in [SILC1] gives example of this scheme.
+
+   This packet use generic Message Payload as Private Message Payload.
+   See section 2.3.2.6 for generic Message Payload.
+
+
+2.3.12 Private Message Key Payload
+
+   This payload is OPTIONAL and can be used to indicate that a static
+   or pre-shared key should be used in the private message communication
+   to protect the messages.  The actual key material has to be sent
+   outside the SILC network, or it has to be a static or pre-shared key.
+   The sender of this packet is considered to be the initiator and the
+   receiver the responder when processing the raw key material as
+   described in the section 4.6 in [SILC1] and in the section 2.3 in
+   [SILC3].
+
+
+
+Riikonen                                                       [Page 38]
+
+Internet Draft                                           15 January 2007
+
+
+   Note that it is also possible to use static or pre-shared keys in
+   client implementations without sending this packet.  Clients may
+   naturally agree to use a key without sending any kind of indication
+   to each other.  The key may be for example a long-living static key
+   that the clients has agreed to use at all times.  Note that it is
+   also possible to agree to use private message key by performing
+   a Key Agreement.  See the section 2.3.20 Key Agreement Payload.
+
+   This payload may only be sent by client to another client.  Server
+   MUST NOT send this payload.  After sending this payload and setting the
+   key into use this payload the sender of private messages MUST set the
+   Private Message Key flag into the SILC Packet Header.
+
+   The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY
+   packet.  It MUST NOT be sent in any other packet type.  The following
+   diagram represents the Private Message Key Payload.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Cipher Name Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                          Cipher Name                          ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       HMAC Name Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                           HMAC Name                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 16:  Private Message Key Payload
+
+
+
+      o Cipher Name Length (2 bytes) - Indicates the length of the
+        Cipher Name field in the payload, not including any other
+        field.
+
+      o Cipher Name (variable length) - Name of the cipher to use
+        in the private message encryption.  If this field does not
+        exist then the default cipher of the SILC protocol is used.
+        See the [SILC1] for defined ciphers.
+
+      o HMAC Name Length (2 bytes) - Indicates the length of the
+
+
+
+Riikonen                                                       [Page 39]
+
+Internet Draft                                           15 January 2007
+
+
+        HMAC Name field in the payload, not including any other
+        field.
+
+      o HMAC Name (variable length) - Name of the HMAC to use
+        in the private message MAC computation.  If this field does
+        not exist then the default HMAC of the SILC protocol is used.
+        See the [SILC1] for defined HMACs.
+
+
+2.3.13 Command Payload
+
+   Command Payload is used to send SILC commands from client to server.
+   Also server MAY send commands to other servers.  The following diagram
+   represents the Command Payload.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Payload Length        | SILC Command  | Arguments Num |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Command Identifier      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 17:  Command Payload
+
+
+      o Payload Length (2 bytes) - Length of the entire command
+        payload including any command argument payloads associated
+        with this payload.
+
+      o SILC Command (1 byte) - Indicates the SILC command.  This MUST
+        be set to non-zero value.  If zero (0) value is found in this
+        field the packet MUST be discarded.
+
+      o Arguments Num (1 byte) - Indicates the number of arguments
+        associated with the command.  If there are no arguments this
+        field is set to zero (0).  The arguments MUST follow the
+        Command Payload.  See section 2.3.2.2 for definition of the
+        Argument Payload.
+
+      o Command Identifier (2 bytes) - Identifies this command at the
+        sender's end.  The entity which replies to this command MUST
+        set the value found from this field into the Command Payload
+        used to send the reply to the sender.  This way the sender
+        can identify which command reply belongs to which originally
+        sent command.  What this field includes is implementation
+        issue but it is RECOMMENDED that wrapping counter value is
+
+
+
+Riikonen                                                       [Page 40]
+
+Internet Draft                                           15 January 2007
+
+
+        used in the field.
+
+   See [SILC4] for detailed description of different SILC commands,
+   their arguments and their reply messages.
+
+
+2.3.14 Command Reply Payload
+
+   Command Reply Payload is used to send replies to the commands.  The
+   Command Reply Payload is identical to the Command Payload thus see
+   the 2.3.13 section for the payload specification.
+
+   The entity which sends the reply packet MUST set the Command Identifier
+   field in the reply packet's Command Payload to the value it received
+   in the original command packet.
+
+   See SILC Commands in [SILC4] for detailed description of different
+   SILC commands, their arguments and their reply messages.
+
+
+2.3.15 Connection Auth Request Payload
+
+   Client MAY send this payload to server to request the authentication
+   method that must be used in authentication protocol.  If client knows
+   this information beforehand this payload is not necessary to be sent.
+   Server performing authentication with another server MAY also send
+   this payload to request the authentication method.  If the connecting
+   server already knows this information this payload is not necessary
+   to be sent.
+
+   Server receiving this request SHOULD reply with same payload sending
+   the mandatory authentication method.  Algorithms that may be required
+   to be used by the authentication method are the ones already
+   established by the SILC Key Exchange protocol.  See section Key
+   Exchange Start Payload in [SILC3] for detailed information.
+
+   The payload may only be sent with SILC_PACKET_CONNECTION_AUTH_REQUEST
+   packet.  It MUST NOT be sent in any other packet type.  The following
+   diagram represents the Connection Auth Request Payload.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Connection Type        |     Authentication Method     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 18:  Connection Auth Request Payload
+
+
+
+Riikonen                                                       [Page 41]
+
+Internet Draft                                           15 January 2007
+
+
+      o Connection Type (2 bytes) - Indicates the type of the
+        connection.  The following connection types are defined:
+
+
+           1    Client connection
+           2    Server connection
+           3    Router connection
+
+        If any other type is found in this field the packet MUST be
+        discarded and the authentication MUST be failed.
+
+      o Authentication Method (2 bytes) - Indicates the authentication
+        method to be used in the authentication protocol.  The following
+        authentication methods are defined:
+
+           0    NONE        (mandatory)
+           1    password    (mandatory)
+           2    public key  (mandatory)
+
+        If any other type is found in this field the packet MUST be
+        discarded and the authentication MUST be failed.  If this
+        payload is sent as request to receive the mandatory
+        authentication method this field MUST be set to zero (0),
+        indicating that receiver should send the mandatory
+        authentication method.  The receiver sending this payload
+        to the requesting party, MAY also set this field to zero (0)
+        to indicate that authentication is not required.  In this
+        case authentication protocol still MUST be started but
+        server is most likely to respond with SILC_PACKET_SUCCESS
+        immediately.
+
+
+2.3.16 New ID Payload
+
+   New ID Payload is a multipurpose payload.  It is used to send newly
+   created ID's from clients and servers.  When client connects to server
+   and registers itself to the server by sending SILC_PACKET_NEW_CLIENT
+   packet, server replies with this packet by sending the created ID for
+   the client.  Server always creates the ID for the client.
+
+   This payload is also used when server tells its router that new client
+   has registered to the SILC network.  In this case the server sends
+   the Client ID of the client to the router.  Similarly when router
+   distributes information to other routers about the client in the SILC
+   network this payload is used.
+
+   Also, when server connects to router, router use this payload to inform
+   other routers about new server in the SILC network.  However, every
+
+
+
+Riikonen                                                       [Page 42]
+
+Internet Draft                                           15 January 2007
+
+
+   server (or router) creates their own ID's thus the ID distributed by
+   this payload is not created by the distributor in this case.  Servers
+   create their own ID's.  Server registers itself to the network by
+   sending SILC_PACKET_NEW_SERVER to the router it connected to.  The case
+   is same when router connects to another router.
+
+   This payload MUST NOT be used to send information about new channels.
+   New channels are always distributed by sending the dedicated
+   SILC_PACKET_NEW_CHANNEL packet.  Client MUST NOT send this payload.
+   Both client and server (and router) MAY receive this payload.
+
+   The packet use generic ID Payload as New ID Payload.  See section
+   2.3.2.1 for generic ID Payload.
+
+
+2.3.17 New Client Payload
+
+   When client is connected to the server, keys has been exchanged and
+   connection has been authenticated, client MUST register itself to the
+   server.  Client's first packet after key exchange and authentication
+   protocols MUST be SILC_PACKET_NEW_CLIENT.  This payload tells server all
+   the relevant information about the connected user.  Server creates a new
+   client ID for the client when received this payload and sends it to the
+   client in New ID Payload.
+
+   This payload sends username and real name of the user on the remote host
+   which is connected to the SILC server with SILC client.  The server
+   creates the client ID according the information sent in this payload.
+   The nickname of the user becomes the nickname sent in this payload.
+
+   The payload may only be sent with SILC_PACKET_NEW_CLIENT packet.  It
+   MUST NOT be sent in any other packet type.  The following diagram
+   represents the New Client Payload.
+
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Username Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                           Username                            ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Real Name Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+
+
+
+Riikonen                                                       [Page 43]
+
+Internet Draft                                           15 January 2007
+
+
+     ~                           Real Name                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 19:  New Client Payload
+
+
+      o Username Length (2 bytes) - Length of the Username field.
+
+      o Username (variable length) - The username of the user on
+        the host where connecting to the SILC server.
+
+      o Real Name Length (2 bytes) - Length of the Real Name field.
+
+      o Real Name (variable length) - The real name of the user
+        on the host where connecting to the SILC server.
+
+
+2.3.18 New Server Payload
+
+   This payload is sent by server when it has completed successfully both
+   key exchange and connection authentication protocols.  The server
+   MUST register itself to the SILC Network by sending this payload.
+   The first packet after these key exchange and authentication protocols
+   is SILC_PACKET_NEW_SERVER packet.  The payload includes the Server ID
+   of the server that it has created by itself.  It also includes a
+   name of the server that is associated to the Server ID.
+
+   The payload may only be sent with SILC_PACKET_NEW_SERVER packet.  It
+   MUST NOT be sent in any other packet type.  The following diagram
+   represents the New Server Payload.
+
+
+
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Server ID Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                        Server ID Data                         ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Server Name Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+
+
+
+Riikonen                                                       [Page 44]
+
+Internet Draft                                           15 January 2007
+
+
+     ~                          Server Name                          ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 20:  New Server Payload
+
+
+      o Server ID Length (2 bytes) - Length of the Server ID Data
+        field.
+
+      o Server ID Data (variable length) - The encoded Server ID
+        data.
+
+      o Server Name Length (2 bytes) - Length of the server name
+        field.
+
+      o Server Name (variable length) - The server name string.
+
+
+2.3.19 New Channel Payload
+
+   Information about newly created channel is broadcasted to all routers
+   in the SILC network by sending this packet payload.  Channels are
+   created by router of the cell.  Server never creates channels unless
+   it is a standalone server and it does not have router connection,
+   in this case server acts as router.  Normal server send JOIN command
+   to the router (after it has received JOIN command from client) which
+   then processes the command and creates the channel.  Client MUST NOT
+   send this packet.  Server MAY send this packet to a router when it is
+   announcing its existing channels to the router after it has connected
+   to the router.
+
+   The packet use generic Channel Payload as New Channel Payload.  See
+   section 2.3.2.3 for generic Channel Payload.  The Mode Mask field in the
+   Channel Payload is the mode of the channel.
+
+
+2.3.20 Key Agreement Payload
+
+   This payload is used by clients to request key negotiation between
+   another client in the SILC Network.  The key agreement protocol used
+   is the SKE protocol.  The result of the protocol, the secret key
+   material, can be used for example as private message key between the
+   two clients.  This significantly adds security as the clients agree
+   about the key without any server interaction.  The protocol is executed
+   peer to peer.  The server and router MUST NOT send this payload.
+
+   The sender MAY tell the receiver of this payload the hostname and the
+
+
+
+Riikonen                                                       [Page 45]
+
+Internet Draft                                           15 January 2007
+
+
+   port where the SKE protocol is running in the sender's end.  The
+   receiver MAY then initiate the SKE negotiation with the sender.  The
+   sender MAY also optionally not to include the hostname and the port
+   of its SKE protocol.  In this case the receiver MAY reply to the
+   request by sending the same payload filled with the receiver's hostname
+   and the port where the SKE protocol is running.  The sender MAY then
+   initiate the SKE negotiation with the receiver.
+
+   This payload may be sent with SILC_PACKET_KEY_AGREEMENT and
+   SILC_PACKET_FTP packet types.  It MUST NOT be sent in any other packet
+   types.  The following diagram represents the Key Agreement Payload.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Hostname Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                           Hostname                            ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |            Protocol           |             Port              |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 21:  Key Agreement Payload
+
+
+      o Hostname Length (2 bytes) - Indicates the length of the
+        Hostname field.
+
+      o Hostname (variable length) - The hostname or IP address where
+        the SKE protocol is running, as UTF-8 encoded string.  The sender
+        MAY fill this field when sending the payload.  If the receiver
+        sends this payload as reply to the request it MUST fill this field.
+
+      o Protocol (2 bytes) - The internet protocol used for the key
+        agreement connection.  Possible values are 0 for TCP and 1 for
+        UDP.  Other values are unsupported.  This is a 16 bit MSB first
+        order value.  If Hostname field is not present, the value in
+        this field is ignored.
+
+      o Port (2 bytes) - The port where the SKE protocol is bound.
+        The sender MAY fill this field when sending the payload.  If
+        the receiver sends this payload as reply to the request it
+        MUST fill this field.  This is a 16 bit MSB first order value.
+
+
+
+
+
+Riikonen                                                       [Page 46]
+
+Internet Draft                                           15 January 2007
+
+
+   After the key material has been received from the SKE protocol it is
+   processed as the [SILC3] describes.  If the key material is used as
+   channel private key then the Sending Encryption Key, as defined in
+   [SILC3] is used as the channel private key.  Other key material must
+   be discarded.  The [SILC1] in section 4.6 defines the way to use the
+   key material if it is intended to be used as private message keys.
+   Any other use for the key material is undefined.
+
+
+2.3.21 Resume Router Payload
+
+   See the [SILC1] for Resume Router protocol where this payload is
+   used.  The payload may only be sent with SILC_PACKET_RESUME_ROUTER
+   packet.  It MUST NOT be sent in any other packet type.  The following
+   diagram represents the Resume Router Payload.
+
+
+                                          1
+                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     |      Type     |  Session ID   |
+                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 22:  Resume Router Payload
+
+
+      o Type (1 byte) - Indicates the type of the backup resume
+        protocol packet.  The type values are defined in [SILC1].
+
+      o Session ID (1 bytes) - Indicates the session ID for the
+        backup resume protocol.  The sender of the packet sets this
+        value and the receiver MUST set the same value in subsequent
+        reply packet.
+
+
+
+
+2.3.22 File Transfer Payload
+
+   File Transfer Payload is used to perform file transfer protocol between
+   two entities in the network.  The actual file transfer protocol is always
+   encapsulated inside the SILC Packet.  The actual data stream is also sent
+   peer to peer outside SILC network.
+
+   When an entity, usually a client wishes to perform file transfer protocol
+   with another client in the network, they perform Key Agreement protocol
+   as described in the section 2.3.20 Key Agreement Payload and in [SILC3],
+   inside File Transfer Payload.  After the Key Agreement protocol has been
+
+
+
+Riikonen                                                       [Page 47]
+
+Internet Draft                                           15 January 2007
+
+
+   performed the subsequent packets in the data stream will be protected
+   using the new key material.  The actual file transfer protocol is also
+   initialized in this stage.  All file transfer protocol packets are always
+   encapsulated in the File Transfer Payload and protected with the
+   negotiated key material.
+
+   The payload may only be sent with SILC_PACKET_FTP packet.  It MUST NOT
+   be sent in any other packet type.  The following diagram represents the
+   File Transfer Payload.
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |                                               |
+     +-+-+-+-+-+-+-+-+                                               +
+     |                                                               |
+     ~                             Data                              ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 23:  File Transfer Payload
+
+
+      o Type (1 byte) - Indicates the type of the file transfer
+        protocol.  The following file transfer protocols has been
+        defined:
+
+          1    Secure File Transfer Protocol (SFTP)  (mandatory)
+
+        If zero (0) value or any unsupported file transfer protocol
+        type is found in this field the packet MUST be discarded.
+        The currently mandatory file transfer protocol is SFTP.
+        The SFTP protocol is defined in [SFTP].
+
+      o Data (variable length) - Arbitrary file transfer data.  The
+        contents and encoding of this field is dependent of the usage
+        of this payload and the type of the file transfer protocol.
+        When this payload is used to perform the Key Agreement
+        protocol, this field include the Key Agreement Payload,
+        as defined in the section 2.3.20 Key Agreement Payload.
+        When this payload is used to send the actual file transfer
+        protocol data, the encoding is defined in the corresponding
+        file transfer protocol.
+
+
+2.3.23 Resume Client Payload
+
+
+
+
+Riikonen                                                       [Page 48]
+
+Internet Draft                                           15 January 2007
+
+
+   This payload is used by client to resume its detached session in the
+   SILC Network.  A client is able to detach itself from the network by
+   sending SILC_COMMAND_DETACH command to its server.  The network
+   connection to the client is lost but the client remains as valid
+   client in the network.  The client is able to resume the session back
+   by sending this packet and including the old Client ID, and an
+   Authentication Payload [SILC1] which the server use to verify with
+   the detached client's public key.  This also implies that the
+   mandatory authentication method is public key authentication.
+
+   Server or router that receives this from the client also sends this,
+   without the Authentication Payload, to routers in the network so that
+   they know the detached client has resumed.  Refer to the [SILC1] for
+   detailed description how the detaching and resuming procedure is
+   performed.
+
+   The payload may only be sent with SILC_PACKET_RESUME_CLIENT packet.  It
+   MUST NOT be sent in any other packet type.  The following diagram
+   represents the Resume Client Payload.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Client ID Length        |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                           Client ID                           ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                     Authentication Payload                    ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 24:  Resume Client Payload
+
+
+      o Client ID Length (1 byte) - The length of the Client ID
+        field not including any other field.
+
+      o Client ID (variable length) - The detached client's Client
+        ID.  The client that sends this payload must know the Client
+        ID.
+
+      o Authentication Payload (variable length) - The authentication
+        payload that the server will verify with the detached client's
+        public key.  If the server doesn't know the public key, it must
+        retrieve it for example with SILC_COMMAND_GETKEY command.
+
+
+
+Riikonen                                                       [Page 49]
+
+Internet Draft                                           15 January 2007
+
+
+2.3.24 Acknowledgement Payload
+
+   This payload is used to acknowledge a packet that had the Acknowledgement
+   packet flag set.  The payload includes the sequence number of the packet
+   that had the flag set, which the recipient can use to identify that the
+   packet was acknowledged.
+
+   The payload may only be sent with SILC_PACKET_ACK packet.  It
+   MUST NOT be sent in any other packet type.  The following diagram
+   represents the Acknowledgement Payload.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                    Packet Sequence Number                     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 24:  Resume Client Payload
+
+
+      o Packet Sequence Number (4 bytes) - The packet sequence number
+        of the packet that had the Acknowledgement flag set.
+
+
+2.4 SILC ID Types
+
+   ID's are used in the SILC network to associate different entities.
+   The following ID's has been defined to be used in the SILC network.
+
+      0    No ID
+
+           This is used when other ID type is available at the time.
+
+      1    Server ID
+
+           Server ID to associate servers.  See the format of
+           this ID in [SILC1].
+
+      2    Client ID
+
+           Client ID to associate clients.  See the format of
+           this ID in [SILC1].
+
+      3    Channel ID
+
+           Channel ID to associate channels.  See the format of
+           this ID in [SILC1].
+
+
+
+
+Riikonen                                                       [Page 50]
+
+Internet Draft                                           15 January 2007
+
+
+   When encoding different IDs into the ID Payload, all fields are always
+   in MSB first order.  The IP address, port, and/or the random number
+   are encoded in the MSB first order.
+
+
+2.5 Packet Encryption And Decryption
+
+   SILC packets are encrypted almost entirely.  Only the MAC at the end
+   of the packet is never encrypted.  The SILC Packet header is the first
+   part of a packet to be encrypted and it is always encrypted with the
+   key of the next receiver of the packet.  The data payload area of the
+   packet is always entirely encrypted and it is usually encrypted with
+   the next receiver's key.  However, there are some special packet types
+   and packet payloads that require special encryption process.  These
+   special cases are described in the next sections.  First is described
+   the normal packet encryption process.
+
+
+
+2.5.1 Normal Packet Encryption And Decryption
+
+   Normal SILC packets are encrypted with the session key of the next
+   receiver of the packet.  The entire SILC Packet header and the packet
+   data payload is is encrypted with the same key.  Padding of the packet
+   is also encrypted always with the session key, also in special cases.
+   Computed MAC of the packet MUST NOT be encrypted.
+
+   Decryption process in these cases are straightforward.  The receiver
+   of the packet MUST first decrypt the SILC Packet header, or some parts
+   of it, usually first 16 bytes of it.  Then the receiver checks the
+   packet type from the decrypted part of the header and can determine
+   how the rest of the packet must be decrypted.  If the packet type is
+   any of the special cases described in the following sections the packet
+   decryption is special.  If the packet type is not among those special
+   packet types rest of the packet can be decrypted with the same key.
+   At this point the receiver is also able to determine the length of the
+   packet.
+
+   With out a doubt, this sort of decryption processing causes some
+   overhead to packet decryption, but never the less, is required.
+
+   The MAC of the packet is also verified at this point.  The MAC is
+   computed from the ciphertext of the packet so it can be verified
+   at this stage.  The length of the packet need to be known to be able
+   to verify the MAC from the ciphertext so the first 16 bytes need to
+   be decrypted to determine the packet length.  However, the MAC MUST
+   be verified from the entire ciphertext.
+
+
+
+
+Riikonen                                                       [Page 51]
+
+Internet Draft                                           15 January 2007
+
+
+2.5.2 Channel Message Encryption And Decryption
+
+   Channel Messages (Channel Message Payload) are always encrypted with
+   the channel specific key.  However, the SILC Packet header is not
+   encrypted with that key.  As in normal case, the header is encrypted
+   with the key of the next receiver of the packet.  Note that, in this
+   case the encrypted data area is not touched at all; it MUST NOT be
+   re-encrypted with the session key.
+
+   Receiver of a channel message, who ever that is, is REQUIRED to decrypt
+   the SILC Packet header to be able to recognize the packet to be as
+   channel message.  This is same procedure as for normal SILC packets.
+   As the receiver founds the packet to be channel message, rest of the
+   packet processing is special.  Rest of the SILC Packet header is
+   decrypted with the same session key along with the padding of the
+   packet.  After that the packet is protected with the channel specific
+   key and thus can be decrypted only if the receiver is the client on
+   the channel.  See section 2.7 Packet Padding Generation for more
+   information about padding on special packets.
+
+   If the receiver of the channel message is router which is routing the
+   message to another router then it MUST decrypt the Channel Message
+   payload too.  Between routers (that is, between cells) channel messages
+   are protected with session keys shared between the routers.  This
+   causes another special packet processing for channel messages.  If
+   the channel message is received from another router then the entire
+   packet, including Channel Message payload, MUST be encrypted with the
+   session key shared between the routers.  In this case the packet
+   decryption process is as with normal SILC packets.  Hence, if the
+   router is sending channel message to another router the Channel
+   Message payload MUST have been decrypted and MUST be re-encrypted
+   with the session key shared between the another router.  In this
+   case the packet encryption is as with any normal SILC packet.
+
+   It must be noted that this is only when the channel messages are sent
+   from router to another router.  In all other cases the channel
+   message encryption and decryption is as described before.  This
+   different processing of channel messages with router to router
+   connection is because channel keys are cell specific.  All cells have
+   their own channel keys thus the channel message traveling from one
+   cell to another MUST be protected as it would be any normal SILC
+   packet.
+
+   If the SILC_CMODE_PRIVKEY channel mode has been set for the channel
+   then the router cannot decrypt the packet as it does not know the
+   private key.  In this case the entire packet MUST be encrypted with
+   the session key and sent to the router.  The router receiving the
+   packet MUST check the channel mode and decrypt the packet accordingly.
+
+
+
+Riikonen                                                       [Page 52]
+
+Internet Draft                                           15 January 2007
+
+
+2.5.3 Private Message Encryption And Decryption
+
+   By default, private message in SILC are protected by session keys.
+   In this case the private message encryption and decryption process is
+   equivalent to normal packet encryption and decryption.
+
+   However, private messages MAY be protected with private message key
+   which causes the packet to be special packet.  The procedure in this
+   case is very much alike to channel packets.  The actual private message
+   is encrypted with the private message key and other parts of the
+   packet is encrypted with the session key.  See 2.7 Packet Padding
+   Generation for more information about padding on special packets.
+
+   The difference from channel message processing is that server or router
+   en route never decrypts the actual private message, as it does not
+   have the key to do that.  Thus, when sending packets between router
+   the processing is same as in any other case as well; the packet's header
+   and padding is protected by the session key and the data area is not
+   touched and is not re-encrypted.
+
+   The true receiver of the private message is able to decrypt the private
+   message as it shares the key with the sender of the message.
+
+
+2.6 Packet MAC Generation
+
+   Data integrity of a packet is protected by including a message
+   authentication code (MAC) at the end of the packet.  The MAC is computed
+   from shared secret MAC key, that is established by the SILC Key Exchange
+   protocol, from packet sequence number, and from the encrypted packet
+   data.  The MAC is always computed after packet is encrypted.  This is
+   so called Encrypt-Then-MAC order; packet is first encrypted, then MAC
+   is computed from the encrypted data.
+
+   The MAC is computed from entire packet.  Every bit of data in the packet,
+   including SILC Packet Header is used in the MAC computing.  This way
+   the entire packet becomes authenticated.
+
+   Hence, packet's MAC generation is as follows:
+
+     mac = MAC(key, sequence number | Encrypted SILC packet)
+
+   The MAC key is negotiated during the SKE protocol.  The sequence number
+   is a 32 bit MSB first value starting from zero for first packet and
+   increasing for subsequent packets, finally wrapping after 2^32 packets.
+   The value is never reset, not even after rekey has been performed.
+   However, rekey MUST be performed before the sequence number wraps
+   and repeats from zero.  Note that the sequence number is incremented only
+
+
+
+Riikonen                                                       [Page 53]
+
+Internet Draft                                           15 January 2007
+
+
+   when MAC is computed for a packet.  If packet is not encrypted and MAC is
+   not computed then the sequence number is not incremented.  Hence, the
+   sequence number is zero for the very first encrypted packet.
+
+   See [SILC1] for defined and allowed MAC algorithms.
+
+
+2.7 Packet Padding Generation
+
+   Padding is needed in the packet because the packet is encrypted.  It
+   always MUST be multiple by eight (8) or multiple by the block size
+   of the cipher, which ever is larger.  The padding is always encrypted.
+
+   For normal packets the padding is added after the SILC Packet Header
+   and between the Data Payload area.  The padding for normal packets
+   may be calculated as follows:
+
+      padding_length = 16 - (packet_length mod block_size)
+      if (padding_length < 8)
+        padding_length += block_size
+
+   The `block_size' is the block size of the cipher.  The maximum padding
+   length is 128 bytes, and minimum is 8 bytes.  For example, packets that
+   include a passphrase or a password for authentication purposes SHOULD
+   pad the packet up to the maximum padding length.  The maximum padding
+   is calculated as follows:
+
+      padding_length = 128 - (packet_length mod block_size)
+
+   For special packets the padding calculation is different as special
+   packets may be encrypted differently.  In these cases the encrypted
+   data area MUST already be multiple by the block size thus in this case
+   the padding is calculated only for SILC Packet Header, not for any
+   other area of the packet.  The same algorithm works in this case as
+   well, except that the `packet length' is now the SILC Packet Header
+   length.
+
+   The padding MUST be random data, preferably, generated by
+   cryptographically strong random number generator for each packet
+   separately.
+
+
+2.8 Packet Compression
+
+   SILC Packets MAY be compressed.  In this case the data payload area
+   is compressed and all other areas of the packet MUST remain as they
+   are.  After compression is performed for the data area, the length
+   field of Packet Header MUST be set to the compressed length of the
+
+
+
+Riikonen                                                       [Page 54]
+
+Internet Draft                                           15 January 2007
+
+
+   data.
+
+   The compression MUST always be applied before encryption.  When
+   the packet is received and decrypted the data area MUST be decompressed.
+   Note that the true sender of the packet MUST apply the compression and
+   the true receiver of the packet MUST apply the decompression.  Any
+   server or router en route SHOULD NOT decompress the packet.
+
+
+2.9 Packet Sending
+
+   The sender of the packet MUST assemble the SILC Packet Header with
+   correct values.  It MUST set the Source ID of the header as its own
+   ID, unless it is forwarding the packet.  It MUST also set the Destination
+   ID of the header to the true destination.  If the destination is client
+   it will be Client ID, if it is server it will be Server ID and if it is
+   channel it will be Channel ID.
+
+   If the sender wants to compress the packet it MUST apply the
+   compression now.  Sender MUST also compute the padding as described
+   in above sections.  Then sender MUST encrypt the packet as has been
+   described in above sections according whether the packet is normal
+   packet or special packet.  Then sender MUST compute the MAC of the
+   packet.  The computed MAC MUST NOT be encrypted.
+
+
+2.10 Packet Reception
+
+   On packet reception the receiver MUST check that all fields in the
+   SILC Packet Header are valid.  It MUST check the flags of the
+   header and act accordingly.  It MUST also check the MAC of the packet
+   and if it is to be failed the packet MUST be discarded.  Also if the
+   header of the packet includes any bad fields the packet MUST be
+   discarded.
+
+   See above sections on the decryption process of the received packet.
+
+   The receiver MUST also check that the ID's in the header are valid
+   ID's.  Unsupported ID types or malformed ID's MUST cause packet
+   rejection.  The padding on the reception is always ignored.
+
+   The receiver MUST also check the packet type and start parsing the
+   packet according to the type.  However, note the above sections on
+   special packet types and their parsing.
+
+
+2.11 Packet Routing
+
+
+
+
+Riikonen                                                       [Page 55]
+
+Internet Draft                                           15 January 2007
+
+
+   Routers are the primary entities in the SILC network that takes care
+   of packet routing.  Normal servers performs packet forwarding, for
+   example, when they are forwarding channel message to the local clients.
+   Routing is quite simple as every packet tells the true origin and the
+   true destination of the packet.
+
+   It is still RECOMMENDED for routers that has several routing connections
+   to create route cache for those destinations that has faster route than
+   the router's primary route.  This information is available for the router
+   when other router connects to the router.  The connecting party then
+   sends all of its locally connected clients, servers and channels.  These
+   informations helps to create the route cache.  Also, when new channels
+   are created to a cell its information is broadcasted to all routers
+   in the network.  Channel ID's are based on router's ID thus it is easy
+   to create route cache based on these informations.  If faster route for
+   destination does not exist in router's route cache the packet MUST be
+   routed to the primary route (default route).
+
+   However, there are some issues when routing channel messages to group
+   of users.  Routers are responsible of routing the channel message to
+   other routers, local servers and local clients as well.  Routers MUST
+   send the channel message to only one router in the network, preferably
+   to the shortest route to reach the channel users.  The message can be
+   routed into either upstream or downstream.  After the message is sent
+   to a router in the network it MUST NOT be sent to any other router in
+   either same route or other route.  The message MUST NOT be routed to
+   the router it came from.
+
+   When routing for example private messages they should be routed to the
+   shortest route always to reach the destination client as fast as possible.
+
+   For server which receives a packet to be forwarded to an entity that is
+   indirectly connected to the sender, the server MUST check whether that
+   particular packet type is allowed to be sent to that destination.  Not
+   all packets may be sent by some odd entity to for example a local client,
+   or to some remote server or router, that is indirectly connected to the
+   sender.  See section 2.3 SILC Packet Types and paragraph about indirectly
+   connected entities and sending packets to them.  That section defines the
+   packets that may be sent to indirectly connected entities.  When a server
+   or a router receives a packet that may be sent to indirectly connected
+   entity and it is destined to other entity except that server, it MUST
+   route it further either to shortest route or to the primary route to reach
+   that destination.
+
+   Routers form a ring in the SILC network.  However, routers may have other
+   direct connections to other routers in the network too.  This can cause
+   interesting routing problems in the network.  Since the network is a ring,
+   the packets usually should be routed into clock-wise direction, or if it
+
+
+
+Riikonen                                                       [Page 56]
+
+Internet Draft                                           15 January 2007
+
+
+   cannot be used then always counter clock-wise (primary route) direction.
+   Problems may arise when a faster direct route exists and router is routing
+   a channel message.  Currently channel messages must be routed either
+   in upstream or downstream, they cannot be routed to other direct routes.
+   The SILC protocol should have a shortest path discovery protocol, and some
+   existing routing protocol, that can handle a ring network with other
+   direct routes inside the ring (so called hybrid ring-mesh topology),
+   MAY be defined to be used with the SILC protocol.  Additional
+   specifications MAY be written on the subject to permeate this
+   specification.
+
+
+2.12 Packet Broadcasting
+
+   SILC packets MAY be broadcasted in SILC network.  However, only router
+   server may send or receive broadcast packets.  Client and normal server
+   MUST NOT send broadcast packets and they MUST ignore broadcast packets
+   if they receive them.  Broadcast packets are sent by setting Broadcast
+   flag to the SILC packet header.
+
+   Broadcasting packets means that the packet is sent to all routers in
+   the SILC network, except to the router that sent the packet.  The router
+   receiving broadcast packet MUST send the packet to its primary route.
+   The fact that SILC routers may have several router connections can
+   cause problems, such as race conditions inside the SILC network, if
+   care is not taken when broadcasting packets.  Router MUST NOT send
+   the broadcast packet to any other route except to its primary route.
+
+   If the primary route of the router is the original sender of the packet
+   the packet MUST NOT be sent to the primary route.  This may happen
+   if router has several router connections and some other router uses
+   the router as its primary route.
+
+   Routers use broadcast packets to broadcast for example information
+   about newly registered clients, servers, channels etc. so that all the
+   routers may keep these informations up to date.
+
+
+3 Security Considerations
+
+   Security is central to the design of this protocol, and these security
+   considerations permeate the specification.  Common security considerations
+   such as keeping private keys truly private and using adequate lengths for
+   symmetric and asymmetric keys must be followed in order to maintain the
+   security of this protocol.
+
+
+4 References
+
+
+
+Riikonen                                                       [Page 57]
+
+Internet Draft                                           15 January 2007
+
+
+   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
+                Protocol Specification", Internet Draft, January 2007.
+
+   [SILC3]      Riikonen, P., "SILC Key Exchange and Authentication
+                Protocols", Internet Draft, January 2007.
+
+   [SILC4]      Riikonen, P., "SILC Commands", Internet Draft, January 2007.
+
+   [IRC]        Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+                RFC 1459, May 1993.
+
+   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+                April 2000.
+
+   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
+                2811, April 2000.
+
+   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+                2812, April 2000.
+
+   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+                2813, April 2000.
+
+   [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
+                Internet Draft.
+
+   [PGP]        Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+                November 1998.
+
+   [SPKI]       Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+                September 1999.
+
+   [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+                Infrastructure, Certificate and CRL Profile", RFC 2459,
+                January 1999.
+
+   [Schneier]   Schneier, B., "Applied Cryptography Second Edition",
+                John Wiley & Sons, New York, NY, 1996.
+
+   [Menezes]    Menezes, A., et al, "Handbook of Applied Cryptography",
+                CRC Press 1997.
+
+   [OAKLEY]     Orman, H., "The OAKLEY Key Determination Protocol",
+                RFC 2412, November 1998.
+
+   [ISAKMP]     Maughan D., et al, "Internet Security Association and
+                Key Management Protocol (ISAKMP)", RFC 2408, November
+                1998.
+
+
+
+Riikonen                                                       [Page 58]
+
+Internet Draft                                           15 January 2007
+
+
+   [IKE]        Harkins D., and Carrel D., "The Internet Key Exchange
+                (IKE)", RFC 2409, November 1998.
+
+   [HMAC]       Krawczyk, H., "HMAC: Keyed-Hashing for Message
+                Authentication", RFC 2104, February 1997.
+
+   [PKCS1]      Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+                Specifications, Version 2.0", RFC 2437, October 1998.
+
+   [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SFTP]       Ylonen T., and Lehtinen S., "Secure Shell File Transfer
+                Protocol", Internet Draft, March 2001.
+
+   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", RFC 3629, November 2003.
+
+
+5 Author's Address
+
+   Pekka Riikonen
+   Helsinki
+   Finland
+
+   EMail: priikone@iki.fi
+
+
+6 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+Riikonen                                                       [Page 59]
+
diff --git a/docs/protocol/draft-riikonen-silc-spec-09.txt b/docs/protocol/draft-riikonen-silc-spec-09.txt
new file mode 100644
index 0000000..dbc35db
--- /dev/null
+++ b/docs/protocol/draft-riikonen-silc-spec-09.txt
@@ -0,0 +1,3251 @@
+
+
+
+
+
+
+Network Working Group                                        P. Riikonen
+Internet-Draft
+draft-riikonen-silc-spec-09.txt                          15 January 2007
+Expires: 15 July 2007
+
+
+                 Secure Internet Live Conferencing (SILC),
+                          Protocol Specification
+                     <draft-riikonen-silc-spec-09.txt>
+
+Status of this Draft
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+   This memo describes a Secure Internet Live Conferencing (SILC)
+   protocol which provides secure conferencing services over insecure
+   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 specifications relates very closely to this memo;
+   SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication
+   Protocols [SILC3] and SILC Commands [SILC4].
+
+
+
+
+
+
+
+
+
+Riikonen                                                        [Page 1]
+
+Internet Draft                                           15 January 2007
+
+
+Table of Contents
+
+   1 Introduction ..................................................  3
+     1.1 Requirements Terminology ..................................  4
+   2 SILC Concepts .................................................  4
+     2.1 SILC Network Topology .....................................  5
+     2.2 Communication Inside a Cell ...............................  6
+     2.3 Communication in the Network ..............................  7
+     2.4 Channel Communication .....................................  7
+     2.5 Router Connections ........................................  8
+   3 SILC Specification ............................................  9
+     3.1 Client ....................................................  9
+         3.1.1 Client ID ........................................... 10
+     3.2 Server .................................................... 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 .................................................... 13
+         3.3.1 Router's Local ID List .............................. 13
+         3.3.2 Router's Global ID List ............................. 14
+         3.3.3 Router's Server ID .................................. 15
+     3.4 Channels .................................................. 15
+         3.4.1 Channel ID .......................................... 16
+     3.5 Operators ................................................. 17
+     3.6 SILC Commands ............................................. 17
+     3.7 SILC Packets .............................................. 17
+     3.8 Packet Encryption ......................................... 18
+         3.8.1 Determination of the Source and the Destination ..... 18
+         3.8.2 Client To Client .................................... 19
+         3.8.3 Client To Channel ................................... 20
+         3.8.4 Server To Server .................................... 21
+     3.9 Key Exchange And Authentication ........................... 21
+         3.9.1 Authentication Payload .............................. 22
+     3.10 Algorithms ............................................... 24
+         3.10.1 Ciphers ............................................ 24
+                3.10.1.1 CBC Mode .................................. 24
+                3.10.1.2 CTR Mode .................................. 25
+                3.10.1.3 Randomized CBC Mode ....................... 27
+         3.10.2 Public Key Algorithms .............................. 27
+                3.10.2.1 Multi-Precision Integers .................. 28
+         3.10.3 Hash Functions ..................................... 28
+         3.10.4 MAC Algorithms ..................................... 28
+         3.10.5 Compression Algorithms ............................. 29
+     3.11 SILC Public Key .......................................... 29
+     3.12 SILC Version Detection ................................... 32
+     3.13 UTF-8 Strings in SILC .................................... 33
+         3.13.1 UTF-8 Identifier Strings ........................... 33
+     3.14 Backup Routers ........................................... 34
+
+
+
+Riikonen                                                        [Page 2]
+
+Internet Draft                                           15 January 2007
+
+
+         3.14.1 Switching to Backup Router ......................... 36
+         3.14.2 Resuming Primary Router ............................ 37
+   4 SILC Procedures ............................................... 39
+     4.1 Creating Client Connection ................................ 39
+     4.2 Creating Server Connection ................................ 41
+         4.2.1 Announcing Clients, Channels and Servers ............ 42
+     4.3 Joining to a Channel ...................................... 43
+     4.4 Channel Key Generation .................................... 44
+     4.5 Private Message Sending and Reception ..................... 45
+     4.6 Private Message Key Generation ............................ 46
+     4.7 Channel Message Sending and Reception ..................... 47
+     4.8 Session Key Regeneration .................................. 47
+     4.9 Command Sending and Reception ............................. 48
+     4.10 Closing Connection ....................................... 49
+     4.11 Detaching and Resuming a Session ......................... 49
+     4.12 UDP/IP Connections ......................................  51
+   5 Security Considerations ....................................... 52
+   6 References .................................................... 53
+   7 Author's Address .............................................. 55
+   Appendix A ...................................................... 55
+   Appendix B ...................................................... 56
+   Appendix C ...................................................... 57
+   Appendix D ...................................................... 57
+   Full Copyright Statement ........................................ 58
+
+List of Figures
+
+   Figure 1:  SILC Network Topology
+   Figure 2:  Communication Inside cell
+   Figure 3:  Communication Between Cells
+   Figure 4:  Router Connections
+   Figure 5:  SILC Public Key
+   Figure 6:  Counter Block
+   Figure 7:  CTR Mode Initialization Vector
+
+
+1. Introduction
+
+   This document describes a Secure Internet Live Conferencing (SILC)
+   protocol which provides secure conferencing services over insecure
+   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 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
+
+
+
+Riikonen                                                        [Page 3]
+
+Internet Draft                                           15 January 2007
+
+
+   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 specifications relates very closely
+   to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and
+   Authentication Protocols [SILC3] and SILC Commands [SILC4].
+
+   The protocol uses extensively packets as conferencing protocol
+   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 SILC Packet Protocol provides secured
+   and authenticated packets, and the protocol is designed to be compact.
+   This makes SILC also suitable in environment of low bandwidth
+   requirements such as mobile networks.  All packet payloads in SILC
+   can be also compressed.
+
+   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 both TCP/IP and UDP/IP
+   network protocols.  However, typical implementation would use only TCP/IP
+   with SILC protocol.  Typical implementation would be made in client-server
+   model.
+
+
+1.1 Requirements Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+   MAY, and OPTIONAL, when they appear in this document, are to be
+   interpreted as described in [RFC2119].
+
+
+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 servers and routers 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.
+
+
+
+Riikonen                                                        [Page 4]
+
+Internet Draft                                           15 January 2007
+
+
+2.1 SILC Network Topology
+
+   SILC network forms a ring as opposed to tree style network topology that
+   conferencing protocols usually have.  The network has a cells which are
+   constructed from 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 router servers.
+
+   A difference between normal server and router server is that routers
+   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
+   within the cell and 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.
+
+   The following diagram represents SILC network topology.
+
+          ---- ---- ----         ---- ---- ----
+         | 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.
+
+                     Figure 1:  SILC Network Topology
+
+
+   A cell is formed when a server or servers connect to one router.  In
+
+
+
+Riikonen                                                        [Page 5]
+
+Internet Draft                                           15 January 2007
+
+
+   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 able to act
+   as normal SILC server; clients may connect to it the same way as to
+   normal SILC server.  This, however is not a requirement and if needed
+   router servers may be hidden from users by not allowing direct client
+   connections.  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 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.
+
+
+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.  A client which is connected to
+   server in the cell and is talking on channel to other client connected
+   to other server in the same cell, will have its messages delivered from
+   its local server first to the router of the cell, and from the router
+   to the other server in the cell.
+
+   The following diagram represents this scenario:
+
+
+                         1 --- S1     S4 --- 5
+                                  S/R
+                          2 -- S2     S3
+                              /        |
+                             4         3
+
+
+                   Figure 2:  Communication Inside cell
+
+
+   Example:  Client 1. connected to Server 1. send message 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
+
+
+
+Riikonen                                                        [Page 6]
+
+Internet Draft                                           15 January 2007
+
+
+             servers in the cell will not see the routed message.
+
+
+   If the client is connected directly to the router, as router is also normal
+   SILC server, the messages inside the cell are always delivered only with
+   one server hop.  If clients communicating with each other are connected
+   to the same server, no router interaction is needed.  This is the optimal
+   situation of message delivery in the SILC network.
+
+
+2.3 Communication in the Network
+
+   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
+   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.
+
+
+
+                1 --- S1     S4 --- 5            S2 --- 1
+                         S/R - - - - - - - - S/R
+                 2 -- S2     S3           S1
+                     /        |             \
+                    4         3              2
+
+                   Cell 1.               Cell 2.
+
+
+                  Figure 3:  Communication Between Cells
+
+
+   Example:  Client 5. connected to Server 4. in Cell 1. sends message
+             to Client 2. connected to Server 1. in Cell 2. travels
+             from Server 4. to Router which routes the message to
+             Router in Cell 2, which then routes the message to
+             Server 1.  All the other servers and routers in the
+             network will not see the routed message.
+
+
+   The optimal case of message delivery from the client point of view is
+   when clients are connected directly to the routers and the messages
+   are delivered from one router to the other.
+
+
+
+
+
+
+
+Riikonen                                                        [Page 7]
+
+Internet Draft                                           15 January 2007
+
+
+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 which are
+   joined to the channel.  Router also distributes the message to its
+   local clients on the channel.
+
+
+2.5 Router Connections
+
+   Router connections play very important role in making the SILC like
+   network topology to work.  For example, sending broadcast packets in
+   SILC network require special connections between routers; routers must
+   be connected in a specific way.
+
+   Every router has their primary route which is a connection to another
+   router in the network.  Unless there is only two routers in the network
+   must not routers use each other as their primary routes.  The router
+   connections in the network must form a ring.
+
+   Example with three routers in the network:
+
+
+                    S/R1 - < - < - < - < - < - < - S/R2
+                     \                               /
+                      v                             ^
+                       \ - > -  > - S/R3 - > - > - /
+
+
+                       Figure 4:  Router Connections
+
+
+   Example:  Network with three routers.  Router 1. uses Router 2. as its
+             primary router.  Router 2. uses Router 3. as its primary router,
+             and Router 3. uses Router 1. as its primary router.  When there
+             are four or more routers in th enetwork, there may be other
+             direct connections between the routers but they must not be used
+             as primary routes.
+
+   The above example is applicable to any amount of routers in the network
+
+
+
+Riikonen                                                        [Page 8]
+
+Internet Draft                                           15 January 2007
+
+
+   except for two routers.  If there are only two routers in the network both
+   routers must be able to handle situation where they use each other as their
+   primary routes.
+
+   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 can cause interesting
+   routing problems.  The [SILC2] discusses the routing of packets in this
+   sort of network in more detail.
+
+
+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.
+
+
+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 user's IP address and nickname.  User use logical nicknames
+   in communication which are then mapped to the corresponding Client ID.
+   Client IDs are low level identifications and should not be seen by the
+   end user.
+
+   Clients provide other information about the end user as well. Information
+   such as the nickname of the user, username and the host name of the end
+   user and user's real name.  See section 3.2 Server for information of
+   the requirements of keeping this information.
+
+   The nickname selected by the user is not unique in the SILC network.
+   There can be 2^8 same nicknames for one IP address.  As for comparison to
+   IRC [IRC] where nicknames are unique this is a fundamental difference
+   between SILC and IRC.  This typically causes the server names or client's
+   host names to be used along with the nicknames on user interface to
+   identify specific users when sending messages.  This feature of SILC
+   makes IRC style nickname-wars obsolete as no one owns their nickname;
+   there can always be someone else with the same nickname.  Also, any kind
+   of nickname registering service becomes obsolete.  See the section 3.13.1
+   for more information about nicknames.
+
+
+
+
+
+Riikonen                                                        [Page 9]
+
+Internet Draft                                           15 January 2007
+
+
+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 IDs,
+   and IDs based on IPv6 addresses extends this to 2^224 different Client
+   IDs.  Collisions are not expected to happen.  The Client ID is defined
+   as follows.
+
+      128 bit Client ID based on IPv4 addresses:
+
+      32 bit  Server ID IP address (bits 1-32)
+       8 bit  Random number or counter
+      88 bit  Truncated MD5 hash value of the nickname
+
+      224 bit Client ID based on IPv6 addresses:
+
+      128 bit  Server ID IP address (bits 1-128)
+        8 bit  Random number or counter
+       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 the client is connected.
+
+      o Random number or counter - Random number to further
+        randomize the Client ID.  Another choice is to use
+        a counter starting from the zero (0).  This makes it
+        possible to have 2^8 same nicknames from the same
+        server IP address.
+
+      o MD5 hash - MD5 hash value of the case folded 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.  Note that the nickname MUST be prepared
+        using the stringprep [RFC3454] profile described in the
+        Appendix A before computing the MD5 hash.  See also the
+        section 3.13.1 for more information.
+
+   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 serious problems if it would occur.  Nicknames are usually
+   logical and it is unlikely to have two distinct logical nicknames
+
+
+
+Riikonen                                                       [Page 10]
+
+Internet Draft                                           15 January 2007
+
+
+   produce same truncated hash value.  Use of MD5 in nickname hash is not
+   a security feature.
+
+
+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 focus on the normal server and router server is described
+   in the section 3.3 Router.
+
+   Normal servers MUST 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 MUST NOT connect to other
+   cell's router except in situations where its cell's router is unavailable.
+
+
+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 IDs, nicknames, usernames and host names 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 do not have to worry about global clients.  Server is also responsible
+   of creating the Client IDs for their clients.
+
+   Normal server also keeps information about locally created channels and
+   their Channel IDs.
+
+   Hence, local list for normal server includes:
+
+      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
+
+
+
+Riikonen                                                       [Page 11]
+
+Internet Draft                                           15 January 2007
+
+
+         o Client ID
+         o Sending key
+         o Receiving key
+         o Public key
+
+      channel list       - All channels in server
+         o Channel name
+         o Channel ID
+         o Client IDs on channel
+         o Client ID modes on channel
+         o Channel key
+
+
+3.2.2 Server ID
+
+   Servers are distinguished from other servers by unique 64 bit Server ID
+   (for IPv4) or 160 bit Server ID (for IPv6).  The Server ID is used in
+   the SILC to route messages to correct servers.  Server IDs also provide
+   information for Client IDs, see section 3.1.1 Client ID.  Server ID is
+   defined as follows.
+
+      64 bit Server ID based on IPv4 addresses:
+
+      32 bit  IP address of the server
+      16 bit  Port
+      16 bit  Random number
+
+      160 bit Server ID based on IPv6 addresses:
+
+      128 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 bound to.
+
+      o Random number - This is used to further randomize the Server ID.
+
+   Collisions are not expected to happen in any conditions.  The Server ID
+   is always created by the server itself and server is responsible of
+   distributing it to the router.
+
+
+3.2.3 SILC Server Ports
+
+   The following ports has been assigned by IANA for the SILC protocol:
+
+
+
+Riikonen                                                       [Page 12]
+
+Internet Draft                                           15 January 2007
+
+
+          silc            706/tcp    SILC
+          silc            706/udp    SILC
+
+
+   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.
+
+
+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
+   may also act as normal server when clients may connect to it.  This is not
+   requirement and router servers may be hidden from clients.
+
+   However, router servers have a lot of important tasks that normal servers
+   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.
+
+
+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 need
+   to keep information about user's nickname, username and host name and real
+   name since these are not needed by the router.  The router keeps only
+   information that it needs.
+
+   Hence, local list for router includes:
+
+      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
+
+
+
+Riikonen                                                       [Page 13]
+
+Internet Draft                                           15 January 2007
+
+
+      channel list       - All channels in the cell
+         o Channel ID
+         o Client IDs on channel
+         o Client ID modes on channel
+         o Channel key
+
+
+   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.  Router MAY also cache same detailed information for other clients
+   if needed.
+
+
+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 IDs, all created channels
+   and their Channel IDs and all servers and routers on SILC and their
+   Server IDs.  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 host names or user's real names.  Router does not need to
+   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:
+
+      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 IDs on channel
+         o Client ID modes on channel
+
+
+
+
+
+
+
+
+Riikonen                                                       [Page 14]
+
+Internet Draft                                           15 January 2007
+
+
+3.3.3 Router's Server ID
+
+   Router's Server ID is equivalent to normal Server ID.  As routers are
+   normal servers same types of IDs applies for routers as well.  See
+   section 3.2.2 Server ID.
+
+
+
+
+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 has left it.  When channel exists, any client
+   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
+   channel founder privileges on the channel later when he joins the
+   channel.
+
+   Channel names are unique although the real uniqueness comes from 64 bit
+   Channel ID.  However, channel names are still unique and no two global
+   channels with same name may exist.  See the section 3.13.1 for more
+   information about channel names.
+
+   Channels can have operators that can administrate the channel and operate
+   all of its modes.  The following operators on channel exist on the
+   SILC network.
+
+      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.  However, it is possible to set a mode for
+        the channel which allows the original channel founder to regain the
+        founder privileges even after leaving 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 to administrate the
+
+
+
+Riikonen                                                       [Page 15]
+
+Internet Draft                                           15 January 2007
+
+
+        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.
+
+
+
+
+3.4.1 Channel ID
+
+   Channels are distinguished from other channels by unique Channel ID.
+   The Channel ID is a 64 bit ID (for IPv4) or 160 bit ID (for IPv6), 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.
+
+      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 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 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
+        taken from the router's Server ID.  This way SILC routers know
+        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 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.
+
+
+
+
+
+
+Riikonen                                                       [Page 16]
+
+Internet Draft                                           15 January 2007
+
+
+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
+   channels, to gain access to the contents of 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 any normal user except they are able to administrate
+   their server or router.
+
+
+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.  Usually server cannot send commands to
+   clients, however there MAY be commands that allow the server to send
+   commands to client.  By default servers MAY send commands only to other
+   servers and routers.
+
+   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
+   choose to ignore the command reply.
+
+   It is expected that some of the commands may be misused 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.  However, to keep response rate up, allowing for
+   example five (5) commands before limiting is allowed.  It is RECOMMENDED
+   that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN,
+   SILC_COMMAND_LEAVE and SILC_COMMAND_KILL SHOULD be limited in all cases
+   as they require heavy operations.  This should be sufficient to prevent
+   the misuse of commands.
+
+   SILC commands are described in [SILC4].
+
+
+3.7 SILC Packets
+
+   Packets are naturally the most important part of the protocol and the
+
+
+
+Riikonen                                                       [Page 17]
+
+Internet Draft                                           15 January 2007
+
+
+   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.  It is not possible to send a packet in SILC network without
+   encryption.  The SILC Packet Protocol is a wide protocol and is described
+   in [SILC2].  This document does not define or describe details of
+   SILC packets.
+
+
+3.8 Packet Encryption
+
+   All packets passed in SILC network MUST be encrypted.  This section
+   gives generic description of 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 have a channel 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 have clients
+   on the channel.  However, channels MAY have channel private keys that are
+   entirely local setting for the client.  All clients on the channel MUST
+   know the channel private key beforehand to be able to talk on the
+   channel.  In this case, no server or router knows the key for the 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 router.  However, every packet passed
+   from router to other router, including packets for channels, are
+   encrypted with the shared session key.  Every router connection MUST
+   have their own session keys.
+
+
+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 MUST be encrypted with the session key of who is the next
+
+
+
+Riikonen                                                       [Page 18]
+
+Internet Draft                                           15 January 2007
+
+
+   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 IDs attached to the header.  The IDs in the header will
+   tell to where the packet needs to be sent and where it is coming from.
+
+   The header in the packet MUST 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 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 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
+   the channel key, however, the header is encrypted with the session key
+   as described above.  Most other packets have both header and packet
+   payload encrypted with the same key, such as command packets.
+
+
+3.8.2 Client To Client
+
+   The 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
+
+
+
+Riikonen                                                       [Page 19]
+
+Internet Draft                                           15 January 2007
+
+
+     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 have established a 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 header
+     is encrypted with the session key shared between the client and
+     server, and the private message payload 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.  Header is encrypted with the session key.
+
+   o Router determines the destination of the packet and sends the
+     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.  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 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 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
+   packet to the destination same way as described above.
+
+
+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.
+
+
+
+Riikonen                                                       [Page 20]
+
+Internet Draft                                           15 January 2007
+
+
+             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.
+
+   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 it.
+
+
+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].
+
+
+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 another router connect
+   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
+   to connect to server without explicit authentication.  Servers are
+   REQUIRED to use authentication protocol when connecting.  The
+   authentication may be based on passphrase (pre-shared secret) or public
+
+
+
+Riikonen                                                       [Page 21]
+
+Internet Draft                                           15 January 2007
+
+
+   key based on digital signatures.  All passphrases sent in SILC protocol
+   MUST be UTF-8 [RFC3629] encoded.  The connection authentication protocol
+   is described in detail in [SILC3].
+
+
+3.9.1 Authentication Payload
+
+   Authentication Payload is used separately from the SKE and the Connection
+   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:
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Payload Length         |     Authentication Method     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Public Data Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                           Public Data                         ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Authentication Data Length  |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                       Authentication Data                     ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 5:  Authentication Payload
+
+
+      o Payload Length (2 bytes) - Length of the entire payload.
+
+      o Authentication Method (2 bytes) - The method of the
+        authentication.  The authentication methods are defined
+        in [SILC2] in the Connection Auth Request Payload.  The NONE
+        authentication method SHOULD NOT be used.
+
+      o Public Data Length (2 bytes) - Indicates the length of
+        the Public Data field.
+
+      o Public Data (variable length) - This is defined only if
+        the authentication method is public key.  If it is any other
+
+
+
+Riikonen                                                       [Page 22]
+
+Internet Draft                                           15 January 2007
+
+
+        this field MAY include random data for padding purposes.
+        However, in this case the field MUST be ignored by the
+        receiver.
+
+        When the authentication method is public key this includes
+        128 to 4096 bytes of non-zero random data that is used in
+        the signature process, described subsequently.
+
+      o Authentication Data Length (2 bytes) - Indicates the
+        length of the Authentication Data field.  If zero (0)
+        value is found in this field the payload MUST be
+        discarded.
+
+      o Authentication Data (variable length) - Authentication
+        method dependent authentication data.
+
+
+   If the authentication method is passphrase-based, the Authentication
+   Data field includes the plaintext UTF-8 encoded passphrase.  It is safe
+   to send plaintext passphrase since the entire payload is encrypted.  In
+   this case the Public Data Length is set to zero (0), but MAY also include
+   random data for padding purposes.  It is also RECOMMENDED that maximum
+   amount of padding is applied to SILC packet when using passphrase-based
+   authentication.  This way it is not possible to approximate the length
+   of the passphrase from the encrypted packet.
+
+   If the authentication method is public key based (or certificate)
+   the Authentication Data is computed as follows:
+
+     HASH = hash(random bytes | ID | public key (or certificate));
+     Authentication Data = sign(HASH);
+
+   The hash() and the sign() are the hash function and the public key
+   cryptography function selected in the SKE protocol, unless otherwise
+   stated in the context where this payload is used.  The public key
+   is SILC style public key unless certificates are used.  The ID is the
+   entity's ID (Client or Server ID) which is authenticating itself.  The
+   ID encoding is described in [SILC2].  The random bytes are non-zero
+   random bytes of length between 128 and 4096 bytes, and will be included
+   into the Public Data field as is.
+
+   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.  Also in case of public key
+   authentication this payload is always encrypted.  This payload is
+   always sent as part of some other payload.
+
+
+
+
+Riikonen                                                       [Page 23]
+
+Internet Draft                                           15 January 2007
+
+
+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.
+
+
+3.10.1 Ciphers
+
+   Cipher is the encryption algorithm that is used to protect the data
+   in the SILC packets.  See [SILC2] for 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.
+
+   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 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.
+
+   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.
+
+
+3.10.1.1 CBC Mode
+
+   The "cbc" encryption mode is the standard cipher-block chaining mode.
+   The very first IV is derived from the SILC Key Exchange protocol.
+   Subsequent IVs for encryption is the previous ciphertext block.  The very
+
+
+
+Riikonen                                                       [Page 24]
+
+Internet Draft                                           15 January 2007
+
+
+   first IV MUST be random and is generated as described in [SILC3].
+
+
+3.10.1.2 CTR Mode
+
+   The "ctr" encryption mode is Counter Mode (CTR).  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.  The format
+   of the 128 bit counter block is as follows:
+
+                          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                  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                        Packet Counter                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                        Block Counter                          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                         Figure 6:  Counter Block
+
+      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 (4 bytes) - If the CTR mode is fully
+        stateful this field MUST include the first 4 bytes from the Sending
+        IV or Receiving IV generated in 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
+
+
+
+Riikonen                                                       [Page 25]
+
+Internet Draft                                           15 January 2007
+
+
+        traffic.  Each rekey MUST produce a new value.
+
+        If the IV Included flag is negotiated in SKE or CTR mode is used
+        where the IV is included in the data payload, this field is the
+        Nonce field from the IV received in the packet, defined below.
+
+      o Packet Counter (4 bytes) - This is MSB first ordered monotonically
+        increasing packet counter.  It is set value 1 for first packet and
+        increases for subsequent packets.  After rekey the counter MUST
+        restart from 1.
+
+        If the IV Included flag is negotiated in SKE or CTR mode is used
+        where the IV is included in the data payload, this field is the
+        Packet Counter field from the IV received in the packet, defined
+        below.
+
+      o Block Counter (4 bytes) - This is an MSB first ordered block
+        counter starting from 1 for first block and increasing for
+        subsequent blocks.  The counter is always set to value 1 for
+        a new packet.
+
+   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.  None of the counters must be allowed to wrap without rekey.
+   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 [SILC2] could be performed to produce fresh key material.
+
+   If the IV Included flag was negotiated in SKE, or CTR mode is used to
+   protect channel messages where the IV will be included in the Message
+   Payload, the Initialization Vector (IV) to be used is a 64-bit block
+   containing randomness and packet counter.  Also note, that in this case
+   the decryption process is not stateful and receiver cannot precompute
+   the key stream.  Hence, the Initialization Vector (IV) when CTR mode is
+   used is as follows.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                            Nonce                              |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                        Packet Counter                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 7:  CTR Mode Initialization Vector
+
+
+
+
+Riikonen                                                       [Page 26]
+
+Internet Draft                                           15 January 2007
+
+
+   o Nonce (4 bytes) - This field should be random or otherwise not
+     easily determinable and SHOULD change for each packet.
+
+   o Packet Counter (4 bytes) - This is MSB first ordered monotonically
+     increasing packet counter.  It is set value 1 for first packet and
+     increases for subsequent packets.  After rekey the counter MUST
+     restart from 1.
+
+   When decrypting the packet the Counter Block is assembled by concatenating
+   the truncated hash, with the received nonce and packet counter, and with
+   the block counter.  The Counter Block is then used to compute the key
+   stream to perform the decryption.
+
+
+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 IV chaining is used, but for the first
+   block new random IV is selected in each packet.  In this mode the IV
+   is appended to the ciphertext.  If this mode is used to secure the SILC
+   session, the IV Included flag must be negotiated in SILC Key Exchange
+   protocol.  It may also be used to secure Message Payloads which can
+   deliver the IV to the recipient.
+
+
+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].
+
+   The following public key algorithms are defined in SILC protocol:
+
+      rsa        RSA  (REQUIRED)
+      dss        DSS  (OPTIONAL)
+
+   DSS is described in [Menezes].  The RSA MUST be implemented according
+   PKCS #1 [PKCS1].  When using SILC Public Key version 2 the PKCS #1
+   implementation MUST be compliant with PKCS #1 version 1.5.  The signatures
+   are computed with appendix; the hash OID is included in the signature.
+   The user may always select the hash algorithm for the signatures.  When
+   using SILC Public Key version 1 the PKCS #1 implementation MUST be
+   compliant with PKCS #1 version 1.5 where signatures are computed without
+   appendix; the hash OID is not present in the signature.  The hash
+   algorithm used is specified separately or the default hash algorithm is
+   used, as defined below.
+
+
+
+
+Riikonen                                                       [Page 27]
+
+Internet Draft                                           15 January 2007
+
+
+   Additional public key algorithms MAY be defined to be used in SILC.
+
+   When signatures are computed in SILC the computing of the signature is
+   denoted 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 paragraph for RSA and DSS keys.  If the hash function is not
+   specified separately for signing process SHA-1 MUST be used, except with
+   SILC public key version 2 and RSA algorithm when the user MAY always
+   select the hash algorithm.  In this case the hash algorithm is included
+   in the signature and can be retrieved during verification.  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] and the PGP signature type used is 0x00.
+
+
+3.10.2.1 Multi-Precision Integers
+
+   Multi-Precision (MP) integers in SILC are encoded and decoded as defined
+   in PKCS #1 [PKCS1].  MP integers are unsigned, encoded with the exact
+   octet length of the integer.  No extra leading zero octets may appear.
+   The actual length of the integer is the bit size of the integer not
+   counting any leading zero bits.  The octet length is derived by calculating
+   (bit_length + 7) / 8.
+
+
+3.10.3 Hash Functions
+
+   Hash functions are used as part of MAC algorithms defined in the next
+   section.  They are also used in the SILC Key Exchange protocol defined
+   in the [SILC3].
+
+   The following Hash algorithm are defined in SILC protocol:
+
+      sha1             SHA-1, length = 20 bytes       (REQUIRED)
+      sha256           SHA-256, length = 32 bytes     (RECOMMENDED)
+      md5              MD5, length = 16 bytes         (RECOMMENDED)
+
+
+3.10.4 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 for a packet.
+
+   The following MAC algorithms are defined in SILC protocol:
+
+
+
+
+Riikonen                                                       [Page 28]
+
+Internet Draft                                           15 January 2007
+
+
+      hmac-sha1-96     HMAC-SHA1, length = 12 bytes   (REQUIRED)
+      hmac-sha256-96   HMAC-SHA256, length = 12 bytes (RECOMMENDED)
+      hmac-md5-96      HMAC-MD5, length = 12 bytes    (OPTIONAL)
+      hmac-sha1        HMAC-SHA1, length = 20 bytes   (OPTIONAL)
+      hmac-sha256      HMAC-SHA256, length = 32 bytes (OPTIONAL)
+      hmac-md5         HMAC-MD5, length = 16 bytes    (OPTIONAL)
+      none             No MAC                         (OPTIONAL)
+
+   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].  The hash algorithms used
+   in HMACs, the SHA-1 is described in [RFC3174] and MD5 is described
+   in [RFC1321].  The SHA-256 algorithm and its used with HMAC is described
+   in [SHA256].
+
+   Additional MAC algorithms MAY be defined to be used in SILC.
+
+
+3.10.5 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.
+
+   The following compression algorithms are defined:
+
+      none        No compression               (REQUIRED)
+      zlib        GNU ZLIB (LZ77) compression  (OPTIONAL)
+
+   Additional compression algorithms MAY be defined to be used in SILC.
+
+
+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 the 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:
+
+
+
+
+
+Riikonen                                                       [Page 29]
+
+Internet Draft                                           15 January 2007
+
+
+                          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     |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                         Algorithm Name                        ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Identifier Length       |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     ~                           Identifier                          ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     ~                           Public Data                         ~
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 5:  SILC Public Key
+
+
+      o Public Key Length (4 bytes) - Indicates the full length
+        of the SILC Public Key, not including this field.
+
+      o Algorithm Name Length (2 bytes) - Indicates the length
+        of the Algorithm Length field, not including this field.
+
+      o Algorithm name (variable length) - Indicates the name
+        of the public key algorithm that the key is.  See the
+        section 3.10.2 Public Key Algorithms for defined names.
+
+      o Identifier Length (2 bytes) - Indicates the length of
+        the Identifier field, not including this field.
+
+      o Identifier (variable length) - Indicates the identifier
+        of the public key.  This data can be used to identify the
+        owner of the key.  The identifier may be of the following
+        format:
+
+           UN     User name
+           HN     Host name or IP address
+           RN     Real name
+           E      EMail address
+           O      Organization
+
+
+
+Riikonen                                                       [Page 30]
+
+Internet Draft                                           15 January 2007
+
+
+           C      Country
+           V      Version
+
+        Examples of an identifier:
+
+          `UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi'
+
+          `UN=sam, HN=dummy.fi, RN=Sammy Sam, C=Finland, V=2'
+
+        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 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.  The Version (V) may only be a decimal digit.
+
+      o Public Data (variable length) - Includes the actual
+        public data of the public key.
+
+        The format of this field for RSA algorithm is
+        as follows:
+
+           4 bytes            Length of e
+           variable length    e
+           4 bytes            Length of n
+           variable length    n
+
+
+        The format of this field for DSS algorithm is
+        as follows:
+
+           4 bytes            Length of p
+           variable length    p
+           4 bytes            Length of q
+           variable length    q
+           4 bytes            Length of g
+           variable length    g
+           4 bytes            Length of y
+           variable length    y
+
+        The variable length fields are multiple precession
+        integers encoded as strings in both examples.
+
+        Other algorithms must define their own type of this
+        field if they are used.
+
+   The SILC Public Key is version is 2.  If the Version (V) identifier is
+   not present the SILC Public Key version is expected to be 1.  All new
+
+
+
+Riikonen                                                       [Page 31]
+
+Internet Draft                                           15 January 2007
+
+
+   implementations SHOULD support version 1 but SHOULD only generate version 2.
+   In this case the Version (V) identifier MUST be present.
+
+   All fields in the public key are in MSB (most significant byte first)
+   order.  All strings in the public key MUST be UTF-8 encoded.
+
+   If an external protocol needs to refer to SILC Public Key by name, the
+   names "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).
+
+   A fingerprint from SILC Public Key is computed from the whole encoded
+   public key data block.  All fields are included in computation.  Compliant
+   implementations MUST support computing a 160-bit SHA-1 fingerprint.
+
+
+3.12 SILC Version Detection
+
+   The version detection of both client and server is performed at the
+   connection phase while executing the SILC Key Exchange protocol.  The
+   version identifier is exchanged between initiator and responder.  The
+   version identifier is of the following format:
+
+      SILC-<protocol version>-<software version>
+
+   The version strings are of the following format:
+
+      protocol version = <major>.<minor>
+      software version = <major>[.<minor>[.<build or vendor string>]]
+
+   Protocol version MUST provide both major and minor version.  Currently
+   implementations MUST set the protocol version and accept at least the
+   protocol version as SILC-1.2-<software version>.  If new protocol version
+   causes incompatibilities with older version the <minor> version number
+   MUST be incremented.  The <major> is incremented if new protocol version
+   is fully incompatible.
+
+   Software version MAY provide major, minor and build (vendor) version.
+   The software version MAY be freely set and accepted.  The version string
+   MUST consist of printable US-ASCII characters.
+
+   Thus, the version strings could be, for example:
+
+      SILC-1.1-2.0.2
+      SILC-1.0-1.2
+      SILC-1.2-1.0.VendorXYZ
+
+
+
+Riikonen                                                       [Page 32]
+
+Internet Draft                                           15 January 2007
+
+
+      SILC-1.2-2.4.5 Vendor Limited
+
+
+3.13 UTF-8 Strings in SILC
+
+   By default all strings that are sent in SILC protocol MUST be UTF-8
+   [RFC3269] encoded, unless otherwise defined.  This means that any string
+   sent inside for example, command, command reply, notify or any packet
+   payload is UTF-8 encoded.  Also nicknames, channel names, server names,
+   and hostnames are UTF-8 encoded.  This definition does not affect
+   messages sent in SILC, as the Message Payload provides its own mechanism
+   to indicate whether a message is UTF-8 text message, data message, which
+   may use its own character encoding, or pure binary message [SILC2].
+
+   Certain limitations are imposed on the UTF-8 encoded strings in SILC.
+   The UTF-8 encoded strings MUST NOT include any characters that are
+   marked in the Unicode standard as control codes, noncharacters,
+   reserved or private range characters, or any other illegal Unicode
+   characters.  Also the BOM (Byte-Order Mark) MUST NOT be used as byte
+   order signature in UTF-8 encoded strings.  A string containing these
+   characters MUST be treated as malformed UTF-8 encoding.
+
+   The Unicode standard defines that malformed sequences shall be signalled
+   by replacing the sequence with a replacement character.  Even though,
+   in case of SILC these strings may not be malformed UTF-8 encodings
+   they MUST be treated as malformed strings.  Implementation MAY use
+   a replacement character, however, the character Unicode standard defines
+   MUST NOT be used, but another character must be chosen.  It is, however,
+   RECOMMENDED that an error is returned instead of using replacement
+   character if it is possible.  For example, when setting a nickname
+   with SILC_COMMAND_NICK command, implementation is able to send error
+   indication back to the command sender.  It must be noted that on server
+   implementation if a character sequence is merely outside of current
+   character subset, but is otherwise valid character, it MUST NOT be
+   replaced by a replacement character.
+
+   On user interface where UTF-8 strings are displayed the implementation
+   is RECOMMENDED to escape any character that it is unable to render
+   properly.  The escaping may be done for example as described in
+   [RFC2253].  The escaping makes it possible to retrieve the original
+   UTF-8 encoding.  Alternatively, a replacement character may be used
+   if it does not cause practical problems to the implementation.
+
+
+3.13.1 UTF-8 Identifier Strings
+
+   Identifier strings are special strings in SILC protocol that require
+   more careful processing, than the general UTF-8 strings described in the
+
+
+
+Riikonen                                                       [Page 33]
+
+Internet Draft                                           15 January 2007
+
+
+   previous section.  These strings include the nicknames, server names,
+   hostnames and some other identifier strings.  These strings are prepared
+   using the stringprep [RFC3454] standard.  The Appendix A defines the
+   stringprep profile for SILC identifier strings and conforming
+   implementation MUST use the profile to prepare any identifier string.
+
+   The stringprep profile describes how identifier strings are prepared,
+   what characters they may include, and which characters are prohibited.
+   Identifier strings with prohibited characters MUST be treated as
+   malformed strings.
+
+   The channel name is also special identifier strings with some slight
+   differences to other identifier strings.  The Appendix B defines the
+   stringprep profile for the channel name strings and conforming
+   implementation MUST use the profile to prepare any channel name string.
+
+   Because of the profile the identifier strings in SILC may generally
+   include only letters, numbers, most punctuation characters, and some
+   other characters.  For practical reasons most symbol characters and
+   many other special characters are prohibited.  All identifier strings
+   are case folded and comparing the identifier strings MUST be done as
+   caseless matching.
+
+   In general, the identifier strings does not have a maximum length.
+   However, the length of a nickname string MUST NOT exceed 128 bytes, and
+   the length of a channel name string MUST NOT exceed 256 bytes.  Since
+   these strings are UTF-8 encoded the length of one character may be
+   longer than one byte.  This means that the character length of these
+   strings may be shorter than the maximum length of the string in bytes.
+   The minimum length of an identifier string MUST be at least one character,
+   which may be one byte or more in length.  Implementation MAY limit the
+   maximum length of an identifier string, with exception of the nickname
+   and channel name strings which has the explicit length definition.
+
+
+3.14 Backup Routers
+
+   Backup routers may exist in the cell in addition to the primary router.
+   However, they must not be active routers or act as routers in the cell.
+   Only one router may be acting as primary router in the cell.  In the case
+   of failure of the primary router one of the backup routers becomes active.
+   The purpose of backup routers are in case of failure of the primary router
+   to maintain working connections inside the cell and outside the cell and
+   to avoid netsplits.
+
+   Backup routers are normal servers in the cell that are prepared to take
+   over the tasks of the primary router if needed.  They need to have at
+   least one direct and active connection to the primary router of the cell.
+
+
+
+Riikonen                                                       [Page 34]
+
+Internet Draft                                           15 January 2007
+
+
+   This communication channel is used to send the router information to
+   the backup router.  When the backup router connects to the primary router
+   of the cell it MUST present itself as router server in the Connection
+   Authentication protocol, even though it is normal server as long as the
+   primary router is available.  Reason for this is that the configuration
+   needed in the responder end requires usually router connection level
+   configuration.  The responder, however must understand and treat the
+   connection as normal server (except when feeding router level data to
+   the backup router).
+
+   Backup router must know everything that the primary router knows to be
+   able to take over the tasks of the primary router.  It is the primary
+   router's responsibility to feed the data to the backup router.  If the
+   backup router does not know all the data in the case of failure some
+   connections may be lost.  The primary router of the cell must consider
+   the backup router being an actual router server when it feeds the data
+   to it.
+
+   In addition to having direct connection to the primary router of the
+   cell, the backup router must also have connection to the same router
+   to which the primary router of the cell is connected.  However, it must
+   not be the active router connection meaning that the backup router must
+   not use that channel as its primary route and it must not notify the
+   router about having connected servers, channels and clients behind it.
+   It merely connects to the router.  This sort of connection is later
+   referred to as being a passive connection.  Some keepalive actions may
+   be needed by the router to keep the connection alive.
+
+   It is required that other normal servers have passive connections to
+   the backup router(s) in the cell.  Some keepalive actions may be needed
+   by the server to keep the connection alive.  After they notice the
+   failure of the primary router they must start using the connection to
+   the first backup router as their primary route.
+
+   Also, if any other router in the network is using the cell's primary
+   router as its own primary router, it must also have passive connection
+   to the cell's backup router.  It too is prepared to switch to use the
+   backup router as its new primary router as soon as the original primary
+   router becomes unresponsive.
+
+   All of the parties of this protocol know which one is the backup router
+   of the cell from their local configuration.  Each of the entities must
+   be configured accordingly and care must be taken when configuring the
+   backup routers, servers and other routers in the network.
+
+   It must be noted that some of the channel messages and private messages
+   may be lost during the switch to the backup router, unless the message
+   flag SILC_MESSAGE_FLAG_ACK is set in the message.  The announcements
+
+
+
+Riikonen                                                       [Page 35]
+
+Internet Draft                                           15 January 2007
+
+
+   assure that the state of the network is not lost during the switch.
+
+   It is RECOMMENDED that there would be at least one backup router in
+   the cell.  It is NOT RECOMMENDED to have all servers in the cell acting
+   as backup routers as it requires establishing several connections to
+   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 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 an active server in the cell.  The backup router
+   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.
+
+   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
+   router as described above.
+
+
+3.14.1 Switching to Backup Router
+
+   When the primary router of the cell becomes unresponsive, for example
+   by sending EOF to the connection, all the parties of this protocol MUST
+   replace the old connection to the primary router with first configured
+   backup router.  The backup router usually needs to do local modifications
+   to its database in order to update all the information needed to maintain
+   working routes.  The backup router must understand that clients that
+   were originated from the primary router are now originated from some of
+   the existing server connections and must update them accordingly.  It
+   must also remove those clients that were owned by the primary router
+   since those connections were lost when the primary router became
+   unresponsive.
+
+   All the other parties of the protocol must also update their local
+   database to understand that the route to the primary router will now go
+   to the backup router.
+
+   Servers connected to the backup router MUST send SILC_PACKET_RESUME_ROUTER
+   packet with type value 21, to indicate that the server will start using
+   the backup router as primary router.  The backup router MUST NOT allow
+   this action if it detects that primary is still up and running.  If
+   backup router knows that primary is up and running it MUST send
+   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
+
+
+
+Riikonen                                                       [Page 36]
+
+Internet Draft                                           15 January 2007
+
+
+   SILC_COMMAND_PING command to detect whether primary router is responsive.
+   If the backup router notices that the primary router is unresponsive
+   it SHOULD NOT start sending data to server links before the server has
+   sent the SILC_PACKET_RESUME_ROUTER with type value 21.
+
+   The servers connected to the backup router must then announce their
+   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 has and distribute the new ones to the
+   primary router.
+
+   The backup router too must announce its servers, clients, channels
+   and other information to the new primary router.  The primary router
+   of the backup router too must announce its information to the backup
+   router.  Both must process only the ones they do not know about.  If
+   any of the announced modes do not match then they are enforced in
+   normal manner as defined in section 4.2.1 Announcing Clients, Channels
+   and Servers.
+
+
+3.14.2 Resuming Primary Router
+
+   Usually the primary router is unresponsive only a short period of time
+   and it is intended that the original router of the cell will resume
+   its position as primary router when it comes back online.  The backup
+   router that is now acting as primary router of the cell must constantly
+   try to connect to the original primary router of the cell.  It is
+   RECOMMENDED that it would try to reconnect in 30 second intervals to
+   the primary router.
+
+   When the connection is established to the primary router the backup
+   resuming protocol is executed.  The protocol is advanced as follows:
+
+     1. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+        value 1 to the primary router that came back online.  The packet
+        will indicate the primary router has been replaced by the backup
+        router.  After sending the packet the backup router will announce
+        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 (4 bytes, MSB first
+        order) back to the backup router.  If backup receives this it
+        MUST NOT continue with the backup resuming protocol.
+
+
+
+Riikonen                                                       [Page 37]
+
+Internet Draft                                           15 January 2007
+
+
+     2. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+        value 1 to its current primary router to indicate that it will
+        resign as being primary router.  Then, backup router sends the
+        SILC_PACKET_RESUME_ROUTER packet with type value 1 to all
+        connected servers to also indicate that it will resign as being
+        primary router.
+
+     3. Backup router also send SILC_PACKET_RESUME_ROUTER packet with
+        type value 1 to the router that is using the backup router
+        currently as its primary router.
+
+     4. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+        with type value 1 must reconnect immediately to the primary
+        router of the cell that came back online.  After they have created
+        the connection they MUST NOT use that connection as active primary
+        route but still route all packets to the backup router.  After
+        the connection is created they MUST send SILC_PACKET_RESUME_ROUTER
+        with type value 2 back to the backup router.  The session ID value
+        found in the first packet MUST be set in this packet.
+
+     5. Backup router MUST wait for all packets with type value 2 before
+        it continues with the protocol.  It knows from the session ID values
+        set in the packet when it has received all packets.  The session
+        value should be different in all packets it has sent earlier.
+        After the packets are received the backup router sends the
+        SILC_PACKET_RESUME_ROUTER packet with type value 3 to the
+        primary router that came back online.  This packet will indicate
+        that the backup router is now ready to resign as being primary
+        router.  The session ID value in this packet MUST be the same as
+        in the first packet sent to the primary router.  During this time
+        the backup router must still route all packets it is receiving
+        from server connections.
+
+     6. The primary router receives the packet and send the packet
+        SILC_PACKET_RESUME_ROUTER with type value 4 to all connected servers
+        including the backup router.  It also sends the packet with type
+        value 4 to its primary router, and to the router that is using
+        it as its primary router.  The Session ID value in these packets
+        SHOULD be zero (0).
+
+     7. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+        packet with type value 4 must switch their primary route to the new
+        primary router and remove the route for the backup router, since
+        it is no longer the primary router of the cell.  They must also
+        update their local database to understand that the clients are
+        not originated from the backup router but from the locally connected
+        servers.  After that they MUST announce their channels, channel
+        users, modes etc. to the primary router.  They MUST NOT use the
+
+
+
+Riikonen                                                       [Page 38]
+
+Internet Draft                                           15 January 2007
+
+
+        backup router connection after this and the connection is considered
+        to be a 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 a normal
+   server in the cell that has the backup link to the primary router.  The
+   primary router feeds the router specific data again to the backup router.
+   All server connections to the backup router are considered passive
+   connections.
+
+   When the primary router of the cell comes back online and connects
+   to its remote primary router, the remote primary router MUST send the
+   SILC_PACKET_RESUME_ROUTER packet with type value 20 indicating that the
+   connection is not allowed since the router has been replaced by an
+   backup router in the cell.  The session ID value in this packet SHOULD be
+   zero (0).  When the primary router receives this packet it MUST NOT use
+   the connection as active connection but must understand that it cannot
+   act as primary router in the cell, until the backup resuming protocol has
+   been executed.
+
+   The following type values has been defined for SILC_PACKET_RESUME_ROUTER
+   packet:
+
+     1    SILC_SERVER_BACKUP_START
+     2    SILC_SERVER_BACKUP_START_CONNECTED
+     3    SILC_SERVER_BACKUP_START_ENDING
+     4    SILC_SERVER_BACKUP_START_RESUMED
+     20   SILC_SERVER_BACKUP_START_REPLACED
+     21   SILC_SERVER_BACKUP_START_USE
+
+   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].
+
+
+4 SILC Procedures
+
+   This section describes various SILC procedures such as how the
+   connections are created and registered, how channels are created and
+   so on.  The references [SILC2], [SILC3] and [SILC4] permeate this
+   section's definitions.
+
+
+4.1 Creating Client Connection
+
+   This section describes the procedure when a 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
+
+
+
+Riikonen                                                       [Page 39]
+
+Internet Draft                                           15 January 2007
+
+
+   host really is 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
+   which will provide the key material used later in the communication.
+   The key exchange protocol MUST be completed successfully before the
+   connection registration may continue.  The SILC Key Exchange protocol
+   is described in [SILC3].
+
+   Typical server implementation would keep a list of connections that it
+   allows to connect to the server.  The implementation would check, for
+   example, the connecting client's IP address from the connection list
+   before the SILC Key Exchange protocol has been started.  The reason for
+   this is that if the host is not allowed to connect to the server there
+   is no reason to perform the key exchange protocol.
+
+   After successful key exchange protocol the client and server perform
+   connection authentication protocol.  The purpose of the protocol is to
+   authenticate the client connecting to the server.  Flexible
+   implementation could also accept the client to connect to the server
+   without explicit authentication.  However, if authentication is
+   desired for a specific client it may be based on passphrase or
+   public key authentication.  If authentication fails the connection
+   MUST be terminated.  The connection authentication protocol is described
+   in [SILC3].
+
+   After successful key exchange and authentication protocol the client
+   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 register the client.  Server registers the
+   client and sends SILC_PACKET_NEW_ID to the client which includes the
+   created Client ID that the client MUST start using after that.  After
+   that all SILC packets from the client MUST have the Client ID as the
+   Source ID in the SILC Packet Header, described in [SILC2].
+
+   Client MUST also get the server's Server ID that is to be used as
+   Destination ID in the SILC Packet Header when communicating with
+   the server (for example when sending commands to the server).  The
+   ID may be resolved in two ways.  Client can take the ID from an
+   previously received packet from server that MUST include the ID,
+   or to send SILC_COMMAND_INFO command and receive the Server ID as
+   command reply.
+
+   Server MAY choose not to use the information received in the
+   SILC_PACKET_NEW_CLIENT packet.  For example, if public key or
+   certificate were used in the authentication, server MAY use that
+   information rather than what it received from client.  This is a suitable
+   way to get the true information about client if it is available.
+
+
+
+Riikonen                                                       [Page 40]
+
+Internet Draft                                           15 January 2007
+
+
+   The nickname of client is initially set to the username sent in the
+   SILC_PACKET_NEW_CLIENT packet.  User may set the nickname to something
+   more desirable by sending SILC_COMMAND_NICK command.  However, this is
+   not required as part of registration process.
+
+   Server MUST also distribute the information about newly registered
+   client to its router (or if the server is router, to all routers in
+   the SILC network).  More information about this in [SILC2].
+
+   Router server MUST also check whether some client in the local cell
+   is watching for the nickname this new client has, and send the
+   SILC_NOTIFY_TYPE_WATCH to the watcher.
+
+
+4.2 Creating Server Connection
+
+   This section describes the procedure when server connects to its
+   router (or when router connects to other router, the cases are
+   equivalent).  The procedure is very much alike to when a client
+   connects to the server thus it is not repeated here.
+
+   One difference is that server MUST perform connection authentication
+   protocol with proper authentication.  A proper authentication is based
+   on passphrase authentication or public key authentication based on
+   digital signatures.
+
+   After server and router have successfully performed the key exchange
+   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.  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
+   in the SILC network.  More information about this is in [SILC2].
+
+   As the client needed to resolve the destination ID this MUST be done by
+   the server that connected to the router, as well.  The way to resolve it
+   is to get the ID from previously received packet.  The server MAY also
+   use SILC_COMMAND_INFO command to resolve the ID.  Server MUST also start
+   using its own Server ID as Source ID in SILC Packet Header and the
+   router's Server ID as Destination when communicating with the router.
+
+
+
+
+
+
+
+Riikonen                                                       [Page 41]
+
+Internet Draft                                           15 January 2007
+
+
+4.2.1 Announcing Clients, Channels and Servers
+
+   After server or router has connected to the remote router, and it already
+   has connected clients and channels it MUST announce them to the router.
+   If the server is router server, also all the local servers in the cell
+   MUST be announced.
+
+   All clients are announced by compiling a list of ID Payloads into the
+   SILC_PACKET_NEW_ID packet.  All channels are announced by compiling a
+   list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet.
+   Channels' mode, founder public key, channel public keys, and other
+   channel mode specific data is announced by sending the
+   SILC_NOTIFY_TYPE_CMODE_CHANGE notify list.
+
+   The channel public keys that are announced are compiled in Argument
+   List Payload where the argument type is 0x03, and each argument is
+   Public Key Payload containing one public key or certificate.
+
+   Also, the channel users on the channels must be announced by compiling
+   a list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type
+   into the SILC_PACKET_NOTIFY packet.  The users' modes on the channel
+   must also be announced by compiling list of Notify Payloads with the
+   SILC_NOTIFY_TYPE_CUMODE_CHANGE notify type into the SILC_PACKET_NOTIFY
+   packet.
+
+   The router MUST also announce the local servers by compiling list of
+   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 SILC_NOTIFY_UMODE_CHANGE
+   notify type into the SILC_PACKET_NOTIFY packet.  Also, channels' 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.
+   Also, channel's invite and ban lists MUST be announced by compiling list
+   of Notify Payloads with the SILC_NOTIFY_TYPE_INVITE and
+   SILC_NOTIFY_TYPE_BAN notify types, respectively, into the
+   SILC_PACKET_NOTIFY packet.
+
+   The router which receives these lists MUST process them and broadcast
+   the packets to its primary router.  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.
+
+
+
+Riikonen                                                       [Page 42]
+
+Internet Draft                                           15 January 2007
+
+
+   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
+   is set.
+
+   If the channel has a channel founder already on the router, the router
+   MUST send the notify type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server
+   to force the mode change for the channel founder on the server.  The
+   channel founder privileges MUST be removed on the server.
+
+   If the channel public keys are already set on the on router, the router
+   MUST ignore the received channel public key list and send the notify
+   type SILC_NOTIFY_TYPE_CUMODE_CHANGE to the server which includes the
+   channel public key list that is on router.  The server MUST change the
+   list to the one it receives from router.
+
+   The router processing the channels MUST also compile a list of
+   Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type into the
+   SILC_PACKET_NOTIFY and send the packet to the server.  This way the
+   server (or router) will receive the clients on the channel that
+   the router has.
+
+
+4.3 Joining to a Channel
+
+   This section describes the procedure when client joins to a channel.
+   Client joins to channel by sending command SILC_COMMAND_JOIN to the
+   server.  If the receiver receiving join command is normal server the
+   server MUST check its local list whether this channel already exists
+   locally.  This would indicate that some client connected to the server
+   has already joined to the channel.  If this is the case, the client is
+   joined to the channel, new channel key is created and information about
+   newly joined channel is sent to the router.  The router is informed
+   by sending SILC_NOTIFY_TYPE_JOIN notify type.  The notify type MUST
+   also be sent to the local clients on the channel.  The new channel key
+   is also sent to the router and to local clients on the channel.
+
+   If the channel does not exist in the local list the client's command
+   MUST be sent to the router which will then perform the actual joining
+   procedure.  When server receives the reply to the command from the
+   router it MUST be sent to the client which sent the command originally.
+   Server will also receive the channel key from the server that it MUST
+   send to the client which originally requested the join command.  The
+   server MUST also save the channel key.
+
+   If the receiver of the join command is router it MUST first check its
+   local list whether anyone in the cell has already joined to the channel.
+   If this is the case, the client is joined to the channel and reply is
+   sent to the client.  If the command was sent by server the command reply
+
+
+
+Riikonen                                                       [Page 43]
+
+Internet Draft                                           15 January 2007
+
+
+   is sent to the server which sent it.  Then the router MUST also create
+   new channel key and distribute it to all clients on the channel and
+   all servers that have clients on the channel.  Router MUST also send
+   the SILC_NOTIFY_TYPE_JOIN notify type to local clients on the channel
+   and to local servers that have clients on the channel.
+
+   If the channel does not exist on the router's local list it MUST
+   check the global list whether the channel exists at all.  If it does
+   the client is joined to the channel as described previously.  If
+   the channel does not exist the channel is created and the client
+   is joined to the channel.  The channel key is also created and
+   distributed as previously described.  The client joining to the created
+   channel is made automatically channel founder and both channel founder
+   and channel operator privileges are set for the client.
+
+   If the router created the channel in the process, information about the
+   new channel MUST be broadcast to all routers.  This is done by
+   broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary
+   route.  When the router joins the client to the channel it MUST also
+   send information about newly joined client to all routers in the SILC
+   network.  This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify
+   type to the router's primary route.
+
+   It is important to note that new channel key is created always when
+   new client joins to channel, whether the channel has existed previously
+   or not.  This way the new client on the channel is not able to decrypt
+   any of the old traffic on the channel.  Client which receives the reply to
+   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 or distributed if the SILC_CMODE_PRIVKEY mode is set.
+
+
+4.4 Channel Key Generation
+
+   Channel keys are created by router which creates the channel by taking
+   enough randomness from cryptographically strong random number generator.
+   The key is generated always when channel is created, when new client
+   joins a channel and after the key has expired.  Key could expire for
+   example in an hour.
+
+   The key MUST also be re-generated whenever some client leaves a channel.
+   In this case the key is created from scratch by taking enough randomness
+   from the random number generator.  After that the key is distributed to
+   all clients on the channel.  However, channel keys are cell specific thus
+   the key is created only on the cell where the client, which left the
+   channel, exists.  While the server or router is creating the new channel
+   key, no other client may join to the channel.  Messages that are sent
+
+
+
+Riikonen                                                       [Page 44]
+
+Internet Draft                                           15 January 2007
+
+
+   while creating the new key are still processed with the old key.  After
+   server has sent the SILC_PACKET_CHANNEL_KEY packet client MUST start
+   using the new key.  If server creates the new key the server MUST also
+   send the new key to its router.  See [SILC2] for more information about
+   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 a 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 MAC key that is used to compute
+   the MACs of the channel messages.  The processing is as follows:
+
+     channel_key  = raw key data
+     MAC key      = hash(raw key data)
+
+   The raw key data is the key data received in the Channel Key Payload.
+   It is used for both encryption and decryption.  The hash() is the hash
+   function used with the HMAC of the channel.  Note that the server also
+   MUST save the channel key.
+
+
+4.5 Private Message Sending and Reception
+
+   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 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
+   client ID from server; it is RECOMMENDED that client implementations
+   send SILC_COMMAND_IDENTIFY command to receive the Client ID.  Client
+   MAY also send SILC_COMMAND_WHOIS command to receive the Client ID.
+   If the sender has received earlier a private message from the receiver
+   it should have cached the Client ID from the SILC Packet Header.
+
+   If server receives a private message packet which includes invalid
+
+
+
+Riikonen                                                       [Page 45]
+
+Internet Draft                                           15 January 2007
+
+
+   destination Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+   notify to the client with error status indicating that such Client ID
+   does not exist.
+
+   See [SILC2] for description of private message encryption and decryption
+   process.
+
+
+4.6 Private Message Key Generation
+
+   Private message MAY be protected with a key generated by the client.
+   One way to generate private message key is to use static or pre-shared
+   keys in the client implementation.  Client that wants to indicate other
+   client on the network that a private message key should be set, the
+   client MAY send SILC_PACKET_PRIVATE_MESSAGE_KEY packet to indicate this.
+   The actual key material has to be transferred outside the SILC network,
+   or it has to be pre-shared key.  The client receiving this packet knows
+   that the sender wishes to use private message key in private message
+   communication.  In case of static or pre-shared keys the IV used in
+   the encryption SHOULD be chosen randomly.  Sending the
+   SILC_PACKET_PRIVATE_MESSAGE_KEY is not mandatory, and clients may
+   naturally agree to use a key without sending the packet.
+
+   Another choice to use private message keys is to negotiate fresh key
+   material by performing the Key Agreement.  The SILC_PACKET_KEY_AGREEMENT
+   packet MAY be used to negotiate the fresh key material.  In this case
+   the resulting 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 can also negotiate the cipher and HMAC to be used
+   in the private message encryption and to negotiate additional security
+   parameters.  The actual Key Agreement [SILC2] is performed by executing
+   the SILC Key Exchange protocol [SILC3], peer to peer.  Because of NAT
+   devices in the network, it might be impossible to perform the Key
+   Agreement.  In this case using static or pre-shared key and sending the
+   SILC_PACKET_PRIVATE_MESSAGE_KEY to indicate the use of a private message
+   key is a working alternative.
+
+   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].  If the SILC_PACKET_PRIVATE_MESSAGE_KEY was sent,
+   then it defines the cipher and HMAC to be used.  The hash algorithm to be
+   used in the key material processing is the one that HMAC algorithm is
+   defined to use.  If the SILC_PACKET_PRIVATE_MESSAGE_KEY was not sent at
+   all, then the hash algorithm to be used SHOULD be SHA1.  In this case
+   also, implementations SHOULD use the SILC protocol's mandatory cipher
+
+
+
+Riikonen                                                       [Page 46]
+
+Internet Draft                                           15 January 2007
+
+
+   and HMAC in private message encryption.
+
+
+4.7 Channel Message Sending and Reception
+
+   Channel messages are delivered to a group of users.  The group forms a
+   channel and all clients on the channel receives messages sent to the
+   channel.  The Source ID in the SILC Packet Header MUST be the ID
+   of the sender of the message.
+
+   Channel messages are destined to a channel by specifying the Channel ID
+   as Destination ID in the SILC Packet Header.  The server MUST then
+   distribute the message to all clients, except to the original sender,
+   on the channel by sending the channel message destined explicitly to a
+   client on the channel.  However, the Destination ID MUST still remain
+   as the Channel ID.
+
+   If server receives a channel message packet which includes invalid
+   destination Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+   notify to the sender with error status indicating that such Channel ID
+   does not exist.
+
+   See the [SILC2] for description of channel message routing for router
+   servers, and channel message encryption and decryption process.
+
+
+4.8 Session Key Regeneration
+
+   Session keys MUST be regenerated periodically, say, once in an hour.
+   The re-key process is started by sending SILC_PACKET_REKEY packet to
+   other end, to indicate that re-key must be performed.  The initiator
+   of the connection SHOULD initiate the re-key.
+
+   If perfect forward secrecy (PFS) flag was selected in the SILC Key
+   Exchange protocol [SILC3] the re-key MUST cause new key exchange with
+   SKE protocol.  In this case the protocol is secured with the old key
+   and the protocol results to new key material.  See [SILC3] for more
+   information.  After the SILC_PACKET_REKEY packet is sent the sender
+   will perform the SKE protocol.
+
+   If PFS flag was set the resulted key material is processed as described
+   in the section Processing the Key Material in [SILC3].  The difference
+   with re-key in the processing is that the initial data for the hash
+   function is just the resulted key material and not the HASH as it
+   is not computed at all with re-key.  Other than that, the key processing
+   it equivalent to normal SKE negotiation.
+
+   If PFS flag was not set, which is the default case, then re-key is done
+
+
+
+Riikonen                                                       [Page 47]
+
+Internet Draft                                           15 January 2007
+
+
+   without executing SKE protocol.  In this case, the new key is created by
+   providing the current sending encryption key to the SKE protocol's key
+   processing function.  The process is described in the section Processing
+   the Key Material in [SILC3].  The difference in the processing is that
+   the initial data for the hash function is the current sending encryption
+   key and not the SKE's KEY and HASH values.  Other than that, the key
+   processing is equivalent to normal SKE negotiation.
+
+   After both parties have regenerated the session key, both MUST send
+   SILC_PACKET_REKEY_DONE packet to each other.  These packets are still
+   secured with the old key.  After these packets, the subsequent packets
+   MUST be protected with the new key.  Note that, in case SKE was performed
+   again the SILC_PACKET_SUCCESS is not sent.  The SILC_PACKET_REKEY_DONE
+   is sent in its stead.
+
+
+4.9 Command Sending and Reception
+
+   Client usually sends the commands in the SILC network.  In this case
+   the client simply sends the command packet to server and the server
+   processes it and replies with command reply packet.  See the [SILC4]
+   for detailed description of all commands.
+
+   However, if the server is not able to process the command, it is sent to
+   the server's router.  This is case for example with commands such as
+   SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands.  However, there are
+   other commands as well [SILC4].  For example, if client sends the WHOIS
+   command requesting specific information about some client the server must
+   send the WHOIS command to router so that all clients in SILC network are
+   searched.  The router, on the other hand, sends the WHOIS command further
+   to receive the exact information about the requested client.  The WHOIS
+   command travels all the way to the server which owns the client and it
+   replies with command reply packet.  Finally, the server which sent the
+   command receives the command reply and it must be able to determine which
+   client sent the original command.  The server then sends command reply to
+   the client.  Implementations should have some kind of cache to handle, for
+   example, WHOIS information.  Servers and routers along the route could all
+   cache the information for faster referencing in the future.
+
+   The commands sent by server may be sent hop by hop until someone is able
+   to process the command.  However, it is preferred to destine the command
+   as precisely as it is possible.  In this case, other routers en route
+   MUST route the command packet by checking the true sender and true
+   destination of the packet.  However, servers and routers MUST NOT route
+   command reply packets to clients coming from other servers.  Client
+   MUST NOT accept command reply packet originated from anyone else but
+   from its own server.
+
+
+
+
+Riikonen                                                       [Page 48]
+
+Internet Draft                                           15 January 2007
+
+
+4.10 Closing Connection
+
+   When remote client connection is closed the server MUST send the notify
+   type SILC_NOTIFY_TYPE_SIGNOFF to its primary router and to all channels
+   the client was joined.  The server MUST also save the client's information
+   for a period of time for history purposes.
+
+   When remote server or router connection is closed the server or router
+   MUST also remove all the clients that was behind the server or router
+   from the SILC Network.  The server or router MUST also send the notify
+   type SILC_NOTIFY_TYPE_SERVER_SIGNOFF to its primary router and to all
+   local clients that are joined on the same channels with the remote
+   server's or router's clients.
+
+   Router server MUST also check whether some client in the local cell
+   is watching for the nickname this client has, and send the
+   SILC_NOTIFY_TYPE_WATCH to the watcher, unless the client which left
+   the network has the SILC_UMODE_REJECT_WATCHING user mode set.
+
+
+4.11 Detaching and Resuming a Session
+
+   SILC protocol provides a possibility for a client to detach itself from
+   the network without actually signing off from the network.  The client
+   connection to the server is closed but the client remains as valid client
+   in the network.  The client may then later resume its session back from
+   any server in the network.
+
+   When client wishes to detach from the network it MUST send the
+   SILC_COMMAND_DETACH command to its server.  The server then MUST set
+   SILC_UMODE_DETACHED mode to the client and send SILC_NOTIFY_UMODE_CHANGE
+   notify to its primary router, which then MUST broadcast it further
+   to other routers in the network.  This user mode indicates that the
+   client is detached from the network.  Implementations MUST NOT use
+   the SILC_UMODE_DETACHED flag to determine whether a packet can be sent
+   to the client.  All packets MUST still be sent to the client even if
+   client is detached from the network.  Only the server that originally
+   had the active client connection is able to make the decision after it
+   notices that the network connection is not active.  In this case the
+   default case is to discard the packet.
+
+   The SILC_UMODE_DETACHED flag cannot be set by client itself directly
+   with SILC_COMMAND_UMODE command, but only implicitly by sending the
+   SILC_COMMAND_DETACH command.  The flag also cannot be unset by the
+   client, server or router with SILC_COMMAND_UMODE command, but only
+   implicitly by sending and receiving the SILC_PACKET_RESUME_CLIENT
+   packet.
+
+
+
+
+Riikonen                                                       [Page 49]
+
+Internet Draft                                           15 January 2007
+
+
+   When the client wishes to resume its session in the SILC Network it
+   connects to a server in the network, which MAY also be a different
+   from the original server, and performs normal procedures regarding
+   creating a connection as described in section 4.1.  After the SKE
+   and the Connection Authentication protocols has been successfully
+   completed the client MUST NOT send SILC_PACKET_NEW_CLIENT packet, but
+   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 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 receive the SILC_PACKET_RESUME_CLIENT packet it MUST
+   do the following:  Server checks that the Client ID is valid client
+   and that it has the SILC_UMODE_DETACHED mode set.  Then it verifies
+   the Authentication Payload with the detached client's public key.
+   If it does not have the public key it retrieves it by sending
+   SILC_COMMAND_GETKEY command to the server that has the public key from
+   the original client connection.  The server MUST NOT use the public
+   key received in the SKE protocol for this connection.  If the
+   signature is valid the server unsets the SILC_UMODE_DETACHED flag,
+   and sends the SILC_PACKET_RESUME_CLIENT packet to its primary router.
+   The routers MUST broadcast the packet and unset the SILC_UMODE_DETACHED
+   flag when the packet is received.  If the server is router server it
+   also MUST send the SILC_PACKET_RESUME_CLIENT packet to the original
+   server whom owned the detached client.
+
+   The servers and routers that receives the SILC_PACKET_RESUME_CLIENT
+   packet MUST know whether the packet already has been received for
+   the client.  It is a protocol error to attempt to resume the client
+   session from more than one server.  The implementations could set
+   internal flag that indicates that the client is resumed.  If router
+   receive SILC_PACKET_RESUME_CLIENT packet for client that is already
+   resumed the client MUST be killed from the network.  This would
+   indicate that the client is attempting to resume the session more
+   than once which is a protocol error.  In this case the router sends
+   SILC_NOTIFY_TYPE_KILLED to the client.  All routers that detect
+   the same situation MUST also send the notify for the client.
+
+   The servers and routers that receive the SILC_PACKET_RESUME_CLIENT
+   must also understand that the client may not be found behind the
+   same server that it originally came from.  They must update their
+   caches according to this.  The server that now owns the client session
+   MUST check whether the Client ID of the resumed client is based
+   on the server's Server ID.  If it is not it creates a new Client
+   ID and send SILC_NOTIFY_TYPE_NICK_CHANGE to the network.  It MUST
+
+
+
+Riikonen                                                       [Page 50]
+
+Internet Draft                                           15 January 2007
+
+
+   also send the channel keys of all channels that the client has
+   joined to the client since it does not have them.  Whether the
+   Client ID was changed or not the server MUST send SILC_PACKET_NEW_ID
+   packet to the client.  Only after this is the client resumed back
+   to the network and may start sending packets and messages.
+
+   It is also possible that the server did not know about the global
+   channels before the client resumed.  In this case it joins the client
+   to the channels, generates new channel keys and distributes the keys
+   to the channels as described in section 4.4.
+
+   It is an implementation issue for how long servers keep detached client
+   sessions.  It is RECOMMENDED that the detached sessions would be
+   persistent as long as the server is running.
+
+
+
+4.12 UDP/IP Connections
+
+   SILC protocol allows the use of UDP/IP instead of TCP/IP.  There may be
+   many reasons to use UDP, such as video and audio conferencing might
+   be more efficient with UDP.
+
+   When UDP/IP is used, in the SILC Key Exchange protocol the IV Included
+   flag MUST be set and the first 16-bits of the Cookie field in the Key
+   Exchange Start Payload MUST include the port that the other end will use
+   as the SILC session port.  The port is in MSB first order.  Both initiator
+   and responder will set the port they are going to use and all packets
+   after the SKE has been completed with the SILC_PACKET_SUCCESS packet MUST
+   be sent to the specified port.  Initiator will send them to the port
+   responder specified and vice versa.  When verifying the cookie for
+   modifications the first two bytes are to be ignored in case IV Included
+   flag has been set.
+
+   The default SILC port or port where the SILC server is listenning for
+   incoming packets is used only during initial key exchange protocol.  After
+   SKE has been completed all packets are sent to the specified ports,
+   including connection authentication packets and rekey packets even when
+   PFS is used in rekey.
+
+   Changing the ports during SILC session is possible only by first detaching
+   from the server (with client-server connections) and then performing the
+   SILC Key Exchange protocol from the beginning and resuming the detached
+   session.
+
+   Since the UDP is unreliable transport the SKE packets may not arrive to
+   the recipient.  Implementation should support retransmission of SKE
+   packets by using exponential backoff algorithm.  Also other SILC packets
+
+
+
+Riikonen                                                       [Page 51]
+
+Internet Draft                                           15 January 2007
+
+
+   such as messages may drop en route.  With message packets only way to
+   assure reliable delivery is to use message acking and retransmit the
+   message by using for example exponential backoff algorithm.  With SKE
+   packets the initial timeout value should be no more than 1000
+   milliseconds.  With message packets the initial timeout value should be
+   around 5000 milliseconds.
+
+
+5 Security Considerations
+
+   Security is central to the design of this protocol, and these security
+   considerations permeate the specification.  Common security considerations
+   such as keeping private keys truly private and using adequate lengths for
+   symmetric and asymmetric keys must be followed in order to maintain the
+   security of this protocol.
+
+   Special attention must also be paid to the servers and routers that are
+   running the SILC service.  The SILC protocol's security depends greatly
+   on the security and the integrity of the servers and administrators that
+   are running the service.  It is recommended that some form of registration
+   is required by the server and router administrator prior to acceptance to
+   the SILC Network.  Even though the SILC protocol is secure in a network
+   of mutual distrust between clients, servers, routers and administrators
+   of the servers, the client should be able to trust the servers they are
+   using if they wish to do so.
+
+   It however must be noted that if the client requires absolute security
+   by not trusting any of the servers or routers in the SILC Network, it can
+   be accomplished by negotiating private secret keys outside the SILC
+   Network, either using SKE or some other key exchange protocol, or to use
+   some other external means for distributing the keys.  This applies for
+   all messages, private messages and channel messages.
+
+   It is important to note that SILC, like any other security protocol, is
+   not a foolproof system; the SILC servers and routers could very well be
+   compromised.  However, to provide an acceptable level of security and
+   usability for end users, the protocol uses many times session keys or
+   other keys generated by the servers to secure the messages.  This is an
+   intentional design feature to allow ease of use for end users.  This way
+   the network is still usable, and remains encrypted even if the external
+   means of distributing the keys is not working.  The implementation,
+   however, may like to not follow this design feature, and may always
+   negotiate the keys outside SILC network.  This is an acceptable solution
+   and many times recommended.  The implementation still must be able to
+   work with the server generated keys.
+
+   If this is unacceptable for the client or end user, the private keys
+   negotiated outside the SILC Network should always be used.  In the end
+
+
+
+Riikonen                                                       [Page 52]
+
+Internet Draft                                           15 January 2007
+
+
+   it is the implementor's choice whether to negotiate private keys by
+   default or whether to use the keys generated by the servers.
+
+   It is also recommended that router operators in the SILC Network would
+   form a joint forum to discuss the router and SILC Network management
+   issues.  Also, router operators along with the cell's server operators
+   should have a forum to discuss the cell management issues.
+
+
+6 References
+
+   [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
+                January 2007.
+
+   [SILC3]      Riikonen, P., "SILC Key Exchange and Authentication
+                Protocols", Internet Draft, January 2007.
+
+   [SILC4]      Riikonen, P., "SILC Commands", Internet Draft, January 2007.
+
+   [IRC]        Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+                RFC 1459, May 1993.
+
+   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+                April 2000.
+
+   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
+                2811, April 2000.
+
+   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+                2812, April 2000.
+
+   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+                2813, April 2000.
+
+   [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
+                Internet Draft.
+
+   [PGP]        Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+                November 1998.
+
+   [SPKI]       Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+                September 1999.
+
+   [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+                Infrastructure, Certificate and CRL Profile", RFC 2459,
+                January 1999.
+
+   [Schneier]   Schneier, B., "Applied Cryptography Second Edition",
+
+
+
+Riikonen                                                       [Page 53]
+
+Internet Draft                                           15 January 2007
+
+
+                John Wiley & Sons, New York, NY, 1996.
+
+   [Menezes]    Menezes, A., et al, "Handbook of Applied Cryptography",
+                CRC Press 1997.
+
+   [OAKLEY]     Orman, H., "The OAKLEY Key Determination Protocol",
+                RFC 2412, November 1998.
+
+   [ISAKMP]     Maughan D., et al, "Internet Security Association and
+                Key Management Protocol (ISAKMP)", RFC 2408, November
+                1998.
+
+   [IKE]        Harkins D., and Carrel D., "The Internet Key Exchange
+                (IKE)", RFC 2409, November 1998.
+
+   [HMAC]       Krawczyk, H., "HMAC: Keyed-Hashing for Message
+                Authentication", RFC 2104, February 1997.
+
+   [PKCS1]      Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+                Specifications, Version 2.0", RFC 2437, October 1998.
+
+   [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", RFC 3629, November 2003.
+
+   [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.
+
+   [RFC3454]    Hoffman, P., et al., "Preparation of Internationalized
+                Strings ("stringprep")", RFC 3454, December 2002.
+
+   [SHA256]     Eastlake 3rd, D., et al., "US Secure Hash Algorithms (SHA
+                and HMAC-SHA)", RFC 4634, July 2006.
+
+
+
+
+
+
+Riikonen                                                       [Page 54]
+
+Internet Draft                                           15 January 2007
+
+
+7 Author's Address
+
+   Pekka Riikonen
+   Helsinki
+   Finland
+
+   EMail: priikone@iki.fi
+
+
+Appendix A
+
+   This appendix defines the stringprep [RFC3454] profile for string
+   identifiers in SILC protocol.  Compliant implementation MUST use this
+   profile to prepare the identifier strings in the SILC protocol.  The
+   profile defines the following as required by [RFC3454].
+
+   - Intended applicability of the profile:  the following identifiers in
+     the SILC Protocol;  nicknames, usernames, server names, hostnames,
+     service names, algorithm names and other security property names [SILC3],
+     and SILC Public Key name.
+
+   - The character repertoire that is the input and output to
+     stringprep:  Unicode 3.2 with the list of unassigned code points
+     being the Table A.1, as defined in [RFC3454].
+
+   - The mapping tables used:  the following tables are used, in order,
+     as defined in [RFC3454].
+
+       Table B.1
+       Table B.2
+
+     The mandatory case folding is done using the Table B.2 which includes
+     the characters for the normalization form KC.
+
+   - The Unicode normalization used:  the Unicode normalization form
+     KC is used, as defined in [RFC3454].
+
+   - The prohibited characters as output:  the following tables are used
+     to prohibit characters, as defined in [RFC3454];
+
+       Table C.1.1
+       Table C.1.2
+       Table C.2.1
+       Table C.2.2
+       Table C.3
+       Table C.4
+       Table C.5
+       Table C.6
+
+
+
+Riikonen                                                       [Page 55]
+
+Internet Draft                                           15 January 2007
+
+
+       Table C.7
+       Table C.8
+       Table C.9
+
+   - Additional prohibited characters as output:  in addition, the following
+     tables are used to prohibit characters, as defined in this document;
+
+       Appendix C
+       Appendix D
+
+   - The bidirectional string testing used:  bidirectional string testing
+     is ignored in this profile.
+
+   This profile is to be maintained in the IANA registry for stringprep
+   profiles.  The name of this profile is "silc-identifier-prep" and this
+   document defines the profile.  This document defines the first version of
+   this profile.
+
+
+Appendix B
+
+   This appendix defines the stringprep [RFC3454] profile for channel name
+   strings in SILC protocol.  Compliant implementation MUST use this profile
+   to prepare the channel name strings in the SILC protocol.  The profile
+   defines the following as required by [RFC3454].
+
+   - Intended applicability of the profile:  channel names.
+
+   - The character repertoire that is the input and output to
+     stringprep:  Unicode 3.2 with the list of unassigned code points
+     being the Table A.1, as defined in [RFC3454].
+
+   - The mapping tables used:  the following tables are used, in order,
+     as defined in [RFC3454].
+
+       Table B.1
+       Table B.2
+
+     The mandatory case folding is done using the Table B.2 which includes
+     the characters for the normalization form KC.
+
+   - The Unicode normalization used:  the Unicode normalization form
+     KC is used, as defined in [RFC3454].
+
+   - The prohibited characters as output:  the following tables are used
+     to prohibit characters, as defined in [RFC3454];
+
+       Table C.1.1
+
+
+
+Riikonen                                                       [Page 56]
+
+Internet Draft                                           15 January 2007
+
+
+       Table C.1.2
+       Table C.2.1
+       Table C.2.2
+       Table C.3
+       Table C.4
+       Table C.5
+       Table C.6
+       Table C.7
+       Table C.8
+       Table C.9
+
+   - Additional prohibited characters as output:  in addition, the following
+     tables are used to prohibit characters, as defined in this document;
+
+       Appendix D
+
+   - The bidirectional string testing used:  bidirectional string testing
+     is ignored in this profile.
+
+   This profile is to be maintained in the IANA registry for stringprep
+   profiles.  The name of this profile is "silc-identifier-ch-prep" and this
+   document defines the profile.  This document defines the first version of
+   this profile.
+
+
+Appendix C
+
+   This appendix defines additional prohibited characters in the identifier
+   strings as defined in the stringprep profile in Appendix A.
+
+   Reserved US-ASCII characters
+   0021 002A 002C 003F 0040
+
+
+Appendix D
+
+   This appendix defines additional prohibited characters in the identifier
+   strings as defined in the stringprep profile in Appendix A and Appendix B.
+   Note that the prohibited character tables listed in the Appendix A and
+   Appendix B may include some of the same characters listed in this
+   appendix as well.
+
+   Symbol characters and other symbol like characters
+   00A2-00A9 00AC 00AE 00AF 00B0 00B1 00B4 00B6 00B8 00D7 00F7
+   02C2-02C5 02D2-02FF 0374 0375 0384 0385 03F6 0482 060E 060F
+   06E9 06FD 06FE 09F2 09F3 09FA 0AF1 0B70 0BF3-0BFA 0E3F
+   0F01-0F03 0F13-0F17 0F1A-0F1F 0F34 0F36 0F38 0FBE 0FBF
+   0FC0-0FC5 0FC7-0FCF 17DB 1940 19E0-19FF 1FBD 1FBF-1FC1
+
+
+
+Riikonen                                                       [Page 57]
+
+Internet Draft                                           15 January 2007
+
+
+   1FCD-1FCF 1FDD-1FDF 1FED-1FEF 1FFD 1FFE 2044 2052 207A-207C
+   208A-208C 20A0-20B1 2100-214F 2150-218F 2190-21FF 2200-22FF
+   2300-23FF 2400-243F 2440-245F 2460-24FF 2500-257F 2580-259F
+   25A0-25FF 2600-26FF 2700-27BF 27C0-27EF 27F0-27FF 2800-28FF
+   2900-297F 2980-29FF 2A00-2AFF 2B00-2BFF 2E9A 2EF4-2EFF
+   2FF0-2FFF 303B-303D 3040 3095-3098 309F-30A0 30FF-3104
+   312D-3130 318F 31B8-31FF 321D-321F 3244-325F 327C-327E
+   32B1-32BF 32CC-32CF 32FF 3377-337A 33DE-33DF 33FF 4DB6-4DFF
+   9FA6-9FFF A48D-A48F A4A2-A4A3 A4B4 A4C1 A4C5 A4C7-ABFF
+   D7A4-D7FF FA2E-FAFF FFE0-FFEE FFFC 10000-1007F 10080-100FF
+   10100-1013F 1D000-1D0FF 1D100-1D1FF 1D300-1D35F 1D400-1D7FF
+
+   Other characters
+   E0100-E01EF
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen                                                       [Page 58]
+
diff --git a/index.html b/index.html
index 08b670f..5cbabd8 100644
--- a/index.html
+++ b/index.html
@@ -7,7 +7,7 @@
         <meta charset="utf-8">
         <meta http-equiv="X-UA-Compatible" content="IE=edge">
         <title>SILC - Secure Internet Live Conferencing</title>
-        <meta name="description" content="SILC - Secure Internet Live Conferencing">
+        <meta name="description" content="SILC - Secure Internet Live Conferencing, modern secure conferencing and chat protocol">
         <meta name="viewport" content="width=device-width, initial-scale=1">
 
         <link rel="stylesheet" href="css/normalize.css">
@@ -66,9 +66,7 @@
 
         <footer>
                 <nav>
-<!--
                 <a href="info.html">INFO</a>
--->
                 <a href="client.html">CLIENT</a>
                 <a href="server.html">SERVER</a>
                 <a href="dev.html">DEVELOPMENT</a>
diff --git a/info.html b/info.html
index faa1a55..7886097 100644
--- a/info.html
+++ b/info.html
@@ -25,11 +25,28 @@
 	<center><a href="/"><img src="img/silc.svg" height=64 alt="SILC logo"></a></center>
 	</header>
 
-	<div id="container2">Download SILC Client</div>
+	<div id="container2">Secure Internet Live Conferencing</div>
 
-        <!-- Download -->
 	<center>
+	<div style="width:85%">
+	SILC protocol is a modern conferencing and chat protocol designed with
+	high security as its main feature.
 
+	<div class="list">
+	<ul>
+	<li>Fully encrypted and authenticated transport</li>
+	<li>End-to-end encrypted and authenticated private messages</li>
+	<li>Encrypted and authenticated channel and group messages</li>
+	<li>Secure video and audio conferencing, image and sound messagse</li>
+	<li>Authenticated Diffie-Hellman key exchange and Perfect Forward Secrecy</li>
+	<li>Off-the-record or On-the-record conversations with or without digital signatures</li>
+	<li>Secure file transfer</li>
+	<li>And every other feature you can expect from a modern conferencing and chat protocol...</li>
+	<li><a href="docs/protocol">See all the details in SILC protocol specifications</a></li>
+	</ul>
+	</div>
+
+	</div>
 	</center>
 
         <footer>
diff --git a/server.html b/server.html
index 53694d1..5184e63 100644
--- a/server.html
+++ b/server.html
@@ -78,9 +78,7 @@
 
         <footer>
                 <nav>
-<!--
                 <a href="info.html">INFO</a>
--->
                 <a href="client.html">CLIENT</a>
                 <a href="server.html">SERVER</a>
                 <a href="dev.html">DEVELOPMENT</a>