idnits 2.17.1 draft-ietf-syslog-sign-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 182: '... signature group MUST ultimately be ro...' RFC 2119 keyword, line 183: '... collector, and MUST NOT ever be sepa...' RFC 2119 keyword, line 204: '...ld, but the size MUST NOT be shorter t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Syslog 2 Internet Draft John Kelsey 3 draft-ietf-syslog-sign-00.txt Expires: June 2001 5 Syslog-Sign Protocol 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other groups 14 may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress". 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 ABSTRACT 29 This document describes syslog-sign, a mechanism for adding 30 origin authenticaiton, message integrity, replay-resistance, 31 message sequencing, and detection of missing messages to 32 syslog. The goal of syslog-sign is to provide all these 33 security features in a way that has minimal requirements and 34 minimal impact on an existing setup of syslog devices, 35 relays, and collectors. In particular, it is possible to 36 support syslog-sign by changing only the behavior of the 37 syslog devices, and some software run either online or 38 offline on the collector's stored logs. 40 1. Introduction 42 Syslog-sign is intended to be an in-band protocol for 43 signing messages within syslog, making no assumptions about 44 any delivery mechanisms. This means that all messages sent 45 along are valid syslog-syslog messages. The messages will 46 be received and stored normally by any syslog collector. 47 However, offline review of the stored logs by a 48 syslog-sign-aware program will allow verification of the 49 logs' origin, integrity, freshness, and completeness. 51 The basic design goals are thus: 53 a. The goal of syslog-sign is offline detection of 54 alterations of the logs. The signatures provide both 55 storage security and transmission security, but we provide 56 no support for any kind of online detection of alterations. 57 (There's nothing saying a collector can't implement such 58 detection online, assuming it can keep up with the workload. 59 But we add nothing to support such online detection.) 61 b. Over the course of a reasonably long session, 62 syslog-sign will transmit the certificate, public key, or 63 key ID on which its signatures are based several times. 65 Draft Syslog Sign December 2000 67 c. Syslog-sign will provide data integrity, data origin 68 authentication, replay detection, and gap detection. It is 69 the responsibility of the users of syslog-sign to ensure 70 that all the logs in a ``signature group'' are sent to the 71 same receiver. (A ``signature group'' is a set of messages 72 signed in the same sequence of signature blocks.) How the 73 administrator sets things up to support this is outside the 74 scope of this document, but if messages from the same 75 signature group are somehow separated during transmission or 76 forwarding, we will generally be unable to authenticate the 77 messages stored by any one collector. 79 d. Because syslog-sign must operate in-band over unreliable 80 delivery mechanisms, there is always some chance that 81 critical information will not make it to the receiver. 82 However, syslog-sign can be configured on the sender side to 83 add redundancy to its messages, to decrease the likelihood 84 that any messages will be impossible to verify. 86 e. Syslog-sign supports multiple signature and hash sizes 87 and schemes. These are encoded in its version field. Larger 88 signatures lead to more bandwidth required by syslog-sign. 89 Syslog-sign even supports symmetric cryptosystems. 91 f. The only awareness of forwarding in syslog-sign is the 92 requirement that a syslog-sign relay (as well as a device) 93 signal some kind of an error if it is required by its 94 forwarding rules to send messages in the same signature 95 group to different recipients. 97 2. Syslog-Sign Message Formats 99 Syslog-sign uses syslog to transmit its messages. That 100 means that all of its messages have to fit inside legal 101 syslog-syslog messages. This determines most of the design. 103 Syslog-sign processes all syslog messages, but it generates 104 only two kinds of messages of its own: signature blocks and 105 certificate blocks. A signature block contains some header 106 information, a sequence of hashes from recently-sent 107 messages, and a signature of some kind, and a new signature 108 block is sent each time there have been N new messages whose 109 hashes need to be signed and sent out. A certificate block 110 contains some or all of the information needed to uniquely 111 identify the key being used in these signatures. 113 2.1. Signature Blocks 114 A signature block contains a signature for a sequence of 115 messages sent by syslog-sign. There are several key points 116 that must be understood before the format of the signature 117 block makes any sense: 119 a. In this document, we refer to the normal syslog messages 120 that aren't generated by syslog-sign as ``messages.'' When 121 we discuss processing messages, we never include signature 122 blocks or certificate blocks in this processing. 124 Draft Syslog Sign December 2000 126 b. The sending device divides the set of messages it will 127 ever send into one or more ``signature groups.'' The 128 maximum number of signature groups allowed is 4095. The 129 only requirement for a signature group is that all messages 130 from that signature group must be routed to the same 131 collector. 133 c. Each time the device starts a new logging ``session,'' 134 e.g. because it has rebooted, it must generate a unique 135 reboot session ID. 137 d. Because we must deal with unreliable delivery, we can't 138 assume that all the messages in this sequence arrived. 139 Therefore, we include the hash of each message sent in this 140 sequence in this signature block. When the logs are 141 reviewed, the messages are hashed and their hashes are found 142 in the appropriate signature block. 144 e. Messages are sent along unaltered. However, each 145 message is assigned a unique identifying number within its 146 reboot session and signature group. Each signature block 147 specifies the number of the first message whose hash is 148 included; the numbers of the succeeding messages are defined 149 by their position in the hash block. 151 f. The signature block is sent in-band, and may 152 legitimately be forwarded through old-style syslog machines. 153 Therefore, it must fit within the requirements of a syslog 154 message. That means it is always less than 1024 bytes, and 155 it contains only printable ASCII characters, and in fact, 156 only the 64 characters used in base 64 encoding. 158 2.1.1. Signature Block Format 160 The signature block consists of the following fields: 162 a. Cookie -- an eight byte sequence to signal to the 163 verifier that this is a signature block. This sequence is 164 ''@#sigSIG''. 166 b. Version -- a 12-bit quantity encoded in base 64 as two 167 bytes, which effectively specifies the hash function, 168 signature mechanism, and other details of the processing of 169 this signature block. 171 c. Session ID -- a 48-bit quantity encoded in base 64 as 172 eight bytes, which is required to never repeat or decrease 173 over multiple reboots of the sender. 175 Draft Syslog Sign December 2000 177 d. Signature Group -- a 12-bit quantity encoded in base 64 178 as two bytes, which indicates which signature group this 179 message belongs to. (Each raw message belongs to exactly 180 one signature group, and each signature block includes 181 hashes from only one signature group. Messages from the 182 same signature group MUST ultimately be routed to the same 183 collector, and MUST NOT ever be separated in transmission by 184 any device or relay. 186 e. Global Block Counter -- a 48-bit quantity encoded in 187 base 64 as eight bytes, which is the number of signature 188 blocks sent out by syslog-sign in this reboot session. 190 f. First Message Number -- a 48-bit quantity encoded in 191 base 64 as eight bytes, which is the unique message number 192 within this signature group of the first message whose hash 193 appears in this block. (That is, if this signature group 194 has processed 1000 messages so far, and the 1001st message 195 from this signature group is the first one whose hash 196 appears in this signature block, then this field is 1001. 198 g. Count -- a 6-bit quantity encoded in base 64 as one 199 byte, which is the number of message hashes to follow. 201 h. Message Hashes -- a block of hashes, each separately 202 encoded in base-64. The size of each hash is determined by 203 the hashing algorithm used, effectively specified by the 204 Version field, but the size MUST NOT be shorter than 160 205 bits. 207 i. Signature -- a digital signature, encoded in base-64. 208 The original encoding of the signature is effectively 209 specified by the Version field. 211 2.1.2. Variability of Format 213 The format has a certain amount of flexibility. Some of 214 this is determined by the version, and some, by the device 215 generating the messages based on requested level of 216 redundancy in transmission. 218 2.1.2.1. Versions and Field Sizes 220 The format has some variability, because different signature 221 schemes and hash functions will alter the size of the 222 fields. The following versions are defined right now: 224 1 = SHA1 and DSA/320 226 2 = SHA1 and RSA/1024 228 3 = SHA1 and RSA/2048 230 [[ I need to reference some specs for all this. --JMK ]] 232 Draft Syslog Sign December 2000 234 2.1.2.2. Redundancy 236 The sending device has a tunable level of redundancy for the 237 signature blocks. If no redundancy is used, then if a 238 signature block is lost, no messages that were signed by 239 that block can be verified. The more redundancy is used, 240 the more signature blocks must be lost before a message 241 cannot be verified. 243 Redundancy is implemented in a simple way: Each message's 244 hash can be included in more than one signature block. If 245 each message's hash is included in two signature blocks, 246 then only when two successive signature blocks from the same 247 signature groups are lost in transit do we end up with 248 messages we can't verify. If each message's hash is 249 included in three signature blocks, then this can happen 250 only when three successive signature blocks from the same 251 signature group are lost in transit. 253 The signature block specifies the message number of the 254 first message whose hash is included in the block. If each 255 signature block contains 40 hashes, and each successive 256 signature block's first message is 20 messages higher than 257 the previous block's, then each message is signed by two 258 blocks. 260 Note that this is totally decided by the sending device, and 261 that any level of redundancy is supported. Similarly, the 262 only requirement about the number of hashes included in each 263 signature block is that it never be less than one, and that 264 it will never be large enough to cause the signature block 265 to go over 1024 bytes in length. (The field cannot support 266 more than 63 message hashes, but in practice, no more than 267 37 could appear in a 1024-byte message, ignoring the other 268 header fields and the signature block.) 270 In particular, note that it is legal for the sending device 271 to simply include one signature block per message. 273 2.2. Certificate Blocks 275 The purpose of a certificate block is provide some support 276 for key management in syslog-sign, by allowing the 277 transmission of a certificate and other identifying 278 information from the sending device. The sending device has 279 a certain initial key management blob to send, which may be 280 a PKIX certificate, or a raw public key, or a key 281 fingerprint. In fact, a syslog-sign device doesn't know 282 anything about this payload except what it's told to report 283 about it during device setup. 285 Draft Syslog Sign December 2000 287 There are three key points to understand about certificate blocks: 289 a. The handle a variable-sized payload, by fragmenting it 290 if necessary, and transmitting the fragments as legal 291 syslog-syslog messages. This payload is expected to be a 292 certificate, but the syslog-sign device does no checking of 293 its format or contents. Its goal is simply to make sure 294 that the payload gets sent along with a log of any 295 reasonable length. 297 b. There is an adjustable parameter for required 298 redundancy, just as in the signature blocks. However, the 299 redundancy functions a little differently. 301 c. Each signature group gets sent its own certificate blocks. 303 2.2.1. Building the Payload Block 305 Note that we build a payload at the time the reboot 306 session starts, and that payload includes a digital 307 signature. The payload block for this reboot session 308 includes: 310 a. Version -- specifying the hash function and signature 311 used; this is the same version identifier as is used in the 312 signature blocks. 314 b. Reboot Session ID -- the same reboot session ID which 315 will be used in the signature blocks 317 c. IP Address of Sender -- the sender's IP address, a 318 128-bit number base-64 encoded as 22 bytes. 320 d. Key Blob Type -- this one-byte field holds one of four values: 321 (i) 'C' -- a PKIX certificate 322 (ii) 'F' -- a key fingerprint (the hash of the public key 323 using the specified hash algorithm) 324 (iii)'K' -- the public key whose corresponding 325 private key is being used to sign these 326 messages. 327 (iv) 'U' -- user-specific field with no defined 328 meaning in the standard. 330 e. Key Blob -- the raw data, base-64 encoded. 332 f. Signature -- a digital signature on fields a-e, encoded 333 in base-64. 335 2.2.2. Building the Certificate Block 337 The certificate block must get the payload block to the 338 collector. Since certificates can legitimately be much 339 longer than 1024 bytes, each certificate block carries a 340 piece of the payload block. 342 Draft Syslog Sign December 2000 344 The certificate block is built as follows: 346 a. Cookie -- an eight byte string, ``@#sigCer''. 348 b. Version -- a 12-bit field encoded in base-64 as two bytes. 350 c. Signature Group -- a 12-bit field encoded in base-64 as 351 two bytes. 353 d. Total Payload Length -- a 32-bit field encoded in 354 base-64 as six bytes. 356 e. Index into Payload -- a 32-bit field encoded in base-64 357 as six bytes. 359 f. Fragment Length -- a 12-bit field encoded in base-64 as 360 two bytes. 362 g. Payload Fragment -- a fragment of the payload, as 363 specified by the above fields. 365 2.2.3. Redundancy 367 Given the 1024-byte limit on syslog messages, a given 368 payload block can be efficiently divided up into some 369 number, P, of certificate blocks. (It is possible that 370 P==1.) The collector must end up with all P of these blocks 371 to be able to verify that this key was in use at the time of 372 this reboot session. 374 The certificate blocks are sent as follows: 376 a. At reboot, we send all P certificate blocks once for 377 each signature group. These are sent as syslog messages, 378 and they are sent before any other syslog messages are sent 379 in this session. 381 b. After this, we resend the certificate blocks 382 occasionally, based on the redundancy parameter R. For each 383 signature group, each time another R messages are sent for 384 that signature group, we send along the next certificate 385 block. Note that this requires that we keep track of which 386 certificate block we're on, for each signature group. If 387 R==0, then we never resend the certificate block. (This 388 would make sense if we were using syslog-sign over 389 syslog-reliable.) 391 3.0. Offline Review 393 Reviewing the stored logs offline now becomes straightforward. 395 a. Verify that the next reboot session ID is valid, e.g., 396 is larger than the previously seen reboot session IDs. 398 Draft Syslog Sign December 2000 400 b. Go through the log entries with this session ID, and 401 pull out each of the certificate blocks. Reassemble the 402 payload block, and make whatever use of it is desired. 404 c. If more than one signature group appears in the logs, 405 process each group separately as follows. 407 d. For each signature block: 408 (i) Verify the signature at the end of the block. 409 If the signature verifies successfully, then 410 continue processing. 411 (ii) Determine what message numbers we're receiving 412 based on the appropriate fields in the signature 413 block. 414 (iii)For each hash in the hash block, look in the 415 nearby messages for a message with the same hash. If 416 a message is found, then add that message, along 417 with its message number, to the list of verified 418 messages for this session ID and signature group. 420 e. When the processing is done, sort the list of verified 421 messages for this session ID and signature group on the 422 message numbers. Eliminate duplicate message numbers, and 423 the result is a verified log file, complete with gaps in the 424 message numbers where there are gaps in the received 425 messages. 427 4 Acknowledgements 429 The author wishes to thank Alex Brown, Chris Calabrese, Jon 430 Callas, Carson Gaspar, Drew Gross, Chris Lonvick, Darrin 431 New, Marshall Rose, Holt Sorenson, and the whole bunch of 432 Counterpane engineering and operations people who commented 433 on early or late versions of this proposal. 435 5 Bibliography 437 A Author's Address 439 John Kelsey 440 Counterpane Internet Security 441 kelsey.j@ix.netcom.com 442 Draft Syslog Sign December 2000 444 B Full Copyright Statement 446 Copyright (C) The Internet Society (2000). All Rights Reserved. 448 This document and translations of it may be copied and furnished to 449 others, and derivative works that comment on or otherwise explain it or 450 assist in its implementation may be prepared, copied, published and 451 distributed, in whole or in part, without restriction of any kind, 452 provided that the above copyright notice and this paragraph are included 453 on all such copies and derivative works. However, this document itself 454 may not be modified in any way, such as by removing the copyright notice 455 or references to the Internet Society or other Internet organizations, 456 except as needed for the purpose of developing Internet standards in 457 which case the procedures for copyrights defined in the Internet 458 Standards process must be followed, or as required to translate it into 459 languages other than English. 461 The limited permissions granted above are perpetual and will not be 462 revoked by the Internet Society or its successors or assigns. 464 This document and the information contained herein is provided on an "AS 465 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 466 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 467 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 468 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 469 FITNESS FOR A PARTICULAR PURPOSE.