





Network Working Group                                        P. Riikonen
Internet-Draft
draft-riikonen-silc-rfc2779-00.txt                           NOT RELEASED
Expires:


                 Comparing SILC and RFC 2779 Requirements
                   <draft-riikonen-silc-rfc2779-00.txt>

                          Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   The distribution of this memo is unlimited.


Abstract

   This memo describes the relationship between the Secure Internet
   Live Conferencing (SILC) protocol and the Instant Messaging /
   Presence Protocol Requirements RFC 2779 document to assertain that
   the SILC protocol meets the requirements of the RFC 2779.


1. Introduction

   This memo describes the relationship between the Secure Internet
   Live Conferencing (SILC) protocol and the Instant Messaging /
   Presence Protocol Requirements RFC 2779 document to assertain that
   the SILC protocol meets the requirements of the RFC 2779.

   SILC protocol is not an Instant Messaging protocol per se, which makes
   some of the terminology between the SILC protocol specification,



Riikonen                                                        [Page 1]

Internet Draft                                              NOT RELEASED


   RFC 2779 and RFC 2778 incompatible.  However, in most cases the meaning
   of the differing terminology is equivalent in both specifications.
   Instant Messaging can be best compared to the Email in terms of terminology.
   SILC on the other hand allows Instant Messaging style implementation but
   also IRC style protocol implementation.  For this reason SILC protocol
   does not use the same terminology as the RFC 2779.

   It is suggested that the [SILC1] is read and understood before comparing
   the requirements.  The [SILC1] defines the actual core of the SILC protocol
   which is what most of the RFC 2779 requirements apply to.  Some of the
   requirements listed in this document apply only to optional features in
   the SILC protocol.  Usually this means that implementor of SILC protocol
   may leave that feature out of the implementation.  Also, some of the
   requirements may mean using so called SILC protocol services, which are
   services that augment the features of the protocol.  This makes the SILC
   protocol very flexible, easily augmentable, but also means that
   implementation may decide which services are used (SILC services are not
   to be confused with IRC services, as they are not equivalent and does not
   work in the same level (IRC service works in user/application level, SILC
   service works in protocol level)).


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] and RFC 2779.


2. The RFC 2779 Requirements

   We shall go through the RFC 2779 document in order of the requirements.
   We shall list all RFC 2779 requirements and compare them to the SILC
   protocol.


- Namespace and Administration

   From RFC 2779:

      2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available
      independent of whether an INSTANT MESSAGE SERVICE is available, and
      vice-versa.

   By default in SILC protocol presence is not separated, or specificly
   defined separately, from the messaging service (or the actual service).
   However, SILC allows the separation of PRESENCE SERVICE (as defined
   in RFC 2779) as SILC allows detaching from the messaging service but



Riikonen                                                        [Page 2]

Internet Draft                                              NOT RELEASED


   remaining in the presence service (remaining in the network as presence
   but not being able to use messaging service due to practical detachment
   from the network).  This allows other users to view the presence of a user
   which is present but not in messaging service.  Hence, SILC conforms
   with 2.1.1 even though not explicitly using the same terminology.
   The detachment is defined in [SILC1] in section 4.1.1.


      2.1.2. The protocols must not assume that an INSTANT INBOX is
      necessarily reached by the same IDENTIFIER as that of a PRESENTITY.
      Specifically, the protocols must assume that some INSTANT INBOXes may
      have no associated PRESENTITIES, and vice versa.

   By default, being present in the network and not being in detached status
   then is equivalent of having INSTANT INBOX in SILC.  Additional protocol
   service would allow the use of INSTANT INBOX also in detached (offline)
   status.  In SILC the actual identifier (some humanly understandable
   identifier, such as nickname) is not necessarily same as the presentity.
   In SILC the PRESENTITY (as defined in RFC 2778) would be equivalent to
   the 128-bit Client ID.  There is not necessarily relationship between
   the ID and the IDENTIFIER in SILC.  The presentity in SILC is also not
   persistent and may change during the session.  Also the IDENTIFIER in
   SILC is not actually unique; there can be multiple same IDENTIFIERs but
   all will have different PRESENTITITY.  All messages are delivered in
   the network using the Client IDs as source and destination indicators,
   this is same whether user is online or offline.


      2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached
      via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY.

   As the Client ID (PRESENTITIY) is binary it is usually never viewed
   by the user.  Any user can be reached by their IDENTIFIER as it can be
   mapped to the ID.  The ID can also be mapped to IDENTIFIER.


      2.1.4. The administration and naming of ENTITIES within a given
      DOMAIN MUST be able to operate independently of actions in any other
      DOMAIN.

   In SILC DOMAIN and NAMESPACE would not have direct equivalence.  However,
   we shall define that the NAMESPACE can be equivalent to the network and
   DOMAIN can be equivalent to servers (or routers) in the SILC network.
   In this case the requirement in 2.1.4 is met as the naming of ENTITIES
   are operated independently of actions in any other cell.  However, in
   SILC there is no centrally administrated system, such as database, however,
   SILC clearly can be implemented that way by using the protocol services.
   It must be said here that SILC by default does not require subscription



