8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-flags-payloads-01.txt XXX
20 Expires: 20 April 2003
25 SILC Message Flag Payloads
26 <draft-riikonen-flags-payloads-01.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 Internet Draft [SILC2]. The
56 purpose of the Message Flags is to augment the function of the Private
57 Message Payload and Channel Message Payload by allowing the sender to
58 tell the receiver what type of data the payload includes, and how the
59 data should be processed. Some of the Message Flags may define additional
60 payloads to be associated with the flag, and this memo describes these
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 .................................... 4
82 4 Security Considerations ....................................... 5
83 5 References .................................................... 5
84 6 Author's Address .............................................. 6
90 The Secure Internet Live Conferencing [SILC1] supports sending binary
91 messages between users in the network. To make the data sending, and
92 processing at the receiver's end as simple as possible the SILC defines
93 Message Flags to the Private Message Payload and Channel Message Payload
94 [SILC2], which can help the receiver to decide how the data is encoded,
95 and how it should be interpreted. Some of the Message Flags may define
96 additional payloads to be associated with the flag, but the [SILC2] does
97 not define them. This memo defines the payloads for those Message Flags
98 that was marked to include additional payloads in [SILC2].
100 By defining the payloads for the Message Flags the SILC message payloads
101 can be augmented to support any kind of data, which can be easily
102 interpreted at the receiver end. For example, it would be possible to
103 send audio stream, video stream, image files and HTML pages as messages,
104 and the receiver can either choose to ignore the message or to process
105 it, or to perhaps pass the message to some application for processing.
106 Without specific payloads for Message Flags it is almost impossible for
107 the receiver to interpret binary data from the payload.
111 1.1 Requirements Terminology
113 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
114 MAY, and OPTIONAL, when they appear in this document, are to be
115 interpreted as described in [RFC2119].
121 The Message Flags was added to the SILC protocol for the reason that SILC
122 provides sending binary data as messages between users, and entities in
123 the network, and interpreting pure binary data is almost impossible.
124 With the flags the purpose, the reason, and the way the message is
125 supposed to be interpreted can be told to the recipient. Other
126 conferencing protocols which are usually ASCII based protocols do not have
127 such problems since they do not generally support sending of binary data
128 at all, or require encoding of the data before it can be sent over the
131 SILC Private Message Payload and Channel Message Payload can have flags
132 that can augment the function of the payload. The flags can tell for
133 example that the message is a request, or a reply to an earlier received
134 request. They can tell that the message is some action that the sender
135 is performing, or they can tell that the message is an auto reply, or
136 that it is explicitly digitally signed by the sender.
138 The problem of Message Flags is that the space for flags mask is only 16
139 bits, so there is a limited number of flags available. For this reason a
140 flag that defines some generic way of sending any kind of data as a
141 message, and that it can be easily interpreted at the receiver's end is
142 important. For this reason the flag SILC_MESSAGE_FLAG_DATA was added to
143 the protocol which can represent any data. This memo describe how this
144 flag is used and how the associated payload is constructed and processed.
145 This memo also describes payloads for all the other flags that can have
150 3 SILC Message Flag Payloads
152 The [SILC2] defines the flags which may have associated payloads. This
153 section will list these flags and define the payloads.
157 3.1 SILC_MESSAGE_FLAG_REQUEST
159 Currently this flag can be used in the context of application specific,
160 service specific or vendor specific requests, and the data payload type is
161 dependent of this context. Therefore, payload is not defined for this
162 flag in this memo. This flag may also be masked with some other flag in
163 the message payload, including with some other flag that defines
168 3.2 SILC_MESSAGE_FLAG_REPLY
170 Currently this flag can be used in the context of application specific,
171 service specific or vendor specific replies, and the data payload type is
172 dependent of this context. Therefore, payload is not defined for this
173 flag in this memo. This flag may also be masked with some other flag in
174 the message payload, including with some other flag that defines
179 3.3 SILC_MESSAGE_FLAG_SIGNED
181 This flag is used to tell the recipient that the sent message is
182 digitally signed by the sender, and that the receipient should verify
183 the signature to verify the true authenticity of the received message.
184 All message payloads in SILC provides message authentication code (MAC)
185 which can be used to verify that the sender produced and sent the message.
186 Even so, signing messages digitally can be used to verify the authenticity
187 of the message when recipient trusts the sender.
189 This flag defines a payload which is used to deliver the actual message,
190 sender's public key and the digital signature. The payload for
191 SILC_MESSAGE_FLAG_SIGNED is as follows:
196 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
197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
203 ~ Public Key Payload ~
205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
206 | Signature Data Length | |
207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
215 Figure 1: SILC_MESSAGE_FLAG_SIGNED Payload
219 o Message Payload (variable length) - This is a message payload
220 consisting of the encrypted message. When this flag is used
221 with channel messages it include Channel Message Payload, and
222 when used with private messages it include Private Message
225 o Public Key Payload (variable length) - This includes the
226 Public Key Payload which can be used to deliver the sender's
227 public key (or certificate). It also indicates the type of the
228 public key (or certificate) which the recipient use to identify
229 how the signature must be verified. This payload must always
230 be present but it is not required to include the public key
231 data. The Public Key Type field in the Public Key Payload
232 MUST be set to the correct type of the key, even if the
233 actual public key data is not included.
235 o Signature Data Length (2 bytes) - Indicates the length of
236 the Signature Data field not including any other field.
238 o Signature Data (variable lenght) - Includes the actual
239 signature data. The signature computation and encoding
240 is key type specific. See [SILC3] for all key types, and
241 their respective references of how to compute and encode
245 How the data is processed before it is signed is key type specific.
246 The actual data that to be signed MUST be the plaintext message
247 payload before encryption. For Channel Message Payload the data to
248 be signed is concatenation of Message Flags, Message Length, Message
249 Data, Padding Length, Padding, Initial Vector fields and the Public
250 Key Payload. Any other field is not included for signature data.
251 For Private Message Payload the data to be signed is concatenation
252 of Message Flags, Message Data Length, Message Data, Padding fields and
253 the Public Key Payload fields. Any other field is not included for
254 signature data. Before signing, the data is always processed, usually
255 hashed. The hash function to be used is defined in the key type
256 specific definitions. See the key type specific references in
259 If the public key of the sender is included in the payload the
260 recipient SHOULD verify before accepting the public key. Recipient
261 SHOULD verify the signature before accepting a public key. With
262 certificates the certificate verification may be done before
263 verifying the signature. If the signature verification fails the
264 message should still be displayed. The end user should also be
265 notified about the result of the signature verification.
267 To make the packet size smaller implementations may not want to
268 include the actual public key in all signed messages. Sending the
269 public key in the first message is usually sufficient. Subsequent
270 messages may include empty Public Key Payload with an indication of
273 Implementations that do not support this flag can still process the
274 message payload in normal manner. These implementations merely ignore
275 rest of the data after the message payload.
277 This flag MAY be masked with any other Message Flag including those that
278 define additional payloads. As long as the defined payload resides in
279 the data area of the message payload this flag may be masked with the
284 3.4 SILC_MESSAGE_FLAG_DATA
286 This flag is used to represent any data as a message in the way that it
287 can be easily interpreted by the recipient. This flag is used to send
288 MIME objects as messages from the sender to the receiver. The MIME as
289 defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is
290 well established protocol for sending different kind of data with many
291 applications and protocols. It support dozens of different media types
292 and encodings, and for this reason is ideal for sending data in SILC
293 message payloads as well.
295 When the receiver has checked that the message payload includes the
296 SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header.
297 It would also be possible to pass the message to some application which
298 can already interpret MIME objects. If the receiver does not support the
299 media type received in the MIME header, it SHOULD be treated as
300 "application/octet-stream". The receiver MAY also ignore and discard
301 messages that it does not support.
303 The MIME header MUST be at the start of the data area of the Private
304 Message Payload or Channel Message Payload. The MIME header received in
305 the data area of the payload SHOULD have the MIME-Version field at first
306 and then Content-Type field. The MIME-Version field is not required to be
307 present in each body part of multipart entity. Additionally the header
308 MAY also include any other MIME compliant headers. The character encoding
309 for the MIME Header strings inside the message payload is US-ASCII, as
310 defined in [RFC2045]. The actual MIME object may define additional
311 character sets or encodings for the data it delivers.
313 Hence, the MIME Header in the message payload may be as follows:
317 MIME-Version: 1.0\\r\\n
318 Content-Type: discrete/composite\\r\\n
319 Content-Transfer-Encoding: binary\\r\\n
323 The Content-Transfer-Encoding field behaves as defined in [RFC2045] and
324 defines the encoding of the data in the MIME object. The preferred data
325 encoding with SILC is "binary". However, many MIME media types defines
326 their preferred encoding and they may be used if binary encoding is not
329 When sending large amounts of traffic or large files as MIME objects the
330 limits of the SILC Packet needs to be taken into consideration. The
331 maximum length of SILC Packet is 2^16 bytes, and larger messages would
332 need to be fragmented. MIME provides way of fragmenting and reassembling
333 messages, and it is to be done with SILC as defined in [RFC2046]. The
334 MIME fragmentation is defined for gateway usage, but in case of SILC the
335 sender may also start sending fragmented MIME objects.
337 This flag SHOULD NOT be masked with some other Message Flag that defines
338 payloads for message data. Generally this sort of setting would be
339 impossible for the receiver to interpret. However, flags that does not
340 define any specific payloads MAY be masked with this flag as well. For
341 example, this flag could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
342 It also can be masked with SILC_MESSAGE_FLAG_SIGNED flag since it does not
343 define data specific payload.
347 4 Security Considerations
349 In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special
350 attention to the security implications of any media type that can cause
351 the remote execution of any actions in the receiver's environment. The
352 [RFC2046] and [RFC2048] discusses more MIME specific security
353 considerations. Even though SILC provides secured messages, in case of
354 MIME which can be used to transfer files and documents which are stored in
355 the receiver's local environment, securing separately the MIME object may
356 be desired. For example, augmenting the MIME support in SILC messages to
357 support S/MIME may be desired in some implementations.
364 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
365 Protocol Specification", Internet Draft, May 2002.
367 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
370 [SILC3] Riikonen, P., "SILC Key Exchange and Authentication
371 Protocols", Internet Draft, May 2002.
373 [RFC2045] Freed, N., et al., "Multipurpose Internet Mail Extensions
374 (MIME) Part One: Format of Internet Message Bodies",
375 Standards Track, RFC 2045, November 1996.
377 [RFC2046] Freed, N., et al., "Multipurpose Internet Mail Extensions
378 (MIME) Part Two: Media Types", Standards Track, RFC 2045,
381 [RFC2047] Moore K., "MIME (Multipurpose Internet Mail Extensions)
382 Part Three: Message Header Extensions for Non-ASCII Text"
383 Standards Track, RFC 2047, November 1996.
385 [RFC2048] Freed, N., et al., "Multipurpose Internet Mail Extensions
386 (MIME) Part Four: Registration Procedures", Standards
387 Track, RFC 2048, November 1996.
389 [RFC2049] Freed, N., et al., "Multipurpose Internet Mail Extensions
390 (MIME) Part Five: Conformance Criteria and Examples",
391 Standards Track, RFC 2049, November 1996.
393 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
394 Requirement Levels", BCP 14, RFC 2119, March 1997.
402 Snellmaninkatu 34 A 15
406 EMail: priikone@iki.fi
408 This Internet-Draft expires 20 April 2003