X-Git-Url: http://git.silcnet.org/gitweb/?p=website.git;a=blobdiff_plain;f=docs%2Fprotocol%2Fdraft-riikonen-silc-flags-payloads-04.txt;fp=docs%2Fprotocol%2Fdraft-riikonen-silc-flags-payloads-04.txt;h=158f3cc35eb1e0986f92cb36ffb2678416a82e68;hp=0000000000000000000000000000000000000000;hb=4deb84ef17e789147fa9f7f35a302c5a38999817;hpb=4c0f02a06b6cd767a24041e0d37e95945e294623 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 + + +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] +