1 .pl 10.0i
2 .po 0
3 .ll 7.2i
4 .lt 7.2i
5 .nr LL 7.2i
6 .nr LT 7.2i
7 .ds LF Riikonen
8 .ds RF FORMFEED[Page %]
9 .ds CF
10 .ds LH Internet Draft
11 .ds RH 7 December 2002
12 .ds CH
13 .na
14 .hy 0
15 .in 0
16 .nf
17 Network Working Group P. Riikonen
18 Internet-Draft
19 draft-riikonen-flags-payloads-02.txt 7 December 2003
20 Expires: 7 May 2003
21
22 .in 3
23
24 .ce 2
25 SILC Message Flag Payloads
26 <draft-riikonen-flags-payloads-02.txt>
27
28 .ti 0
29 Status of this Memo
30
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.
36
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."
41
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
44
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
47
48 The distribution of this memo is unlimited.
49
50
51 .ti 0
52 Abstract
53
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 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.
62
63
64
65
66
67
68
69
70 .ti 0
71 Table of Contents
72
73 .nf
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 4 Security Considerations ....................................... 7
83 5 References .................................................... 7
84 6 Author's Address .............................................. 8
85
86
87 .ti 0
88 1. Introduction
89
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 Message Payload [SILC2] that is used to send private
94 and channel messages, which can help the receiver to decide how the data
95 is encoded, and how it should be interpreted. Some of the Message Flags
96 may define additional payloads to be associated with the flag, but the
97 [SILC2] does not define them. This memo defines the payloads for those
98 Message Flags that was marked to include additional payloads in [SILC2].
99
100 By defining the payloads for the Message Flags the Message Payload
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.
108
109
110 .ti 0
111 1.1 Requirements Terminology
112
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].
116
117
118 .ti 0
119 2 SILC Message Flags
120
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
129 network.
130
131 The Message Payload in SILC can have flags that can augment the function
132 of the payload. The flags can tell for example that the message is a
133 request, or a reply to an earlier received request. They can tell that
134 the message is some action that the sender is performing, or they can tell
135 that the message is an auto reply, or that it is explicitly digitally
136 signed by the sender.
137
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
146 associated payloads.
147
148
149 .ti 0
150 3 SILC Message Flag Payloads
151
152 The [SILC2] defines the flags which may have associated payloads. This
153 section will list these flags and define the payloads.
154
155
156 .ti 0
157 3.1 SILC_MESSAGE_FLAG_REQUEST
158
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
164 additional payload.
165
166
167 .ti 0
168 3.2 SILC_MESSAGE_FLAG_REPLY
169
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
175 additional payload.
176
177
178 .ti 0
179 3.3 SILC_MESSAGE_FLAG_SIGNED
180
181 This flag is used to tell the recipient that the sent message is
182 digitally signed by the sender, and that the recipient 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.
188
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:
192
193 .in 5
194 .nf
195 1 2 3
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
198 | |
199 ~ Start of Message Payload ~
200 | |
201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
202 | |
203 ~ Public Key Payload ~
204 | |
205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
206 | Signature Data Length | |
207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
208 | |
209 ~ Signature Data ~
210 | |
211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
212 | |
213 ~ Initial Vector * ~
214 | |
215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
216 | |
217 ~ MAC * ~
218 | |
219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
220 .in 3
221
222 .ce
223 Figure 1: SILC_MESSAGE_FLAG_SIGNED Payload
224
225
226 .in 6
227 o Start of Message Payload (variable length) - This is the
228 start of the Message Payload without the IV and MAC fields,
229 since those fields are appended at the end of this payload.
230
231 o Public Key Payload (variable length) - This includes the
232 Public Key Payload [SILC2] which can be used to deliver the
233 sender's public key (or certificate). It also indicates the
234 type of the public key (or certificate) which the recipient
235 use to identify how the signature must be verified. This
236 payload must always be present but it is not required to
237 include the public key data. The Public Key Type field in
238 the Public Key Payload MUST be set to the correct type of
239 the key, even if the actual public key data is not included.
240
241 o Signature Data Length (2 bytes) - Indicates the length of
242 the Signature Data field not including any other field.
243
244 o Signature Data (variable length) - Includes the actual
245 signature data. The signature computation and encoding
246 is key type specific. See [SILC3] for all key types, and
247 their respective references of how to compute and encode
248 the signature.
249
250 o Initial Vector (variable length) - the IV of the Message
251 Payload as defined in [SILC2]. This field is not encrypted.
252
253 o MAC (variable length) - the MAC of the Message Payload as
254 defined in [SILC2]. The MAC is computed after encryption
255 and after signature computation. All data in the Message
256 Payload and this payload, including the IV field are
257 included in the MAC computation. This field is not
258 encrypted.
259 .in 3
260
261 How the data is processed before it is signed is key type specific.
262 The actual data that to be signed MUST be the plaintext message
263 payload before encryption. The data to be signed is concatenation
264 of the Start of Message Payload field and the Public Key Payload,
265 in that order. Any other fields are not included for signature data.
266 Before signing, the data is always processed, usually hashed. The
267 hash function to be used is defined in the key type specific
268 definitions. See the key type specific references in [SILC3].
269
270 If the public key of the sender is included in the payload the
271 recipient SHOULD verify it before accepting the public key. Recipient
272 SHOULD verify the signature before accepting a public key. With
273 certificates the certificate verification may be done before
274 verifying the signature. If the signature verification fails the
275 message should still be displayed. The end user should also be
276 notified about the result of the signature verification.
277
278 To make the packet size smaller implementations may not want to
279 include the actual public key in all signed messages. Sending the
280 public key in the first message is usually sufficient. Subsequent
281 messages may include empty Public Key Payload with an indication of
282 the public key type.
283
284 Implementations that do not support this flag can still process the
285 message payload in normal manner. These implementations merely parse
286 the decrypted payload in normal manner and ignore the extra data in
287 the payload.
288
289 This flag MAY be masked with any other Message Flag including those that
290 define additional payloads. As long as the defined payload resides in
291 the data area of the message payload this flag may be masked with the
292 other flags.
293
294
295
296 .ti 0
297 3.4 SILC_MESSAGE_FLAG_DATA
298
299 This flag is used to represent any data as a message in the way that it
300 can be easily interpreted by the recipient. This flag is used to send
301 MIME objects as messages from the sender to the receiver. The MIME as
302 defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is
303 well established protocol for sending different kind of data with many
304 applications and protocols. It support dozens of different media types
305 and encodings, and for this reason is ideal for sending data in SILC
306 message payloads as well.
307
308 When the receiver has checked that the message payload includes the
309 SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header.
310 It would also be possible to pass the message to some application which
311 can already interpret MIME objects. If the receiver does not support the
312 media type received in the MIME header, it SHOULD be treated as
313 "application/octet-stream". The receiver MAY also ignore and discard
314 messages that it does not support.
315
316 The MIME header MUST be at the start of the data area of the Message
317 Payload. The MIME header received in the data area of the payload SHOULD
318 have the MIME-Version field at first and then Content-Type field. The
319 MIME-Version field is not required to be present in each body part of
320 multipart entity. Additionally the header MAY also include any other
321 MIME compliant headers. The character encoding for the MIME Header
322 strings inside the message payload is US-ASCII, as defined in [RFC2045].
323 The actual MIME object may define additional character sets or encodings
324 for the data it delivers.
325
326 Hence, the MIME Header in the message payload may be as follows:
327
328 .in 8
329 .nf
330 MIME-Version: 1.0\\r\\n
331 Content-Type: discrete/composite\\r\\n
332 Content-Transfer-Encoding: binary\\r\\n
333 \\r\\n
334 .in 3
335
336 The Content-Transfer-Encoding field behaves as defined in [RFC2045] and
337 defines the encoding of the data in the MIME object. The preferred data
338 encoding with SILC is "binary". However, many MIME media types defines
339 their preferred encoding and they may be used if binary encoding is not
340 suitable.
341
342 When sending large amounts of traffic or large files as MIME objects the
343 limits of the SILC Packet needs to be taken into consideration. The
344 maximum length of SILC Packet is 2^16 bytes, and larger messages would
345 need to be fragmented. MIME provides way of fragmenting and reassembling
346 messages, and it is to be done with SILC as defined in [RFC2046]. The
347 MIME fragmentation is defined for gateway usage, but in case of SILC the
348 sender may also start sending fragmented MIME objects.
349
350 This flag SHOULD NOT be masked with some other Message Flag that defines
351 payloads for message data. Generally this sort of setting would be
352 impossible for the receiver to interpret. However, flags that does not
353 define any specific payloads MAY be masked with this flag as well. For
354 example, this flag could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
355 It also can be masked with SILC_MESSAGE_FLAG_SIGNED flag since it does not
356 define data specific payload.
357
358
359 .ti 0
360 4 Security Considerations
361
362 In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special
363 attention to the security implications of any media type that can cause
364 the remote execution of any actions in the receiver's environment. The
365 [RFC2046] and [RFC2048] discusses more MIME specific security
366 considerations. Even though SILC provides secured messages, in case of
367 MIME which can be used to transfer files and documents which are stored in
368 the receiver's local environment, securing separately the MIME object may
369 be desired. For example, augmenting the MIME support in SILC messages to
370 support S/MIME may be desired in some implementations.
371
372
373
374 .ti 0
375 5 References
376
377 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
378 Protocol Specification", Internet Draft, May 2002.
379
380 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
381 May 2002.
382
383 [SILC3] Riikonen, P., "SILC Key Exchange and Authentication
384 Protocols", Internet Draft, May 2002.
385
386 [RFC2045] Freed, N., et al., "Multipurpose Internet Mail Extensions
387 (MIME) Part One: Format of Internet Message Bodies",
388 Standards Track, RFC 2045, November 1996.
389
390 [RFC2046] Freed, N., et al., "Multipurpose Internet Mail Extensions
391 (MIME) Part Two: Media Types", Standards Track, RFC 2045,
392 November 1996.
393
394 [RFC2047] Moore K., "MIME (Multipurpose Internet Mail Extensions)
395 Part Three: Message Header Extensions for Non-ASCII Text"
396 Standards Track, RFC 2047, November 1996.
397
398 [RFC2048] Freed, N., et al., "Multipurpose Internet Mail Extensions
399 (MIME) Part Four: Registration Procedures", Standards
400 Track, RFC 2048, November 1996.
401
402 [RFC2049] Freed, N., et al., "Multipurpose Internet Mail Extensions
403 (MIME) Part Five: Conformance Criteria and Examples",
404 Standards Track, RFC 2049, November 1996.
405
406 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
407 Requirement Levels", BCP 14, RFC 2119, March 1997.
408
409
410
411 .ti 0
412 6 Author's Address
413
414 Pekka Riikonen
415 Snellmaninkatu 34 A 15
416 70100 Kuopio
417 Finland
418
419 EMail: priikone@iki.fi
420
421 This Internet-Draft expires 7 May 2003
This page was automatically generated by the LXR engine.
Free-text search provided by Glimpse