Riikonen                                                        [Page 3]

Internet Draft                                              NOT RELEASED


   (registration) to the service, and for that reason the users are not
   persistent in the sense that they would be registered into a database
   (however, they are persistent in the network).  However, this is clearly
   an implementation issue.


      2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS
      within the NAMESPACE.

   Using the definitions from above (whether DOMAIN is router or server),
   then SILC does meet this requirement.  There is no resctriction in number
   of DOMAINS withing NAMESPACE.


- Scalability

   From RFC 2779:

      2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate
      with ENTITIES in another DOMAIN, without the DOMAINS having
      previously been aware of each other.

   This is the default assumption in SILC network.  By default servers does not
   know any global information that they do not need to know.  In this sense
   SILC network is truly asynchronous and all information is resolved only
   when needed.


   From RFC 2779:

      The protocol MUST be capable of meeting  its other functional and
      performance requirements even when

         -- (2.2.2) there are millions of ENTITIES within a single DOMAIN.

   The Client ID is 128-bit, so 2^128 ENTITIES can be allowed within
   a single DOMAIN in SILC.  For IPv6 based IDs the number is larger.

         -- (2.2.3) there are millions of DOMAINS within the single
            NAMESPACE.

   The Server ID is 64-bits, so 2^64 DOMAINS can be allowed.  For
   IPv6 based IDs the number is larger.

         -- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds
            of PRESENTITIES.

   SUBCRIPTION in SILC would be equivalent of using the WATCH [SILC3] command



Riikonen                                                        [Page 4]

Internet Draft                                              NOT RELEASED


   to watch for the presence of users in the network (whether online or
   offline).  There is no limit in SILC.

         -- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to
            a single PRESENTITY.

   There is no limit in SILC.

         -- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to
            PRESENTITIES in hundreds of distinct DOMAINS.

   There is no limit in SILC.


