doc/draft-riikonen-silc-flags-payloads-03.nroff

   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 17 June 2003
  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-03.txt                        17 June 2003
  20 Expires: 17 December 2003
  21
  22 .in 3
  23
  24 .ce 2
  25 SILC Message Flag Payloads
  26 <draft-riikonen-flags-payloads-03.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 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.
  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 ....................................................  8
  84 6 Author's Address ..............................................  8
  85 7 Full Copyright Statement ......................................  9
  86
  87
  88 .ti 0
  89 1. Introduction
  90
  91 The Secure Internet Live Conferencing [SILC1] supports sending binary
  92 messages between users in the network.  To make the data sending, and
  93 processing at the receiver's end as simple as possible the SILC defines
  94 Message Flags to the Message Payload [SILC2] that is used to send private
  95 and channel messages, which can help the receiver to decide how the data
  96 is encoded, and how it should be interpreted.  Some of the Message Flags
  97 may define additional payloads to be associated with the flag, but the
  98 [SILC2] does not define them.  This memo defines the payloads for those
  99 Message Flags that was marked to include additional payloads in [SILC2].
 100
 101 By defining the payloads for the Message Flags the Message Payload
 102 can be augmented to support any kind of data, which can be easily
 103 interpreted at the receiver end.  For example, it would be possible to
 104 send audio stream, video stream, image files and HTML pages as messages,
 105 and the receiver can either choose to ignore the message or to process
 106 it, or to perhaps pass the message to some application for processing.
 107 Without specific payloads for Message Flags it is almost impossible for
 108 the receiver to interpret binary data from the payload.
 109
 110
 111 .ti 0
 112 1.1 Requirements Terminology
 113
 114 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
 115 MAY, and OPTIONAL, when they appear in this document, are to be
 116 interpreted as described in [RFC2119].
 117
 118
 119 .ti 0
 120 2 SILC Message Flags
 121
 122 The Message Flags was added to the SILC protocol for the reason that SILC
 123 provides sending binary data as messages between users, and entities in
 124 the network, and interpreting pure binary data is almost impossible.
 125 With the flags the purpose, the reason, and the way the message is
 126 supposed to be interpreted can be told to the recipient.  Other
 127 conferencing protocols which are usually ASCII based protocols do not have
 128 such problems since they do not generally support sending of binary data
 129 at all, or require encoding of the data before it can be sent over the
 130 network.
 131
 132 The Message Payload in SILC can have flags that can augment the function
 133 of the payload.  The flags can tell for example that the message is a
 134 request, or a reply to an earlier received request.  They can tell that
 135 the message is some action that the sender is performing, or they can tell
 136 that the message is an auto reply, or that it is explicitly digitally
 137 signed by the sender.
 138
 139 The problem of Message Flags is that the space for flags mask is only 16
 140 bits, so there is a limited number of flags available.  For this reason
 141 having a flag that defines a generic way of sending any kind of data as
 142 a message, and can be easily interpreted at the receiver's end is important.
 143 For this reason the flag SILC_MESSAGE_FLAG_DATA was added to the protocol
 144 which can represent any data.  This memo describe how this flag is used
 145 and how the associated payload is constructed and processed.  This memo
 146 also describes payloads for all the other flags that can have associated
 147 payloads.
 148
 149
 150 .ti 0
 151 3 SILC Message Flag Payloads
 152
 153 The [SILC2] defines the flags which may have associated payloads.  This
 154 section will list these flags and define the payloads.
 155
 156
 157 .ti 0
 158 3.1 SILC_MESSAGE_FLAG_REQUEST
 159
 160 Currently this flag can be used in the context of application specific,
 161 service specific or vendor specific requests, and the data payload type is
 162 dependent of this context.  Therefore, payload is not defined for this
 163 flag in this memo.  This flag may also be masked with some other flag in
 164 the message payload, including with some other flag that defines
 165 additional payload.
 166
 167
 168 .ti 0
 169 3.2 SILC_MESSAGE_FLAG_REPLY
 170
 171 Currently this flag can be used in the context of application specific,
 172 service specific or vendor specific replies, and the data payload type is
 173 dependent of this context.  Therefore, payload is not defined for this
 174 flag in this memo.  This flag may also be masked with some other flag in
 175 the message payload, including with some other flag that defines
 176 additional payload.
 177
 178
 179 .ti 0
 180 3.3 SILC_MESSAGE_FLAG_SIGNED
 181
 182 This flag is used to tell the recipient that the sent message is
 183 digitally signed by the sender, and that the recipient should verify
 184 the signature to verify the true authenticity of the received message.
 185 All message payloads in SILC provides message authentication code (MAC)
 186 which can be used to verify that the sender produced and sent the message.
 187 Even so, signing messages digitally can be used to verify the authenticity
 188 of the message when recipient trusts the sender and to provide
 189 non-repudiation.
 190
 191 This flag defines a payload which is used to deliver the actual message,
 192 sender's public key and the digital signature.  The payload for
 193 SILC_MESSAGE_FLAG_SIGNED is as follows:
 194
 195 .in 5
 196 .nf
 197                      1                   2                   3
 198  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
 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 200 |                                                               |
 201 ~                   Start of Message Payload                    ~
 202 |                                                               |
 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 204 |                                                               |
 205 ~                      Public Key Payload                       ~
 206 |                                                               |
 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 208 |     Signature Data Length     |                               |
 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 210 |                                                               |
 211 ~                        Signature Data                         ~
 212 |                                                               |
 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 214 |                                                               |
 215 ~                       Initial Vector *                        ~
 216 |                                                               |
 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 218 |                                                               |
 219 ~                              MAC *                            ~
 220 |                                                               |
 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 222 .in 3
 223
 224 .ce
 225 Figure 1:  SILC_MESSAGE_FLAG_SIGNED Payload
 226
 227
 228 .in 6
 229 o Start of Message Payload (variable length) - This is the
 230   start of the Message Payload without the IV and MAC fields,
 231   since those fields are appended at the end of this payload.
 232
 233 o Public Key Payload (variable length) - This includes the
 234   Public Key Payload [SILC2] which can be used to deliver the
 235   sender's public key (or certificate).  It also indicates the
 236   type of the public key (or certificate) which the recipient
 237   use to identify how the signature must be verified.  This
 238   payload must always be present but it is not required to
 239   include the public key data.  The Public Key Type field in
 240   the Public Key Payload MUST be set to the correct type of
 241   the key, even if the actual public key data is not included.
 242
 243 o Signature Data Length (2 bytes) - Indicates the length of
 244   the Signature Data field not including any other field.
 245
 246 o Signature Data (variable length) - Includes the actual
 247   signature data.  The signature computation and encoding
 248   is key type specific.  See [SILC3] for all key types, and
 249   their respective references for how to compute and encode
 250   the signature.
 251
 252 o Initial Vector (variable length) - the IV of the Message
 253   Payload as defined in [SILC2].  This field is not encrypted.
 254
 255 o MAC (variable length) - the MAC of the Message Payload as
 256   defined in [SILC2].  The MAC is computed after encryption
 257   and after signature computation.  All data in the Message
 258   Payload and this payload, including the IV field are
 259   included in the MAC computation.  This field is not
 260   encrypted.
 261 .in 3
 262
 263 How the data is processed before it is signed is key type specific.
 264 The actual data that to be signed MUST be the plaintext message
 265 payload before encryption.  The data to be signed is concatenation
 266 of the Start of Message Payload field and the Public Key Payload,
 267 in that order.  Any other fields are not included for signature data.
 268 Before signing, the data is always processed, usually hashed.  The
 269 hash function to be used is defined in the key type specific
 270 definitions.  See the key type specific references in [SILC3].
 271
 272 If the public key of the sender is included in the payload the
 273 recipient SHOULD verify it before accepting the public key.  Recipient
 274 SHOULD verify the signature before accepting and caching the public key.
 275 With certificates the certificate verification may be done before
 276 verifying the signature.  If the signature verification fails the
 277 message should still be displayed.  The end user should also be
 278 notified about the result of the signature verification.
 279
 280 To make the packet size smaller implementations may not want to
 281 include the actual public key in all signed messages.  Sending the
 282 public key in the first message is usually sufficient.  Subsequent
 283 messages may include empty Public Key Payload with an indication of
 284 the public key type.
 285
 286 Implementations that do not support this flag can still process the
 287 message payload in normal manner.  These implementations merely parse
 288 the decrypted payload in normal manner and ignore the extra data in
 289 the payload.  They can do this by extracting the MAC and the IV from
 290 the end of the data buffer and thus ignoring the data between start of
 291 the Message Payload and the Initial Vector field.
 292
 293 This flag MAY be masked with any other Message Flag including those that
 294 define additional payloads.  As long as the defined payload resides in
 295 the data area of the message payload this flag may be masked with the
 296 other flags.
 297
 298
 299 .ti 0
 300 3.4 SILC_MESSAGE_FLAG_DATA
 301
 302 This flag is used to represent any data as a message in the way that it
 303 can be easily interpreted by the recipient.  This flag is used to send
 304 MIME objects as messages from the sender to the receiver.  The MIME as
 305 defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is
 306 well established protocol for sending different kind of data with many
 307 applications and protocols.  It support dozens of different media types
 308 and encodings, and for this reason is ideal for sending data in SILC
 309 message payloads as well.
 310
 311 When the receiver has checked that the message payload includes the
 312 SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header.
 313 It would also be possible to pass the message to some application which
 314 can already interpret MIME objects.  If the receiver does not support the
 315 media type received in the MIME header, it SHOULD be treated as
 316 "application/octet-stream".  The receiver MAY also ignore and discard
 317 messages that it does not support.
 318
 319 The MIME header MUST be at the start of the data area of the Message
 320 Payload.  The MIME header received in the data area of the payload SHOULD
 321 have the MIME-Version field at first and then Content-Type field.  The
 322 MIME-Version field is not required to be present in each body part of
 323 multipart entity.  Additionally the header MAY also include any other
 324 MIME compliant headers.  The character encoding for the MIME Header
 325 strings inside the message payload is US-ASCII, as defined in [RFC2045].
 326 The actual MIME object may define additional character sets or encodings
 327 for the data it delivers.
 328
 329 Hence, the MIME Header in the message payload may be as follows:
 330
 331 .in 8
 332 .nf
 333 MIME-Version: 1.0\\r\\n
 334 Content-Type: discrete/composite\\r\\n
 335 Content-Transfer-Encoding: binary\\r\\n
 336 \\r\\n
 337 .in 3
 338
 339 The Content-Transfer-Encoding field behaves as defined in [RFC2045] and
 340 defines the encoding of the data in the MIME object.  The preferred data
 341 encoding with SILC is "binary".  However, many MIME media types defines
 342 their preferred encoding and they may be used if binary encoding is not
 343 suitable.
 344
 345 When sending large amounts of traffic or large files as MIME objects the
 346 limits of the SILC Packet needs to be taken into consideration.  The
 347 maximum length of SILC Packet is 2^16 bytes, and larger messages would
 348 need to be fragmented.  MIME provides way of fragmenting and reassembling
 349 messages, and it is to be done with SILC as defined in [RFC2046].  The
 350 MIME fragmentation is defined for gateway usage, but in case of SILC the
 351 sender (for example, a client) may also start sending fragmented MIME
 352 objects.
 353
 354 This flag SHOULD NOT be masked with some other Message Flag that defines
 355 payloads for message data.  Generally this sort of setting would be
 356 impossible for the receiver to interpret.  However, flags that does not
 357 define any specific payloads MAY be masked with this flag as well.  For
 358 example, this flag could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
 359 It also can be masked with SILC_MESSAGE_FLAG_SIGNED flag since it does not
 360 define data specific payload.
 361
 362
 363 .ti 0
 364 4 Security Considerations
 365
 366 In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special
 367 attention to the security implications of any media type that can cause
 368 the remote execution of any actions in the receiver's environment.  The
 369 [RFC2046] and [RFC2048] discusses more MIME specific security
 370 considerations.  Even though SILC provides secured messages, in case of
 371 MIME which can be used to transfer files and documents which are stored in
 372 the receiver's local environment, securing separately the MIME object may
 373 be desired.  For example, augmenting the MIME support in SILC messages to
 374 support S/MIME may be desired in some implementations.
 375
 376
 377
 378
 379 .ti 0
 380 5 References
 381
 382 [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
 383              Protocol Specification", Internet Draft, June 2003.
 384
 385 [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
 386              June 2003.
 387
 388 [SILC3]      Riikonen, P., "SILC Key Exchange and Authentication
 389              Protocols", Internet Draft, June 2003.
 390
 391 [RFC2045]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 392              (MIME) Part One: Format of Internet Message Bodies",
 393              Standards Track, RFC 2045, November 1996.
 394
 395 [RFC2046]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 396              (MIME) Part Two: Media Types", Standards Track, RFC 2045,
 397              November 1996.
 398
 399 [RFC2047]    Moore K., "MIME (Multipurpose Internet Mail Extensions)
 400              Part Three: Message Header Extensions for Non-ASCII Text"
 401              Standards Track, RFC 2047, November 1996.
 402
 403 [RFC2048]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 404              (MIME) Part Four: Registration Procedures", Standards
 405              Track, RFC 2048, November 1996.
 406
 407 [RFC2049]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 408              (MIME) Part Five: Conformance Criteria and Examples",
 409              Standards Track, RFC 2049, November 1996.
 410
 411 [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
 412              Requirement Levels", BCP 14, RFC 2119, March 1997.
 413
 414
 415
 416 .ti 0
 417 6 Author's Address
 418
 419 Pekka Riikonen
 420 Snellmaninkatu 34 A 15
 421 70100 Kuopio
 422 Finland
 423
 424 EMail: priikone@iki.fi
 425
 426
 427
 428
 429 .ti 0
 430 7 Full Copyright Statement
 431
 432 Copyright (C) The Internet Society (2003). All Rights Reserved.
 433
 434 This document and translations of it may be copied and furnished to
 435 others, and derivative works that comment on or otherwise explain it
 436 or assist in its implementation may be prepared, copied, published
 437 and distributed, in whole or in part, without restriction of any
 438 kind, provided that the above copyright notice and this paragraph are
 439 included on all such copies and derivative works. However, this
 440 document itself may not be modified in any way, such as by removing
 441 the copyright notice or references to the Internet Society or other
 442 Internet organizations, except as needed for the purpose of
 443 developing Internet standards in which case the procedures for
 444 copyrights defined in the Internet Standards process must be
 445 followed, or as required to translate it into languages other than
 446 English.
 447
 448 The limited permissions granted above are perpetual and will not be
 449 revoked by the Internet Society or its successors or assigns.
 450
 451 This document and the information contained herein is provided on an
 452 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 453 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 454 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 455 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 456 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.