idnits 2.17.1 draft-ietf-syslog-sign-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1380. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (September 28, 2007) is 6055 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2440 (ref. '5') (Obsoleted by RFC 4880) == Outdated reference: A later version (-14) exists of draft-ietf-syslog-transport-tls-10 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 syslog Working Group J. Kelsey 3 Internet-Draft NIST 4 Intended status: Standards Track J. Callas 5 Expires: March 31, 2008 PGP Corporation 6 A. Clemm 7 Cisco Systems 8 September 28, 2007 10 Signed syslog Messages 11 draft-ietf-syslog-sign-23.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 31, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes a mechanism to add origin authentication, 45 message integrity, replay resistance, message sequencing, and 46 detection of missing messages to the transmitted syslog messages. 47 This specification is intended to be used in conjunction with the 48 work defined in RFC xxxx, "The syslog Protocol". 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Conventions Used in this Document . . . . . . . . . . . . . . 6 54 3. syslog Message Format . . . . . . . . . . . . . . . . . . . . 7 55 4. Signature Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 56 4.1. syslog Messages Containing a Signature Block . . . . . . . 8 57 4.2. Signature Block Format and Fields . . . . . . . . . . . . 8 58 4.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.2.2. Reboot Session ID . . . . . . . . . . . . . . . . . . 10 60 4.2.3. Signature Group and Signature Priority . . . . . . . . 10 61 4.2.4. Global Block Counter . . . . . . . . . . . . . . . . . 12 62 4.2.5. First Message Number . . . . . . . . . . . . . . . . . 13 63 4.2.6. Count . . . . . . . . . . . . . . . . . . . . . . . . 14 64 4.2.7. Hash Block . . . . . . . . . . . . . . . . . . . . . . 14 65 4.2.8. Signature . . . . . . . . . . . . . . . . . . . . . . 14 66 5. Payload and Certificate Blocks . . . . . . . . . . . . . . . . 15 67 5.1. Preliminaries: Key Management and Distribution Issues . . 15 68 5.2. Payload Block . . . . . . . . . . . . . . . . . . . . . . 16 69 5.3. Certificate Block . . . . . . . . . . . . . . . . . . . . 16 70 5.3.1. syslog Messages Containing a Certificate Block . . . . 16 71 5.3.2. Certificate Block Format and Fields . . . . . . . . . 17 72 6. Redundancy and Flexibility . . . . . . . . . . . . . . . . . . 20 73 6.1. Redundancy . . . . . . . . . . . . . . . . . . . . . . . . 20 74 6.1.1. Configuration Parameters for Certificate Blocks . . . 20 75 6.1.2. Configuration Parameters for Signature Blocks . . . . 20 76 6.2. Flexibility . . . . . . . . . . . . . . . . . . . . . . . 21 77 7. Efficient Verification of Logs . . . . . . . . . . . . . . . . 22 78 7.1. Offline Review of Logs . . . . . . . . . . . . . . . . . . 22 79 7.2. Online Review of Logs . . . . . . . . . . . . . . . . . . 23 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 8.1. Cryptographic Constraints . . . . . . . . . . . . . . . . 25 82 8.2. Packet Parameters . . . . . . . . . . . . . . . . . . . . 25 83 8.3. Message Authenticity . . . . . . . . . . . . . . . . . . . 26 84 8.4. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 26 85 8.5. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 26 86 8.6. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 26 87 8.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 26 88 8.8. Message Observation . . . . . . . . . . . . . . . . . . . 27 89 8.9. Man In The Middle Attacks . . . . . . . . . . . . . . . . 27 90 8.10. Denial of Service . . . . . . . . . . . . . . . . . . . . 27 91 8.11. Covert Channels . . . . . . . . . . . . . . . . . . . . . 27 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 93 9.1. Structured Data and syslog messages . . . . . . . . . . . 28 94 9.2. Version Field . . . . . . . . . . . . . . . . . . . . . . 28 95 9.3. SG Field . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 9.4. Key Blob Type . . . . . . . . . . . . . . . . . . . . . . 30 97 10. Working Group . . . . . . . . . . . . . . . . . . . . . . . . 31 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 101 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 103 Intellectual Property and Copyright Statements . . . . . . . . . . 36 105 1. Introduction 107 This document describes a mechanism, called syslog-sign in this 108 document, that adds origin authentication, message integrity, replay 109 resistance, message sequencing, and detection of missing messages to 110 syslog. Essentially, this is accomplished by sending a special 111 syslog message. The contents of this syslog message is called a 112 Signature Block. Each Signature Block contains, in effect, a 113 detached signature on some number of previously sent messages. It is 114 cryptographically signed and contains the hashes of previously sent 115 syslog messages. 117 While most implementations of syslog involve only a single originator 118 and a single collector of each message, provisions need to be made to 119 cover situations in which messages are sent to multiple collectors. 120 This concerns, in particular, situations in which different messages 121 are sent to different collectors, which means that some messages are 122 sent to some collectors but not to others. The required 123 differentiation of messages is generally performed based on the 124 Priority value of the individual messages. For example, messages 125 from any Facility with a Severity value of 3, 2, 1, or 0 may be sent 126 to one collector while all messages of Facilities 4, 10, 13, and 14 127 may be sent to another collector. Appropriate syslog-sign messages 128 must be kept with their proper syslog messages. To address this, 129 syslog-sign uses a Signature Group. A Signature Group identifies a 130 group of messages that are all kept together for signing purposes by 131 the originator. A Signature Block always belongs to exactly one 132 signature group and always signs messages belonging only to that 133 signature group. 135 Additionally, a originator sends a Certificate Block to provide key 136 management information between the originator and the collector. 137 This Certificate Block has a field to denote the type of key material 138 which may be such things as a PKIX certificate, an OpenPGP 139 certificate, or even an indication that a key had been 140 predistributed. In the cases of certificates being sent, the 141 certificates may have to be split across multiple packets. 143 The collector of the previous messages may verify that the hash of 144 each received message matches the signed hash contained in the 145 Signature Block. A collector may process these Signature Blocks as 146 they arrive, building an authenticated log file. Alternatively, it 147 may store all the log messages in the order they were received. This 148 allows a network operator to authenticate the log file at the time 149 the logs are reviewed. 151 The mechanism described in this specification is intended to be used 152 in conjunction with the syslog protocol as defined in RFC xxxx [8] as 153 its message delivery mechanism and uses the concept of STRUCTURED- 154 DATA elements defined in that document. In fact, this specification 155 mandates implementation of syslog protocol. Nevertheless, it is 156 conceivable that the concepts underlying this mechanism could also be 157 used in conjunction with other message delivery mechanisms. 158 Designers of other efforts to define event notification mechanisms 159 are therefore encouraged to consider this specification in their 160 designs. 162 NOTE to RFC editor: replace xxxx with the actual RFC number assigned 163 to [8], replace zzzz with the actual RFC number assigned to [9], 164 replace wwww with the actual RFC number assigned to [10], replace 165 yyyy with the actual RFC number assigned to this document, and remove 166 this note. 168 2. Conventions Used in this Document 170 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [11]. 174 3. syslog Message Format 176 This specification is intended to be used in conjunction with the 177 syslog protocol as defined in RFC xxxx [8]. The syslog protocol 178 therefore MUST be supported by implementations of this specification. 180 Because the originator generating the Signature Block message signs 181 each message in its entirety, the messages MUST NOT be changed in 182 transit. By the same token, the syslog-sign messages MUST NOT be 183 changed in transit. Specifically, a relay as described in RFC xxxx 184 [8] MAY make changes to a syslog packet. If this occurs, the 185 mechanism described in this document is rendered useless. Likewise, 186 any truncation of messages that occurs between sending and receiving 187 renders the mechanism useless. For this reason, syslog originator 188 and collector implementations implementing this specification MUST 189 support messages of up to and including 2048 octets in length, in 190 order to minimize the chance of truncation. While syslog originator 191 and collector implementations MAY support messages with a length 192 larger than 2048 octets, implementors need to be aware that any 193 message truncations that occur render the mechanism useless. 195 This specification uses the syslog message format described in RFC 196 xxxx [8]. Along with other fields, that document describes the 197 concept of Structured Data (SD). Structured Data is defined in terms 198 of SD ELEMENTS (SDEs). An SDE consists of a name and a set of 199 parameter name - value pairs. The SDE name is referred to as SD-ID. 200 The name-value pairs are referred to as SD-PARAM, or SD Parameters, 201 with the name constituting the SD-PARAM-NAME, and the value 202 constituting the SD-PARAM-VALUE. 204 The syslog messages defined in this document carry the signature and 205 certificate data as Structured Data. The special syslog messages 206 defined in this document include for this purpose definitions of SDEs 207 to convey parameters that relate to the signing of syslog messages. 208 The MSG part of the syslog messages defined in this document SHOULD 209 simply be empty -- the content of the messages is not intended for 210 interpretation by humans but by applications that use those messages 211 to build an authenticated log. 213 Because the syslog messages defined in this document adhere to the 214 format described in RFC xxxx [8], they identify the machine that 215 originates the syslog message in the HOSTNAME field. Therefore, the 216 signature and certificate data do not need to include an additional 217 parameter to identify the machine that orginates the message. 219 4. Signature Blocks 221 This section describes the format of the Signature Block and the 222 fields used within the Signature Block, as well as the syslog 223 messages used to carry the Signature Block. 225 4.1. syslog Messages Containing a Signature Block 227 There is a need to distinguish the Signature Block itself from the 228 syslog message that is used to carry a Signature Block. Signature 229 Blocks MUST be encompassed within completely formed syslog messages. 230 Syslog messages that contain a Signature Block are also referred to 231 as Signature Block messages. 233 A Signature Block message is identified by the presence of an SD 234 ELEMENT with an SD-ID with the value "ssign". In addition, a 235 Signature Block message MUST contain valid APP-NAME, PROCID, and 236 MSGID fields to be compliant with RFC xxxx [8]. This specification 237 does not mandate particular values for these fields; however, for 238 consistency, originators SHOULD use the same values for APP-NAME, 239 PROCID, and MSGID fields for every Signature Block message that is 240 sent, whichever values are chosen. It is RECOMMENDED (but not 241 required) to use 110 as value for the PRI field, corresponding to 242 facility 13 and severity 6 (informational). The Signature Block is 243 carried as Structured Data within the Signature Block message, per 244 the definitions that follow in the next section. A Signature Block 245 message SHOULD NOT carry other Structured Data besides the Structured 246 Data of the Signature Block itself. 248 The syslog messages defined as part of syslog-sign themselves 249 (Signature Block messages and Certificate Block messages) do not need 250 to be signed by a Signature Block. Collectors that implement syslog- 251 sign know to distinguish syslog messages that are associated with 252 syslog-sign from those that are subjected to signing and process them 253 differently. 255 4.2. Signature Block Format and Fields 257 The content of a Signature Block message is the Signature Block. The 258 Signature Block MUST be encoded as an SD ELEMENT, as defined in RFC 259 xxxx [8]. 261 The SD-ID MUST have the value of "ssign". 263 The SDE contains the fields of the Signature Block encoded as SD 264 Parameters, as specified in the following. The Signature Block is 265 composed of the following fields. The value of each field MUST be 266 printable ASCII, and any binary values MUST be base 64 encoded, as 267 defined in RFC 4648 [7]. 269 Field SD-PARAM-NAME Size in octets 270 ----- ------------- ---- -- ------ 272 Version VER 4 274 Reboot Session ID RSID 1-10 276 Signature Group SG 1 278 Signature Priority SPRI 1-3 280 Global Block Counter GBC 1-10 282 First Message Number FMN 1-10 284 Count CNT 1-2 286 Hash Block HB variable, size of hash 287 times the number of hashes 288 (base 64 encoded binary) 290 Signature SIGN variable 291 (base 64 encoded binary) 293 A Signature Block is accordingly encoded as follows, where xxx 294 denotes a placeholder for the particular values: 296 [ssign VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" GBC="xxx" FMN="xxx" 297 CNT="xxx" HB="xxx" SIGN="xxx"] 299 Values of the fields constitute SD parameter values and are hence 300 enclosed in quotes, per RFC xxxx [8]. The fields are separated by 301 single spaces and are described below. 303 4.2.1. Version 305 The Signature Block Version field is a decimal value that has a 306 length of 4 octets, which may include leading zeroes. Each octet 307 contains a decimal character in the range of "0" to "9". The value 308 in this field specifies the version of the syslog-sign protocol. 309 This is extensible to allow for different hash algorithms and 310 signature schemes to be used in the future. The value of this field 311 is the grouping of the protocol version (2 octets), the hash 312 algorithm (1 octet) and the signature scheme (1 octet). 314 Protocol Version - 2 octets, with "01" as the value for the 315 protocol version that is described in this document. 317 Hash Algorithm - 1 octet, where, in conjunction with Protocol 318 Version 01, a value of "1" denotes SHA1 and a value of "2" denotes 319 SHA256, as defined in FIPS-180-2.2002 [2]. 321 Signature Scheme - 1 octet, where, in conjunction with Protocol 322 Version 01, a value of "1" denotes OpenPGP DSA, defined in RFC 323 2440 [5] and FIPS.186-2.2000 [1]. 325 The version, hash algorithm and signature scheme defined in this 326 document would accordingly be represented as "0111" (if SHA1 is used 327 as Hash Algorithm) and "0121" (if SHA256 is used as Hash Algorithm), 328 respectively (without the quotation marks). 330 The values of the Hash Algorithm and Signature Scheme are defined 331 relative to the Protocol Version. If the single-octet representation 332 of the values for Hash Algorithm and Signature Scheme were to ever 333 represent a limitation, this limitation could be overcome by defining 334 a new Protocol Version with additional Hash Algorithms and/or 335 Signature Schemes, and having implementations support both Protocol 336 Versions concurrently. 338 4.2.2. Reboot Session ID 340 The Reboot Session ID is a decimal value that has a length between 1 341 and 10 octets. The acceptable values for this are between 0 and 342 9999999999. Leading zeroes MUST be omitted. A Reboot Session ID is 343 expected to increase whenever an originator reboots in order to allow 344 collectors to distinguish messages and message signatures across 345 reboots. Hence, an originator needs to retain the previous Reboot 346 Session ID across reboots. In cases where an originator does not 347 support this capability, the Reboot Session ID MUST always be set to 348 a value of 0, which indicates that this capability is not supported. 349 Otherwise, it MUST increase whenever an originator reboots, starting 350 with a value of 1. If the value reaches 9999999999, then manual 351 intervention may be required to subsequently reset it to 1. 352 Implementors MAY wish to consider using the snmpEngineBoots value as 353 a source for this counter as defined in RFC 3414 [6]. 355 4.2.3. Signature Group and Signature Priority 357 The SG parameter may take any value from 0-3 inclusive. The SPRI 358 parameter may take any value from 0-191 inclusive. These fields 359 taken together allow network administrators to associate groupings of 360 syslog messages with appropriate Signature Blocks and Certificate 361 Blocks. Groupings of syslog messages that are signed together are 362 also called Signature Groups. A Signature Block contains only hashes 363 of those syslog messages that are part of the same Signature Group. 365 For example, in some cases, network administrators might have 366 originators send syslog messages of Facilities 0 through 15 to one 367 collector and those with Facilities 16 through 23 to another. In 368 such cases, associated Signature Blocks should likely be sent to the 369 corresponding collectors as well, signing the syslog messages that 370 are intended for each collector separately. This way, each collector 371 receives Signature Blocks for all syslog messages that it receives, 372 and only for those. The ability to associate different categories of 373 syslog messages with different Signature Groups, signed in separate 374 Signature Blocks, provides administrators with flexibility in this 375 regard. 377 Syslog-sign provides four options for handling Signature Groups, 378 linking them with PRI values so they may be routed to the destination 379 commensurate with the corresponding syslog messages. In all cases, 380 no more than 192 distinct Signature Groups (0-191) are permitted. 382 The Signature Group to which a Signature Block pertains is indicated 383 by the Signature Priority (SPRI) field. The Signature Group (SG) 384 field indicates how to interpret the Signature Priority field. (Note 385 that the SG field does not indicate the Signature Group itself, as 386 its name might suggest.) The SG field can have one of the following 387 values: 389 a. "0" -- There is only one Signature Group. In this case, the 390 administrators want all Signature Blocks to be sent to a single 391 destination; in all likelihood, all of the syslog messages will 392 also be going to that same destination. Signature Blocks sign 393 all messages regardless of their PRI value. This means that, in 394 effect, the Signature Block's SPRI value can be ignored. 395 However, it is RECOMMENDED that a single SPRI value be used for 396 all Signature Blocks. Furthermore, it is RECOMMENDED to set that 397 value to the same value as the PRI field of the Signature Block 398 message. This way, the PRI of the Signature Block message 399 matches the SPRI of the Signature Block that it contains. 401 b. "1" -- Each PRI value is associated with its own Signature Group. 402 Signature Blocks for a given Signature Group have SPRI = PRI for 403 that Signature Group. In other words, the SPRI of the Signature 404 Block matches the PRI value of the syslog messages that are part 405 of the Signature Group and hence signed by the Signature Block. 406 An SG value of 1 can, for example, be used when the administrator 407 of an originator does not know where any of the syslog messages 408 will ultimately go but anticipates that messages with different 409 PRI values will be collected and processed separately. Having a 410 Signature Group per PRI value provides administrators with a 411 large degree of flexibility with regard to how to divide up the 412 processing of syslog messages and their signatures after they are 413 received, at the same time allowing Signature Blocks to follow 414 the corresponding syslog messages to their eventual destination. 416 c. "2" -- Each Signature Group contains a range of PRI values. 417 Signature Groups are assigned sequentially. A Signature Block 418 for a given Signature Group has its own SPRI value denoting the 419 highest PRI value of syslog messages in that Signature Group. 420 The lowest PRI value of syslog messages in that Signature Group 421 will be one larger than the SPRI value of the previous Signature 422 Group or "0" in case there is no other Signature Group with a 423 lower SPRI value. The specific Signature Groups and ranges they 424 are associated with are subject to configuration by a system 425 administrator. 427 d. "3" -- Signature Groups are not assigned with any of the above 428 relationships to PRI values of the syslog messages they sign. 429 Instead, another scheme is used, which is outside the scope of 430 this specification. There has to be some predefined arrangement 431 between the originator and the intended collectors as to which 432 syslog messages are to be included in which Signature Group, 433 requiring configuration by a system administrator. This provides 434 administrators also with the flexibility to group syslog messages 435 into Signature Groups according to criteria that are not tied to 436 the PRI value. 438 One reasonable way to configure some installations is to have only 439 one Signature Group, indicated with SG=0, and have the originator 440 send a copy of each Signature Block to each collector. In that case, 441 collectors that are not configured to receive every syslog message 442 will still receive signatures for every message, even ones they are 443 not supposed to receive. While the collector will not be able to 444 detect gaps in the messages (because the presence of a signature of a 445 message that is missing does not tell the collector whether or not 446 the corresponding message would be of the collector's concern), it 447 does allow all messages that do arrive at each collector to be put 448 into the right order and to be verified. It also allows each 449 collector to detect duplicates. Likewise, configuring only one 450 Signature Group can be a reasonable way to configure installations 451 that involve relay chains, where one or more interim relays may or 452 may not relay all messages to the same destination. 454 4.2.4. Global Block Counter 456 The Global Block Counter is a decimal value representing the number 457 of Signature Blocks sent by syslog-sign before the current one, in 458 this reboot session. This takes at least 1 octet and at most 10 459 octets displayed as a decimal counter. The acceptable values for 460 this are between 0 and 9999999999, starting with 0. Leading zeroes 461 MUST be omitted. If the value of the Global Block Counter has 462 reached 9999999999 and the Reboot Session ID has a value other than 0 463 (indicating the fact that persistence of the Reboot Session ID is 464 supported), then the Reboot Session ID MUST be incremented by 1 and 465 the Global Block Counter resumes at 0. When the Reboot Session ID is 466 0 (i.e., persistent Reboot Session IDs are not supported) and the 467 Global Block Counter reaches its maximum value, then the Global Block 468 Counter is reset to 0 and the Reboot Session ID MUST remain at 0. 470 Note that the Global Block Counter crosses Signature Groups; it 471 allows one to roughly synchronize when two messages were sent, even 472 though they went to different collectors and are part of different 473 Signature Groups. 475 Because a reboot results in the start of a new reboot session, the 476 originator MUST reset the Global Block Counter to 0 after a reboot 477 occurs. Applications need to take into account the possibility that 478 a reboot occurred when authenticating a log, and situations in which 479 reboots occur frequently may result in losing the ability to verify 480 the proper sequence in which messages were sent, hence jeopardizing 481 the integrity of the log. 483 4.2.5. First Message Number 485 This is a decimal value between 1 and 10 octets, with leading zeroes 486 omitted. It contains the unique message number within this Signature 487 Group of the first message whose hash appears in this block. The 488 very first message of the reboot session is numbered "1". This 489 implies that when the Reboot Session ID increases, the message number 490 is reset to 1. 492 For example, if this Signature Group has processed 1000 messages so 493 far and message number 1001 is the first message whose hash appears 494 in this Signature Block, then this field contains 1001. The message 495 number is relative to the Signature Group to which it belongs; hence, 496 a message number does not identify a message beyond its Signature 497 Group. 499 Should the message number reach 9999999999 within the same reboot 500 session and Signature Group, the message number subsequently restarts 501 at 1. In such event, the Global Block Counter will be vastly 502 different between two occurrences of the same message number. 504 4.2.6. Count 506 The count is a 1 or 2 octet field that indicates the number of 507 message hashes to follow. The valid values for this field are 1 508 through 99. The number of hashes included in the Signature Block 509 MUST be chosen such that the length of the resulting syslog message 510 does not exceed the maximum permissible syslog message length. 512 4.2.7. Hash Block 514 The hash block is a block of hashes, each separately encoded in base 515 64. Each hash in the hash block is the hash of the entire syslog 516 message represented by the hash, independent of the underlying 517 transport. Hashes are ordered from left to right in the order of 518 occurrence of the syslog messages that they represent. 520 The "entire syslog message" refers to what is described as the syslog 521 message excluding transport parts that are described in RFC zzzz [9] 522 and RFC wwww [10], and excluding other parts that may be defined in 523 future transports. The hash value will be the result of the hashing 524 algorithm run across the syslog message, starting with the "<" of the 525 PRI portion of the header part of the message. The hash algorithm 526 used and indicated by the Version field determines the size of each 527 hash, but the size MUST NOT be shorter than 160 bits without the use 528 of padding. It is base 64 encoded as per RFC 4648 [7]. 530 The number of hashes in a hash block SHOULD be chosen such that the 531 resulting Signature Block message does not exceed a length of 2048 532 octets in order to avoid the possibility that truncation occurs. 533 When more hashes need to be sent than fit inside a Signature Block 534 message, it is advisable to start a new Signature Block. 536 4.2.8. Signature 538 This is a digital signature, encoded in base 64 per RFC 4648 [7]. 539 The signature is calculated over the completely formatted syslog- 540 message, including all of the PRI, HEADER, and hashes in the hash 541 block, excluding spaces between fields, and also excluding the 542 signature field (SD Parameter Name "SIGN", "=", and corresponding 543 value). 545 5. Payload and Certificate Blocks 547 Certificate Blocks and Payload Blocks provide key management for 548 syslog-sign. Their purpose is to support key management that uses 549 public key cryptosystems. 551 5.1. Preliminaries: Key Management and Distribution Issues 553 A Payload Block contains public key certificate information that is 554 to be conveyed to the collector. A Payload Block is sent at the 555 beginning of a new reboot session, carrying public key information in 556 effect for the reboot session. However, a Payload Block is not sent 557 directly, but in (one or more) fragments. Those fragments are termed 558 Certificate Blocks. Therefore, originators send at least one 559 Certificate Block at the beginning of a new reboot session. 561 There are three key points to understand about Certificate Blocks: 563 a. They handle a variable-sized payload, fragmenting it if necessary 564 and transmitting the fragments as legal syslog messages. This 565 payload is built (as described below) at the beginning of a 566 reboot session and is transmitted in pieces with each Certificate 567 Block carrying a piece. There is exactly one Payload Block per 568 reboot session. 570 b. The Certificate Blocks are digitally signed. The originator does 571 not sign the Payload Block, but the signatures on the Certificate 572 Blocks ensure its authenticity. Note that it may not even be 573 possible to verify the signature on the Certificate Blocks 574 without the information in the Payload Block; in this case the 575 Payload Block is reconstructed, the key is extracted, and then 576 the Certificate Blocks are verified. (This is necessary even 577 when the Payload Block carries a certificate, because some other 578 fields of the Payload Block are not otherwise verified.) In 579 practice, most installations keep the same public key over long 580 periods of time, so that most of the time, it is easy to verify 581 the signatures on the Certificate Blocks, and use the Payload 582 Block to provide other useful per-session information. 584 c. The kind of Payload Block that is expected is determined by what 585 kind of key material is on the collector that receives it. The 586 originator and collector (or offline log viewer) both have some 587 key material (such as a root public key or predistributed public 588 key) and an acceptable value for the Key Blob Type in the Payload 589 Block, below. The collector or offline log viewer MUST NOT 590 accept a Payload Block of the wrong type. 592 5.2. Payload Block 594 The Payload Block is built when a new reboot session is started. 595 There is a one-to-one correspondence between reboot sessions and 596 Payload Blocks. An originator creates a new Payload Block after each 597 reboot. The Payload Block is used until the next reboot. A Payload 598 Block MUST have the following fields: 600 a. Full local time stamp for the originator at the time the reboot 601 session started. This must be in the time stamp format specified 602 in RFC xxxx [8] (essentially, time stamp format per RFC 3339 [12] 603 with some further restrictions). 605 b. Key Blob Type, a one-octet field containing one of five values: 607 1. 'C' -- a PKIX certificate. 609 2. 'P' -- an OpenPGP certificate. 611 3. 'K' -- the public key whose corresponding private key is 612 being used to sign these messages. 614 4. 'N' -- no key information sent; key is predistributed. 616 5. 'U' -- installation-specific key exchange information 618 c. The key blob, if any, base 64 encoded per RFC 4648 [7] and 619 consisting of the raw key data. 621 The fields are separated by single space characters. Because a 622 Payload Block is not carried in a syslog message directly, only the 623 corresponding Certificate Blocks, it does not need to be encoded as 624 an SD ELEMENT. The Payload Block does not contain a field that 625 identifies the reboot session; instead, the reboot session can be 626 inferred from the Reboot Session ID parameter of the Certificate 627 Blocks that are used to carry the Payload Block. 629 5.3. Certificate Block 631 This section describes the format of the Certificate Block and the 632 fields used within the Certificate Block, as well as the syslog 633 messages used to carry Certificate Blocks. 635 5.3.1. syslog Messages Containing a Certificate Block 637 Certificate Blocks are used to get the Payload Block to the 638 collector. As with a Signature Block, each Certificate Block is 639 carried in its own syslog message, called Certificate Block message. 641 Because certificates can legitimately be much longer than 2048 642 octets, the Payload Block can be split up into several pieces, with 643 each Certificate Block carrying a piece of the Payload Block. Note 644 that the originator MAY make the Certificate Blocks of any legal 645 length (that is, any length that keeps the entire Certificate Block 646 message within 2048 octets) that holds all the required fields. 647 Software that processes Certificate Blocks MUST deal correctly with 648 blocks of any legal length. The length of the fragment of the 649 Payload Block that a Certificate Block carries MUST be at least 1 650 octet. The length SHOULD be chosen such that the length of the 651 Certificate Block message does not exceed 2048 octets. 653 A Certificate Block message is identified by the presence of an SD 654 ELEMENT with an SD-ID with the value "ssign-cert". In addition, a 655 Certificate Block message MUST contain valid APP-NAME, PROCID, and 656 MSGID fields to be compliant with syslog protocol. Syslog-sign does 657 not mandate particular values for these fields; however, for 658 consistency, implementations SHOULD use the same value for APP-NAME, 659 PROCID, and MSGID fields for every Certificate Block message, 660 whichever values are chosen. It is RECOMMENDED to use 110 as value 661 for the PRI field, corresponding to facility 13 and severity 6 662 (informational). The Certificate Block is carried as Structured Data 663 within the Certificate Block message. A Certificate Block message 664 SHOULD NOT carry other Structured Data besides the Structured Data of 665 the Certificate Block itself. The MSG part of a Certificate Block 666 message SHOULD be empty. 668 5.3.2. Certificate Block Format and Fields 670 The contents of a Certificate Block message is the Certificate Block 671 itself. Like a Signature Block, the Certificate Block is encoded as 672 an SD ELEMENT. The SD-ID of the Certificate Block is "ssign-cert". 673 The Certificate Block is composed of the following fields, each of 674 which is encoded as an SD Parameter with parameter name as indicated. 675 Each field must be printable ASCII, and any binary values are base 64 676 encoded per RFC 4648 [7]. 678 Field SD-PARAM-NAME Size in octets 679 ----- ------------- ---- -- ------ 681 Version VER 4 683 Reboot Session ID RSID 1-10 685 Signature Group SG 1 687 Signature Priority SPRI 1-3 689 Total Payload Block Length TPBL 1-8 691 Index into Payload Block INDEX 1-8 693 Fragment Length FLEN 1-4 695 Payload Block Fragment FRAG variable 696 (base 64 encoded binary) 698 Signature SIGN variable 699 (base 64 encoded binary) 701 A Certificate Block is accordingly encoded as follows, where xxx 702 denotes a placeholder for the particular values: 704 [ssign-cert VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" TBPL="xxx" 705 INDEX="xxx" FLEN="xxx" FRAG="xxx" SIGN="xxx"] 707 Values of the fields constitute SD parameter values and are hence 708 enclosed in quotes, per RFC xxxx [8]. The fields are separated by 709 single spaces and are described below. 711 5.3.2.1. Version 713 The Signature Group version field is 4 octets in length. This field 714 is identical in format and meaning to the Version field described in 715 Section 4.2.1. 717 5.3.2.2. Reboot Session ID 719 The Reboot Session ID is identical in format and meaning to the RSID 720 field described in Section 4.2.2. 722 5.3.2.3. Signature Group and Signature Priority 724 The SIG field is identical in format and meaning to the SIG field 725 described in Section 4.2.3. The SPRI field is identical in format 726 and meaning to the SPRI field described there. 728 5.3.2.4. Total Payload Block Length 730 The Total Payload Block Length is a value representing the total 731 length of the Payload Block in octets, expressed as a decimal with 732 one to eight octets. 734 5.3.2.5. Index into Payload Block 736 This is a decimal value between 1 and 8 octets, with leading zeroes 737 omitted. It contains the number of octets into the Payload Block at 738 which this fragment starts. The first octet of the first fragment is 739 numbered "1". 741 5.3.2.6. Fragment Length 743 The total length of this fragment expressed as a decimal integer with 744 one to four octets. The fragment length must be at least 1. 746 5.3.2.7. Payload Block Fragment 748 The Payload Block Fragment contains a fragment of the payload block, 749 encoded in base 64, as per RFC 4648 [7]. Its length must match the 750 indicated fragment length. 752 5.3.2.8. Signature 754 This is a digital signature, encoded in base 64, as per RFC 4648 [7]. 755 The Version field effectively specifies the original encoding of the 756 signature. The signature is calculated over the completely formatted 757 syslog message, including all of the PRI, HEADER, and certificate 758 block, excluding spaces between fields, and also excluding the 759 signature field itself (SD Parameter Name "SIGN", "=", and 760 corresponding value). 762 6. Redundancy and Flexibility 764 There is a general rule that determines how redundancy works and what 765 level of flexibility the originator and collector have in message 766 formats: in general, the originator is allowed to send Signature and 767 Certificate Blocks multiple times, to send Signature and Certificate 768 Blocks of any legal length, to include fewer hashes in hash blocks, 769 etc. 771 6.1. Redundancy 773 Syslog messages are in general sent over unreliable transport, which 774 means that they can be lost in transit. However, if a collector does 775 not receive Signature and Certificate Blocks, many messages may not 776 be able to be verified. Sending Signature and Certificate Blocks 777 multiple times provides redundancy; because the collector MUST ignore 778 Signature/Certificate Blocks it has already received and 779 authenticated, the originator can in principle change its redundancy 780 level for any reason, without communicating this fact to the 781 collector. 783 Although the transport sender is not constrained in how it decides to 784 send redundant Signature and Certificate Blocks, or even in whether 785 it decides to send along multiple copies of normal syslog messages, 786 we define some redundancy parameters below which may be useful in 787 controlling redundant transmission from the transport sender to the 788 transport receiver, and which may be useful for administrators to 789 configure. 791 6.1.1. Configuration Parameters for Certificate Blocks 793 certInitialRepeat = number of times each Certificate Block should be 794 sent before the first message is sent. 796 certResendDelay = maximum time delay in seconds to delay before next 797 redundant sending. 799 certResendCount = maximum number of sent messages to delay before 800 next redundant sending. 802 6.1.2. Configuration Parameters for Signature Blocks 804 sigNumberResends = number of times a Signature Block is resent. 806 sigResendDelay = maximum time delay in seconds from original sending 807 to next redundant sending. 809 sigResendCount = maximum number of sent messages to delay before next 810 redundant sending. 812 6.2. Flexibility 814 An originator may change many things about the makeup of Signature 815 and Certificate Blocks in a given reboot session. The things it 816 cannot change are: 818 * The version 820 * The number or arrangements of Signature Groups 822 It is legitimate for an originator to send short Signature Blocks to 823 allow the collector to verify messages quickly. 825 7. Efficient Verification of Logs 827 The logs secured with syslog-sign may be reviewed either online or 828 offline. Online review is somewhat more complicated and 829 computationally expensive, but not prohibitively so. 831 7.1. Offline Review of Logs 833 When the collector stores logs to be reviewed later, they can be 834 authenticated offline just before they are reviewed. Reviewing these 835 logs offline is simple and relatively inexpensive in terms of 836 resources used, so long as there is enough space available on the 837 reviewing machine. Here, we presume that the stored log files have 838 already been separated by originator, Reboot Session ID, and 839 Signature Group. This can be done easily with a script file. We 840 then do the following: 842 a. First, we go through the raw log file and split its contents into 843 three files. Each message in the raw log file is classified as a 844 normal message, a Signature Block message, or a Certificate Block 845 message. Signature Blocks and Certificate Blocks are then stored 846 in their own files. Normal messages are stored in a keyed file, 847 indexed on their hash values. 849 b. We sort the Certificate Block file by INDEX value, and check to 850 see whether we have a set of Certificate Blocks that can 851 reconstruct the Payload Block. If so, we reconstruct the Payload 852 Block, verify any key-identifying information, and then use this 853 to verify the signatures on the Certificate Blocks we have 854 received. When this is done, we have verified the reboot session 855 and key used for the rest of the process. 857 c. We sort the Signature Block file by First Message Number. We now 858 create an authenticated log file, which consists of some header 859 information and then a sequence of message number, message text 860 pairs. We next go through the Signature Block file. For each 861 Signature Block in the file, we do the following: 863 1. Verify the signature on the Block. 865 2. For each hashed message in the Block: 867 a. Look up the hash value in the keyed message file. 869 b. If the message is found, write (message number, message 870 text) to the authenticated log file. 872 Skip all other Signature Blocks with the same First Message 873 Number. 875 The resulting authenticated log file contains all messages that 876 have been authenticated. In addition, it implicitly indicates 877 all gaps in the authenticated messages (specifically in the case 878 when all messages of the same Signature Group are sent to the 879 same collector), because their message numbers are missing. 881 One can see that, assuming sufficient space for building the keyed 882 file, this whole process is linear in the number of messages 883 (generally two seeks, one to write and the other to read, per normal 884 message received), and O(N lg N) in the number of Signature Blocks. 885 This estimate comes with two caveats: first, the Signature Blocks 886 arrive very nearly in sorted order, and so can probably be sorted 887 more cheaply on average than O(N lg N) steps. Second, the signature 888 verification on each Signature Block almost certainly is more 889 expensive than the sorting step in practice. We have not discussed 890 error-recovery, which may be necessary for the Certificate Blocks. 891 In practice, a simple error-recovery strategy is probably enough: if 892 the Payload Block is not valid, then we can just try alternate 893 instances of each Certificate Block, if such are available, until we 894 get the Payload Block right. 896 It is easy for an attacker to flood us with plausible-looking 897 messages, Signature Blocks, and Certificate Blocks. 899 7.2. Online Review of Logs 901 Some collector implementations may need to monitor log messages in 902 close to real-time. This can be done with syslog-sign, though it is 903 somewhat more complex than offline verification. This is done as 904 follows: 906 a. We have an authenticated message file, into which we write 907 (message number, message text) pairs which have been 908 authenticated. Again, we will assume that we are handling only 909 one Signature Group and only one Reboot Session ID at any given 910 time. 912 b. We have three data structures: A queue in which (message number, 913 hash of message) pairs are kept in sorted order, a queue in which 914 (arrival sequence, hash of message) pairs are kept in sorted 915 order, and a hash table that stores (message text, count) pairs 916 indexed by hash value. In the hash table, count may be any 917 number greater than zero; when count is zero, the entry in the 918 hash table is cleared. 920 c. We must receive all the Certificate Blocks before any other 921 processing can really be done. (This is why they are sent 922 first.) Once that is done, any Certificate Block message that 923 arrives is discarded. 925 d. Whenever a normal message arrives, we add (arrival sequence, hash 926 of message) to our message queue. If our hash table has an entry 927 for the message's hash value, we increment its count by one; 928 otherwise, we create a new entry with count = 1. If the message 929 queue is full, we roll the oldest messages off the queue by 930 taking the oldest entry in the queue, and using it to index the 931 hash table. If that entry has count 1, we delete the entry from 932 the hash table; otherwise, we decrement its count. We then 933 delete the oldest entry in the queue. 935 e. Whenever a Signature Block message arrives, we first check to see 936 whether the First Message Number value is too old to still be of 937 interest, or if another Signature Block with that First Message 938 Number has already been received. If so, we discard the 939 Signature Block. Otherwise, we check its signature and discard 940 it if the signature is not valid. A Signature Block contains a 941 sequence of (message number, message hash) pairs. For each pair, 942 we first check to see whether the message hash is in the hash 943 table. If so, we write the (message number, message text) into 944 the authenticated message queue. Otherwise, we write the 945 (message number, message hash) to the message number queue. This 946 generally involves rolling the oldest entry out of this queue: 947 before this is done, that entry's hash value is again looked up 948 in the hash table. If a matching entry is found, the (message 949 number, message text) pair is written to the authenticated 950 message file. In either case, the oldest entry is then 951 discarded. 953 f. The result of this is a sequence of messages in the authenticated 954 message file, each of which has been authenticated, and which are 955 labeled with numbers showing their order of original 956 transmission. 958 One can see that this whole process is roughly linear in the number 959 of messages, and also in the number of Signature Blocks received. 960 The process is susceptible to flooding attacks; an attacker can send 961 enough normal messages that the messages roll off their queue before 962 their Signature Blocks can be processed. 964 8. Security Considerations 966 Normal syslog event messages are unsigned and have most of the 967 security attributes described in Section 8 of RFC xxxx [8]. This 968 document also describes Certificate Blocks and Signature Blocks, 969 which are signed syslog messages. The Signature Blocks contain 970 signature information for previously sent syslog event messages. All 971 of this information can be used to authenticate syslog messages and 972 to minimize or obviate many of the security concerns described in RFC 973 xxxx [8]. 975 8.1. Cryptographic Constraints 977 As with any technology involving cryptography, it is advisable to 978 check the current literature to determine whether any algorithms used 979 here have been found to be vulnerable to attack. 981 This specification uses Public Key Cryptography technologies. The 982 proper party or parties have to control the private key portion of a 983 public-private key pair. Any party that controls a private key can 984 sign anything it pleases. 986 Certain operations in this specification involve the use of random 987 numbers. An appropriate entropy source SHOULD be used to generate 988 these numbers. See RFC 4086 [13] and NIST SP 800-90 [3]. 990 8.2. Packet Parameters 992 As an originator, it is advisable to avoid message lengths exceeding 993 2048 octets. Various problems might result if an originator were to 994 send messages with a length greater than 2048 octets, because relays 995 MAY truncate messages with lengths greater than 2048 octets which 996 would make it impossible for collectors to validate a hash of the 997 packet. To increase the chance of interoperability, it tends to be 998 best to be conservative with what you send but liberal in what you 999 are able to receive. 1001 Originators need to rigidly enforce the correctness of message 1002 bodies. Problems may arise if the collector does not fully accept 1003 the syslog packets sent from an originator, or if it has problems 1004 with the format of the Certificate Block or Signature Block messages. 1006 Collectors are not to malfunction in case they receive malformed 1007 syslog messages or messages containing characters other than those 1008 specified in this document. In other words, they are to ignore such 1009 messages and continue working. 1011 8.3. Message Authenticity 1013 Syslog does not strongly associate the message with the message 1014 originator. That association is established by the collector upon 1015 verification of the Signature Block. Before a Signature Block is 1016 used to ascertain the authenticity of an event message, it might be 1017 received, stored, and reviewed by a person or automated parser. It 1018 is advisable not to assume a message is authentic until after a 1019 message has been validated by checking the contents of the Signature 1020 Block. 1022 With the Signature Block checking, an attacker may only forge 1023 messages if it can compromise the private key of the true originator. 1025 8.4. Replaying 1027 Event messages might be recorded and replayed by an attacker. Using 1028 the information contained in the Signature Blocks, a reviewer can 1029 determine whether the received messages are the ones originally sent 1030 by an originator. The reviewer can also identify messages that have 1031 been replayed. 1033 8.5. Reliable Delivery 1035 RFC wwww [10] can be used for the reliable delivery of syslog 1036 messages. Event messages sent over UDP might be lost in transit. A 1037 reviewer can pinpoint any messages sent by the originator but not 1038 received by the collector by reviewing the Signature Block 1039 information. In addition, the information in subsequent Signature 1040 Blocks allows a reviewer to determine whether any Signature Block 1041 messages were lost in transit. 1043 8.6. Sequenced Delivery 1045 Syslog messages delivered over UDP might not only be lost, but also 1046 arrive out of sequence. A reviewer can determine the original order 1047 of syslog messages and identify which messages were delivered out of 1048 order by examining the information in the Signature Block along with 1049 any timestamp information in the message. 1051 8.7. Message Integrity 1053 Syslog messages might be damaged in transit. A review of the 1054 information in the Signature Block determines whether the received 1055 message was the intended message sent by the originator. A damaged 1056 Signature Block or Certificate Block is evident because the collector 1057 will not be able to validate that it was signed by the originator. 1059 8.8. Message Observation 1061 Event messages, Certificate Blocks, and Signature Blocks are all sent 1062 in plaintext. This allows network administrators to read the message 1063 when sniffing the wire. However, this also allows an attacker to see 1064 the contents of event messages and perhaps to use that information 1065 for malicious purposes. 1067 8.9. Man In The Middle Attacks 1069 It is conceivable that an attacker might intercept Certificate Block 1070 messages and insert its own Certificate information. In that case, 1071 the attacker would be able to receive event messages from the actual 1072 originator and then relay modified messages, insert new messages, or 1073 delete messages. It would then be able to construct a Signature 1074 Block and sign it with its own private key. Network administrators 1075 need to verify that the key contained in the Payload Block is indeed 1076 the key being used on the actual originator. If that is the case, 1077 then this MITM attack will not succeed. 1079 8.10. Denial of Service 1081 An attacker might send invalid Signature Block messages to overwhelm 1082 the collector's processing capability and consume all available 1083 resources. For this reason, it can be appropriate to simply receive 1084 the Signature Block messages and process them only as time permits. 1086 An attacker might also just overwhelm a collector by sending more 1087 messages to it than it can handle. Implementors are advised to 1088 consider features that minimize this threat, such as only accepting 1089 syslog messages from known IP addresses. 1091 8.11. Covert Channels 1093 Nothing in this protocol attempts to eliminate covert channels. In 1094 fact, just about every aspect of syslog messages lends itself to the 1095 conveyance of covert signals. For example, a collusionist could send 1096 odd and even PRI values to indicate Morse Code dashes and dots. 1098 9. IANA Considerations 1100 9.1. Structured Data and syslog messages 1102 With regard to RFC xxxx [8], IANA is requested to add the following 1103 values to the registry entitled "syslog Structured Data id values": 1105 SD-ID PARAM_NAME 1106 ----- ---------- 1107 ssign 1108 VER 1109 RSID 1110 SG 1111 SPRI 1112 GBC 1113 FMN 1114 CNT 1115 HB 1116 SIGN 1118 ssign-cert 1119 VER 1120 RSID 1121 SG 1122 SPRI 1123 TBPL 1124 INDEX 1125 FLEN 1126 FRAG 1127 SIGN 1129 In addition, several fields need to be controlled by the IANA in both 1130 the Signature Block and the Certificate Block, as outlined in the 1131 following sections. 1133 9.2. Version Field 1135 IANA is requested to create three registries, each associated with a 1136 different subfield of the Version field of Signature Blocks and 1137 Certificate Blocks, described in Section 4.2.1 and Section 5.3.2.1, 1138 respectively. 1140 The first registry that IANA is requested to create is entitled 1141 "syslog-sign protocol version values". It is for the values of the 1142 Protocol Version subfield. The Protocol Version subfield constitutes 1143 the first 2 octets in the Version field. New values shall be 1144 assigned by the IANA using the "IETF Consensus" policy defined in RFC 1145 2434 [4]. Assigned numbers are to be increased by 1, up to a maximum 1146 value of "50". Protocol Version numbers of "51" through "99" are 1147 vendor-specific; values in this range are not to be assigned by the 1148 IANA. 1150 IANA is requested to register the Protocol Version values shown 1151 below. 1153 VALUE PROTOCOL VERSION 1154 ----- ---------------- 1155 00 Reserved 1156 01 Defined in RFC yyyy 1158 The second registry that IANA is requested to create is entitled 1159 "syslog-sign hash algorithm values". It is for the values of the 1160 Hash Algorithm subfield. The Hash Algorithm subfield constitutes the 1161 third octet in the Version field Signature Blocks and Certificate 1162 Blocks. New values shall be assigned by the IANA using the "IETF 1163 Consensus" policy defined in RFC 2434 [4]. Assigned values are to be 1164 increased by 1, up to a maximum value of "9". The values are 1165 registered relative to the Protocol Version. This means that the 1166 same Hash Algorithm value can be reserved for different Protocol 1167 Versions, possibly referring to a different hash algorithm each time. 1168 This makes it possible to deal with future scenarios in which the 1169 single octet representation becomes a limitation, as more Hash 1170 Algorithms can be supported by defining additional Protocol Versions 1171 that implementations might support concurrently. 1173 IANA is requested to register the Hash Algorithm values shown below. 1175 VALUE PROTOCOL VERSION HASH ALGORITHM 1176 ----- ---------------- -------------- 1177 0 01 Reserved 1178 1 01 SHA1 1179 2 01 SHA256 1181 The third registry that IANA is requested to create is entitled 1182 "syslog-sign signature scheme values". It is for the values of the 1183 Signature Scheme subfield. The Signature Scheme subfield constitutes 1184 the fourth octet in the Version field of Signature Blocks and 1185 Certificate Blocks. New values shall be assigned by the IANA using 1186 the "IETF Consensus" policy defined in RFC 2434 [4]. Assigned values 1187 are to be increased by 1, up to a maximum value of "9". This means 1188 that the same Signature Scheme value can be reserved for different 1189 Protocol Versions, possibly in each case referring to a different 1190 Signature Scheme each time. This makes it possible to deal with 1191 future scenarios in which the single octet representation becomes a 1192 limitation, as more Signature Schemes can be supported by defining 1193 additional Protocol Versions that implementations might support 1194 concurrently. 1196 IANA is requested to register the Signature Scheme values shown 1197 below. 1199 VALUE PROTOCOL VERSION SIGNATURE SCHEME 1200 ----- ---------------- ---------------- 1201 0 01 Reserved 1202 1 01 OpenPGP DSA 1204 9.3. SG Field 1206 IANA is requested to create a registry entitled "syslog-sign sg field 1207 values". It is for values of the SG Field as defined in 1208 Section 4.2.3. New values shall be assigned by the IANA using the 1209 "IETF Consensus" policy defined in RFC 2434 [4]. Assigned values are 1210 to be incremented by 1, up to a maximum value of "7". Values "8" and 1211 "9" shall be left as vendor specific and shall not be assigned by the 1212 IANA. 1214 IANA is requested to register the SG Field values shown below. 1216 VALUE MEANING 1217 ----- ------- 1218 0 per RFC yyyy 1219 1 per RFC yyyy 1220 2 per RFC yyyy 1221 3 per RFC yyyy 1223 9.4. Key Blob Type 1225 IANA is requested to create a registry entitled "syslog-sign key blob 1226 type values". It is to register one-character identifiers for the 1227 key blob type, per Section 5.2. New values shall be assigned by the 1228 IANA using the "IETF Consensus" policy defined in RFC 2434 [4]. 1229 Uppercase letters may be assigned as values. Lowercase letters are 1230 left as vendor specific and shall not be assigned by the IANA. 1232 IANA is requested to register the key blob type values shown below. 1234 VALUE KEY BLOB TYPE 1235 ----- ------------ 1236 'C' a PKIX certificate 1237 'P' an OpenPGP certificate 1238 'K' the public key whose corresponding private key is used to sign the messages 1239 'N' no key information sent, key is predistributed 1240 'U' installation-specific key exchange information 1242 10. Working Group 1244 The working group can be contacted via the mailing list: 1246 syslog@ietf.org 1248 The current Chairs of the Working Group can be contacted at: 1250 Chris Lonvick 1251 Cisco Systems 1252 Email: clonvick@cisco.com 1254 David Harrington 1255 Huawei Technologies (USA) 1256 Email: ietfdbh@comcast.net 1257 dharrington@huawei.com 1258 Tel: +1-603-436-8634 1260 11. Acknowledgements 1262 The authors wish to thank Alex Brown, Chris Calabrese, Steve Chang, 1263 Carson Gaspar, Drew Gross, David Harrington, Chris Lonvick, Darrin 1264 New, Marshall Rose, Holt Sorenson, Rodney Thayer, Andrew Ross, Rainer 1265 Gerhards, Albert Mietus, and the many Counterpane Internet Security 1266 engineering and operations people who commented on various versions 1267 of this proposal. 1269 12. References 1271 12.1. Normative References 1273 [1] National Institute of Standards and Technology, "Digital 1274 Signature Standard", FIPS PUB 186-2, January 2000, . 1278 [2] National Institute of Standards and Technology, "Secure Hash 1279 Standard", FIPS PUB 180-2, August 2002, . 1282 [3] National Institute of Standards and Technology, "NIST Special 1283 Publication 800-90: Recommendation for Random Number Generation 1284 using Deterministic Random Bit Generators", June 2006, . 1288 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1289 Considerations Section in RFCs", BCP 26, RFC 2434, 1290 October 1998. 1292 [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1293 "OpenPGP Message Format", RFC 2440, November 1998. 1295 [6] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 1296 for version 3 of the Simple Network Management Protocol 1297 (SNMPv3)", RFC 3414, December 2002. 1299 [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1300 RFC 4648, October 2006. 1302 [8] Gerhards, R., "The syslog Protocol, 1303 draft-ietf-syslog-protocol-23.txt (work in progress)", 1304 September 2007. 1306 [9] Okmianski, A., "Transmission of syslog Messages over UDP, 1307 draft-ietf-syslog-transport-udp-12.txt (work in progress)", 1308 September 2007. 1310 [10] Miao, F. and M. Yuzhi, "TLS Transport Mapping for syslog, 1311 draft-ietf-syslog-transport-tls-10.txt (work in progress)", 1312 May 2007. 1314 12.2. Informative References 1316 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1317 Levels", BCP 14, RFC 2119, March 1997. 1319 [12] Klyne, G. and C. Newman, "Date and Time on the Internet: 1320 Timestamps", RFC 3339, July 2002. 1322 [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1323 Recommendations for Security", RFC 4086, June 2005. 1325 Authors' Addresses 1327 John Kelsey 1328 NIST 1330 Email: john.kelsey@nist.gov 1332 Jon Callas 1333 PGP Corporation 1335 Email: jon@callas.org 1337 Alexander Clemm 1338 Cisco Systems 1340 Email: alex@cisco.com 1342 Full Copyright Statement 1344 Copyright (C) The IETF Trust (2007). 1346 This document is subject to the rights, licenses and restrictions 1347 contained in BCP 78, and except as set forth therein, the authors 1348 retain all their rights. 1350 This document and the information contained herein are provided on an 1351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1353 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1354 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1355 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1358 Intellectual Property 1360 The IETF takes no position regarding the validity or scope of any 1361 Intellectual Property Rights or other rights that might be claimed to 1362 pertain to the implementation or use of the technology described in 1363 this document or the extent to which any license under such rights 1364 might or might not be available; nor does it represent that it has 1365 made any independent effort to identify any such rights. Information 1366 on the procedures with respect to rights in RFC documents can be 1367 found in BCP 78 and BCP 79. 1369 Copies of IPR disclosures made to the IETF Secretariat and any 1370 assurances of licenses to be made available, or the result of an 1371 attempt made to obtain a general license or permission for the use of 1372 such proprietary rights by implementers or users of this 1373 specification can be obtained from the IETF on-line IPR repository at 1374 http://www.ietf.org/ipr. 1376 The IETF invites any interested party to bring to its attention any 1377 copyrights, patents or patent applications, or other proprietary 1378 rights that may cover technology that may be required to implement 1379 this standard. Please address the information to the IETF at 1380 ietf-ipr@ietf.org. 1382 Acknowledgment 1384 Funding for the RFC Editor function is provided by the IETF 1385 Administrative Support Activity (IASA).