- Access Control

   From RFC 2779:

      The PRINCIPAL controlling a PRESENTITY MUST be able to control

         -- (2.3.1) which WATCHERS can observe that PRESENTITY’s PRESENCE
            INFORMATION.

         -- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that
            PRESENTITY’s PRESENCE INFORMATION.

         -- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will see
            for that PRESENTITY, regardless of whether the WATCHER gets it
            by fetching or NOTIFICATION.

   User can reject watching (eqv. SUBSCRIPTION) from other users.  A protocol
   service could allow setting any of the limits described above.  By default,
   such service is not used.

   NOTE: In SILC it is not so strictly defined as what information is
   presence.  By default the basic information (nickname, username, realname,
   and mode (which can represent simple presence) can be fetched with fe.
   WHOIS command.  However, WHOIS also allows using of so called Requested
   Attributes.  The [SILC5] defines the user online status and presence
   attributes (which are separate from the basic user information) that are
   used in SILC.  If this is considered to be the default presence information
   in SILC then the requirements 2.3.1, 2.3.2 and 2.3.3 are met as user can
   set any kinds of limits.  However, in this case it is implementation issue.

         -- (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE
            INFORMATION of that PRESENTITY.

   This is not allowed in SILC due to clear security reasons.  No other user



Riikonen                                                        [Page 5]

Internet Draft                                              NOT RELEASED


   can modify other user’s information or presence status in SILC protocol.


   From RFC 2779:

      The PRINCIPAL controlling an INSTANT INBOX MUST be able to control

         -- (2.3.5) which other PRINCIPALS, if any, can send INSTANT
            MESSAGES to that INSTANT INBOX.

   In SILC, in protocol level, it is possible to set limitations based on
   other user privileges.  For example to not allow users without operator
   privileges to send messsages.  A protocol service could allow more specific
   limits.  By default, such service is not used.

   Clearly this is also implementation issue, as implementation may set such
   limits.

         -- (2.3.6) which other PRINCIPALS, if any, can read INSTANT
            MESSAGES from that INSTANT INBOX.

   This is not allowed in SILC due to clear security reasons.  No other
   user can read (due to default and mandatory encryption and authentication
   of _all_ messages) other user’s messages.


- Network Topology

   From RFC 2779:

      2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both
      directly and via intermediaries, such as PROXIES.

      2.4.2. The protocol MUST allow the sending of a NOTIFICATION both
      directly and via intermediaries, such as PROXIES.

      2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both
      directly and via intermediaries, such as PROXIES.

   Clearly all of these are implementation issues.  By default use of proxy
   is not defined in SILC protocol.  However, clearly, implementation may
   allow the use of it.  If such specification is needed SILC specification
   may be changed to mention that implementation MAY use proxies.


      2.4.4. The protocol proxying facilities and transport practices MUST
      allow ADMINISTRATORS ways to enable and disable protocol activity
      through existing and commonly-deployed FIREWALLS.  The protocol MUST



Riikonen                                                        [Page 6]

Internet Draft                                              NOT RELEASED


      specify how it can be effectively filtered by such FIREWALLS.

   The SILC protocol use IANA specified port TCP/UDP 706.  Opening or closing
   this port can be allowed or disallowed the use of SILC protocol.


- Message Encryption and Authentication

   From RFC 2779:

      2.5.1. The protocol MUST provide means to ensure confidence that a
      received message (NOTIFICATION or INSTANT MESSAGE) has not been
      corrupted or tampered with.

      2.5.2. The protocol MUST provide means to ensure confidence that a
      received message (NOTIFICATION or INSTANT MESSAGE) has not been
      recorded and played back by an adversary.

   By default all messages and encrypted and authentication.  Both req. 2.5.1
   and 2.5.2 are met.


      2.5.3. The protocol MUST provide means to ensure that a sent message
      (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that
      the sender allows.

   It is quaranteed that a message, when destined either to a specific user
   or to group of users is only readable by that specific user or the group
   of users.


      2.5.4. The protocol MUST allow any client to use the means to ensure
      non-corruption, non-playback, and privacy, but the protocol MUST NOT
      require that all clients use these means at all times.

   The protocol does allow the means of ensuring non-corruption, non-playback
   and privacy but it does NOT allow it to be optional.  In SILC the security
   cannot be turned off, as it would create severe security problems.  In fact
   using encrypted and authenticated messages, and non-secured message in the
   same network could render to network insecure as it would be suspectible
   to attacks such as chosen ciphertext attacks and adaptive chosen ciphertext
   attacks (among others).  The SILC Project takes a clear stand on this issue,
   and objects that such requirement is included in RFC 2779.

   Having said that, SILC protocol lists encryption and authentication algorithms
   named "none".  These are algorithms that would not encrypt or authenticate
   messages.  However, specification clearly states that these should be used
   only in special debugging mode, and not in normal operations.  Practical



Riikonen                                                        [Page 7]

Internet Draft                                              NOT RELEASED


   implementation would not allow these.


- Common Presence Format

   From RFC 2779:

      3.1.1. All ENTITIES MUST produce and consume at least a common base
      format for PRESENCE INFORMATION.

   This is ensured by the servers, and all users always consume "common base"
   information for presence (it is the user mode which provides basic
   presence information for all users).


      3.1.2. The common presence format MUST include a means to uniquely
      identify the PRESENTITY whose PRESENCE INFORMATION is reported.

   As all clients has unique Client ID (eqv. PRESENTITY) that can be mapped
   to IDENTIFIER.  Additionally, protocol allows the use of public key
   or certificate fingerprints to map the information.  All reported
   notifications always explicitly state the target.  User online attributes
   may also be digitally signed [SILC5].


      3.1.3. The common presence format MUST include a means to encapsulate
      contact information for the PRESENTITY’s PRINCIPAL (if applicable),
      such as email address, telephone number, postal address, or the like.

   The user online attributes allows this information to be encapsulated [SILC5].


      3.1.4. There MUST be a means of extending the common presence format
      to represent additional information not included in the common
      format, without undermining or rendering invalid the fields of the
      common format.

   The user online attributes allows additional information, that may be
   actually anything to be included in the information, without undermining
   or rendering invalid the fields of the common format [SILC5].


      3.1.6. The presence format SHOULD be based on IETF standards such as
      vCard [RFC 2426] if possible.

   The vCard standard RFC 2426 is used in [SILC5].





Riikonen                                                        [Page 8]

Internet Draft                                              NOT RELEASED


- Presence Lookup and Notification

   From RFC 2779:

      3.2.1. A FETCHER MUST be able to fetch a PRESENTITY’s PRESENCE
      INFORMATION even when the PRESENTITY is OUT OF CONTACT.

   Users may detach from the network (OUT OF CONTACT), and their information
   still can be fetched in the network.


      3.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a
      PRESENTITY’s PRESENCE INFORMATION, even when the PRESENTITY is OUT OF
      CONTACT.

   It is possible to start watching users that are OUT OF CONTACT.


      3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY’s
      PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the
      PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER,
      unless prevented by the PRESENTITY´s ACCESS RULES.

   When basic presence information changes the notification is delivered
   to watchers.  If the optional user online attributes [SILC5] changes,
   it is not guaranteed that a notification would be delivered.


      3.2.4. The protocol MUST provide a mechanism for detecting when a
      PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.

   When user detaches or otherwise leaves (OUT OF CONTACT), it is notified
   to all watchers.


      3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER
      gracefully telling the service that it will no longer be in
      communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT
      due to unanticipated failures.

   No such dependecy is expected.  SILC is allowed to work also on such
   transports that are unreliable.


- Presence Caching and Replication

   From RFC 2779:




Riikonen                                                        [Page 9]

Internet Draft                                              NOT RELEASED


      3.3.1. The protocol MUST include mechanisms to allow PRESENCE
      INFORMATION to be cached.

      3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE
      INFORMATION to be updated when the master copy changes.

      3.3.3 The protocol caching facilities MUST NOT circumvent established
      ACCESS RULES or restrict choice of authentication/encryption
      mechanisms.

   These are mainly implementation issues.  The specification states that
   implementations MAY cache the information.  Practical server implementation
   would cache especially the user online attributes in case the user goes
   offline.  Updating the cache is left to the implementation.  This is mainly
   considered to be implementation issue in SILC.  If clients want to cache
   information, it is clearly implementation issue.


- Performance

   From RFC 2779:

      3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any
      SUBSCRIBER to that information MUST be notified of the changed
      information rapidly, except when such notification is entirely
      prevented by ACCESS RULES. This requirement is met if each
      SUBSCRIBER’s NOTIFICATION is transported as rapidly as an INSTANT
      MESSAGE would be transported to an INSTANT INBOX.

   When the status changes the notification is sent immediately and is
   delivered as rapidly as any other message would be delivered.  The
   access rules allowed by default protocol (without protocol services) are
   naturally in effect [SILC2].


- Common Message Format

   From RFC 2779:

      4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST
      implement at least a common base format for INSTANT MESSAGES.

   Wihtout implementing common base format, though no such this is defined
   in SILC, would prevent sending any messages.  In SILC implementing
   the Message Payload [SILC2] and all security features [SILC1] would be
   regarded as the common base format.





Riikonen                                                       [Page 10]

Internet Draft                                              NOT RELEASED


      4.1.2. The common base format for an INSTANT MESSAGE MUST identify
      the sender and intended recipient.

   Message Payload defines this [SILC2].


      4.1.3. The common message format MUST include a return address for
      the receiver to reply to the sender with another INSTANT MESSAGE.

   Message Payload defines this [SILC2].


      4.1.4. The common message format SHOULD include standard forms of
      addresses or contact means for media other than INSTANT MESSAGES,
      such as telephone numbers or email addresses.

   No such information is included in Message Payload.  However, Message
   Payload can be augmented very easily by using Message Flags [SILC2].


      4.1.5. The common message format MUST permit the encoding and
      identification of the message payload to allow for non-ASCII or
      encrypted content.

   Message Payload allows this [SILC2].  In SILC it is possible to send
   any kind of messages.  The Message Payload utilizes the MIME standard
   to define what the payload includes as a message.  This allows sending
   messages such as images, sound, video/audio stream, etc [SILC6].


      4.1.6. The protocol must reflect best current practices related to
      internationalization.

      4.1.7. The protocol must reflect best current practices related to
      accessibility.

   As the message in Message Payload can be anything that can be explicitly
   identified, these requirements are met.


      4.1.8. The working group MUST define the extension and registration
      mechanisms for the message format, including new fields and new
      schemes for INSTANT INBOX ADDRESSES.

      4.1.9. The working group MUST determine whether the common message
      format includes fields for numbering or identifying messages. If
      there are such fields, the working group MUST define the scope within
      which such identifiers are unique and the acceptable means of



Riikonen                                                       [Page 11]

Internet Draft                                              NOT RELEASED


      generating such identifiers.

   Number and names defined in SILC specifications are to be registered
   in IANA.

      4.1.10. The common message format SHOULD be based on IETF-standard
      MIME [RFC 2045].

   The Message Payload [SILC2] specificly defines the use of MIME [SILC6].


- Reliability

   From RFC 2779:

      4.2.1. The protocol MUST include mechanisms so that a sender can be
      informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons
      for failure.  The working group must determine what mechanisms apply
      when final delivery status is unknown, such as when a message is
      relayed to non-IMPP systems.

   The SILC protocol supports acknowledgement messages [SILC6] by default
   utilized in the Message Payload [SILC2].


- Performance

   From RFC 2779:

      4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid
      to allow for comfortable conversational exchanges of short messages.

   Practical implementations of the SILC protocol has proved that this
   requirement is met.


- Presence Format

   From RFC 2779:

      4.4.1. The common presence format MUST define a minimum standard
      presence schema suitable for INSTANT MESSAGE SERVICES.

      4.4.2. When used in a system supporting INSTANT MESSAGES, the common
      presence format MUST include a means to represent the STATUS
      conditions OPEN and CLOSED.

      4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to



Riikonen                                                       [Page 12]

Internet Draft                                              NOT RELEASED


      messaging or communication modes other than INSTANT MESSAGE SERVICES.

   In SILC finding equivalent terminology is again hard.  The basic status
   in SILC does not include any OPEN or CLOSED status types.  These can be
   easily considered to be implementation specific issues.  However, if presence
   NORMAL can be considered to be OPEN and DETACHED (OUT OF CONTACT) can be
   considered to be CLOSED then these requirements are met by default.


- Requirements related to SUBSCRIPTIONS

   From RFC 2779:

      When A establishes a SUBSCRIPTION to B’s PRESENCE INFORMATION:

      5.1.1. The protocol MUST provide A means of identifying and
      authenticating that the PRESENTITY subscribed to is controlled by B.

   This can be identified and authenticated either by IDENTIFY or WHOIS
   commands.


      5.1.2. If A so chooses, the protocol SHOULD NOT make A’s SUBSCRIPTION
      to B obvious to a third party C.

   In SILC C will not know from any protocol action of A’s SUBSCRIPTION to B.


      5.1.3. The protocol MUST provide B with means of allowing an
      unauthenticated subscription by A.

   Watching in SILC does not require authentication from the watchee.


      5.1.4. The protocol MUST provide A means of verifying the accurate
      receipt of the content B chooses to disclose to A.

   The B may or may not choose to digitally sign the information for A
   to verify.  A third party, server, MAY also digitally sign the information
   in some implementations and networks.


      5.1.5. B MUST inform A if B refuses A’s SUBSCRIPTION. Note that B may
      choose to accept A’s SUBSCRIPTION, but fail to deliver any
      information to it (so-called "polite blocking"). See 5.1.15.

   In SILC authentication for subscrition is not required.  B may reject
   watching, however this is silent and A does not receive any notification



Riikonen                                                       [Page 13]

Internet Draft                                              NOT RELEASED


   of the fact.  However, A can get that status (of the fact that B rejects
   watching) by using WHOIS command.


      5.1.6. The protocol MUST NOT let any third party C force A to
      subscribe to B’s PRESENCE INFORMATION without A’s consent.

   No forceful watching in SILC is possible.


      5.1.7. A MUST be able to cancel her SUBSCRIPTION to B’s PRESENCE
      INFORMATION at any time and for any reason.  When A does so, the
      PRESENCE SERVICE stops informing A of changes to B’s PRESENCE
      INFORMATION.

   Cancelling watching is a default feature in WATCH command.


      5.1.8. The protocol MUST NOT let an unauthorized party C cancel A’s
      SUBSCRIPTION to B.

   No forceful cancelling of watching is possible in SILC.


      5.1.9. If A’s SUBSCRIPTION to B is cancelled, the service SHOULD
      inform A of the cancellation.

   Notification of the cancelling is sent to the A as command reply.


      5.1.10. A SHOULD be able to determine the status of A’s SUBSCRIPTION
      to B, at any time.

   There is only two statuses of watching in SILC: A is watching B,
   or A is not watching B.  No other intermediate status exist.


      5.1.11. The protocol MUST provide B means of learning about A’s
      SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION
      and afterwards.

      5.1.12. The protocol MUST provide B means of identifying and
      authenticating the SUBSCRIBER’s PRINCIPAL, A.

      5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL
      from subscribing.

      5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS



Riikonen                                                       [Page 14]

Internet Draft                                              NOT RELEASED


      from subscribing.

      5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE
      to deny A’s subscription while appearing to A as if the subscription
      has been granted (this is sometimes called "polite blocking").  The
      protocol MUST NOT mandate the PRESENCE SERVICE to service
      subscriptions that are treated in this manner.

      5.1.16. B MUST be able to cancel A’s subscription at will.

   As watching in SILC does not require authentication no such features
   exist in SILC.  A protocol service can allow these, with the additional
   features of limiting who can watch the user.

   In SILC the feature of watching matches closest the definition of
   SUBSCRIPTION as defined in RFC 2778.  However, this is traditional view
   of Instant Messaging protocols of subcription.  In SILC the watching is
   just means of tracking a user’s status in the network.  The WHOIS command
   provides powerful means of retrieving information about the user.  In this
   case also implementations may set any kind of limits (limits that meet the
   above requirements) on the use of that information.  It is for this reason
   quite hard to make one-to-one mapping of watching feature in SILC and
   the these requirements in RFC 2779.  In short, SILC supports all the
   features that are listed in above requirements, but they are not
   necessarily tied explicitly to only watching or SUBSCRIPTION as defined
   in RFC 2778, but are more generic in nature.  Many of the access control
   features are left for implementation, as defining them only to protocol
   limits the future needs on access control significatly.  Implementation
   however can be changed in the future more easily than the actual protocol.


      5.1.17. The protocol MUST NOT require A to reveal A’s IP address to
      B.

      5.1.18 The protocol MUST NOT require B to reveal B’s IP address to A.

   No IP addresses are revealed in wacthing in SILC.


- Requirements related to NOTIFICATION

   From RFC 2779:

      When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to
      another PRINCIPAL A:

      5.2.1. The protocol MUST provide means of ensuring that only the
      PRINCIPAL A being sent the NOTIFICATION by B can read the



Riikonen                                                       [Page 15]

Internet Draft                                              NOT RELEASED


      NOTIFICATION.

      5.2.2. A should receive all NOTIFICATIONS intended for her.

   All notification messages (NOTIFY packet) in addition of any other
   message is always guaranted by encryption and authentication and explicit
   destination to be available only for the intended recipient.


      5.2.3. It MUST be possible for B to prevent A from receiving
      notifications, even if A is ordinarily permitted to see such
      notifications.  It MUST be possible for B to, at its choosing, notify
      different subscribers differently, through different notification
      mechanisms or through publishing different content. This is a
      variation on "polite blocking".

   The B may reject watching him in the SILC network.  In this regard B prevents
   others receiving the notification.  Using user online attributes [SILC5]
   B can decide (in implementation) what information to send to what user.


      5.2.4. The protocol MUST provide means of protecting B from another
      PRINCIPAL C "spoofing" notification messages about B.

   No third party is able to spoof or impersonate B in the network or send
   forged notifications.  Security is the principal feature of SILC and
   all security means possible are taken to prevent any wrong doing in the
   network.


      5.2.5. The protocol MUST NOT require that A reveal A’s IP address to
      B.

      5.2.6. The protocol MUST NOT require that B reveal B’s IP address to
      A.

   No IP addresses are revealed in notifying in SILC.


- Requirements related to receiving a NOTIFICATION

   From RFC 2779:

      When a PRINCIPAL A receives a notification message from another
      principal B, conveying PRESENCE INFORMATION,

      5.3.1. The protocol MUST provide A means of verifying that the
      presence information is accurate, as sent by B.



Riikonen                                                       [Page 16]

Internet Draft                                              NOT RELEASED


   The B may or may not choose to digitally sign the information for A
   to verify.  A third party, server, MAY also digitally sign the information
   in some implementations and networks.


      5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS
      from entities she has subscribed to.

   Watching notifications may be only sent to users that are watching, and
   notifications about only the users they are wathing [SILC2].


      5.3.3. The protocol MUST provide A means of verifying that the
      notification was sent by B.

   The notifications are not sent by clients, they are sent by servers.
   However, the notification clearly states, and includes the Client ID
   of the client that the notification is about.


- Requirements related to INSTANT MESSAGES

   From RFC 2779:

      When a user A sends an INSTANT MESSAGE M to another user B,

      5.4.1. A MUST receive confirmation of non-delivery.

   A NOTIFY packet is received if error occurred sending message [SILC1], [SILC2].


      5.4.2. If M is delivered, B MUST receive the message only once.

   This is requirement in SILC protocol.


      5.4.3. The protocol MUST provide B means of verifying that A sent the
      message.

   There are several ways this can be done.  a) if keys are shared by the
   two users (in private messages) then MAC guarantees this.  b) if message
   is sent to channel, the MAC guarantees this.  c) if Message Payload includes
   digital signature it can guarantee this.  Both private and channel messages
   may be digitally signed.


      5.4.4. B MUST be able to reply to the message via another instant
      message.



