idnits 2.17.1 draft-ietf-syslog-sign-21.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 1338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1362. 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 (March 15, 2007) is 6244 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) -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-23) exists of draft-ietf-syslog-protocol-19 == Outdated reference: A later version (-12) exists of draft-ietf-syslog-transport-udp-08 == Outdated reference: A later version (-14) exists of draft-ietf-syslog-transport-tls-06 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 11 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: September 16, 2007 PGP Corporation 6 A. Clemm 7 Cisco 8 March 15, 2007 10 Signed syslog Messages 11 draft-ietf-syslog-sign-21.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 September 16, 2007. 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . 17 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. Cryptography Constraints . . . . . . . . . . . . . . . . . 25 82 8.2. Packet Parameters . . . . . . . . . . . . . . . . . . . . 25 83 8.3. Message Authenticity . . . . . . . . . . . . . . . . . . . 26 84 8.4. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 26 85 8.5. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 26 86 8.6. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 26 87 8.7. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 26 88 8.8. Message Integrity . . . . . . . . . . . . . . . . . . . . 27 89 8.9. Message Observation . . . . . . . . . . . . . . . . . . . 27 90 8.10. Man In The Middle Attacks . . . . . . . . . . . . . . . . 27 91 8.11. Denial of Service . . . . . . . . . . . . . . . . . . . . 27 92 8.12. Covert Channels . . . . . . . . . . . . . . . . . . . . . 27 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 94 9.1. Structured data and syslog messages . . . . . . . . . . . 28 95 9.2. Version Field . . . . . . . . . . . . . . . . . . . . . . 28 96 9.3. SG Field . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 9.4. Key Blob Type . . . . . . . . . . . . . . . . . . . . . . 30 98 10. Working Group . . . . . . . . . . . . . . . . . . . . . . . . 31 99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 104 Intellectual Property and Copyright Statements . . . . . . . . . . 36 106 1. Introduction 108 This document describes a mechanism that adds origin authentication, 109 message integrity, replay resistance, message sequencing, and 110 detection of missing messages to syslog. Essentially, this is 111 accomplished by sending a special syslog message. The contents of 112 this syslog message is called a Signature Block. Each Signature 113 Block contains, in effect, a detached signature on some number of 114 previously sent messages. It is cryptographically signed and 115 contains the hashes of previously sent syslog messages. 117 While most implementations of syslog involve only a single sender as 118 the generator of each message and a single receiver as the collector 119 of each message, provisions need to be made to cover situations in 120 which messages are sent to multiple receivers. This concerns in 121 particular situations in which different messages are sent to 122 different receivers, which means that some messages are sent to some 123 receivers but not to others. The required differentiation of 124 messages is generally performed based on the Priority value of the 125 individual messages. For example, messages from any Facility with a 126 Severity value of 3, 2, 1 or 0 may be sent to one collector while all 127 messages of Facilities 4, 10, 13, and 14 may be sent to another 128 collector. Appropriate syslog-sign messages must be kept with their 129 proper syslog messages. To address this, syslog-sign uses a 130 signature group. A signature group identifies a group of messages 131 that are all kept together for signing purposes by the sender. A 132 Signature Block always belongs to exactly one signature group and it 133 always signs messages belonging only to that signature group. 135 Additionally, a sender will send a Certificate Block to provide key 136 management information between the sender and the receiver. This 137 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 receiver 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 message delivery mechanism and utilizes 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 that underly this mechanism could also 157 be 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 design. 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 in 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 device generating the Signature Block message signs each 181 message in its entirety, it is imperative that the messages MUST NOT 182 be changed in transit. It is equally imperative that the syslog-sign 183 messages MUST NOT be changed in transit. Specifically, a relay as 184 described in RFC xxxx [8] MAY make changes to a syslog packet. If 185 this occurs, the mechanism described in this document is rendered 186 useless. Likewise, any truncation of messages that occurs between 187 sending and receiving renders the mechanism useless. For this 188 reason, syslog sender and receiver implementations implementing this 189 specification MUST support messages of up to and including 2048 190 octets in length, in order to minimize the chances of truncation from 191 happening. While syslog sender and receiver implementations MAY 192 support messages with a length larger than 2048 octets, implementors 193 need to be aware that any message truncations that occur render the 194 mechanism useless. 196 This specification uses the syslog message format described in RFC 197 xxxx [8]. Along with the other fields, that document describes the 198 concept of STRUCTURED DATA (SD). STRUCTURED DATA is defined in the 199 form of SD ELEMENTS (SDEs). An SDE consists of a name and a set of 200 parameter name - value pairs. The SDE name is referred to as SD-ID. 201 The name-value pairs are referred to as SD-PARAM, or SD Parameters, 202 with the name constituting the SD-PARAM-NAME, the value constituting 203 the SD-PARAM-VALUE. 205 The syslog messages defined in this document carry the signature and 206 certificate data as STRUCTURED DATA. The special syslog messages 207 that are defined in this document include for this purpose 208 definitions of SDEs to convey parameters that relate to the signing 209 of syslog messages. The MSG part of the syslog messages defined in 210 this document is simply empty - the content of the messages is not 211 intended for interpretation by humans but by applications that use 212 those messages to build an authenticated log. 214 4. Signature Blocks 216 This section describes the format of the Signature Block and the 217 fields used within the Signature Block, as well as the syslog 218 messages used to carry the Signature Block. 220 4.1. syslog Messages Containing a Signature Block 222 There is a need to distinguish the Signature Block itself from the 223 syslog message that is used to carry a Signature Block. Signature 224 Blocks MUST be encompassed within completely formed syslog messages. 225 Syslog messages that contain a Signature Block are also referred to 226 as Signature Block messages. 228 A Signature Block message is identified by the presence of an SD 229 ELEMENT with an SD-ID with the value "ssign". In addition, a 230 Signature Block message MUST contain valid APP-NAME, PROCID, and 231 MSGID fields to be compliant with RFC xxxx [8]. This specification 232 does not mandate particular values for these fields; however, for 233 consistency, implementations SHOULD use the same value for APP-NAME, 234 PROCID, and MSGID fields for every Signature Block message, whichever 235 values are chosen. It is RECOMMENDED (but not required) to use 110 236 as value for the PRI field, corresponding to facility 13 and severity 237 6 (informational). The Signature Block is carried as Structured Data 238 within the Signature Block message, per the definitions that follow 239 in the next section. A Signature Block message SHOULD NOT carry 240 other Structured Data besides the Structured Data of the Signature 241 Block itself. The MSG part of a Signature Block message SHOULD be 242 empty. 244 The syslog messages defined as part of syslog-sign themselves 245 (Signature Block messages and Certificate Block messages) do not need 246 to be signed by a Signature Block. Receivers that implement syslog- 247 sign know to distinguish messages that are associated with syslog- 248 sign from the syslog messages that are subjected to signing and 249 process them differently. 251 4.2. Signature Block Format and Fields 253 The content of a Signature Block message is the Signature Block. The 254 Signature Block MUST be encoded as an SD ELEMENT, as defined in RFC 255 xxxx [8]. 257 The SD-ID MUST have the value of "ssign". 259 The SDE contains the fields of the Signature Block encoded as SD 260 Parameters, as specified in the following. The Signature Block is 261 composed of the following fields. The value of each field MUST be 262 printable ASCII, and any binary values MUST be base 64 encoded, as 263 defined in RFC 4648 [7]. 265 Field SD-PARAM-NAME Size in octets 266 ----- ------------- ---- -- ------ 268 Version VER 4 270 Reboot Session ID RSID 1-10 272 Signature Group SG 1 274 Signature Priority SPRI 1-3 276 Global Block Counter GBC 1-10 278 First Message Number FMN 1-10 280 Count CNT 1-2 282 Hash Block HB variable, size of hash 283 (base 64 encoded binary) 285 Signature SIGN variable 286 (base 64 encoded binary) 288 A Signature Block is accordingly encoded as follows, where xxx 289 denotes a placeholder for the particular value: 291 "[ssign VER=xxx RSID=xxx SG=xxx SPRI=xxx GBC=xxx FMN=xxx CNT=xxx 292 HB=xxx SIGN=xxx]". 294 The fields are separated by single spaces and are described below. 296 4.2.1. Version 298 The Signature Block version field is 4 octets in length. The value 299 in this field specifies the version of the syslog-sign protocol. 300 This is extensible to allow for different hash algorithms and 301 signature schemes to be used in the future. The value of this field 302 is the grouping of the protocol version (2 octets), the hash 303 algorithm (1 octet) and the signature scheme (1 octet). 305 Protocol Version - 2 octets, with the protocol version that is 306 described in this document referred to with "01" as the value. 308 Hash Algorithm - 1 octet, with the definition that in conjunction 309 with Protocol Version 01, a value of "1" denotes SHA1, a value of 310 2 denotes SHA256, as defined in FIPS-180-2.2002 [2]. 312 Signature Scheme - 1 octet, with the definition that in 313 conjunction with Protocol Version 01, a value of "1" denotes 314 OpenPGP DSA - RFC 2440 [5], FIPS.186-2.2000 [1]. 316 The version, hash algorithm and signature scheme defined in this 317 document would accordingly be represented as "0111" (if SHA1 is used 318 as Hash Algorithm) and "0121" (if SHA256 is used as Hash Algorithm), 319 respectively (without the quotation marks). 321 The values of the Hash Algorithm and Signature Scheme are defined 322 relative to the Protocol Version. If the single-octet representation 323 of the values for Hash Algorithm and Signature Scheme were to ever 324 represent a limitation, this limitation could be overcome by defining 325 a new Protocol Version with additional Hash Algorithms and / or 326 Signature Schemes, and having implementations support both Protocol 327 Versions concurrently. 329 4.2.2. Reboot Session ID 331 The reboot session ID is a decimal value that has a length between 1 332 and 10 octets. The acceptable values for this are between 0 and 333 9999999999. A reboot session ID is expected to increase whenever a 334 sender reboots in order to allow receivers to uniquely distinguish 335 messages and message signatures across reboots. A device needs to 336 hence support persisting previous reboot session ID across reboots. 337 In cases where a sender does not support this capability, the reboot 338 session ID MUST always be set to a value of 0, which indicates that 339 this capability is not supported. Otherwise, it MUST increase 340 whenever a sender reboots, starting with a value of 1. If the value 341 latches at 9999999999, then manual intervention may be required to 342 reset it to 1. Implementors MAY wish to consider using the 343 snmpEngineBoots value as a source for this counter as defined in RFC 344 3414 [6]. 346 4.2.3. Signature Group and Signature Priority 348 The SG identifier may take on any value from 0-3 inclusive. The SPRI 349 may take on any value from 0-191 inclusive. These fields taken 350 together allow network administrators to associate groupings of 351 syslog messages with appropriate Signature Blocks and Certificate 352 Blocks. Groupings of syslog messages that are signed together are 353 also referred to as signature groups. A Signature Block contains 354 only hashes of those syslog messages that are part of the same 355 signature group. 357 For example, in some cases, network administrators might send syslog 358 messages of Facilities 0 through 15 to one destination while those 359 with Facilities 16 through 23 to another. In such cases, associated 360 Signature Blocks should likely be sent to the corresponding syslog 361 servers as well, signing the syslog messages that are intended for 362 each destination separately. This way, each syslog destination 363 receives Signature Blocks for all syslog messages that it receives, 364 and only for those. The ability to to associate different categories 365 of syslog messages with different signature groups, signed in 366 separate Signature Blocks, provides administrators with flexibility 367 to that regard. 369 Syslog-sign provides four options for handling signature groups, 370 linking them with PRI values so they may be routed to the destination 371 commensurate with the appropriate syslog messages. In all cases, no 372 more than 192 distinct signature groups (0-191) are permitted. 374 The signature group to which a Signature Block pertains is indicated 375 by the signature priority (SPRI) field. The signature group (SG) 376 field indicates how to interpret the signature priority field. (Note 377 that the SG field does not indicate the signature group itself, as 378 its name might suggest.) The SG field can have one of the following 379 values: 381 a. '0' -- There is only one signature group. In this case, the 382 administrators want all Signature Blocks to be sent to a single 383 destination; in all likelihood, all of the syslog messages will 384 also be going to that same destination. Signature Blocks sign 385 all messages regardless of their PRI value. This means that in 386 effect, the Signature Block's SPRI value can be ignored. 387 However, it is RECOMMENDED that a single SPRI value is used for 388 all Signature Blocks. Furthermore, it is RECOMMENDED to use as 389 that value the same value that is used for the PRI field of the 390 Signature Block message. This way, the PRI of the Signature 391 Block message matches the SPRI of the Signature Block that it 392 contains. 394 b. '1' -- Each PRI value is associated with its own signature group. 395 Signature Blocks for a given signature group have SPRI = PRI for 396 that signature group. In other words, the SPRI of the Signature 397 Block matches the PRI value of the syslog messages that are part 398 of the signature group and hence signed by the Signature Block. 399 An SG value of 1 can for example be used when the administrator 400 of a device does not know where any of the syslog messages will 401 ultimately go but anticipates that messages with different PRI 402 values will be collected and processed separately. Having a 403 signature group per PRI value provides administrators with a 404 large degree of flexibility with regards to how to divide up the 405 processing syslog messages and their signatures after they are 406 received, at the same time allowing Signature Blocks to follow 407 the corresponding syslog messages to their eventual destination. 409 c. '2' -- Each signature group contains a range of PRI values. 410 Signature groups are assigned sequentially. A Signature Block 411 for a given signature group has its own SPRI value denoting the 412 highest PRI value of syslog messages in that signature group. 413 The lowest PRI value of syslog messages in that signature group 414 will be one larger than the SPRI value of the next signature 415 group or "0" in case there is no other signature group with a 416 lower SPRI value. The specific signature groups and ranges they 417 are associated with are subject to configuration by a system 418 administrator. 420 d. '3' -- Signature groups are not assigned with any of the above 421 relationships to PRI values of the syslog messages they sign. 422 Instead, another scheme is used, which is outside the scope of 423 this specification. There has to be some predefined arrangement 424 between the sender and the intended receivers as to which syslog 425 messages are to be included in which signature group, requiring 426 configuration by a system administrator. This provides 427 administrators also with the flexibility to group syslog messages 428 into signature groups along criteria that are not tied to the PRI 429 value. 431 One reasonable way to configure some installations is to have only 432 one signature group, indicated with SG=0, and have the device send a 433 copy of each Signature Block to each collector. In that case, 434 collectors that are not configured to receive every syslog message 435 will still receive signatures for every message, even ones they are 436 not supposed to receive. While the collector will not be able to 437 detect gaps in the messages (because the presence of a signature does 438 not tell the collector whether or not the corresponding message would 439 be of the collector's concern), it does allow all messages that do 440 arrive at each collector to be put into the right order and to be 441 verified. It also allows each collector to detect duplicates. 443 4.2.4. Global Block Counter 445 The global block counter is a decimal value representing the number 446 of Signature Blocks sent by syslog-sign before the current one, in 447 this reboot session. This takes at least 1 octet and at most 10 448 octets displayed as a decimal counter. The acceptable values for 449 this are between 0 and 9999999999, starting with 0. If the value of 450 the global block counter latches at 9999999999 and the reboot session 451 ID has a value other than 0 (indicating the fact that persisting of 452 the reboot session ID is supported), then the reboot session ID MUST 453 be incremented by 1 and the global block counter resumes at 0. In 454 the case in which the reboot session ID is in fact 0 and persisting 455 of reboot session IDs is not supported, when the global block counter 456 latches, it resumes at 0 also in this case but the reboot session ID 457 MUST NOT be incremented and remains at 0. 459 Note that the global block counter crosses signature groups; it 460 allows us to roughly synchronize when two messages were sent, even 461 though they went to different collectors and are part of different 462 signature groups. 464 Because a reboot results in the start of a new reboot session, the 465 sender MUST reset the global block counter to 0 after a reboot 466 occurs. Applications need to apply consideration to the possibility 467 that a reboot occurred when authenticating a log, and situations in 468 which reboots occur frequently may result in losing the ability to 469 verify the proper sequence in which messages were sent and hence 470 jeopardizing integrity of the log. 472 4.2.5. First Message Number 474 This is a decimal value between 1 and 10 octets. It contains the 475 unique message number within this signature group of the first 476 message whose hash appears in this block. The very first message of 477 the reboot session is numbered "1". This implies that when the 478 reboot session ID increases, the first message number is reset to 1. 480 For example, if this signature group has processed 1000 messages so 481 far and message number 1001 is the first message whose hash appears 482 in this Signature Block, then this field contains 1001. The message 483 number is relative to the signature group that it belongs to; a 484 message number hence does not identify the message across signature 485 groups. 487 Should the message number within the same reboot session and 488 signature group reach 9999999999, the message number becomes modulo 489 9999999999. This means it latches and restarts with 1 (not with 0, 490 which would be modulo 10000000000). In such event, the global block 491 counter will be vastly different between two occurrences of the same 492 message number. 494 4.2.6. Count 496 The count is a 1 or 2 octet field that indicates the number of 497 message hashes to follow. The valid values for this field are 1 498 through 99. The number of hashes included in the Signature Block 499 MUST be chosen such that the length of the resulting syslog message 500 does not exceed the maximum permissible syslog message length. 502 4.2.7. Hash Block 504 The hash block is a block of hashes, each separately encoded in base 505 64. Each hash in the hash block is the hash of the entire syslog 506 message represented by the hash, independent of the underlying 507 transport. Hashes are ordered from left to right in the order of 508 occurrence of the syslog messages that they represent. 510 The "entire syslog message" refers to what is described as the syslog 511 message excluding transport parts that are described in RFC zzzz [9] 512 and RFC wwww [10], and excluding other parts that may be defined in 513 future transports. The hash value will be the result of the hashing 514 algorithm run across the syslog message, starting with the < of the 515 PRI portion of the header part of the message. The hash algorithm 516 used and indicated by the Version field determines the size of each 517 hash, but the size MUST NOT be shorter than 160 bits. It is base 64 518 encoded as per RFC 4648 [7]. 520 The number of hashes in a hash block SHOULD be chosen such that the 521 resulting Signature Block message does not exceed a length of 2048 522 octets in order to avoid the possibility that truncation occurs. 523 When more hashes need to sent than fit inside a Signature Block 524 message, it is advisable to start a new Signature Block. 526 4.2.8. Signature 528 This is a digital signature, encoded in base 64 per RFC 4648 [7]. 529 The signature is calculated over the completely formatted syslog- 530 message, including all of the PRI, HEADER, and hashes in the hash 531 block, excluding spaces between fields, and also excluding the 532 signature field (SD Parameter Name "SIGN" and corresponding value). 534 5. Payload and Certificate Blocks 536 Certificate Blocks and Payload Blocks provide key management in 537 syslog-sign. Their purpose is to support key management that uses 538 public key cryptosystems. 540 5.1. Preliminaries: Key Management and Distribution Issues 542 A Payload Block contains public key certificate information that is 543 to be conveyed to the receiver. A Payload Block is not sent 544 directly, but in (one or more) fragments. Those fragments are termed 545 Certificate Blocks. All devices send at least one Certificate Block 546 at the beginning of a new reboot session, carrying public key 547 information in effect for the reboot session. 549 There are three key points to understand about Certificate Blocks: 551 a. They handle a variable-sized payload, fragmenting it if necessary 552 and transmitting the fragments as legal syslog messages. This 553 payload is built (as described below) at the beginning of a 554 reboot session and is transmitted in pieces with each Certificate 555 Block carrying a piece. There is exactly one Payload Block per 556 reboot session. 558 b. The Certificate Blocks are digitally signed. The device does not 559 sign the Payload Block, but the signatures on the Certificate 560 Blocks ensure its authenticity. Note that it may not even be 561 possible to verify the signature on the Certificate Blocks 562 without the information in the Payload Block; in this case the 563 Payload Block is reconstructed, the key is extracted, and then 564 the Certificate Blocks are verified. (This is necessary even 565 when the Payload Block carries a certificate, because some other 566 fields of the Payload Block are not otherwise verified.) In 567 practice, most installations keep the same public key over long 568 periods of time, so that most of the time, it is easy to verify 569 the signatures on the Certificate Blocks, and use the Payload 570 Block to provide other useful per-session information. 572 c. The kind of Payload Block that is expected is determined by what 573 kind of key material is on the collector that receives it. The 574 device and collector (or offline log viewer) has both some key 575 material (such as a root public key or predistributed public key) 576 and an acceptable value for the Key Blob Type in the Payload 577 Block, below. The collector or offline log viewer MUST NOT 578 accept a Payload Block of the wrong type. 580 5.2. Payload Block 582 The Payload Block is built when a new reboot session is started. 583 There is a one-to-one correspondence between reboot sessions and 584 Payload Blocks. That is, each reboot session has only one Payload 585 Block, regardless of how many signature groups it supports. A 586 Payload Block MUST have the following fields. Each of these fields 587 are separated by a single space character. Because a Payload Block 588 is not carried in a syslog message directly, only the corresponding 589 Certificate Blocks, it does not need to be encoded as an SD ELEMENT. 591 a. Unique identifier of sender; by default, the sender's IP address 592 in dotted-decimal (IPv4) or colon-separated (IPv6) notation. 594 b. Full local time stamp for the device at the time the reboot 595 session started. This must be in the time stamp format specified 596 in RFC xxxx [8] (essentially, TIMESTAMP-3339 format time stamp 597 format per RFC 3339 [12] with some further restrictions). 599 c. Key Blob Type, a one-octet field which holds one of five values: 601 1. 'C' -- a PKIX certificate. 603 2. 'P' -- an OpenPGP certificate. 605 3. 'K' -- the public key whose corresponding private key is 606 being used to sign these messages. 608 4. 'N' -- no key information sent; key is predistributed. 610 5. 'U' -- installation-specific key exchange information 612 d. The key blob, if any, base 64 encoded per RFC 4648 [7] and 613 consisting of the raw key data. 615 5.3. Certificate Block 617 The Certificate Block must get the Payload Block to the collector. 618 The Certificate Block itself needs to be distinguished from the 619 syslog message that carries it, refererred to as a Certificate Block 620 message. 622 Because certificates can legitimately be much longer than 2048 623 octets, each Certificate Block carries a piece of the Payload Block. 624 Note that the device MAY make the Certificate Blocks of any legal 625 length (that is, any length less than 2048 octets) that holds all the 626 required fields. Software that processes Certificate Blocks MUST 627 deal correctly with blocks of any legal length. The length of the 628 piece of the Payload Block that a Certificate Block is to carry 629 SHOULD be chosen such that the length of the Certificate Block 630 message does not exceed 2048 octets. 632 5.3.1. syslog Messages Containing a Certificate Block 634 As with a Signature Block, each Certificate Block is carried in its 635 own syslog message, referred to as a Certificate Block message. 637 A Certificate Block message is identified by the presence of an SD 638 ELEMENT with an SD-ID with the value "ssign-cert". In addition, a 639 Certificate Block message MUST contain valid APP-NAME, PROCID, and 640 MSGID fields to be compliant with syslog protocol. This 641 specification does not mandate particular values for these fields; 642 however, for consistency, implementations SHOULD use the same value 643 for APP-NAME, PROCID, and MSGID fields for every Certificate Block 644 message, whichever values are chosen. It is RECOMMENDED to use 110 645 as value for the PRI field, corresponding to facility 13 and severity 646 6 (informational). The Certificate Block is carried as Structured 647 Data within the Certificate Block message. A Certificate Block 648 message SHOULD NOT carry other Structured Data besides the Structured 649 Data of the Certificate Block itself. The MSG part of a Certificate 650 Block message SHOULD be empty. 652 5.3.2. Certificate Block Format and Fields 654 The contents of a Certificate Block message is the Certificate Block 655 itself. Like a Signature Block, the Certificate Block is encoded as 656 an SD ELEMENT. The SD-ID of the Certificate Block is "ssign-cert". 657 The Certificate Block is composed of the following fields, each of 658 which is encoded as an SD Parameter with parameter name as indicated. 659 Each field must be printable ASCII, and any binary values are base 64 660 encoded per RFC 4648 [7]. 662 Field SD-PARAM-NAME Size in octets 663 ----- ------------- ---- -- ------ 665 Version VER 4 667 Reboot Session ID RSID 1-10 669 Signature Group SG 1 671 Signature Priority SPRI 1-3 673 Total Payload Block Length TPBL 1-8 675 Index into Payload Block INDEX 1-8 677 Fragment Length FLEN 1-4 679 Payload Block Fragment FRAG variable 680 (base 64 encoded binary) 682 Signature SIGN variable 683 (base 64 encoded binary) 685 A Certificate Block is accordingly encoded as follows, where xxx 686 denotes a placeholder for the particular value: 688 "[ssign-cert VER=xxx RSID=xxx SG=xxx SPRI=xxx TBPL=xxx INDEX=xxx 689 FLEN=xxx FRAG=xxx SIGN=xxx]". 691 The fields are separated by single spaces and are described below. 693 5.3.2.1. Version 695 The signature group version field is 4 octets in length. This field 696 is identical in format and meaning to the Version field described in 697 Section 4.2.1. 699 5.3.2.2. Reboot Session ID 701 The Reboot Session ID is identical in format and meaning to the RSID 702 field described in Section 4.2.2. 704 5.3.2.3. Signature Group and Signature Priority 706 The SIG field is identical in format and meaning to the SIG field 707 described in Section 4.2.8. The SPRI field is identical in format 708 and meaning to the SPRI field described there. 710 5.3.2.4. Total Payload Block Length 712 The Total Payload Block Length is a value representing the total 713 length of the Payload Block in octets, expressed as a decimal with 714 one to eight octets. 716 5.3.2.5. Index into Payload Block 718 This is a value between 1 and 8 octets. It contains the number of 719 octets into the Payload Block at which this fragment starts. The 720 first octet of the first fragment is numbered "1". 722 5.3.2.6. Fragment Length 724 The total length of this fragment expressed as a decimal integer with 725 one to four octets. 727 5.3.2.7. Signature 729 This is a digital signature, encoded in base 64, as per RFC 4648 [7]. 730 The Version field effectively specifies the original encoding of the 731 signature. The signature is calculated over the completely formatted 732 syslog message, including all of the PRI, HEADER, and certificate 733 block, excluding spaces between fields, and also excluding the 734 signature field itself (SD Parameter Name "SIGN" and corresponding 735 value). 737 6. Redundancy and Flexibility 739 There is a general rule that determines how redundancy works and what 740 level of flexibility the sender and receiver have in message formats: 741 in general, the sender is allowed to send Signature and Certificate 742 Blocks multiple times, to send Signature and Certificate Blocks of 743 any legal length, to include fewer hashes in hash blocks, etc. 745 6.1. Redundancy 747 Syslog messages are in general sent over unreliable transport, which 748 means that they can be lost in transit. However, if a collector does 749 not receive Signature and Certificate Blocks, many messages may not 750 be able to be verified. Sending Signature and Certificate Blocks 751 multiple times provides redundancy; since the collector MUST ignore 752 Signature/Certificate Blocks it has already received and 753 authenticated, the sender can in principle change its redundancy 754 level for any reason, without communicating this fact to the 755 collector. 757 Although the sender is not constrained in how it decides to send 758 redundant Signature and Certificate Blocks, or even in whether it 759 decides to send along multiple copies of normal syslog messages, we 760 define some redundancy parameters below which may be useful in 761 controlling redundant transmission from the sender to the collector, 762 and which may be useful for administrators to configure. 764 6.1.1. Configuration Parameters for Certificate Blocks 766 certInitialRepeat = number of times each Certificate Block should be 767 sent before the first message is sent. 769 certResendDelay = maximum time delay in seconds to delay before next 770 redundant sending. 772 certResendCount = maximum number of sent messages to delay before 773 next redundant sending. 775 6.1.2. Configuration Parameters for Signature Blocks 777 sigNumberResends = number of times a Signature Block is resent. 779 sigResendDelay = maximum time delay in seconds from original sending 780 to next redundant sending. 782 sigResendCount = maximum number of sent messages to delay before next 783 redundant sending. 785 6.2. Flexibility 787 The device may change many things about the makeup of Signature and 788 Certificate Blocks in a given reboot session. The things it cannot 789 change are: 791 * The version 793 * The number or arrangements of signature groups 795 It is legitimate for a device to send short Signature Blocks, in 796 order to allow the collector to verify messages quickly. In general, 797 unless something verified by the Payload Block or Certificate Blocks 798 is changed within the reboot session ID, any change is allowed to the 799 Signature or Certificate Blocks during the session. 801 7. Efficient Verification of Logs 803 The logs secured with syslog-sign may be reviewed either online or 804 offline. Online review is somewhat more complicated and 805 computationally expensive, but not prohibitively so. 807 7.1. Offline Review of Logs 809 When the collector stores logs to be reviewed later, they can be 810 authenticated offline just before they are reviewed. Reviewing these 811 logs offline is simple and relatively inexpensive in terms of 812 resources used, so long as there is enough space available on the 813 reviewing machine. Here, we consider that the stored log files have 814 already been separated by sender, reboot session ID, and signature 815 group. This can be done easily with a script file. We then do the 816 following: 818 a. First, we go through the raw log file and split its contents into 819 three files. Each message in the raw log file is classified as a 820 normal message, a Signature Block, or a Certificate Block. 821 Certificate Blocks and Signature Blocks are stored in their own 822 files. Normal messages are stored in a keyed file, indexed on 823 their hash values. 825 b. We sort the Certificate Block file by INDEX value, and check to 826 see whether we have a set of Certificate Blocks that can 827 reconstruct the Payload Block. If so, we reconstruct the Payload 828 Block, verify any key-identifying information, and then use this 829 to verify the signatures on the Certificate Blocks we have 830 received. When this is done, we have verified the reboot session 831 and key used for the rest of the process. 833 c. We sort the Signature Block file by First Message Number. We now 834 create an authenticated log file, which consists of some header 835 information, and then a sequence of message number, message text 836 pairs. We next go through the Signature Block file. For each 837 Signature Block in the file, we do the following: 839 1. Verify the signature on the Block. 841 2. For each hashed message in the Block: 843 a. Look up the hash value in the keyed message file. 845 b. If the message is found, write (message number, message 846 text) to the authenticated log file. 848 3. Skip all other Signature Blocks with the same First Message 849 Number. 851 d. The resulting authenticated log file contains all messages that 852 have been authenticated. In addition, it implicitly indicates 853 all gaps in the authenticated messages (specifically in the case 854 when all messages of the same Signature Group are sent to the 855 same collector), because their message numbers are missing. 857 One can see that, assuming sufficient space for building the keyed 858 file, this whole process is linear in the number of messages 859 (generally two seeks, one to write and the other to read, per normal 860 message received), and O(N lg N) in the number of Signature Blocks. 861 This estimate comes with two caveats: first, the Signature Blocks 862 arrive very nearly in sorted order, and so can probably be sorted 863 more cheaply on average than O(N lg N) steps. Second, the signature 864 verification on each Signature Block almost certainly is more 865 expensive than the sorting step in practice. We have not discussed 866 error-recovery, which may be necessary for the Certificate Blocks. 867 In practice, a simple error-recovery strategy is probably enough: if 868 the Payload Block is not valid, then we can just try alternate 869 instances of each Certificate Block, if such are available, until we 870 get the Payload Block right. 872 It is easy for an attacker to flood us with plausible-looking 873 messages, Signature Blocks, and Certificate Blocks. 875 7.2. Online Review of Logs 877 Some processes on the collector machine may need to monitor log 878 messages in close to real-time. This can be done with syslog-sign, 879 though it is somewhat more complex than offline verification. This 880 is done as follows: 882 a. We have an authenticated message file, into which we write 883 (message number, message text) pairs which have been 884 authenticated. Again, we will assume that we are handling only 885 one signature group, and only one reboot session ID at any given 886 time. 888 b. We have three data structures: A queue into which (message 889 number, hash of message) pairs is kept in sorted order, a queue 890 into which (arrival sequence, hash of message) is kept in sorted 891 order, and a hash table which stores (message text, count) 892 indexed by hash value. In the hash table, count may be any 893 number greater than zero; when count is zero, the entry in the 894 hash table is cleared. 896 c. We must receive all the Certificate Blocks before any other 897 processing can really be done. (This is why they are sent 898 first.) Once that is done, any Certificate Block that arrives is 899 discarded. 901 d. Whenever a normal message arrives, we add (arrival sequence, hash 902 of message) to our message queue. If our hash table has an entry 903 for the message's hash value, we increment its count by one; 904 otherwise, we create a new entry with count = 1. If the message 905 queue is full, we roll the oldest messages off the queue by 906 taking the last entry in the queue, and using it to index the 907 hash table. If that entry has count 1, we delete the entry from 908 the hash table; otherwise, we decrement its count. We then 909 delete the last entry in the queue. 911 e. Whenever a Signature Block arrives, we first check to see whether 912 the First Message Number value is too old to still be of 913 interest, or if another Signature Block with that First Message 914 Number has already been received. If so, we discard the 915 Signature Block unread. Otherwise, we check its signature, and 916 discard it if the signature is not valid. A Signature Block 917 contains a sequence of (message number, message hash) pairs. For 918 each pair, we first check to see if the message hash is in the 919 hash table. If so, we write the (message number, message text) 920 into the authenticated message queue. Otherwise, we write the 921 (message number, message hash) to the message number queue. This 922 generally involves rolling the oldest entry out of this queue: 923 before this is done, that entry's hash value is again searched 924 for in the hash table. If a matching entry is found, the 925 (message number, message text) pair is written out to the 926 authenticated message file. In either case, the oldest entry is 927 then discarded. 929 f. The result of this is a sequence of messages in the authenticated 930 message file, each of which has been authenticated, and which are 931 labeled with numbers showing their order of original 932 transmission. 934 One can see that this whole process is roughly linear in the number 935 of messages, and also in the number of Signature Blocks received. 936 The process is susceptible to flooding attacks; an attacker can send 937 enough normal messages that the messages roll off their queue before 938 their Signature Blocks can be processed. 940 8. Security Considerations 942 Normal syslog event messages are unsigned and have most of the 943 security attributes described in Section 8 of RFC xxxx [8]. This 944 document also describes Certificate Blocks and Signature Blocks which 945 are signed syslog messages. The Signature Blocks contains signature 946 information of previously sent syslog event messages. All of this 947 information can be used to authenticate syslog messages and to 948 minimize or obviate many of the security concerns described in RFC 949 xxxx [8]. 951 8.1. Cryptography Constraints 953 As with any technology involving cryptography, it is advisable to 954 check the current literature to determine whether any algorithms used 955 here have been found to be vulnerable to attack. 957 This specification uses Public Key Cryptography technologies. The 958 proper party or parties have to control the private key portion of a 959 public-private key pair. Any party that controls a private key can 960 sign anything they please. 962 Certain operations in this specification involve the use of random 963 numbers. An appropriate entropy source SHOULD be used to generate 964 these numbers. See RFC 4086 [13] and NIST 800-90 [3]. 966 8.2. Packet Parameters 968 As a sender, it is advisable to avoid message lengths exceeding 2048 969 octets. Various problems might result if a sender were to send out 970 messages with a length greater than 2048 octets, because relays MAY 971 truncate messages with lengths greater than 2048 octets which would 972 make it impossible for receivers to validate a hash of the packet. 973 To increase the chance of interoperability, it tends to be best to be 974 conservative with what you send but liberal in what you are able to 975 receive. 977 Senders need to rigidly enforce the correctness of the message body. 978 Problems may arise if the receiver does not fully accept the syslog 979 packets sent from a device, or if it has problems with the format of 980 the Certificate Block or Signature Block messages. 982 Receivers are not to malfunction in case they receive malformed 983 syslog messages or messages containing characters other than those 984 specified in this document. In other words, they are to ignore such 985 messages and continue working. 987 8.3. Message Authenticity 989 Syslog does not strongly associate the message with the message 990 sender. That association is established by the receiver upon 991 verification of the Signature Block. Before a Signature Block is 992 used to ascertain the authenticity of an event message, it might be 993 received, stored and reviewed by a person or automated parser. It is 994 advisable to not assume a message is authentic until after a message 995 has been validated by checking the contents of the Signature Block. 997 With the Signature Block checking, an attacker may only forge 998 messages if they can compromise the private key of the true sender. 1000 8.4. Sequenced Delivery 1002 Event messages might be recorded and replayed by an attacker. Using 1003 the information contained in the Signature Blocks, a reviewer can 1004 determine whether the received messages are the ones originally sent 1005 by a sender. The reviewer can also identify messages that have been 1006 replayed. 1008 8.5. Replaying 1010 Event messages might be recorded and replayed by an attacker. 1011 However, the information contained in the Signature Blocks will allow 1012 a reviewer to determine if the received messages are the ones 1013 originally sent by a device. This process will also alert the 1014 reviewer to replayed messages. 1016 8.6. Reliable Delivery 1018 RFC wwww [10] can be used for the reliable delivery of syslog 1019 messages. Event messages sent over UDP might be lost in transit. A 1020 reviewer can pinpoint any messages sent by the sender but not 1021 received by the receiver by properly reviewing the Signature Block 1022 information. In addition, the information in subsequent Signature 1023 Blocks allows a reviewer to determine if any Signature Block messages 1024 were lost in transit. 1026 8.7. Sequenced Delivery 1028 Syslog messages delivered over UDP might not only be lost, but also 1029 arrive out of sequence. A reviewer can determine the original order 1030 of syslog messages and identify which messages were delivered out of 1031 order by examining the information in the Signature Block along with 1032 any timestamp information in the message. 1034 8.8. Message Integrity 1036 Syslog messages might be damaged in transit. A review of the 1037 information in the Signature Block determines whether the received 1038 message was the intended message sent by the sender. A damaged 1039 Signature Block or Certificate Block is evident because the receiver 1040 will not be able to validate that it was signed by the sender. 1042 8.9. Message Observation 1044 Event messages, Certificate Blocks, and Signature Blocks are all sent 1045 in plaintext. This allows network administrators to read the message 1046 when sniffing the wire. However, this also allows an attacker to see 1047 the contents of event messages and perhaps to use that information 1048 for malicious purposes. 1050 8.10. Man In The Middle Attacks 1052 It is conceivable that an attacker might intercept Certificate Block 1053 messages and insert its own Certificate information. In that case, 1054 the attacker would be able to receive event messages from the actual 1055 sender and then relay modified messages, insert new messages, or 1056 delete messages. It would then be able to construct a Signature 1057 Block and sign it with its own private key. Network administrators 1058 need to verify that the key contained in the Payload Block is indeed 1059 the key being used on the actual device. If that is the case, then 1060 this MITM attack will not succeed. 1062 8.11. Denial of Service 1064 An attacker might send invalid Signature Block messages to overwhelm 1065 the receiver's processing capability and consume all available 1066 resources. For this reason, it can be appropriate to simply receive 1067 the Signature Block messages and process them only as time permits. 1069 An attacker might also just overwhelm a receiver by sending more 1070 messages to it than it can handle. Implementors are advised to 1071 consider features that minimize this threat, such as only accepting 1072 syslog messages from known IP addresses. 1074 8.12. Covert Channels 1076 Nothing in this protocol attempts to eliminate covert channels. In 1077 fact, just about every aspect of syslog messages lends itself to the 1078 conveyance of covert signals. For example, a collusionist could send 1079 odd and even PRI values to indicate Morse Code dashes and dots. 1081 9. IANA Considerations 1083 9.1. Structured data and syslog messages 1085 With regards to RFC xxxx [8], IANA is requested to add the following 1086 values to the registry entitled "syslog structured data id values": 1088 SD-ID PARAM_NAME 1089 ----- ---------- 1090 ssign 1091 VER 1092 RSID 1093 SG 1094 SPRI 1095 GBC 1096 FMN 1097 CNT 1098 HB 1099 SIGN 1101 ssign-cert 1102 VER 1103 RSID 1104 SG 1105 SPRI 1106 TBPL 1107 INDEX 1108 FLEN 1109 FRAG 1110 SIGN 1112 In addition, several fields need to be controlled by the IANA in both 1113 the Signature Block and the Certificate Block, as outlined in the 1114 following sections. 1116 9.2. Version Field 1118 IANA is requested to create three registries, each associated with a 1119 different subfield of the Version field of Signature Blocks and 1120 Certificate Blocks, described in Section 4.2.1 and Section 5.3.2.1, 1121 respectively. 1123 The first registry that IANA is requested to create is entitled 1124 "syslog-sign protocol version values". It is for the values of the 1125 Protocol Version subfield. The Protocol Version subfield constitutes 1126 the first 2 octets in the Version field. New values shall be 1127 assigned by the IANA using the "IETF Consensus" policy defined in RFC 1128 2434 [4]. Assigned numbers are to be incremented monotonically with 1129 decimal values, up to a maximum value of "50". Protocol Version 1130 numbers of "51" through "99" are vendor-specific; values in this 1131 range are not to be assigned by the IANA. 1133 IANA is requested to register the Protocol Version values shown 1134 below. 1136 VALUE PROTOCOL VERSION 1137 ----- ---------------- 1138 00 Reserved 1139 01 Defined in RFC yyyy 1141 The second registry that IANA is requested to create is entitled 1142 "syslog-sign hash algorithm values". It is for the values of the 1143 Hash Algorithm subfield. The Hash Algorithm subfield constitutes the 1144 third octet in the Version field Signature Blocks and Certificate 1145 Blocks. New values shall be assigned by the IANA using the "IETF 1146 Consensus" policy defined in RFC 2434 [4]. Assigned values are to be 1147 incremented monotonically up to a maximum value of "9". The values 1148 are registered relative to the Protocol Version. This means that the 1149 same Hash Algorithm value can be reserved for different Protocol 1150 Versions, possibly referring to a different hash algorithm each time. 1151 This makes it possible to deal with future scenario in which the 1152 single octet represenation becomes a limitation, as more Hash 1153 Algorithms can be supported by defining additional Protocol Version 1154 that implementations might support concurrently. 1156 IANA is requested to register the Hash Algorithm values shown below. 1158 VALUE PROTOCOL VERSION HASH ALGORITHM 1159 ----- ---------------- -------------- 1160 0 01 Reserved 1161 1 01 SHA1 1162 2 01 SHA256 1164 The third registry that IANA is requested to create is entitled 1165 "syslog-sign signature scheme values". It is for the values of the 1166 Signature Scheme subfield. The Signature Scheme subfield constitutes 1167 the fourth octet in the Version field Signature Blocks and 1168 Certificate Blocks. New values shall be assigned by the IANA using 1169 the "IETF Consensus" policy defined in RFC 2434 [4]. Assigned values 1170 are to be incremented monotonically up to a maximum value of "9". 1171 This means that the same Signature Scheme value can be reserved for 1172 different Protocol Versions, possibly in each case referring to a 1173 different Signature Scheme each time. This makes it possible to deal 1174 with future scenario in which the single octet represenation becomes 1175 a limitation, as more Signature Schemes can be supported by defining 1176 additional Protocol Version that implementations might support 1177 concurrently. 1179 IANA is requested to register the Signature Scheme values shown 1180 below. 1182 VALUE PROTOCOL VERSION SIGNATURE SCHEME 1183 ----- ---------------- ---------------- 1184 0 01 Reserved 1185 1 01 OpenPGP DSA 1187 9.3. SG Field 1189 IANA is requested to create a registry entitled "syslog-sign sg field 1190 values". It is for values of the SG Field as defined in 1191 Section 4.2.3. New values shall be assigned by the IANA using the 1192 "IETF Consensus" policy defined in RFC 2434 [4]. Assigned values are 1193 to be incremented monotonically up to a maximum value of "7". Values 1194 "8" and "9" shall be left as vendor specific and shall not be 1195 assigned by the IANA. 1197 IANA is requested to register the SG Field values shown below. 1199 VALUE MEANING 1200 ----- ------- 1201 0 per RFC yyyy 1202 1 per RFC yyyy 1203 2 per RFC yyyy 1204 3 per RFC yyyy 1206 9.4. Key Blob Type 1208 IANA is requested to create a registry entitled "syslog-sign key blob 1209 type values". It is to register one-character identifiers for the 1210 key blob type, per RFC 2434 (Section 5.2). Uppercase letters may be 1211 assigned as values. Lowercase letters are left as vendor specific 1212 and shall not be assigned by the IANA. 1214 IANA is requested to register the key blob type values shown below. 1216 VALUE KEY BLOB TYPE 1217 ----- ------------ 1218 'C' a PKIX certificate 1219 'P' an OpenPGP certificate 1220 'K' the public key whose corresponding private key is used to sign the messages 1221 'N' no key information sent, key is predistributed 1222 'U' installation-specific key exchange information 1224 10. Working Group 1226 The working group can be contacted via the mailing list: 1228 syslog-sec@employees.org 1230 The current Chairs of the Working Group can be contacted at: 1232 Chris Lonvick 1233 Cisco 1234 Email: clonvick@cisco.com 1236 David Harrington 1237 Huawei Technologies (USA) 1238 Email: ietfdbh@comcast.net 1239 dharrington@huawei.com 1240 Tel: +1-603-436-8634 1242 11. Acknowledgements 1244 The authors wish to thank Alex Brown, Chris Calabrese, Steve Chang, 1245 Carson Gaspar, Drew Gross, David Harrington, Chris Lonvick, Darrin 1246 New, Marshall Rose, Holt Sorenson, Rodney Thayer, Andrew Ross, Rainer 1247 Gerhards, Albert Mietus, and the many Counterpane Internet Security 1248 engineering and operations people who commented on various versions 1249 of this proposal. 1251 12. References 1253 12.1. Normative References 1255 [1] National Institute of Standards and Technology, "Digital 1256 Signature Standard", FIPS PUB 186-2, January 2000, . 1260 [2] National Institute of Standards and Technology, "Secure Hash 1261 Standard", FIPS PUB 180-2, August 2002, . 1264 [3] National Institute of Standards and Technology, "NIST Special 1265 Publication 800-90: Recommendation for Random Number Generation 1266 using Deterministic Random Bit Generators", June 2006, . 1270 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1271 Considerations Section in RFCs", BCP 26, RFC 2434, 1272 October 1998. 1274 [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1275 "OpenPGP Message Format", RFC 2440, November 1998. 1277 [6] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 1278 for version 3 of the Simple Network Management Protocol 1279 (SNMPv3)", December 2002. 1281 [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1282 RFC 4648, October 2006. 1284 [8] Gerhards, R., "The syslog Protocol, 1285 draft-ietf-syslog-protocol-19.txt (work in progress)", 1286 November 2006. 1288 [9] Okmianski, A., "Transmission of syslog Messages over UDP, 1289 draft-ietf-syslog-transport-udp-08.txt (work in progress)", 1290 November 2006. 1292 [10] Miao, F. and M. Yuzhi, "TLS Transport Mapping for syslog, 1293 draft-ietf-syslog-transport-tls-06.txt (work in progress)", 1294 December 2006. 1296 12.2. Informative References 1298 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1299 Levels", BCP 14, RFC 2119, March 1997. 1301 [12] Klyne, G. and C. Newman, "Date and Time on the Internet: 1302 Timestamps", RFC 3339, July 2002. 1304 [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1305 Recommendations for Security", RFC 4086, June 2005. 1307 Authors' Addresses 1309 John Kelsey 1310 NIST 1312 Email: john.kelsey@nist.gov 1314 Jon Callas 1315 PGP Corporation 1317 Email: jon@callas.org 1319 Alexander Clemm 1320 Cisco 1322 Email: alex@cisco.com 1324 Full Copyright Statement 1326 Copyright (C) The IETF Trust (2007). 1328 This document is subject to the rights, licenses and restrictions 1329 contained in BCP 78, and except as set forth therein, the authors 1330 retain all their rights. 1332 This document and the information contained herein are provided on an 1333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1335 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1336 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1337 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1340 Intellectual Property 1342 The IETF takes no position regarding the validity or scope of any 1343 Intellectual Property Rights or other rights that might be claimed to 1344 pertain to the implementation or use of the technology described in 1345 this document or the extent to which any license under such rights 1346 might or might not be available; nor does it represent that it has 1347 made any independent effort to identify any such rights. Information 1348 on the procedures with respect to rights in RFC documents can be 1349 found in BCP 78 and BCP 79. 1351 Copies of IPR disclosures made to the IETF Secretariat and any 1352 assurances of licenses to be made available, or the result of an 1353 attempt made to obtain a general license or permission for the use of 1354 such proprietary rights by implementers or users of this 1355 specification can be obtained from the IETF on-line IPR repository at 1356 http://www.ietf.org/ipr. 1358 The IETF invites any interested party to bring to its attention any 1359 copyrights, patents or patent applications, or other proprietary 1360 rights that may cover technology that may be required to implement 1361 this standard. Please address the information to the IETF at 1362 ietf-ipr@ietf.org. 1364 Acknowledgment 1366 Funding for the RFC Editor function is provided by the IETF 1367 Administrative Support Activity (IASA).