Network Working Group P. Riikonen Internet-Draft draft-riikonen-silc-rfc2779-00.txt NOT RELEASED Expires: Comparing SILC and RFC 2779 Requirements 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 ascertain 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 ascertain 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 restriction in number of DOMAINS within 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 messages. 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 guaranteed 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 dependency 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. Without 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. Numbers 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 subscription 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. Canceling 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 canceling 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 canceling 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 subscription. 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 significantly. 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 guaranteed 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 watching [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 legitimately 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]