X-Git-Url: http://git.silcnet.org/gitweb/?a=blobdiff_plain;f=doc%2Fdraft-riikonen-silc-flags-payloads-03.nroff;fp=doc%2Fdraft-riikonen-silc-flags-payloads-03.nroff;h=0000000000000000000000000000000000000000;hb=72c2de619079457f7a68100eb13385275a424a23;hp=a17fb04aed5a4086472b5c0e1f953e6d3624921e;hpb=e7b6c157b80152bf9fb9266e6bdd93f9fb0db776;p=runtime.git diff --git a/doc/draft-riikonen-silc-flags-payloads-03.nroff b/doc/draft-riikonen-silc-flags-payloads-03.nroff deleted file mode 100644 index a17fb04a..00000000 --- a/doc/draft-riikonen-silc-flags-payloads-03.nroff +++ /dev/null @@ -1,456 +0,0 @@ -.pl 10.0i -.po 0 -.ll 7.2i -.lt 7.2i -.nr LL 7.2i -.nr LT 7.2i -.ds LF Riikonen -.ds RF FORMFEED[Page %] -.ds CF -.ds LH Internet Draft -.ds RH 17 June 2003 -.ds CH -.na -.hy 0 -.in 0 -.nf -Network Working Group P. Riikonen -Internet-Draft -draft-riikonen-flags-payloads-03.txt 17 June 2003 -Expires: 17 December 2003 - -.in 3 - -.ce 2 -SILC Message Flag Payloads - - -.ti 0 -Status of this Memo - -This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC 2026. 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/ietf/1id-abstracts.txt - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html - -The distribution of this memo is unlimited. - - -.ti 0 -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. - - - - - - - - -.ti 0 -Table of Contents - -.nf -1 Introduction .................................................. 2 - 1.1 Requirements Terminology .................................. 2 -2 SILC Message Flags ............................................ 2 -3 SILC Message Flag Payloads .................................... 3 - 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. 3 - 3.2 SILC_MESSAGE_FLAG_REPLY ................................... 3 - 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. 4 - 3.4 SILC_MESSAGE_FLAG_DATA .................................... 6 -4 Security Considerations ....................................... 7 -5 References .................................................... 8 -6 Author's Address .............................................. 8 -7 Full Copyright Statement ...................................... 9 - - -.ti 0 -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. - - -.ti 0 -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]. - - -.ti 0 -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 flags the purpose, the reason, and the way the message is -supposed to 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 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. - - -.ti 0 -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. - - -.ti 0 -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. - - -.ti 0 -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. - - -.ti 0 -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: - -.in 5 -.nf - 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 * ~ -| | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -.in 3 - -.ce -Figure 1: SILC_MESSAGE_FLAG_SIGNED Payload - - -.in 6 -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. - -o Signature Data Length (2 bytes) - Indicates the length of - the Signature Data field not including any other field. - -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. - -o Initial Vector (variable length) - the IV of the Message - Payload as defined in [SILC2]. This field is not encrypted. - -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. -.in 3 - -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. - -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. - - -.ti 0 -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: - -.in 8 -.nf -MIME-Version: 1.0\\r\\n -Content-Type: discrete/composite\\r\\n -Content-Transfer-Encoding: binary\\r\\n -\\r\\n -.in 3 - -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. - -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. - - -.ti 0 -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. - - - - -.ti 0 -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. - -[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - -.ti 0 -6 Author's Address - -Pekka Riikonen -Snellmaninkatu 34 A 15 -70100 Kuopio -Finland - -EMail: priikone@iki.fi - - - - -.ti 0 -7 Full Copyright Statement - -Copyright (C) The Internet Society (2003). All Rights Reserved. - -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it -or assist in its implementation may be prepared, copied, published -and distributed, in whole or in part, without restriction of any -kind, provided that the above copyright notice and this paragraph are -included on all such copies and derivative works. However, this -document itself may not be modified in any way, such as by removing -the copyright notice or references to the Internet Society or other -Internet organizations, except as needed for the purpose of -developing Internet standards in which case the procedures for -copyrights defined in the Internet Standards process must be -followed, or as required to translate it into languages other than -English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an -"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING -TASK FORCE DISCLAIMS 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.