Riikonen                                                       [Page 17]

Internet Draft                                              NOT RELEASED


   Naturally protocol allows conversation between users.


      5.4.5. The protocol MUST NOT always require A to reveal A’s IP
      address, for A to send an instant message.

   No IP addresses are revealed when sending messages in SILC.


      5.4.6. The protocol MUST provide A means of ensuring that no other
      PRINCIPAL C can see the content of M.

   Due to the mandatory message encryption and authentication the protocol
   ensures that no third party is able to see any messages.


      5.4.7. The protocol MUST provide A means of ensuring that no other
      PRINCIPAL C can tamper with M, and B means to verify that no
      tampering has occurred.

   Due to the mandatory message authentication and optional digital signatures
   in messages ensure that no third party may tamper any messages.


      5.4.8. B must be able to read M.

   B is able to read the message if B has the key to decrypt the message.
   If B is joined on channel then at all times B has the channel key (unless
   channel private keys are used, in which case B may not know the key) and
   is able to decrypt messages.  In private messages between users either
   the session key is used or specific key is negotiated between users.
   It would be considered network, protocol or implementation error if user
   would not have the key to ligitimately received message.


      5.4.9. The protocol MUST allow A to sign the message, using existing
      standards for digital signatures.

   Digital signatures are allowed to all kinds of messages in SILC.  The
   Message Payload [SILC2] allows this.


      5.4.10. B MUST be able to prevent A from sending him messages

   In SILC it is possible to prevent message sending in many ways.  For example
   on channel it is possible to reject all messages, messages from normal users,
   messages from operators, messages from robots etc.  In private messages it
   is possible to reject unauthorized messages (messages without explicitly



Riikonen                                                       [Page 18]

Internet Draft                                              NOT RELEASED


   negotiated key).  Additional protocol service could allow even more finer
   grained limitations.  However, it is best to leave more advanced ignoring
   features for the implementation.


