From 87606e736912bbfc7493b3dfc27d873dffae6f43 Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Mon, 20 Oct 2003 13:09:50 +0000 Subject: [PATCH] Added SILC_MESSAGE_FLAG_ACK. --- CHANGES | 6 + doc/Makefile.am.pre | 8 +- ...raft-riikonen-silc-flags-payloads-04.nroff | 494 ++++++++++++++++++ doc/draft-riikonen-silc-pp-08.nroff | 11 +- lib/silccore/silcmessage.h | 5 +- 5 files changed, 516 insertions(+), 8 deletions(-) create mode 100644 doc/draft-riikonen-silc-flags-payloads-04.nroff diff --git a/CHANGES b/CHANGES index 3b6ab18e..ca81d557 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,9 @@ +Mon Oct 20 16:08:22 EEST 2003 Pekka Riikonen + + * Added new SILC_MESSAGE_FLAG_ACK that can be used to + acknowledge recepetion of a message to the sender. Updated + protocol specs. + Sat Oct 18 11:55:33 EEST 2003 Pekka Riikonen * Unregister channel key saving callback when deleting channel. diff --git a/doc/Makefile.am.pre b/doc/Makefile.am.pre index edb11a70..599d57a1 100644 --- a/doc/Makefile.am.pre +++ b/doc/Makefile.am.pre @@ -28,7 +28,7 @@ all: touch draft-riikonen-silc-pp-08.txt touch draft-riikonen-silc-ke-auth-07.txt touch draft-riikonen-silc-commands-06.txt - touch draft-riikonen-silc-flags-payloads-03.txt + touch draft-riikonen-silc-flags-payloads-04.txt touch draft-riikonen-presence-attrs-02.txt if SILC_DIST_TOOLKIT @@ -60,7 +60,7 @@ dist-hook: touch draft-riikonen-silc-pp-08.txt touch draft-riikonen-silc-ke-auth-07.txt touch draft-riikonen-silc-commands-06.txt - touch draft-riikonen-silc-flags-payloads-03.txt + touch draft-riikonen-silc-flags-payloads-04.txt touch draft-riikonen-presence-attrs-02.txt $(makerfc) draft-riikonen-silc-spec-08.nroff \ draft-riikonen-silc-spec-08.txt @@ -70,8 +70,8 @@ dist-hook: draft-riikonen-silc-ke-auth-07.txt $(makerfc) draft-riikonen-silc-commands-06.nroff \ draft-riikonen-silc-commands-06.txt - $(makerfc) draft-riikonen-silc-flags-payloads-03.nroff \ - draft-riikonen-silc-flags-payloads-03.txt + $(makerfc) draft-riikonen-silc-flags-payloads-04.nroff \ + draft-riikonen-silc-flags-payloads-04.txt $(makerfc) draft-riikonen-presence-attrs-02.nroff \ draft-riikonen-presence-attrs-02.txt diff --git a/doc/draft-riikonen-silc-flags-payloads-04.nroff b/doc/draft-riikonen-silc-flags-payloads-04.nroff new file mode 100644 index 00000000..77e6c730 --- /dev/null +++ b/doc/draft-riikonen-silc-flags-payloads-04.nroff @@ -0,0 +1,494 @@ +.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 + 3.5 SILC_MESSAGE_FLAG_ACK ..................................... 7 +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 +3.5 SILC_MESSAGE_FLAG_ACK + +This flag is used to send acknowledgement messages. When sender of a +message requires the recipient to acknowledge the received message, the +sender MUST set the SILC_MESSAGE_FLAG_ACK and MUST NOT set the +SILC_MESSAGE_FLAG_NOREPLY. When a message with this flag set is received +an acknowledgement message MUST be sent back. In the acknowledgement +message the sender MUST set the SILC_MESSAGE_FLAG_ACK, +SILC_MESSAGE_FLAG_AUTOREPLY and SILC_MESSAGE_FLAG_NOREPLY flags. The +receiver MUST NOT acknowledge the acknowledgement message. This flag +MUST NOT be used with channel messages, and MUST be ignored if received +in a channel message. + +The construction of the acknowledgement reply message is normal Message +Payload where the Message Data field includes a computed MAC of the +original received Message Payload MAC. Hence, the MAC is computed as +follows: + +.in 8 +ack_mac = mac(key, MAC); +.in 3 + +Where the 'key' is the MAC key used to compute MACs for the Message +Payload, and the 'MAC' is the MAC taken from the received Message Payload. +The 'ack_mac' is placed in the Message Data field in a new Message +Payload, and the payload is encrypted in normal manner. After this the +message is sent back to the original sender of the message. + +The receiver of the acknowledgement reply message SHOULD verify the MAC +from the Message Data field to assure that acknowledgement was received to +an earlier sent message. Implementation needs to keep the old message +MACs stored until acknowledgement is received. It is left for +implementation to decide any possible retransmission strategy if +acknowledgement messages are not received. + + +.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. diff --git a/doc/draft-riikonen-silc-pp-08.nroff b/doc/draft-riikonen-silc-pp-08.nroff index ab7998cc..f6958444 100644 --- a/doc/draft-riikonen-silc-pp-08.nroff +++ b/doc/draft-riikonen-silc-pp-08.nroff @@ -1091,11 +1091,18 @@ o Message Flags (2 bytes) - Includes the Message Flags of the this flag SHOULD be used. When this flag is used the text sent as message MUST be UTF-8 encoded. - 0x0200 - 0x0800 RESERVED + 0x0200 SILC_MESSAGE_FLAG_ACK + + This flag indicates the sender requires the recpipient + to acknowledge the received message. This same flag + is used in the acknowledgement. A separate document + should define how the acknowledgement is performed. + + 0x0400 - 0x1000 RESERVED Reserved for future flags. - 0x1000 - 0x8000 PRIVATE RANGE + 0x2000 - 0x8000 PRIVATE RANGE Private range for free use. diff --git a/lib/silccore/silcmessage.h b/lib/silccore/silcmessage.h index 8e1a9f81..52c0aebc 100644 --- a/lib/silccore/silcmessage.h +++ b/lib/silccore/silcmessage.h @@ -96,8 +96,9 @@ typedef SilcUInt16 SilcMessageFlags; #define SILC_MESSAGE_FLAG_REPLY 0x0040 /* A reply */ #define SILC_MESSAGE_FLAG_DATA 0x0080 /* MIME object */ #define SILC_MESSAGE_FLAG_UTF8 0x0100 /* UTF-8 string */ -#define SILC_MESSAGE_FLAG_RESERVED 0x0200 /* to 0x0800 */ -#define SILC_MESSAGE_FLAG_PRIVATE 0x1000 /* to 0x8000 */ +#define SILC_MESSAGE_FLAG_ACK 0x0200 /* ACK messages */ +#define SILC_MESSAGE_FLAG_RESERVED 0x0400 /* to 0x1000 */ +#define SILC_MESSAGE_FLAG_PRIVATE 0x2000 /* to 0x8000 */ /***/ /****f* silccore/SilcMessageAPI/silc_message_payload_decrypt -- 2.43.0