idnits 2.17.1 draft-ietf-syslog-sign-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5424]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 31, 2009) is 5352 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 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 4, 2010 PGP Corporation 6 A. Clemm 7 Cisco Systems 8 August 31, 2009 10 Signed syslog Messages 11 draft-ietf-syslog-sign-27.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on March 4, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes a mechanism to add origin authentication, 60 message integrity, replay resistance, message sequencing, and 61 detection of missing messages to the transmitted syslog messages. 62 This specification is intended to be used in conjunction with the 63 work defined in [RFC5424], "The syslog Protocol". 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Conventions Used in this Document . . . . . . . . . . . . . . 7 69 3. syslog Message Format . . . . . . . . . . . . . . . . . . . . 8 70 4. Signature Blocks . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. syslog Messages Containing a Signature Block . . . . . . . 10 72 4.2. Signature Block Format and Fields . . . . . . . . . . . . 11 73 4.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.2.2. Reboot Session ID . . . . . . . . . . . . . . . . . . 12 75 4.2.3. Signature Group and Signature Priority . . . . . . . . 13 76 4.2.4. Global Block Counter . . . . . . . . . . . . . . . . . 15 77 4.2.5. First Message Number . . . . . . . . . . . . . . . . . 16 78 4.2.6. Count . . . . . . . . . . . . . . . . . . . . . . . . 16 79 4.2.7. Hash Block . . . . . . . . . . . . . . . . . . . . . . 16 80 4.2.8. Signature . . . . . . . . . . . . . . . . . . . . . . 17 81 4.2.9. Example . . . . . . . . . . . . . . . . . . . . . . . 17 82 5. Payload and Certificate Blocks . . . . . . . . . . . . . . . . 19 83 5.1. Preliminaries: Key Management and Distribution Issues . . 19 84 5.2. Payload Block . . . . . . . . . . . . . . . . . . . . . . 20 85 5.2.1. Block Format and Fields . . . . . . . . . . . . . . . 20 86 5.2.2. Signer Authentication and Authorization . . . . . . . 21 87 5.3. Certificate Block . . . . . . . . . . . . . . . . . . . . 22 88 5.3.1. syslog Messages Containing a Certificate Block . . . . 22 89 5.3.2. Certificate Block Format and Fields . . . . . . . . . 23 90 6. Redundancy and Flexibility . . . . . . . . . . . . . . . . . . 27 91 6.1. Configuration parameters . . . . . . . . . . . . . . . . . 27 92 6.1.1. Configuration Parameters for Certificate Blocks . . . 27 93 6.1.2. Configuration Parameters for Signature Blocks . . . . 28 94 6.2. Overlapping Signature Blocks . . . . . . . . . . . . . . . 29 95 7. Efficient Verification of Logs . . . . . . . . . . . . . . . . 30 96 7.1. Offline Review of Logs . . . . . . . . . . . . . . . . . . 30 97 7.2. Online Review of Logs . . . . . . . . . . . . . . . . . . 31 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 99 8.1. Cryptographic Constraints . . . . . . . . . . . . . . . . 34 100 8.2. Packet Parameters . . . . . . . . . . . . . . . . . . . . 34 101 8.3. Message Authenticity . . . . . . . . . . . . . . . . . . . 35 102 8.4. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 35 103 8.5. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 35 104 8.6. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 35 105 8.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 36 106 8.8. Message Observation . . . . . . . . . . . . . . . . . . . 36 107 8.9. Man In The Middle Attacks . . . . . . . . . . . . . . . . 36 108 8.10. Denial of Service . . . . . . . . . . . . . . . . . . . . 36 109 8.11. Covert Channels . . . . . . . . . . . . . . . . . . . . . 36 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 111 9.1. Structured Data and syslog messages . . . . . . . . . . . 37 112 9.2. Version Field . . . . . . . . . . . . . . . . . . . . . . 37 113 9.3. SG Field . . . . . . . . . . . . . . . . . . . . . . . . . 39 114 9.4. Key Blob Type . . . . . . . . . . . . . . . . . . . . . . 39 115 10. Working Group . . . . . . . . . . . . . . . . . . . . . . . . 41 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 43 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 122 1. Introduction 124 This document describes a mechanism, called syslog-sign in this 125 document, that adds origin authentication, message integrity, replay 126 resistance, message sequencing, and detection of missing messages to 127 syslog. Essentially, this is accomplished by sending a special 128 syslog message. The contents of this syslog message is called a 129 Signature Block. Each Signature Block contains, in effect, a 130 detached signature on some number of previously sent messages. It is 131 cryptographically signed and contains the hashes of previously sent 132 syslog messages. The originator of syslog-sign messages is also 133 simply referred to as "signer". The signer can be the same 134 originator as the originator whose messages it signs, or it can be a 135 separate originator. 137 While most implementations of syslog involve only a single originator 138 and a single collector of each message, provisions need to be made to 139 cover situations in which messages are sent to multiple collectors. 140 This concerns, in particular, situations in which different messages 141 from the same originator are sent to different collectors, which 142 means that some messages are sent to some collectors but not to 143 others. The required differentiation of messages is generally 144 performed based on the Priority value of the individual messages. 145 For example, messages from any Facility with a Severity value of 3, 146 2, 1, or 0 may be sent to one collector while all messages of 147 Facilities 4, 10, 13, and 14 may be sent to another collector. 148 Appropriate syslog-sign messages must be kept with their proper 149 syslog messages. To address this, syslog-sign uses a Signature 150 Group. A Signature Group identifies a group of messages that are all 151 kept together for signing purposes by the signer. A Signature Block 152 always belongs to exactly one Signature Group and always signs 153 messages belonging only to that Signature Group. 155 Additionally, a signer sends a Certificate Block to provide key 156 management information between the signer and the collector. This 157 Certificate Block has a field to denote the type of key material 158 which may be such things as a PKIX certificate, an OpenPGP 159 certificate, or even an indication that a key had been pre- 160 distributed. In the cases of certificates being sent, the 161 certificates may have to be split across multiple packets. 163 It is possible that the same host contains multiple signers that each 164 use their own keys to sign syslog messages. In this case, each 165 signer sends its own Certificate Block and Signature Blocks. 166 Furthermore, each signer defines its own Signature Groups. Each 167 signer on a given host needs to use a distinct combination of APP- 168 NAME and PROCID for its Signature Block and Certificate Block 169 message. (This implies that the combination of HOSTNAME, APP-NAME 170 and PROCID uniquely distinguishes originators of syslog-sign messages 171 across hosts, provided that the signers use a unique HOSTNAME.) 173 The collector of the previous messages may verify that the hash of 174 each received message matches the signed hash contained in the 175 Signature Block. A collector may process these Signature Blocks as 176 they arrive, building an authenticated log file. Alternatively, it 177 may store all the log messages in the order they were received. This 178 allows a network operator to authenticate the log file at the time 179 the logs are reviewed. 181 The mechanism described in this specification is intended to be used 182 in conjunction with the syslog protocol as defined in [RFC5424] as 183 its message delivery mechanism and uses the concept of STRUCTURED- 184 DATA elements defined in that document. In fact, this specification 185 mandates implementation of syslog protocol. Nevertheless, it is 186 conceivable that the concepts underlying this mechanism could also be 187 used in conjunction with other message delivery mechanisms. 188 Designers of other efforts to define event notification mechanisms 189 are therefore encouraged to consider this specification in their 190 designs. 192 2. Conventions Used in this Document 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 3. syslog Message Format 200 This specification is intended to be used in conjunction with the 201 syslog protocol as defined in [RFC5424]. The syslog protocol 202 therefore MUST be supported by implementations of this specification. 204 Because the originator generating the Signature Block message, also 205 simply referred to as "signer", signs each message in its entirety, 206 the messages MUST NOT be changed in transit. By the same token, the 207 syslog-sign messages MUST NOT be changed in transit. [RFC3164] 208 describes relay behavior in which syslog messages are altered. If 209 such behavior were to occur in conjunction with syslog-sign, it would 210 render any signing invalid and hence make the mechanism useless. 211 Likewise, any truncation of messages that occurs between sending and 212 receiving renders the mechanism useless. For this reason, syslog 213 signer and collector implementations implementing this specification 214 MUST support messages of up to and including 2048 octets in length, 215 in order to minimize the chance of truncation. While syslog signer 216 and collector implementations MAY support messages with a length 217 larger than 2048 octets, implementers need to be aware that any 218 message truncations that occur render the mechanism useless. 220 This specification uses the syslog message format described in 221 [RFC5424]. Along with other fields, that document describes the 222 concept of Structured Data (SD). Structured Data is defined in terms 223 of SD ELEMENTS (SDEs). An SDE consists of a name and a set of 224 parameter name - value pairs. The SDE name is referred to as SD-ID. 225 The name-value pairs are referred to as SD-PARAM, or SD Parameters, 226 with the name constituting the SD-PARAM-NAME, and the value 227 constituting the SD-PARAM-VALUE. 229 The syslog messages defined in this document carry the signature and 230 certificate data as Structured Data. The special syslog messages 231 defined in this document include for this purpose definitions of SDEs 232 to convey parameters that relate to the signing of syslog messages. 233 The MSG part of the syslog messages defined in this document SHOULD 234 simply be empty -- the content of the messages is not intended for 235 interpretation by humans but by applications that use those messages 236 to build an authenticated log. 238 Because the syslog messages defined in this document adhere to the 239 format described in [RFC5424], they identify the machine that 240 originates the syslog message in the HOSTNAME field. Therefore, the 241 signature and certificate data do not need to include any additional 242 parameter to identify the machine that orginates the message. 244 In addition, several signers MAY sign messages on a single host 245 independently of each other, each using their own Signature Groups. 247 In that case, each unique signer is distinguished by the combination 248 of APP-NAME and PROCID. Each unique signer MUST have a unique APP- 249 NAME and PROCID on each host. (This implies that the combination of 250 HOSTNAME, APP-NAM and PROCID uniquely distinguishes the originator of 251 syslog-sign messages, provided that the signers use a unique 252 HOSTNAME.) A Signature Block message MUST use the same combination 253 of HOSTNAME, APP-NAME, and PROC-ID that was used to send the 254 corresponding Certificate Block messages containing the Payload 255 Block. 257 4. Signature Blocks 259 This section describes the format of the Signature Block and the 260 fields used within the Signature Block, as well as the syslog 261 messages used to carry the Signature Block. 263 4.1. syslog Messages Containing a Signature Block 265 There is a need to distinguish the Signature Block itself from the 266 syslog message that is used to carry a Signature Block. Signature 267 Blocks MUST be encompassed within completely formed syslog messages. 268 Syslog messages that contain a Signature Block are also referred to 269 as Signature Block messages. 271 A Signature Block message is identified by the presence of an SD 272 ELEMENT with an SD-ID with the value "ssign". In addition, a 273 Signature Block message MUST contain valid APP-NAME, PROCID, and 274 MSGID fields to be compliant with [RFC5424]. This specification does 275 not mandate particular values for these fields; however, for 276 consistency, a signer MUST use the same values for APP-NAME, PROCID, 277 and MSGID fields for every Signature Block message that is sent, 278 whichever values are chosen. It MUST also use the same value for its 279 HOSTNAME field. To allow for the possibility of multiple signers per 280 host, the combination of APP-NAME and PROCID MUST be unique for each 281 such signer on any given host. If a signer daemon is restarted, it 282 MAY use a new PROCID for what is otherwise the same signer but MUST 283 continue to use the same APP-NAME. If it uses a new PROCID, it MUST 284 send a new Payload Block using Certificate Block messages that use 285 the same new PROCID (and the same APP-NAME). It is RECOMMENDED (but 286 not required) to use 110 as value for the PRI field, corresponding to 287 facility 13 (log audit) and severity 6 (informational). The 288 Signature Block is carried as Structured Data within the Signature 289 Block message, per the definitions that follow in the next section. 290 A Signature Block message MAY carry other Structured Data besides the 291 Structured Data of the Signature Block itself. The MSG part of a 292 Signature Block message SHOULD be empty. 294 The syslog messages defined as part of syslog-sign themselves 295 (Signature Block messages and Certificate Block messages) MUST NOT be 296 signed by a Signature Block. Collectors that implement syslog-sign 297 know to distinguish syslog messages that are associated with syslog- 298 sign from those that are subjected to signing and process them 299 differently. The intent of syslog-sign is to sign a stream of syslog 300 messages, not to alter it. 302 4.2. Signature Block Format and Fields 304 The content of a Signature Block message is the Signature Block. The 305 Signature Block MUST be encoded as an SD ELEMENT, as defined in 306 [RFC5424]. 308 The SD-ID MUST have the value of "ssign". 310 The SDE contains the fields of the Signature Block encoded as SD 311 Parameters, as specified in the following. The Signature Block is 312 composed of the following fields. The value of each field MUST be 313 printable ASCII, and any binary values MUST be base 64 encoded, as 314 defined in [RFC4648]. 316 Field SD-PARAM-NAME Size in octets 317 ----- ------------- ---- -- ------ 319 Version VER 4 321 Reboot Session ID RSID 1-10 323 Signature Group SG 1 325 Signature Priority SPRI 1-3 327 Global Block Counter GBC 1-10 329 First Message Number FMN 1-10 331 Count CNT 1-2 333 Hash Block HB variable, size of hash 334 times the number of hashes 335 (base 64 encoded binary) 337 Signature SIGN variable 338 (base 64 encoded binary) 340 The fields MUST be provided in the order listed. Each SD parameter 341 MUST occur once and only once in the Signature Block. New SD 342 parameters MUST NOT be added unless a new Version of the protocol is 343 defined. (Implementations that wish to add proprietary extensions 344 will need to define a separate SD ELEMENT.) A Signature Block is 345 accordingly encoded as follows, where xxx denotes a placeholder for 346 the particular values: 348 [ssign VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" GBC="xxx" FMN="xxx" 349 CNT="xxx" HB="xxx" SIGN="xxx"] 350 Values of the fields constitute SD parameter values and are hence 351 enclosed in quotes, per [RFC5424]. The fields are separated by 352 single spaces and are described in the subsequent subsections. 354 4.2.1. Version 356 The Version field is an alphanumeric value that has a length of 4 357 octets, which may include leading zeroes. The first two octets and 358 the last octet contain a decimal character in the range of "0" to 359 "9", whereas the third octet contains an alphanumeric character in 360 the range of "0" to "9", "a" to "z", or "A" to "Z". The value in 361 this field specifies the version of the syslog-sign protocol. This 362 is extensible to allow for different hash algorithms and signature 363 schemes to be used in the future. The value of this field is the 364 grouping of the protocol version (2 octets), the hash algorithm (1 365 octet) and the signature scheme (1 octet). 367 Protocol Version - 2 octets, with "01" as the value for the 368 protocol version that is described in this document. 370 Hash Algorithm - 1 octet, where, in conjunction with Protocol 371 Version 01, a value of "1" denotes SHA1 and a value of "2" denotes 372 SHA256, as defined in [FIPS.180-2.2002]. (This is the octet that 373 can have a value of not just "0" to "9" but also "a" to "z" and 374 "A" to "Z".) 376 Signature Scheme - 1 octet, where, in conjunction with Protocol 377 Version 01, a value of "1" denotes OpenPGP DSA, defined in 378 [RFC4880] and [FIPS.186-2.2000]. 380 The version, hash algorithm and signature scheme defined in this 381 document would accordingly be represented as "0111" (if SHA1 is used 382 as Hash Algorithm) and "0121" (if SHA256 is used as Hash Algorithm), 383 respectively (without the quotation marks). 385 The values of the Hash Algorithm and Signature Scheme are defined 386 relative to the Protocol Version. If the single-octet representation 387 of the values for Hash Algorithm and Signature Scheme were to ever 388 represent a limitation, this limitation could be overcome by defining 389 a new Protocol Version with additional Hash Algorithms and/or 390 Signature Schemes, and having implementations support both Protocol 391 Versions concurrently. 393 4.2.2. Reboot Session ID 395 The Reboot Session ID is a decimal value that has a length between 1 396 and 10 octets. The acceptable values for this are between 0 and 397 9999999999. Leading zeroes MUST be omitted. 399 A Reboot Session ID is expected to strictly monotonically increase 400 (i.e., to never repeat or decrease) whenever a signer reboots in 401 order to allow collectors to distinguish messages and message 402 signatures across reboots. There are several ways in which this may 403 be accomplished. In one way, the Reboot Session ID may increase by 404 1, starting with a value of 1. Note that in this case, a signer is 405 required to retain the previous Reboot Session ID across reboots. In 406 another way, a value of the unix time (number of seconds since 1 407 January 1970) may be used. Implementers of this method need to 408 beware of the possibility of multiple reboots occurring within a 409 single second. Implementers need to also beware of the year 2038 410 problem, which will cause the 32-bit representation of unix time to 411 wrap in the year 2038. In yet another way, implementers wish to 412 consider using the snmpEngineBoots value as a source for this counter 413 as defined in [RFC3414]. 415 In cases where a signer is not able to guarantee that the Reboot 416 Session ID is always increased after a reboot, the Reboot Session ID 417 MUST always be set to a value of 0. If the value can no longer be 418 increased (e.g., because it reaches 9999999999), it SHOULD be reset 419 to a value of 1. It is up to implementations to ensure that such a 420 reset does not go undetected, for example by requesting operator 421 acknowledgment when a reset is performed upon reboot. 423 If a reboot of a signer takes place, Signature Block messages MAY use 424 a new PROCID. However, Signature Block messages of the same signer 425 MUST continue to use the same HOSTNAME, APP-NAME, and MSGID. 427 4.2.3. Signature Group and Signature Priority 429 The SG parameter may take any value from 0-3 inclusive. The SPRI 430 parameter may take any value from 0-191 inclusive. These fields 431 taken together allow network administrators to associate groupings of 432 syslog messages with appropriate Signature Blocks and Certificate 433 Blocks. Groupings of syslog messages that are signed together are 434 also called Signature Groups. A Signature Block contains only hashes 435 of those syslog messages that are part of the same Signature Group. 437 For example, in some cases, network administrators might have 438 originators send syslog messages of Facilities 0 through 15 to one 439 collector and those with Facilities 16 through 23 to another. In 440 such cases, associated Signature Blocks should likely be sent to the 441 corresponding collectors as well, signing the syslog messages that 442 are intended for each collector separately. This way, each collector 443 receives Signature Blocks for all syslog messages that it receives, 444 and only for those. The ability to associate different categories of 445 syslog messages with different Signature Groups, signed in separate 446 Signature Blocks, provides administrators with flexibility in this 447 regard. 449 Syslog-sign provides four options for handling Signature Groups, 450 linking them with PRI values so they may be routed to the destination 451 commensurate with the corresponding syslog messages. In all cases, 452 no more than 192 distinct Signature Groups (0-191) are permitted. 454 The Signature Group to which a Signature Block pertains is indicated 455 by the Signature Priority (SPRI) field. The Signature Group (SG) 456 field indicates how to interpret the Signature Priority field. (Note 457 that the SG field does not indicate the Signature Group itself, as 458 its name might suggest.) The SG field can have one of the following 459 values: 461 a. "0" -- There is only one Signature Group. In this case, the 462 administrators want all Signature Blocks to be sent to a single 463 destination; in all likelihood, all of the syslog messages will 464 also be going to that same destination. Signature Blocks sign 465 all messages regardless of their PRI value. This means that, in 466 effect, the Signature Block's SPRI value can be ignored. 467 However, it is RECOMMENDED that a single SPRI value be used for 468 all Signature Blocks. Furthermore, it is RECOMMENDED to set that 469 value to the same value as the PRI field of the Signature Block 470 message. This way, the PRI of the Signature Block message 471 matches the SPRI of the Signature Block that it contains. 473 b. "1" -- Each PRI value is associated with its own Signature Group. 474 Signature Blocks for a given Signature Group have SPRI = PRI for 475 that Signature Group. In other words, the SPRI of the Signature 476 Block matches the PRI value of the syslog messages that are part 477 of the Signature Group and hence signed by the Signature Block. 478 An SG value of 1 can, for example, be used when the administrator 479 of a signer does not know where any of the syslog messages will 480 ultimately go but anticipates that messages with different PRI 481 values will be collected and processed separately. Having a 482 Signature Group per PRI value provides administrators with a 483 large degree of flexibility with regard to how to divide up the 484 processing of syslog messages and their signatures after they are 485 received, at the same time allowing Signature Blocks to follow 486 the corresponding syslog messages to their eventual destination. 488 c. "2" -- Each Signature Group contains a range of PRI values. 489 Signature Groups are assigned sequentially. A Signature Block 490 for a given Signature Group has its own SPRI value denoting the 491 highest PRI value of syslog messages in that Signature Group. 492 The lowest PRI value of syslog messages in that Signature Group 493 will be one larger than the SPRI value of the previous Signature 494 Group or "0" in case there is no other Signature Group with a 495 lower SPRI value. The specific Signature Groups and ranges they 496 are associated with are subject to configuration by a system 497 administrator. 499 d. "3" -- Signature Groups are not assigned with any of the above 500 relationships to PRI values of the syslog messages they sign. 501 Instead, another scheme is used, which is outside the scope of 502 this specification. There has to be some predefined arrangement 503 between the originator and the intended collectors as to which 504 syslog messages are to be included in which Signature Group, 505 requiring configuration by a system administrator. This provides 506 administrators also with the flexibility to group syslog messages 507 into Signature Groups according to criteria that are not tied to 508 the PRI value. 510 One reasonable way to configure some installations is to have only 511 one Signature Group, indicated with SG=0, and have the signer send a 512 copy of each Signature Block to each collector. In that case, 513 collectors that are not configured to receive every syslog message 514 will still receive signatures for every message, even ones they are 515 not supposed to receive. While the collector will not be able to 516 detect gaps in the messages (because the presence of a signature of a 517 message that is missing does not tell the collector whether or not 518 the corresponding message would be of the collector's concern), it 519 does allow all messages that do arrive at each collector to be put 520 into the right order and to be verified. It also allows each 521 collector to detect duplicates. Likewise, configuring only one 522 Signature Group can be a reasonable way to configure installations 523 that involve relay chains, where one or more interim relays may or 524 may not relay all messages to the same destination. 526 4.2.4. Global Block Counter 528 The Global Block Counter is a decimal value representing the number 529 of Signature Blocks sent by syslog-sign before the current one, in 530 this reboot session. This takes at least 1 octet and at most 10 531 octets displayed as a decimal counter. The acceptable values for 532 this are between 0 and 9999999999, starting with 0. Leading zeroes 533 MUST be omitted. If the value of the Global Block Counter has 534 reached 9999999999 and the Reboot Session ID has a value other than 0 535 (indicating the fact that persistence of the Reboot Session ID is 536 supported), then the Reboot Session ID MUST be incremented by 1 and 537 the Global Block Counter resumes at 0. When the Reboot Session ID is 538 0 (i.e., persistent Reboot Session IDs are not supported) and the 539 Global Block Counter reaches its maximum value, then the Global Block 540 Counter is reset to 0 and the Reboot Session ID MUST remain at 0. 542 Note that the Global Block Counter crosses Signature Groups; it 543 allows one to roughly synchronize when two messages were sent, even 544 though they went to different collectors and are part of different 545 Signature Groups. 547 Because a reboot results in the start of a new reboot session, the 548 signer MUST reset the Global Block Counter to 0 after a reboot 549 occurs. Applications need to take into account the possibility that 550 a reboot occurred when authenticating a log, and situations in which 551 reboots occur frequently may result in losing the ability to verify 552 the proper sequence in which messages were sent, hence jeopardizing 553 the integrity of the log. 555 4.2.5. First Message Number 557 This is a decimal value between 1 and 10 octets, with leading zeroes 558 omitted. It contains the unique message number within this Signature 559 Group of the first message whose hash appears in this block. The 560 very first message of the reboot session is numbered "1". This 561 implies that when the Reboot Session ID increases, the message number 562 is reset to 1. 564 For example, if this Signature Group has processed 1000 messages so 565 far and message number 1001 is the first message whose hash appears 566 in this Signature Block, then this field contains 1001. The message 567 number is relative to the Signature Group to which it belongs; hence, 568 a message number does not identify a message beyond its Signature 569 Group. 571 Should the message number reach 9999999999 within the same reboot 572 session and Signature Group, the message number subsequently restarts 573 at 1. In such event, the Global Block Counter will be vastly 574 different between two occurrences of the same message number. 576 4.2.6. Count 578 The count is a 1 or 2 octet field that indicates the number of 579 message hashes to follow. The valid values for this field are 1 580 through 99. The number of hashes included in the Signature Block 581 MUST be chosen such that the length of the resulting syslog message 582 does not exceed the maximum permissible syslog message length. 584 4.2.7. Hash Block 586 The hash block is a block of hashes, each separately encoded in base 587 64. Each hash in the hash block is the hash of the entire syslog 588 message represented by the hash, independent of the underlying 589 transport. Hashes are ordered from left to right in the order of 590 occurrence of the syslog messages that they represent. The space 591 character is used to separate the hashes. Note, the hash block 592 constitutes a single SD-Param; a Signature Block message MUST include 593 all its hashes in a single hash block and MUST NOT spread its hashes 594 across several hash blocks. 596 The "entire syslog message" refers to what is described as the syslog 597 message excluding transport parts that are described in [RFC5425] and 598 [RFC5426], and excluding other parts that may be defined in future 599 transports. The hash value will be the result of the hashing 600 algorithm run across the syslog message, starting with the "<" of the 601 PRI portion of the header part of the message. The hash algorithm 602 used and indicated by the Version field determines the size of each 603 hash, but the size MUST NOT be shorter than 160 bits without the use 604 of padding. It is base 64 encoded as per [RFC4648]. 606 The number of hashes in a hash block SHOULD be chosen such that the 607 resulting Signature Block message does not exceed a length of 2048 608 octets in order to avoid the possibility that truncation occurs. 609 When more hashes need to be sent than fit inside a Signature Block 610 message, it is advisable to start a new Signature Block. 612 4.2.8. Signature 614 This is a digital signature, encoded in base 64 per [RFC4648]. The 615 signature is calculated over the completely formatted Signature Block 616 message (starting from the first octet of PRI and continuing to the 617 last octet of MSG, or STRUCTURED-DATA if MSG is not present), before 618 the SIGN parameter (SD Parameter Name and the space before it [" 619 SIGN"], "=", and the corresponding value) is added. For the OpenPGP 620 DSA signature scheme, the value of the signature field contains the 621 DSA values r and s, encoded as two multiprecision integers (see 622 [RFC4880], Sections 5.2.2 and 3.2), concatenated, and then encoded in 623 base 64 [RFC4648]. 625 4.2.9. Example 627 An example of a Signature Block message is depicted below, broken 628 into lines to fit internet-draft publication rules. There is a space 629 at the end of each line, with the exception of the last line which 630 ends with "]" and the second-to-last line which ends with "ld6hg". 632 <110>1 2009-05-03T14:00:39.529966+02:00 host.example.org syslogd 633 2138 - [ssign VER="0111" RSID="1" SG="0" SPRI="0" GBC="2" FMN="1" 634 CNT="7" HB="K6wzcombEvKJ+UTMcn9bPryAeaU= zrkDcIeaDluypaPCY8WWzwHpPok= 635 zgrWOdpx16ADc7UmckyIFY53icE= XfopJ+S8/hODapiBBCgVQaLqBKg= 636 J67gKMFl/OauTC20ibbydwIlJC8= M5GziVgB6KPY3ERU1HXdSi2vtdw= 637 Wxd/lU7uG/ipEYT9xeqnsfohyH0=" 638 SIGN="AKBbX4J7QkrwuwdbV7Taujk2lvOf8gCgC62We1QYfnrNHz7FzAvdySuMyfM="] 640 The message is of syslog-sign protocol version "01". It uses SHA1 as 641 hash algorithm and an OpenPGP DSA signature scheme. Its reboot 642 session ID is 1. Its Signature Group is 0 which means that all 643 syslog messages go to the same destination; its Signature Priority 644 (which can effectively be ignored because all syslog messages will be 645 signed regardless of their PRI value) is 0. Its Global Block Counter 646 is 2. The first message number is 1; the message contains 7 message 647 hashes. 649 5. Payload and Certificate Blocks 651 Certificate Blocks and Payload Blocks provide key management for 652 syslog-sign. Their purpose is to support key management that uses 653 public key cryptosystems. 655 5.1. Preliminaries: Key Management and Distribution Issues 657 A Payload Block contains public key certificate information that is 658 to be conveyed to the collector. A Payload Block is sent at the 659 beginning of a new reboot session, carrying public key information in 660 effect for the reboot session. However, a Payload Block is not sent 661 directly, but in (one or more) fragments. Those fragments are termed 662 Certificate Blocks. Therefore, signers send at least one Certificate 663 Block at the beginning of a new reboot session. 665 There are three key points to understand about Certificate Blocks: 667 a. They handle a variable-sized payload, fragmenting it if necessary 668 and transmitting the fragments as legal syslog messages. This 669 payload is built (as described below) at the beginning of a 670 reboot session and is transmitted in pieces with each Certificate 671 Block carrying a piece. There is exactly one Payload Block per 672 reboot session. 674 b. The Certificate Blocks are digitally signed. The signer does not 675 sign the Payload Block, but the signatures on the Certificate 676 Blocks ensure its authenticity. Note that it may not even be 677 possible to verify the signature on the Certificate Blocks 678 without the information in the Payload Block; in this case the 679 Payload Block is reconstructed, the key is extracted, and then 680 the Certificate Blocks are verified. (This is necessary even 681 when the Payload Block carries a certificate, because some other 682 fields of the Payload Block are not otherwise verified.) In 683 practice, most installations keep the same public key over long 684 periods of time, so that most of the time, it is easy to verify 685 the signatures on the Certificate Blocks, and use the Payload 686 Block to provide other useful per-session information. 688 c. The kind of Payload Block that is expected is determined by what 689 kind of key material is on the collector that receives it. The 690 signer and collector (or offline log viewer) both have some key 691 material (such as a root public key or pre-distributed public 692 key) and an acceptable value for the Key Blob Type in the Payload 693 Block, below. The collector or offline log viewer MUST NOT 694 accept a Payload Block of the wrong type. 696 5.2. Payload Block 698 The Payload Block is built when a new reboot session is started. 699 There is a one-to-one correspondence between reboot sessions and 700 Payload Blocks. A signer creates a new Payload Block after each 701 reboot. The Payload Block is used until the next reboot. 703 5.2.1. Block Format and Fields 705 A Payload Block MUST have the following fields: 707 a. Full local time stamp for the signer at the time the reboot 708 session started. This must be in the time stamp format specified 709 in [RFC5424] (essentially, time stamp format per [RFC3339] with 710 some further restrictions). 712 b. Key Blob Type, a one-octet field containing one of five values: 714 1. 'C' -- a PKIX certificate. 716 2. 'P' -- an OpenPGP certificate (a Transferable Public Key as 717 defined in [RFC4880], Section 11.1). 719 3. 'K' -- the public key whose corresponding private key is 720 being used to sign these messages. For the OpenPGP DSA 721 signature scheme, this field contains the DSA prime p, DSA 722 group order q, DSA group generator g, and DSA public-key 723 value y, encoded as four multiprecision integers (see 724 [RFC4880], Sections 5.5.2 and 3.2). 726 4. 'N' -- no key information sent; key is pre-distributed. 728 5. 'U' -- installation-specific key exchange information 730 c. The key blob, if any, base 64 encoded per [RFC4648] and 731 consisting of the raw key data. 733 The fields are separated by single space characters. Because a 734 Payload Block is not carried in a syslog message directly, only the 735 corresponding Certificate Blocks, it does not need to be encoded as 736 an SD ELEMENT. The Payload Block does not contain a field that 737 identifies the reboot session; instead, the reboot session can be 738 inferred from the Reboot Session ID parameter of the Certificate 739 Blocks that are used to carry the Payload Block. 741 When a PKIX certificate is used ("C" key blob type), it is the 742 certificate specified in ([RFC5280]). Per [RFC5425], syslog messages 743 may be transported over the TLS protocol, even where there is no PKI. 745 If that transport is used, then the device will already have a PKIX 746 certificate and it MAY use the private key associated with that 747 certificate to sign messages. In the case where there is no PKI, the 748 chain of trust of a PKIX certificate must still be established to 749 meet conventional security requirements. The methods for doing this 750 are described in [RFC5425]. 752 5.2.2. Signer Authentication and Authorization 754 When the collector receives a Payload Block, it needs to determine 755 whether the signatures are to be trusted. The following methods are 756 in scope of this specification: 758 a. X.509 certification path validation: The collector is configured 759 with one or more trust anchors (typically root CA certificates), 760 which allow it to verify a binding between the subject name and 761 the public key. Certification path validation is performed as 762 specified in [RFC5280]. 764 If the HOSTNAME contains an FQDN or an IP address, it is then 765 compared against the certificate as described in [RFC5425], 766 Section 5.2. Comparing other forms of HOSTNAMEs is beyond the 767 scope of this specification. 769 Collectors SHOULD support this method. 771 Note that due to message size restrictions, syslog-sign sends 772 only the end-entity certificate in the Payload Block. Depending 773 on the PKI deployment, the collector may need to obtain 774 intermediate certificates by other means (for example, from a 775 directory). 777 b. X.509 end-entity certificate matching: The collector is 778 configured with information necessary to identify the valid end- 779 entity certificates of its valid peers, and for each peer, the 780 HOSTNAME(s) it is authorized to use. 782 To ensure interoperability, implementations MUST support 783 fingerprints of X.509 certificates as described below. Other 784 methods MAY be supported. 786 Collectors MUST support key blob type 'C', and specifying the 787 list of valid peers using certificate fingerprints. The 788 fingerprint is calculated and formatted as specified in 789 [RFC5425], Section 4.2.2. 791 For each peer, the collector MUST support specifying a list of 792 HOSTNAME(s) this peer is allowed to use either as FQDNs or IP 793 addresses. Other forms of HOSTNAMEs are beyond the scope of this 794 specification. 796 If the locally configured FQDN is an internationalized domain 797 name, conforming implementations MUST convert it to the ASCII 798 Compatible Encoding (ACE) format for performing comparisons as 799 specified in Section 7 of [RFC5280]. An exact case-insensitive 800 string match MUST be supported, but the implementation MAY also 801 support wildcards of any type ("*", regular expressions, etc.) in 802 locally configured names. 804 Signer implementations MUST provide a means to generate a key 805 pair and self-signed certificate in the case that a key pair and 806 certificate are not available through another mechanism, and MUST 807 make the certificate fingerprint available through a management 808 interface. 810 c. OpenPGP V4 fingerprints: Like X.509 fingerprints, except key blob 811 type 'P' is used, and the fingerprint is calculated as specified 812 in [RFC4880], Section 12.2. When the fingerprint value is 813 display or configured, each byte is represented in hexadecimal 814 (using two uppercase ASCII characters), and space is added after 815 every second byte. For example: "0830 2A52 2CD1 D712 6E76 6EEC 816 32A5 CAE1 03C8 4F6E". 818 Signers and collectors MAY support this method. 820 Other methods, such as "web of trust", are beyond the scope of this 821 document. 823 5.3. Certificate Block 825 This section describes the format of the Certificate Block and the 826 fields used within the Certificate Block, as well as the syslog 827 messages used to carry Certificate Blocks. 829 5.3.1. syslog Messages Containing a Certificate Block 831 Certificate Blocks are used to get the Payload Block to the 832 collector. As with a Signature Block, each Certificate Block is 833 carried in its own syslog message, called Certificate Block message. 834 In case separate collectors are associated with different Signature 835 Groups, Certificate Block messages need to be sent to each collector. 837 Because certificates can legitimately be much longer than 2048 838 octets, the Payload Block can be split up into several pieces, with 839 each Certificate Block carrying a piece of the Payload Block. Note 840 that the signer MAY make the Certificate Blocks of any legal length 841 (that is, any length that keeps the entire Certificate Block message 842 within 2048 octets) that holds all the required fields. Software 843 that processes Certificate Blocks MUST deal correctly with blocks of 844 any legal length. The length of the fragment of the Payload Block 845 that a Certificate Block carries MUST be at least 1 octet. The 846 length SHOULD be chosen such that the length of the Certificate Block 847 message does not exceed 2048 octets. 849 A Certificate Block message is identified by the presence of an SD 850 ELEMENT with an SD-ID with the value "ssign-cert". In addition, a 851 Certificate Block message MUST contain valid APP-NAME, PROCID, and 852 MSGID fields to be compliant with syslog protocol. Syslog-sign does 853 not mandate particular values for these fields; however, for 854 consistency, a signer MUST use the same value for APP-NAME, PROCID, 855 and MSGID fields for every Certificate Block message, whichever 856 values are chosen. It MUST also use the same value for its HOSTNAME 857 field. To allow for the possibility of multiple signers per host, 858 the combination of APP-NAME and PROCID MUST be unique for each such 859 originator. If a signer daemon is restarted, it MAY use a new PROCID 860 for what is otherwise the same signer. The combination of APP-NAME 861 and PROCID MUST be the same that is used for Signature Block messages 862 of the same signer; however, a different MSGID MAY be used for 863 Signature Block and Certificate Block messages. It is RECOMMENDED to 864 use 110 as value for the PRI field, corresponding to facility 13 (log 865 audit) and severity 6 (informational). The Certificate Block is 866 carried as Structured Data within the Certificate Block message. A 867 Certificate Block message MAY carry other Structured Data besides the 868 Structured Data of the Certificate Block itself. The MSG part of a 869 Certificate Block message SHOULD be empty. 871 5.3.2. Certificate Block Format and Fields 873 The contents of a Certificate Block message is the Certificate Block 874 itself. Like a Signature Block, the Certificate Block is encoded as 875 an SD ELEMENT. The SD-ID of the Certificate Block is "ssign-cert". 876 The Certificate Block is composed of the following fields, each of 877 which is encoded as an SD Parameter with parameter name as indicated. 878 Each field must be printable ASCII, and any binary values are base 64 879 encoded per [RFC4648]. 881 Field SD-PARAM-NAME Size in octets 882 ----- ------------- ---- -- ------ 884 Version VER 4 886 Reboot Session ID RSID 1-10 888 Signature Group SG 1 890 Signature Priority SPRI 1-3 892 Total Payload Block Length TPBL 1-8 894 Index into Payload Block INDEX 1-8 896 Fragment Length FLEN 1-4 898 Payload Block Fragment FRAG variable 899 (base 64 encoded binary) 901 Signature SIGN variable 902 (base 64 encoded binary) 904 The fields MUST be provided in the order listed. New SD parameters 905 MUST NOT be added unless a new Version of the protocol is defined. 906 (Implementations that wish to add proprietary extensions will need to 907 define a separate SD ELEMENT.) A Certificate Block is accordingly 908 encoded as follows, where xxx denotes a placeholder for the 909 particular values: 911 [ssign-cert VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" TPBL="xxx" 912 INDEX="xxx" FLEN="xxx" FRAG="xxx" SIGN="xxx"] 914 Values of the fields constitute SD parameter values and are hence 915 enclosed in quotes, per [RFC5424]. The fields are separated by 916 single spaces and are described below. Each SD parameter MUST occur 917 once and only once. 919 5.3.2.1. Version 921 The Version field is 4 octets in length. This field is identical in 922 format and meaning to the Version field described in Section 4.2.1. 924 5.3.2.2. Reboot Session ID 926 The Reboot Session ID is identical in format and meaning to the RSID 927 field described in Section 4.2.2. 929 5.3.2.3. Signature Group and Signature Priority 931 The SIG field is identical in format and meaning to the SIG field 932 described in Section 4.2.3. The SPRI field is identical in format 933 and meaning to the SPRI field described there. 935 A signer SHOULD send separate Certificate Block messages for each 936 Signature Group. This ensures that each collector that is associated 937 with a Signature Group will receive the necessary key material in the 938 case that messages of different Signature Groups are sent to 939 different collectors. Note that the signer needs to get the same 940 Payload Block to each collector, as for any given signer there is a 941 one-to-one relationship between Payload Block and Reboot Session 942 across all Signature Groups. Deployments that wish to associate 943 different key material (and hence different Payload Blocks) with 944 different Signature Groups can use separate signers for that purpose, 945 each distinguished by its own combination of HOSTNAME, APP-NAME, 946 PROCID. 948 5.3.2.4. Total Payload Block Length 950 The Total Payload Block Length is a value representing the total 951 length of the Payload Block in octets, expressed as a decimal with 952 one to eight octets with leading zeroes omitted. 954 5.3.2.5. Index into Payload Block 956 This is a decimal value between 1 and 8 octets, with leading zeroes 957 omitted. It contains the number of octets into the Payload Block at 958 which this fragment starts. The first octet of the first fragment is 959 numbered "1". (Note, it is not numbered "0".) 961 5.3.2.6. Fragment Length 963 The total length of this fragment expressed as a decimal integer with 964 one to four octets with leading zeroes omitted. The fragment length 965 must be at least 1. 967 5.3.2.7. Payload Block Fragment 969 The Payload Block Fragment contains a fragment of the payload block. 970 Its length must match the indicated fragment length. 972 5.3.2.8. Signature 974 This is a digital signature, encoded in base 64, as per [RFC4648]. 975 The Version field effectively specifies the original encoding of the 976 signature. The signature is calculated over the completely formatted 977 Certificate Block message, before the SIGN parameter is added (see 978 Section 4.2.8). For the OpenPGP DSA signature scheme, the value of 979 the signature field contains the DSA values r and s, encoded as two 980 multiprecision integers (see [RFC4880], Sections 5.2.2 and 3.2), 981 concatenated, and then encoded in base 64 [RFC4648]. 983 5.3.2.9. Example 985 An example of a Certificate Block message is is depicted below, 986 broken into lines to fit internet-draft publication rules. There are 987 no spaces at the end of the lines that contain the key blob and the 988 signature. 990 <110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd 991 2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587" 992 INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZN 993 CV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1zcX 994 ADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQrAAe 995 nBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9mN8n8 996 21BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry5X648 997 2fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTMgDXyC+ 998 bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgCssS9E1q 999 ARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZFRC1B82Su 1000 b152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg==" 1001 SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="] 1003 The message is of syslog-sign protocol version "01". It uses SHA1 as 1004 hash algorithm and an OpenPGP DSA signature scheme. Its reboot 1005 session ID is 1. Its Signature Group is 0; its Signature Priority is 1006 0. The Total Payload Block Length is 587. The index into the 1007 payload block is 1 (meaning this is the first fragment). The length 1008 of the fragment is 587 (meaning that the Certificate Block message 1009 contains the entire Payload Block). The Payload Block has the time 1010 stamp 2009-05-03T14:00:39.519005+02:00. The Key Blob Type is 'K', 1011 meaning that it contains a public key whose corresponding private key 1012 is being used to sign these messages. 1014 Note that the Certificate Block message in this example has the same 1015 time stamp as the Payload Block. This implies that this is the first 1016 Certificate Block message sent in this reboot session; additional 1017 Certificate Block messages can be sent later with a later time stamp, 1018 which will carry the same Payload Block that will still contain the 1019 same time stamp. 1021 6. Redundancy and Flexibility 1023 As described in Section 8.5 of [RFC5424], a transport sender may 1024 discard syslog messages. Likewise, when syslog messages are sent 1025 over unreliable transport, they can be lost in transit. However, if 1026 a collector does not receive Signature and Certificate Blocks, many 1027 messages may not be able to be verified. The signer is allowed to 1028 send Signature and Certificate Blocks multiple times. Sending 1029 Signature and Certificate Blocks multiple times provides redundancy 1030 with the intent to ensure that the collector or relay does get the 1031 Signature Blocks and in particular the Payload Block at some point in 1032 time. In the meantime, any online review of logs as described in 1033 Section 7.2 is delayed until the needed blocks are received. The 1034 collector MUST ignore Signature Blocks and Certificate Blocks it has 1035 already received and authenticated. The signer can in principle 1036 change its redundancy level for any reason, without communicating 1037 this fact to the collector. 1039 A signer that is also the originator of messages that it signs does 1040 not need to queue up other messages while sending redundant 1041 Certificate Block and Signature Block messages. It MAY send 1042 redundant Certificate Block messages even after Signature Block 1043 messages and regular syslog messages have been sent. By the same 1044 token, it MAY send redundant Signature Block messages even after 1045 newer syslog messages that are signed by a subsequent Signature Block 1046 have been sent, or even after a subsequent Signature Block message. 1048 In addition, the signer has flexibility in how many hashes to include 1049 within a Signature Block. It is legitimate for an originator to send 1050 short Signature Blocks to allow the collector to verify messages with 1051 minimal delay. 1053 6.1. Configuration parameters 1055 Although the transport sender is not constrained in how it decides to 1056 send redundant Signature and Certificate Blocks, or even in whether 1057 it decides to send along multiple copies of normal syslog messages, 1058 we define some redundancy parameters below which may be useful in 1059 controlling redundant transmission from the transport sender to the 1060 transport receiver, and which may be useful for administrators to 1061 configure. 1063 6.1.1. Configuration Parameters for Certificate Blocks 1065 Certificate Blocks are always sent at the beginning of a new reboot 1066 session. One technique to ensure reliable delivery (see Section 8.5) 1067 is to send multiple copies. This can be controlled by a 1068 "certInitialRepeat" parameter: 1070 certInitialRepeat = number of times each Certificate Block should 1071 be sent before the first message is sent. 1073 It is also useful to resend Certificate Blocks every now and then for 1074 long-lived reboot sessions. This can be controlled by the 1075 certResendDelay and certResendCount parameters: 1077 certResendDelay = maximum time delay in seconds until resending 1078 the Certificate Block. 1080 certResendCount = maximum number of other syslog messages to send 1081 until resending the Certificate Block. 1083 In some cases, it may be desirable to allow for configuration of the 1084 transport sender such that Certificate Blocks are not sent at all 1085 after the first normal syslog message has been sent. This could be 1086 expressed by setting both certResendDelay and certResendCount to "0". 1087 However, it is RECOMMENDED to configure the transport sender to send 1088 redundant Certificate Blocks even after the first message is sent 1089 when the UDP transport [RFC5426] is used. 1091 Implementations which support sending syslog messages of different 1092 Signature Groups to different collectors and which wish to offer very 1093 granular controls MAY consider allowing the above parameters to be 1094 configured on a per Signature Group basis. 1096 6.1.2. Configuration Parameters for Signature Blocks 1098 Verification of log messages involves a certain delay of time that is 1099 caused by the lag in time between the sending of the message itself 1100 and the corresponding Signature Block. The following configuration 1101 parameter can be useful to limit the time lag that will be incurred 1102 (note that the maximum message length may also force generating a 1103 Signature Block; see Sections Section 4.2.6 and Section 4.2.7): 1105 sigMaxDelay = generate a new Signature Block if this many seconds 1106 have elapsed since the message with the First Message Number of 1107 the Signature Block was sent. 1109 Retransmissions of Signature Blocks are not sent immediately after 1110 the original transmission, but slightly later. The following 1111 parameters control when those retransmissions are done: 1113 sigNumberResends = number of times a Signature Block is resent. 1114 (It is recommended so select a value of greater than "0" in 1115 particular when the UDP transport [RFC5426] is used.) 1116 sigResendDelay = send the next retransmission when this many 1117 seconds have elapsed since the previous sending of this Signature 1118 Block. 1120 sigResendCount = send the next retransmission when this many other 1121 syslog messages have been sent since the previous sending of this 1122 Signature Block. 1124 6.2. Overlapping Signature Blocks 1126 Notwithstanding the fact that the signer is not constrained in 1127 whether it decides to send redundant Signature Block messages, 1128 Signature Blocks SHOULD NOT overlap. This facilitates their 1129 processing by the receiving collector. This means that an originator 1130 of Signature Block messages, after having sent a first message with 1131 some First Message Number and a Count, SHOULD NOT send a second 1132 message with the same First Message Number but a different Count. It 1133 also means that an originator of Signature Block messages SHOULD NOT 1134 send a second message whose First Message Number is greater than the 1135 First Message Number, but smaller than the First Message Number plus 1136 the Count indicated in the first message. 1138 That said, the possibility of Signature Blocks that overlap does 1139 provide additional flexibility with regards to redundancy; it 1140 provides an additional option that may be desirable in some 1141 deployments. Therefore collectors MUST be designed in a way that 1142 they can cope with overlapping Signature Blocks when confronted with 1143 them. The collector MUST ignore hashes of messages that it has 1144 already received and validated. 1146 7. Efficient Verification of Logs 1148 The logs secured with syslog-sign may be reviewed either online or 1149 offline. Online review is somewhat more complicated and 1150 computationally expensive, but not prohibitively so. 1152 7.1. Offline Review of Logs 1154 When the collector stores logs to be reviewed later, they can be 1155 authenticated offline just before they are reviewed. Reviewing these 1156 logs offline is simple and relatively inexpensive in terms of 1157 resources used, so long as there is enough space available on the 1158 reviewing machine. 1160 To do so, we first go through the stored log file. Each message in 1161 the log file is classified as a normal message, a Signature Block 1162 message, or a Certificate Block message. Signature Blocks and 1163 Certificate Blocks are then separated by signer (as identified by 1164 HOSTNAME, APP-NAME, PROCID), Reboot Session ID, and Signature Group, 1165 and stored in their own files. Normal messages are stored in a keyed 1166 file, indexed on their hash values. They are not separated by 1167 signer, as their (HOSTNAME, APP-NAME, PROCID) identifies the 1168 application that generated the message. The application that 1169 generated the message does not have to coincide with the signer. 1171 For each signer, Reboot Session ID, and Signature Group, we then do 1172 the following: 1174 a. We sort the Certificate Block file by INDEX value, and check to 1175 see whether we have a set of Certificate Blocks that can 1176 reconstruct the Payload Block. If so, we reconstruct the Payload 1177 Block, verify any key-identifying information, and then use this 1178 to verify the signatures on the Certificate Blocks we have 1179 received. When this is done, we have verified the reboot session 1180 and key used for the rest of the process. 1182 b. We sort the Signature Block file by First Message Number. We now 1183 create an authenticated log file, which consists of some header 1184 information and then a sequence of message number, message text 1185 pairs. We next go through the Signature Block file. We 1186 initialize a cursor for the last message number processed with 1187 the number 0. For each Signature Block in the file, we do the 1188 following: 1190 1. Verify the signature on the Signature Block. 1192 2. If the value of the First Message Number of the Signature 1193 Block is less than or equal to the last message number 1194 processed, skip the first (last message number processed 1195 minus First Message Number plus 1) hashes. 1197 3. For each remaining hashed message in the Signature Block: 1199 a. Look up the hash value in the keyed message file. 1201 b. If the message is found, write (message number, message 1202 text) to the authenticated log file. 1204 4. Set the last message number processed to the value of the 1205 First Message Number plus the Count of the Signature Block 1206 minus 1. 1208 5. Skip all other Signature Blocks with the same First Message 1209 Number unless one with a larger Count is encountered. 1211 The resulting authenticated log file contains all messages that 1212 have been authenticated. In addition, it implicitly indicates 1213 all gaps in the authenticated messages (specifically in the case 1214 when all messages of the same Signature Group are sent to the 1215 same collector), because their message numbers are missing. 1217 One can see that, assuming sufficient space for building the keyed 1218 file, this whole process is linear in the number of messages 1219 (generally two seeks, one to write and the other to read, per normal 1220 message received), and O(N lg N) in the number of Signature Blocks. 1221 This estimate comes with two caveats: first, the Signature Blocks 1222 arrive very nearly in sorted order, and so can probably be sorted 1223 more cheaply on average than O(N lg N) steps. Second, the signature 1224 verification on each Signature Block almost certainly is more 1225 expensive than the sorting step in practice. We have not discussed 1226 error-recovery, which may be necessary for the Certificate Blocks. 1227 In practice, a simple error-recovery strategy is probably enough: if 1228 the Payload Block is not valid, then we can just try alternate 1229 instances of each Certificate Block, if such are available, until we 1230 get the Payload Block right. 1232 It is easy for an attacker to flood us with plausible-looking 1233 messages, Signature Blocks, and Certificate Blocks. 1235 7.2. Online Review of Logs 1237 Some collector implementations may need to monitor log messages in 1238 close to real-time. This can be done with syslog-sign, though it is 1239 somewhat more complex than offline verification. This is done as 1240 follows: 1242 a. We have an authenticated message file, into which we write 1243 (message number, message text) pairs which have been 1244 authenticated. We will assume that we are handling only one 1245 signer, Signature Group, and Reboot Session ID at any given time. 1246 (For the concurrent support of multiple signers, Signature 1247 Groups, and Reboot Session IDs, the same procedure is applied 1248 analogously to each. Signature Block mesages and Certificate 1249 Block messages clearly indicate their respective signer, 1250 Signature Group, and Reboot Session ID.) 1252 b. We have three data structures: A queue in which (message number, 1253 hash of message) pairs are kept in sorted order, a queue in which 1254 (arrival sequence, hash of message) pairs are kept in sorted 1255 order, and a hash table that stores (message text, count) pairs 1256 indexed by hash value. In the hash table, count may be any 1257 number greater than zero; when count is zero, the entry in the 1258 hash table is cleared. 1260 c. We must receive all the Certificate Blocks before any other 1261 processing can really be done. (This is why they are sent 1262 first.) Once that is done, any additional Certificate Block 1263 message that arrives is discarded. Any syslog messages or 1264 Signature Block messages that arrive before all Certificate 1265 Blocks have been received need to be buffered. Once all 1266 Certificate Blocks have been received, the messages in the buffer 1267 can be retrieved and processed as if they were just arriving. 1269 d. Whenever a normal message arrives, we add (arrival sequence, hash 1270 of message) to our message queue. If our hash table has an entry 1271 for the message's hash value, we increment its count by one; 1272 otherwise, we create a new entry with count = 1. If the message 1273 queue is full, we roll the oldest messages off the queue by 1274 taking the oldest entry in the queue, and using it to index the 1275 hash table. If that entry has count 1, we delete the entry from 1276 the hash table; otherwise, we decrement its count. We then 1277 delete the oldest entry in the queue. 1279 e. Whenever a Signature Block message arrives, we check its 1280 originator, (i.e. the signer) by way of HOSTNAME, APP-NAME, 1281 PROCID, as well as its Signature Group, and Reboot Session ID to 1282 ensure it matches our Certificate Blocks. We then check to see 1283 whether the First Message Number value is too old to still be of 1284 interest, or if another Signature Block with that First Message 1285 Number and the same Count or a greater Count has already been 1286 received. If so, we discard the Signature Block. Otherwise, we 1287 check its signature and discard it if the signature is not valid. 1288 A Signature Block contains a sequence of hashes, each of which is 1289 associated with a message number, starting with the First Message 1290 Number for the first hash and incrementing by one for each 1291 subsequent hash. For each hash, we first check to see whether 1292 the message hash is in the hash table. If this is the case, we 1293 do the following: 1295 A. We check if a message with the same message number is already 1296 in the authenticated message queue. 1298 B. If that is not the case, we write the (message number, 1299 message text) into the authenticated message queue, otherwise 1300 the signed hash is a duplicate and we discard it. 1302 Otherwise (the message hash is not in the hash table), we write 1303 the (message number, message hash) to the message number queue. 1304 This generally involves rolling the oldest entry out of this 1305 queue: before this is done, that entry's hash value is again 1306 looked up in the hash table. If a matching entry is found, a 1307 check is made if the authenticated message file already contains 1308 an entry with the same message number and if that is not the 1309 case, the (message number, message text) pair is written to the 1310 authenticated message. In either case, the oldest entry is then 1311 discarded. 1313 f. The result of this is a sequence of messages in the authenticated 1314 message file, each of which has been authenticated, and which are 1315 labeled with numbers showing their order of original 1316 transmission. 1318 One can see that this whole process is roughly linear in the number 1319 of messages, and also in the number of Signature Blocks received. 1320 The process is susceptible to flooding attacks; an attacker can send 1321 enough normal messages that the messages roll off their queue before 1322 their Signature Blocks can be processed. 1324 8. Security Considerations 1326 Normal syslog event messages are unsigned and have most of the 1327 security attributes described in Section 8 of [RFC5424]. This 1328 document also describes Certificate Blocks and Signature Blocks, 1329 which are signed syslog messages. The Signature Blocks contain 1330 signature information for previously sent syslog event messages. All 1331 of this information can be used to authenticate syslog messages and 1332 to minimize or obviate many of the security concerns described in 1333 [RFC5424]. 1335 The model for syslog-sign is a direct trust system where the 1336 certificate transferred is its own trust anchor. If a transport 1337 sender sends a stream of syslog messages that is signed using a 1338 certificate, the operator or application will transfer to the 1339 transport receiver the certificate that was used when signing. There 1340 is no need for a certificate chain. 1342 8.1. Cryptographic Constraints 1344 As with any technology involving cryptography, it is advisable to 1345 check the current literature to determine whether any algorithms used 1346 here have been found to be vulnerable to attack. 1348 This specification uses Public Key Cryptography technologies. The 1349 proper party or parties have to control the private key portion of a 1350 public-private key pair. Any party that controls a private key can 1351 sign anything it pleases. 1353 Certain operations in this specification involve the use of random 1354 numbers. An appropriate entropy source SHOULD be used to generate 1355 these numbers. See [RFC4086] and [NIST800.90]. 1357 8.2. Packet Parameters 1359 As a signer, it is advisable to avoid message lengths exceeding 2048 1360 octets. Various problems might result if a signer were to send 1361 messages with a length greater than 2048 octets, because relays MAY 1362 truncate messages with lengths greater than 2048 octets which would 1363 make it impossible for collectors to validate a hash of the packet. 1364 To increase the chance of interoperability, it tends to be best to be 1365 conservative with what you send but liberal in what you are able to 1366 receive. 1368 Signers need to rigidly enforce the correctness of message bodies. 1369 Problems may arise if the collector does not fully accept the syslog 1370 packets sent from an signer, or if it has problems with the format of 1371 the Certificate Block or Signature Block messages. 1373 Collectors are not to malfunction in case they receive malformed 1374 syslog messages or messages containing characters other than those 1375 specified in this document. In other words, they are to ignore such 1376 messages and continue working. 1378 8.3. Message Authenticity 1380 Syslog does not strongly associate the message with the message 1381 originator. That association is established by the collector upon 1382 verification of the Signature Block. Before a Signature Block is 1383 used to ascertain the authenticity of an event message, it might be 1384 received, stored, and reviewed by a person or automated parser. It 1385 is advisable not to assume a message is authentic until after a 1386 message has been validated by checking the contents of the Signature 1387 Block. 1389 With the Signature Block checking, an attacker may only forge 1390 messages if he or she can compromise the private key of the true 1391 originator. 1393 8.4. Replaying 1395 Event messages might be recorded and replayed by an attacker. Using 1396 the information contained in the Signature Blocks, a reviewer can 1397 determine whether the received messages are the ones originally sent 1398 by an originator. The reviewer can also identify messages that have 1399 been replayed. 1401 8.5. Reliable Delivery 1403 Event messages sent over UDP might be lost in transit. [RFC5425] can 1404 be used for the reliable delivery of syslog messages; however, it 1405 does not protect against loss of syslog messages at the application 1406 layer, for example if the TCP connection or TLS session has been 1407 closed by the transport receiver for some reason. A reviewer can 1408 pinpoint any messages sent by the originator but not received by the 1409 collector by reviewing the Signature Block information. In addition, 1410 the information in subsequent Signature Blocks allows a reviewer to 1411 determine whether any Signature Block messages were lost in transit. 1413 8.6. Sequenced Delivery 1415 Syslog messages delivered over UDP might not only be lost, but also 1416 arrive out of sequence. A reviewer can determine the original order 1417 of syslog messages and identify which messages were delivered out of 1418 order by examining the information in the Signature Block along with 1419 any timestamp information in the message. 1421 8.7. Message Integrity 1423 Syslog messages might be damaged in transit. A review of the 1424 information in the Signature Block determines whether the received 1425 message was the intended message sent by the originator. A damaged 1426 Signature Block or Certificate Block is evident because the collector 1427 will not be able to validate that it was signed by the signer. 1429 8.8. Message Observation 1431 Unless TLS is used as a secure transport [RFC5425], event messages, 1432 Certificate Blocks, and Signature Blocks are all sent in plaintext. 1433 This allows network administrators to read the message when sniffing 1434 the wire. However, this also allows an attacker to see the contents 1435 of event messages and perhaps to use that information for malicious 1436 purposes. 1438 8.9. Man In The Middle Attacks 1440 It is conceivable that an attacker might intercept Certificate Block 1441 messages and insert its own Certificate information. In that case, 1442 the attacker would be able to receive event messages from the actual 1443 originator and then relay modified messages, insert new messages, or 1444 delete messages. It would then be able to construct a Signature 1445 Block and sign it with its own private key. Network administrators 1446 need to verify that the key contained in the Payload Block is indeed 1447 the key being used on the actual signer. If that is the case, then 1448 this MITM attack will not succeed. Methods for establishing a chain 1449 of trust are also described in [RFC5425]. 1451 8.10. Denial of Service 1453 An attacker might send invalid Signature Block messages to overwhelm 1454 the collector's processing capability and consume all available 1455 resources. For this reason, it can be appropriate to simply receive 1456 the Signature Block messages and process them only as time permits. 1458 An attacker might also just overwhelm a collector by sending more 1459 messages to it than it can handle. Implementers are advised to 1460 consider features that minimize this threat, such as only accepting 1461 syslog messages from known IP addresses. 1463 8.11. Covert Channels 1465 Nothing in this protocol attempts to eliminate covert channels. In 1466 fact, just about every aspect of syslog messages lends itself to the 1467 conveyance of covert signals. For example, a collusionist could send 1468 odd and even PRI values to indicate Morse Code dashes and dots. 1470 9. IANA Considerations 1472 9.1. Structured Data and syslog messages 1474 With regard to [RFC5424], IANA is requested to add the following 1475 values to the registry entitled "syslog Structured Data id values": 1477 SD-ID PARAM_NAME 1478 ----- ---------- 1479 ssign 1480 VER 1481 RSID 1482 SG 1483 SPRI 1484 GBC 1485 FMN 1486 CNT 1487 HB 1488 SIGN 1490 ssign-cert 1491 VER 1492 RSID 1493 SG 1494 SPRI 1495 TPBL 1496 INDEX 1497 FLEN 1498 FRAG 1499 SIGN 1501 In addition, several fields need to be controlled by the IANA in both 1502 the Signature Block and the Certificate Block, as outlined in the 1503 following sections. 1505 9.2. Version Field 1507 IANA is requested to create three registries, each associated with a 1508 different subfield of the Version field of Signature Blocks and 1509 Certificate Blocks, described in Section 4.2.1 and Section 5.3.2.1, 1510 respectively. 1512 The first registry that IANA is requested to create is entitled 1513 "syslog-sign protocol version values". It is for the values of the 1514 Protocol Version subfield. The Protocol Version subfield constitutes 1515 the first 2 octets in the Version field. New values shall be 1516 assigned by the IANA using the "IETF Review" policy defined in 1517 [RFC5226]. Assigned numbers are to be increased by 1, up to a 1518 maximum value of "50". Protocol Version numbers of "51" through "99" 1519 are vendor-specific; values in this range are not to be assigned by 1520 the IANA. 1522 IANA is requested to register the Protocol Version values shown 1523 below. 1525 VALUE PROTOCOL VERSION 1526 ----- ---------------- 1527 00 Reserved 1528 01 Defined in RFC yyyy 1530 The second registry that IANA is requested to create is entitled 1531 "syslog-sign hash algorithm values". It is for the values of the 1532 Hash Algorithm subfield. The Hash Algorithm subfield constitutes the 1533 third octet in the Version field Signature Blocks and Certificate 1534 Blocks. New values shall be assigned by the IANA using the "IETF 1535 Consensus" policy defined in [RFC5226]. Assigned values are to be 1536 increased sequentially, first up to a maximum value of "9", then from 1537 "a" to "z", then from "A" to "Z". The values are registered relative 1538 to the Protocol Version. This means that the same Hash Algorithm 1539 value can be reserved for different Protocol Versions, possibly 1540 referring to a different hash algorithm each time. This makes it 1541 possible to deal with future scenarios in which the single octet 1542 representation becomes a limitation, as more Hash Algorithms can be 1543 supported by defining additional Protocol Versions that 1544 implementations might support concurrently. 1546 IANA is requested to register the Hash Algorithm values shown below. 1548 VALUE PROTOCOL VERSION HASH ALGORITHM 1549 ----- ---------------- -------------- 1550 0 01 Reserved 1551 1 01 SHA1 1552 2 01 SHA256 1554 The third registry that IANA is requested to create is entitled 1555 "syslog-sign signature scheme values". It is for the values of the 1556 Signature Scheme subfield. The Signature Scheme subfield constitutes 1557 the fourth octet in the Version field of Signature Blocks and 1558 Certificate Blocks. New values shall be assigned by the IANA using 1559 the "IETF Consensus" policy defined in [RFC5226]. Assigned values 1560 are to be increased by 1, up to a maximum value of "9". This means 1561 that the same Signature Scheme value can be reserved for different 1562 Protocol Versions, possibly in each case referring to a different 1563 Signature Scheme each time. This makes it possible to deal with 1564 future scenarios in which the single octet representation becomes a 1565 limitation, as more Signature Schemes can be supported by defining 1566 additional Protocol Versions that implementations might support 1567 concurrently. 1569 IANA is requested to register the Signature Scheme values shown 1570 below. 1572 VALUE PROTOCOL VERSION SIGNATURE SCHEME 1573 ----- ---------------- ---------------- 1574 0 01 Reserved 1575 1 01 OpenPGP DSA 1577 9.3. SG Field 1579 IANA is requested to create a registry entitled "syslog-sign sg field 1580 values". It is for values of the SG Field as defined in 1581 Section 4.2.3. New values shall be assigned by the IANA using the 1582 "IETF Consensus" policy defined in [RFC5226]. Assigned values are to 1583 be incremented by 1, up to a maximum value of "7". Values "8" and 1584 "9" shall be left as vendor specific and shall not be assigned by the 1585 IANA. 1587 IANA is requested to register the SG Field values shown below. 1589 VALUE MEANING 1590 ----- ------- 1591 0 per RFC yyyy 1592 1 per RFC yyyy 1593 2 per RFC yyyy 1594 3 per RFC yyyy 1596 9.4. Key Blob Type 1598 IANA is requested to create a registry entitled "syslog-sign key blob 1599 type values". It is to register one-character identifiers for the 1600 key blob type, per Section 5.2. New values shall be assigned by the 1601 IANA using the "IETF Consensus" policy defined in [RFC5226]. 1602 Uppercase letters may be assigned as values. Lowercase letters are 1603 left as vendor specific and shall not be assigned by the IANA. 1605 IANA is requested to register the key blob type values shown below. 1607 VALUE KEY BLOB TYPE 1608 ----- ------------ 1609 'C' a PKIX certificate 1610 'P' an OpenPGP certificate 1611 'K' the public key whose corresponding private key is 1612 used to sign the messages 1613 'N' no key information sent, key is pre-distributed 1614 'U' installation-specific key exchange information 1616 10. Working Group 1618 The working group can be contacted via the mailing list: 1620 syslog@ietf.org 1622 The current Chairs of the Working Group can be contacted at: 1624 Chris Lonvick 1625 Cisco Systems 1626 Email: clonvick@cisco.com 1628 David Harrington 1629 Huawei Technologies (USA) 1630 Email: ietfdbh@comcast.net 1631 dharrington@huawei.com 1632 Tel: +1-603-436-8634 1634 11. Acknowledgements 1636 The authors wish to thank Alex Brown, Chris Calabrese, Steve Chang, 1637 Pasi Eronen, Carson Gaspar, Rainer Gerhards, Drew Gross, David 1638 Harrington, Chris Lonvick, Albert Mietus, Darrin New, Marshall Rose, 1639 Andrew Ross, Martin Schuette, Holt Sorenson, Rodney Thayer, and the 1640 many Counterpane Internet Security engineering and operations people 1641 who commented on various versions of this proposal. 1643 12. References 1645 12.1. Normative References 1647 [FIPS.186-2.2000] 1648 National Institute of Standards and Technology, "Digital 1649 Signature Standard", FIPS PUB 186-2, January 2000, . 1653 [FIPS.180-2.2002] 1654 National Institute of Standards and Technology, "Secure 1655 Hash Standard", FIPS PUB 180-2, August 2002, . 1658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1659 Requirement Levels", BCP 14, RFC 2119, March 1997. 1661 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1662 Encodings", RFC 4648, October 2006. 1664 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1665 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1667 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1668 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1669 May 2008. 1671 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1672 Housley, R., and W. Polk, "Internet X.509 Public Key 1673 Infrastructure Certificate and Certificate Revocation List 1674 (CRL) Profile", RFC 5280, May 2008. 1676 [RFC5424] Gerhards, R., "The syslog Protocol", RFC 5424, March 2009. 1678 [RFC5425] Miao, F., Yuzhi, M., and J. Salowey, "TLS Transport 1679 Mapping for syslog", RFC 5425, March 2009. 1681 [RFC5426] Okmianski, A., "Transmission of syslog Messages over UDP", 1682 RFC 5426, March 2009. 1684 12.2. Informative References 1686 [NIST800.90] 1687 National Institute of Standards and Technology, "NIST 1688 Special Publication 800-90: Recommendation for Random 1689 Number Generation using Deterministic Random Bit 1690 Generators", June 2006, . 1694 [RFC3164] Lonvick, C., "The BSD syslog Protocol", RFC 3164, 1695 August 2001. 1697 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1698 Timestamps", RFC 3339, July 2002. 1700 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1701 (USM) for version 3 of the Simple Network Management 1702 Protocol (SNMPv3)", RFC 3414, December 2002. 1704 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1705 Recommendations for Security", RFC 4086, June 2005. 1707 Authors' Addresses 1709 John Kelsey 1710 NIST 1712 Email: john.kelsey@nist.gov 1714 Jon Callas 1715 PGP Corporation 1717 Email: jon@callas.org 1719 Alexander Clemm 1720 Cisco Systems 1722 Email: alex@cisco.com