3. Conclusions

   Biggest difference between the SILC protocol and the RFC 2779 requirements
   is the lack of common terminology.  This is understandable because SILC
   was not developed by the IMPP WG or specificly for RFC 2779.  SILC was
   developed before the IMPP WG existed or had released the RFC 2779.  In
   this memo we tried to explain some of the terminology used in RFC 2779
   with SILC terminology.  For the most part we are able to find equivalent
   terminology.

   The issue where SILC cannot be said to fully conform RFC 2779 is the
   use of term SUBSCRIPTION.  The SUBSCRIPTION can be safely assumed to
   include authentication and maybe even registration.  These are fundamental
   differences in SILC and in these cases SILC does not conform to RFC 2779.
   However, in terms of features that the SUBSCRIPTION and the services
   it is used for we can find equivalent features in SILC, that indeed does
   conform with RFC 2779.  In many cases, the access control issues are
   not defined explicitly in the same scope as they are assumed by RFC 2779.
   Furthermore, SILC assume most of the access control issues to be
   implementation issues, as that practically allows more detailed and better
   access control than only few basic access control limits defined in
   the protocol.  It is our feel that generally access control is best
   left for implementation.  Having said that, SILC can be augmented to
   support them in protocol level as well, by using protocol services.  From
   IETF procedures point of view, this would require introducing new document
   for each of the service to describe the details of the service.  It also
   must be noted that use of services are optional in SILC.

   The second important issue where SILC can be safely said to not conform
   RFC 2779 is the requirement 2.5.4 which would allow the protocol to make
   security optional feature.  In our view, this would be a mistake that in
   the long run would cause severe security issues in the network.

   It cannot be said that SILC fully conforms to RFC 2779, but can be said
   that it meets or optional features of SILC protocol can be used to meet
   the requirements.  In some security issues SILC goes beyond the
   requirements and is very strict.  In our view this is only a good thing.


4 Security Considerations

   TBD




Riikonen                                                       [Page 19]

Internet Draft                                              NOT RELEASED


5 References

   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
                Protocol Specification", Internet Draft, May 2002.

   [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
                May 2002.

   [SILC3]      Riikonen, P., "SILC Key Exchange and Authentication
                Protocols", Internet Draft, May 2002.

   [SILC4]      Riikonen, P., "SILC Commands", Internet Draft, May 2002.

   [SILC5]      Riikonen, P., "User Online Presence and Information Attributes",
                Febraury 2004.

   [SILC6]      Riikonen, P., "SILC Message Flag Payloads", December 2003.


6 Author’s Address

   Pekka Riikonen
   Snellmaninkatu 34 A 15
   70100 Kuopio
   Finland

   EMail: priikone@iki.fi


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be



Riikonen                                                       [Page 20]

Internet Draft                                              NOT RELEASED


   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.











































Riikonen                                                       [Page 21]
