8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-flags-payloads-03.txt 17 June 2003
20 Expires: 17 December 2003
25 SILC Message Flag Payloads
26 <draft-riikonen-flags-payloads-03.txt>
31 This document is an Internet-Draft and is in full conformance with
32 all provisions of Section 10 of RFC 2026. Internet-Drafts are
33 working documents of the Internet Engineering Task Force (IETF), its
34 areas, and its working groups. Note that other groups may also
35 distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
48 The distribution of this memo is unlimited.
54 This memo describes the data payloads associated with the SILC Message
55 Flags, as defined in the SILC Packet Protocol specification [SILC2]. The
56 purpose of the Message Flags is to augment the function of the Message
57 Payload used to send both private and channel messages, by allowing the
58 sender to tell the receiver what type of data the payload includes, and
59 how the data should be processed. Some of the Message Flags may define
60 additional payloads to be associated with the flag, and this memo
61 describes these payloads.
74 1 Introduction .................................................. 2
75 1.1 Requirements Terminology .................................. 2
76 2 SILC Message Flags ............................................ 2
77 3 SILC Message Flag Payloads .................................... 3
78 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. 3
79 3.2 SILC_MESSAGE_FLAG_REPLY ................................... 3
80 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. 4
81 3.4 SILC_MESSAGE_FLAG_DATA .................................... 6
82 3.5 SILC_MESSAGE_FLAG_ACK ..................................... 7
83 4 Security Considerations ....................................... 7
84 5 References .................................................... 8
85 6 Author's Address .............................................. 8
86 7 Full Copyright Statement ...................................... 9
92 The Secure Internet Live Conferencing [SILC1] supports sending binary
93 messages between users in the network. To make the data sending, and
94 processing at the receiver's end as simple as possible the SILC defines
95 Message Flags to the Message Payload [SILC2] that is used to send private
96 and channel messages, which can help the receiver to decide how the data
97 is encoded, and how it should be interpreted. Some of the Message Flags
98 may define additional payloads to be associated with the flag, but the
99 [SILC2] does not define them. This memo defines the payloads for those
100 Message Flags that was marked to include additional payloads in [SILC2].
102 By defining the payloads for the Message Flags the Message Payload
103 can be augmented to support any kind of data, which can be easily
104 interpreted at the receiver end. For example, it would be possible to
105 send audio stream, video stream, image files and HTML pages as messages,
106 and the receiver can either choose to ignore the message or to process
107 it, or to perhaps pass the message to some application for processing.
108 Without specific payloads for Message Flags it is almost impossible for
109 the receiver to interpret binary data from the payload.
113 1.1 Requirements Terminology
115 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
116 MAY, and OPTIONAL, when they appear in this document, are to be
117 interpreted as described in [RFC2119].
123 The Message Flags was added to the SILC protocol for the reason that SILC
124 provides sending binary data as messages between users, and entities in
125 the network, and interpreting pure binary data is almost impossible.
126 With the flags the purpose, the reason, and the way the message is
127 supposed to be interpreted can be told to the recipient. Other
128 conferencing protocols which are usually ASCII based protocols do not have
129 such problems since they do not generally support sending of binary data
130 at all, or require encoding of the data before it can be sent over the
133 The Message Payload in SILC can have flags that can augment the function
134 of the payload. The flags can tell for example that the message is a
135 request, or a reply to an earlier received request. They can tell that
136 the message is some action that the sender is performing, or they can tell
137 that the message is an auto reply, or that it is explicitly digitally
138 signed by the sender.
140 The problem of Message Flags is that the space for flags mask is only 16
141 bits, so there is a limited number of flags available. For this reason
142 having a flag that defines a generic way of sending any kind of data as
143 a message, and can be easily interpreted at the receiver's end is important.
144 For this reason the flag SILC_MESSAGE_FLAG_DATA was added to the protocol
145 which can represent any data. This memo describe how this flag is used
146 and how the associated payload is constructed and processed. This memo
147 also describes payloads for all the other flags that can have associated
152 3 SILC Message Flag Payloads
154 The [SILC2] defines the flags which may have associated payloads. This
155 section will list these flags and define the payloads.
159 3.1 SILC_MESSAGE_FLAG_REQUEST
161 Currently this flag can be used in the context of application specific,
162 service specific or vendor specific requests, and the data payload type is
163 dependent of this context. Therefore, payload is not defined for this
164 flag in this memo. This flag may also be masked with some other flag in
165 the message payload, including with some other flag that defines
170 3.2 SILC_MESSAGE_FLAG_REPLY
172 Currently this flag can be used in the context of application specific,
173 service specific or vendor specific replies, and the data payload type is
174 dependent of this context. Therefore, payload is not defined for this
175 flag in this memo. This flag may also be masked with some other flag in
176 the message payload, including with some other flag that defines
181 3.3 SILC_MESSAGE_FLAG_SIGNED
183 This flag is used to tell the recipient that the sent message is
184 digitally signed by the sender, and that the recipient should verify
185 the signature to verify the true authenticity of the received message.
186 All message payloads in SILC provides message authentication code (MAC)
187 which can be used to verify that the sender produced and sent the message.
188 Even so, signing messages digitally can be used to verify the authenticity
189 of the message when recipient trusts the sender and to provide
192 This flag defines a payload which is used to deliver the actual message,
193 sender's public key and the digital signature. The payload for
194 SILC_MESSAGE_FLAG_SIGNED is as follows:
199 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
200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
202 ~ Start of Message Payload ~
204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
206 ~ Public Key Payload ~
208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
209 | Signature Data Length | |
210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
226 Figure 1: SILC_MESSAGE_FLAG_SIGNED Payload
230 o Start of Message Payload (variable length) - This is the
231 start of the Message Payload without the IV and MAC fields,
232 since those fields are appended at the end of this payload.
234 o Public Key Payload (variable length) - This includes the
235 Public Key Payload [SILC2] which can be used to deliver the
236 sender's public key (or certificate). It also indicates the
237 type of the public key (or certificate) which the recipient
238 use to identify how the signature must be verified. This
239 payload must always be present but it is not required to
240 include the public key data. The Public Key Type field in
241 the Public Key Payload MUST be set to the correct type of
242 the key, even if the actual public key data is not included.
244 o Signature Data Length (2 bytes) - Indicates the length of
245 the Signature Data field not including any other field.
247 o Signature Data (variable length) - Includes the actual
248 signature data. The signature computation and encoding
249 is key type specific. See [SILC3] for all key types, and
250 their respective references for how to compute and encode
253 o Initial Vector (variable length) - the IV of the Message
254 Payload as defined in [SILC2]. This field is not encrypted.
256 o MAC (variable length) - the MAC of the Message Payload as
257 defined in [SILC2]. The MAC is computed after encryption
258 and after signature computation. All data in the Message
259 Payload and this payload, including the IV field are
260 included in the MAC computation. This field is not
264 How the data is processed before it is signed is key type specific.
265 The actual data that to be signed MUST be the plaintext message
266 payload before encryption. The data to be signed is concatenation
267 of the Start of Message Payload field and the Public Key Payload,
268 in that order. Any other fields are not included for signature data.
269 Before signing, the data is always processed, usually hashed. The
270 hash function to be used is defined in the key type specific
271 definitions. See the key type specific references in [SILC3].
273 If the public key of the sender is included in the payload the
274 recipient SHOULD verify it before accepting the public key. Recipient
275 SHOULD verify the signature before accepting and caching the public key.
276 With certificates the certificate verification may be done before
277 verifying the signature. If the signature verification fails the
278 message should still be displayed. The end user should also be
279 notified about the result of the signature verification.
281 To make the packet size smaller implementations may not want to
282 include the actual public key in all signed messages. Sending the
283 public key in the first message is usually sufficient. Subsequent
284 messages may include empty Public Key Payload with an indication of
287 Implementations that do not support this flag can still process the
288 message payload in normal manner. These implementations merely parse
289 the decrypted payload in normal manner and ignore the extra data in
290 the payload. They can do this by extracting the MAC and the IV from
291 the end of the data buffer and thus ignoring the data between start of
292 the Message Payload and the Initial Vector field.
294 This flag MAY be masked with any other Message Flag including those that
295 define additional payloads. As long as the defined payload resides in
296 the data area of the message payload this flag may be masked with the
301 3.4 SILC_MESSAGE_FLAG_DATA
303 This flag is used to represent any data as a message in the way that it
304 can be easily interpreted by the recipient. This flag is used to send
305 MIME objects as messages from the sender to the receiver. The MIME as
306 defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is
307 well established protocol for sending different kind of data with many
308 applications and protocols. It support dozens of different media types
309 and encodings, and for this reason is ideal for sending data in SILC
310 message payloads as well.
312 When the receiver has checked that the message payload includes the
313 SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header.
314 It would also be possible to pass the message to some application which
315 can already interpret MIME objects. If the receiver does not support the
316 media type received in the MIME header, it SHOULD be treated as
317 "application/octet-stream". The receiver MAY also ignore and discard
318 messages that it does not support.
320 The MIME header MUST be at the start of the data area of the Message
321 Payload. The MIME header received in the data area of the payload SHOULD
322 have the MIME-Version field at first and then Content-Type field. The
323 MIME-Version field is not required to be present in each body part of
324 multipart entity. Additionally the header MAY also include any other
325 MIME compliant headers. The character encoding for the MIME Header
326 strings inside the message payload is US-ASCII, as defined in [RFC2045].
327 The actual MIME object may define additional character sets or encodings
328 for the data it delivers.
330 Hence, the MIME Header in the message payload may be as follows:
334 MIME-Version: 1.0\\r\\n
335 Content-Type: discrete/composite\\r\\n
336 Content-Transfer-Encoding: binary\\r\\n
340 The Content-Transfer-Encoding field behaves as defined in [RFC2045] and
341 defines the encoding of the data in the MIME object. The preferred data
342 encoding with SILC is "binary". However, many MIME media types defines
343 their preferred encoding and they may be used if binary encoding is not
346 When sending large amounts of traffic or large files as MIME objects the
347 limits of the SILC Packet needs to be taken into consideration. The
348 maximum length of SILC Packet is 2^16 bytes, and larger messages would
349 need to be fragmented. MIME provides way of fragmenting and reassembling
350 messages, and it is to be done with SILC as defined in [RFC2046]. The
351 MIME fragmentation is defined for gateway usage, but in case of SILC the
352 sender (for example, a client) may also start sending fragmented MIME
355 This flag SHOULD NOT be masked with some other Message Flag that defines
356 payloads for message data. Generally this sort of setting would be
357 impossible for the receiver to interpret. However, flags that does not
358 define any specific payloads MAY be masked with this flag as well. For
359 example, this flag could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
360 It also can be masked with SILC_MESSAGE_FLAG_SIGNED flag since it does not
361 define data specific payload.
365 3.5 SILC_MESSAGE_FLAG_ACK
367 This flag is used to send acknowledgement messages. When sender of a
368 message requires the recipient to acknowledge the received message, the
369 sender MUST set the SILC_MESSAGE_FLAG_ACK and MUST NOT set the
370 SILC_MESSAGE_FLAG_NOREPLY. When a message with this flag set is received
371 an acknowledgement message MUST be sent back. In the acknowledgement
372 message the sender MUST set the SILC_MESSAGE_FLAG_ACK,
373 SILC_MESSAGE_FLAG_AUTOREPLY and SILC_MESSAGE_FLAG_NOREPLY flags. The
374 receiver MUST NOT acknowledge the acknowledgement message. This flag
375 MUST NOT be used with channel messages, and MUST be ignored if received
376 in a channel message.
378 The construction of the acknowledgement reply message is normal Message
379 Payload where the Message Data field includes a computed MAC of the
380 original received Message Payload MAC. Hence, the MAC is computed as
384 ack_mac = mac(key, MAC);
387 Where the 'key' is the MAC key used to compute MACs for the Message
388 Payload, and the 'MAC' is the MAC taken from the received Message Payload.
389 The 'ack_mac' is placed in the Message Data field in a new Message
390 Payload, and the payload is encrypted in normal manner. After this the
391 message is sent back to the original sender of the message.
393 The receiver of the acknowledgement reply message SHOULD verify the MAC
394 from the Message Data field to assure that acknowledgement was received to
395 an earlier sent message. Implementation needs to keep the old message
396 MACs stored until acknowledgement is received. It is left for
397 implementation to decide any possible retransmission strategy if
398 acknowledgement messages are not received.
402 4 Security Considerations
404 In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special
405 attention to the security implications of any media type that can cause
406 the remote execution of any actions in the receiver's environment. The
407 [RFC2046] and [RFC2048] discusses more MIME specific security
408 considerations. Even though SILC provides secured messages, in case of
409 MIME which can be used to transfer files and documents which are stored in
410 the receiver's local environment, securing separately the MIME object may
411 be desired. For example, augmenting the MIME support in SILC messages to
412 support S/MIME may be desired in some implementations.
420 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
421 Protocol Specification", Internet Draft, June 2003.
423 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
426 [SILC3] Riikonen, P., "SILC Key Exchange and Authentication
427 Protocols", Internet Draft, June 2003.
429 [RFC2045] Freed, N., et al., "Multipurpose Internet Mail Extensions
430 (MIME) Part One: Format of Internet Message Bodies",
431 Standards Track, RFC 2045, November 1996.
433 [RFC2046] Freed, N., et al., "Multipurpose Internet Mail Extensions
434 (MIME) Part Two: Media Types", Standards Track, RFC 2045,
437 [RFC2047] Moore K., "MIME (Multipurpose Internet Mail Extensions)
438 Part Three: Message Header Extensions for Non-ASCII Text"
439 Standards Track, RFC 2047, November 1996.
441 [RFC2048] Freed, N., et al., "Multipurpose Internet Mail Extensions
442 (MIME) Part Four: Registration Procedures", Standards
443 Track, RFC 2048, November 1996.
445 [RFC2049] Freed, N., et al., "Multipurpose Internet Mail Extensions
446 (MIME) Part Five: Conformance Criteria and Examples",
447 Standards Track, RFC 2049, November 1996.
449 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
450 Requirement Levels", BCP 14, RFC 2119, March 1997.
458 Snellmaninkatu 34 A 15
462 EMail: priikone@iki.fi
468 7 Full Copyright Statement
470 Copyright (C) The Internet Society (2003). All Rights Reserved.
472 This document and translations of it may be copied and furnished to
473 others, and derivative works that comment on or otherwise explain it
474 or assist in its implementation may be prepared, copied, published
475 and distributed, in whole or in part, without restriction of any
476 kind, provided that the above copyright notice and this paragraph are
477 included on all such copies and derivative works. However, this
478 document itself may not be modified in any way, such as by removing
479 the copyright notice or references to the Internet Society or other
480 Internet organizations, except as needed for the purpose of
481 developing Internet standards in which case the procedures for
482 copyrights defined in the Internet Standards process must be
483 followed, or as required to translate it into languages other than
486 The limited permissions granted above are perpetual and will not be
487 revoked by the Internet Society or its successors or assigns.
489 This document and the information contained herein is provided on an
490 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
491 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
492 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
493 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
494 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.