idnits 2.17.1 draft-ietf-syslog-sign-26.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 10 instances of too long lines in the document, the longest one being 2 characters 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 (May 27, 2009) is 5448 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: November 28, 2009 PGP Corporation 6 A. Clemm 7 Cisco Systems 8 May 27, 2009 10 Signed syslog Messages 11 draft-ietf-syslog-sign-26.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 November 28, 2009. 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. Originator 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. 134 While most implementations of syslog involve only a single originator 135 and a single collector of each message, provisions need to be made to 136 cover situations in which messages are sent to multiple collectors. 137 This concerns, in particular, situations in which different messages 138 from the same originator are sent to different collectors, which 139 means that some messages are sent to some collectors but not to 140 others. The required differentiation of messages is generally 141 performed based on the Priority value of the individual messages. 142 For example, messages from any Facility with a Severity value of 3, 143 2, 1, or 0 may be sent to one collector while all messages of 144 Facilities 4, 10, 13, and 14 may be sent to another collector. 145 Appropriate syslog-sign messages must be kept with their proper 146 syslog messages. To address this, syslog-sign uses a Signature 147 Group. A Signature Group identifies a group of messages that are all 148 kept together for signing purposes by the originator. A Signature 149 Block always belongs to exactly one Signature Group and always signs 150 messages belonging only to that Signature Group. 152 Additionally, an originator sends a Certificate Block to provide key 153 management information between the originator and the collector. 154 This Certificate Block has a field to denote the type of key material 155 which may be such things as a PKIX certificate, an OpenPGP 156 certificate, or even an indication that a key had been pre- 157 distributed. In the cases of certificates being sent, the 158 certificates may have to be split across multiple packets. 160 It is possible that the same host contains multiple originators that 161 each use their own keys to sign syslog messages. In this case, each 162 originator sends its own Certificate Block and Signature Blocks. 163 Furthermore, each originator defines its own Signature Groups. Each 164 originator on a given host needs to use a a distinct combination of 165 APP-NAME and PROCID for its Signature Block and Certificate Block 166 message. (This implies that, provided the originators include in 167 their messages a HOSTNAME that uniquely identifies a host, not a 168 NILVALUE, the combination of HOSTNAME, APP-NAME and PROCID uniquely 169 distinguishes originators of syslog-sign messages across hosts.) 170 The collector of the previous messages may verify that the hash of 171 each received message matches the signed hash contained in the 172 Signature Block. A collector may process these Signature Blocks as 173 they arrive, building an authenticated log file. Alternatively, it 174 may store all the log messages in the order they were received. This 175 allows a network operator to authenticate the log file at the time 176 the logs are reviewed. 178 The mechanism described in this specification is intended to be used 179 in conjunction with the syslog protocol as defined in [RFC5424] as 180 its message delivery mechanism and uses the concept of STRUCTURED- 181 DATA elements defined in that document. In fact, this specification 182 mandates implementation of syslog protocol. Nevertheless, it is 183 conceivable that the concepts underlying this mechanism could also be 184 used in conjunction with other message delivery mechanisms. 185 Designers of other efforts to define event notification mechanisms 186 are therefore encouraged to consider this specification in their 187 designs. 189 2. Conventions Used in this Document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [RFC2119]. 195 3. syslog Message Format 197 This specification is intended to be used in conjunction with the 198 syslog protocol as defined in [RFC5424]. The syslog protocol 199 therefore MUST be supported by implementations of this specification. 201 Because the originator generating the Signature Block message signs 202 each message in its entirety, the messages MUST NOT be changed in 203 transit. By the same token, the syslog-sign messages MUST NOT be 204 changed in transit. [RFC3164] describes relay behavior in which 205 syslog messages are altered. If such behavior were to occur in 206 conjunction with syslog-sign, it would render any signing invalid and 207 hence make the mechanism useless. Likewise, any truncation of 208 messages that occurs between sending and receiving renders the 209 mechanism useless. For this reason, syslog originator and collector 210 implementations implementing this specification MUST support messages 211 of up to and including 2048 octets in length, in order to minimize 212 the chance of truncation. While syslog originator and collector 213 implementations MAY support messages with a length larger than 2048 214 octets, implementers need to be aware that any message truncations 215 that occur render the mechanism useless. 217 This specification uses the syslog message format described in 218 [RFC5424]. Along with other fields, that document describes the 219 concept of Structured Data (SD). Structured Data is defined in terms 220 of SD ELEMENTS (SDEs). An SDE consists of a name and a set of 221 parameter name - value pairs. The SDE name is referred to as SD-ID. 222 The name-value pairs are referred to as SD-PARAM, or SD Parameters, 223 with the name constituting the SD-PARAM-NAME, and the value 224 constituting the SD-PARAM-VALUE. 226 The syslog messages defined in this document carry the signature and 227 certificate data as Structured Data. The special syslog messages 228 defined in this document include for this purpose definitions of SDEs 229 to convey parameters that relate to the signing of syslog messages. 230 The MSG part of the syslog messages defined in this document SHOULD 231 simply be empty -- the content of the messages is not intended for 232 interpretation by humans but by applications that use those messages 233 to build an authenticated log. 235 Because the syslog messages defined in this document adhere to the 236 format described in [RFC5424], they identify the machine that 237 originates the syslog message in the HOSTNAME field. Therefore, the 238 signature and certificate data do not need to include any additional 239 parameter to identify the machine that orginates the message. 241 In addition, the same host MAY host several originators that each 242 sign syslog messages independently of each other, each using their 243 own Signature Groups. In the context of syslog-sign, different such 244 originators on the same host are distinguished by the combination of 245 APP-NAME and PROCID fields used in their messages, hence the 246 combination of APP-NAME and PROCID MUST be unique for an originator 247 on a given host. (This implies that, provided the message contains a 248 HOSTNAME that uniquely identifies a host, not a NILVALUE, the 249 combination of HOSTNAME, APP-NAME and PROCID uniquely identifies an 250 originator across hosts.) A Signature Block message MUST use the 251 same combination of HOSTNAME, APP-NAME, and PROC-ID that was used to 252 send the corresponding Certificate Block messages containing the 253 Payload Block. 255 4. Signature Blocks 257 This section describes the format of the Signature Block and the 258 fields used within the Signature Block, as well as the syslog 259 messages used to carry the Signature Block. 261 4.1. syslog Messages Containing a Signature Block 263 There is a need to distinguish the Signature Block itself from the 264 syslog message that is used to carry a Signature Block. Signature 265 Blocks MUST be encompassed within completely formed syslog messages. 266 Syslog messages that contain a Signature Block are also referred to 267 as Signature Block messages. 269 A Signature Block message is identified by the presence of an SD 270 ELEMENT with an SD-ID with the value "ssign". In addition, a 271 Signature Block message MUST contain valid APP-NAME, PROCID, and 272 MSGID fields to be compliant with [RFC5424]. This specification does 273 not mandate particular values for these fields; however, for 274 consistency, an originator MUST use the same values for APP-NAME, 275 PROCID, and MSGID fields for every Signature Block message that is 276 sent, whichever values are chosen. It MUST also use the same value 277 for its HOSTNAME field. To allow for the possibility of multiple 278 originators per host, the combination of APP-NAME and PROCID MUST be 279 unique for each such originator on any given host. If an originator 280 daemon is restarted, it MAY use a new PROCID for what is otherwise 281 the same originator but MUST continue to use the same APP-NAME. If 282 it uses a new PROCID, it MUST send a new Payload Block using 283 Certificate Block messages that use the same new PROCID (and the same 284 APP-NAME). It is RECOMMENDED (but not required) to use 110 as value 285 for the PRI field, corresponding to facility 13 and severity 6 286 (informational). The Signature Block is carried as Structured Data 287 within the Signature Block message, per the definitions that follow 288 in the next section. A Signature Block message MAY carry other 289 Structured Data besides the Structured Data of the Signature Block 290 itself. The MSG part of a Signature Block message SHOULD be empty. 292 The syslog messages defined as part of syslog-sign themselves 293 (Signature Block messages and Certificate Block messages) MUST NOT be 294 signed by a Signature Block. Collectors that implement syslog-sign 295 know to distinguish syslog messages that are associated with syslog- 296 sign from those that are subjected to signing and process them 297 differently. The intent of syslog-sign is to sign a stream of syslog 298 messages, not to alter it. 300 4.2. Signature Block Format and Fields 302 The content of a Signature Block message is the Signature Block. The 303 Signature Block MUST be encoded as an SD ELEMENT, as defined in 304 [RFC5424]. 306 The SD-ID MUST have the value of "ssign". 308 The SDE contains the fields of the Signature Block encoded as SD 309 Parameters, as specified in the following. The Signature Block is 310 composed of the following fields. The value of each field MUST be 311 printable ASCII, and any binary values MUST be base 64 encoded, as 312 defined in [RFC4648]. 314 Field SD-PARAM-NAME Size in octets 315 ----- ------------- ---- -- ------ 317 Version VER 4 319 Reboot Session ID RSID 1-10 321 Signature Group SG 1 323 Signature Priority SPRI 1-3 325 Global Block Counter GBC 1-10 327 First Message Number FMN 1-10 329 Count CNT 1-2 331 Hash Block HB variable, size of hash 332 times the number of hashes 333 (base 64 encoded binary) 335 Signature SIGN variable 336 (base 64 encoded binary) 338 The fields MUST be provided in the order listed. Each SD parameter 339 MUST occur once and only once in the Signature Block. New SD 340 parameters MUST NOT be added unless a new Version of the protocol is 341 defined. (Implementations that wish to add proprietary extensions 342 will need to define a separate SD ELEMENT.) A Signature Block is 343 accordingly encoded as follows, where xxx denotes a placeholder for 344 the particular values: 346 [ssign VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" GBC="xxx" FMN="xxx" 347 CNT="xxx" HB="xxx" SIGN="xxx"] 348 Values of the fields constitute SD parameter values and are hence 349 enclosed in quotes, per [RFC5424]. The fields are separated by 350 single spaces and are described in the subsequent subsections. 352 4.2.1. Version 354 The Version field is an alphanumeric value that has a length of 4 355 octets, which may include leading zeroes. The first two octets and 356 the last octet contain a decimal character in the range of "0" to 357 "9", whereas the third octet contains an alphanumeric character in 358 the range of "0" to "9", "a" to "z", or "A" to "Z". The value in 359 this field specifies the version of the syslog-sign protocol. This 360 is extensible to allow for different hash algorithms and signature 361 schemes to be used in the future. The value of this field is the 362 grouping of the protocol version (2 octets), the hash algorithm (1 363 octet) and the signature scheme (1 octet). 365 Protocol Version - 2 octets, with "01" as the value for the 366 protocol version that is described in this document. 368 Hash Algorithm - 1 octet, where, in conjunction with Protocol 369 Version 01, a value of "1" denotes SHA1 and a value of "2" denotes 370 SHA256, as defined in [FIPS.180-2.2002]. (This is the octet that 371 can have a value of not just "0" to "9" but also "a" to "z" and 372 "A" to "Z".) 374 Signature Scheme - 1 octet, where, in conjunction with Protocol 375 Version 01, a value of "1" denotes OpenPGP DSA, defined in 376 [RFC4880] and [FIPS.186-2.2000]. 378 The version, hash algorithm and signature scheme defined in this 379 document would accordingly be represented as "0111" (if SHA1 is used 380 as Hash Algorithm) and "0121" (if SHA256 is used as Hash Algorithm), 381 respectively (without the quotation marks). 383 The values of the Hash Algorithm and Signature Scheme are defined 384 relative to the Protocol Version. If the single-octet representation 385 of the values for Hash Algorithm and Signature Scheme were to ever 386 represent a limitation, this limitation could be overcome by defining 387 a new Protocol Version with additional Hash Algorithms and/or 388 Signature Schemes, and having implementations support both Protocol 389 Versions concurrently. 391 4.2.2. Reboot Session ID 393 The Reboot Session ID is a decimal value that has a length between 1 394 and 10 octets. The acceptable values for this are between 0 and 395 9999999999. Leading zeroes MUST be omitted. 397 A Reboot Session ID is expected to strictly monotonically increase 398 (i.e., to never repeat or decrease) whenever an originator reboots in 399 order to allow collectors to distinguish messages and message 400 signatures across reboots. There are several ways in which this may 401 be accomplished. In one way, the Reboot Session ID may increase by 402 1, starting with a value of 1. Note that in this case, an originator 403 is required to retain the previous Reboot Session ID across reboots. 404 In another way, a value of the unix time (number of seconds since 1 405 January 1970) may be used. Implementers of this method need to 406 beware of the possibility of multiple reboots occurring within a 407 single second. Implementers need to also beware of the year 2038 408 problem, which will cause the 32-bit representation of unix time to 409 wrap in the year 2038. In yet another way, implementers wish to 410 consider using the snmpEngineBoots value as a source for this counter 411 as defined in [RFC3414]. 413 In cases where an originator is not able to guarantee that the Reboot 414 Session ID is always increased after a reboot, the Reboot Session ID 415 MUST always be set to a value of 0. If the value can no longer be 416 increased (e.g., because it reaches 9999999999), then manual 417 intervention may be required to subsequently reset it. 419 If a reboot of an originator takes place, Signature Block messages 420 MAY use a new PROCID. However, Signature Block messages of the same 421 originator MUST continue to use the same HOSTNAME, APP-NAME, and 422 MSGID. 424 4.2.3. Signature Group and Signature Priority 426 The SG parameter may take any value from 0-3 inclusive. The SPRI 427 parameter may take any value from 0-191 inclusive. These fields 428 taken together allow network administrators to associate groupings of 429 syslog messages with appropriate Signature Blocks and Certificate 430 Blocks. Groupings of syslog messages that are signed together are 431 also called Signature Groups. A Signature Block contains only hashes 432 of those syslog messages that are part of the same Signature Group. 434 For example, in some cases, network administrators might have 435 originators send syslog messages of Facilities 0 through 15 to one 436 collector and those with Facilities 16 through 23 to another. In 437 such cases, associated Signature Blocks should likely be sent to the 438 corresponding collectors as well, signing the syslog messages that 439 are intended for each collector separately. This way, each collector 440 receives Signature Blocks for all syslog messages that it receives, 441 and only for those. The ability to associate different categories of 442 syslog messages with different Signature Groups, signed in separate 443 Signature Blocks, provides administrators with flexibility in this 444 regard. 446 Syslog-sign provides four options for handling Signature Groups, 447 linking them with PRI values so they may be routed to the destination 448 commensurate with the corresponding syslog messages. In all cases, 449 no more than 192 distinct Signature Groups (0-191) are permitted. 451 The Signature Group to which a Signature Block pertains is indicated 452 by the Signature Priority (SPRI) field. The Signature Group (SG) 453 field indicates how to interpret the Signature Priority field. (Note 454 that the SG field does not indicate the Signature Group itself, as 455 its name might suggest.) The SG field can have one of the following 456 values: 458 a. "0" -- There is only one Signature Group. In this case, the 459 administrators want all Signature Blocks to be sent to a single 460 destination; in all likelihood, all of the syslog messages will 461 also be going to that same destination. Signature Blocks sign 462 all messages regardless of their PRI value. This means that, in 463 effect, the Signature Block's SPRI value can be ignored. 464 However, it is RECOMMENDED that a single SPRI value be used for 465 all Signature Blocks. Furthermore, it is RECOMMENDED to set that 466 value to the same value as the PRI field of the Signature Block 467 message. This way, the PRI of the Signature Block message 468 matches the SPRI of the Signature Block that it contains. 470 b. "1" -- Each PRI value is associated with its own Signature Group. 471 Signature Blocks for a given Signature Group have SPRI = PRI for 472 that Signature Group. In other words, the SPRI of the Signature 473 Block matches the PRI value of the syslog messages that are part 474 of the Signature Group and hence signed by the Signature Block. 475 An SG value of 1 can, for example, be used when the administrator 476 of an originator does not know where any of the syslog messages 477 will ultimately go but anticipates that messages with different 478 PRI values will be collected and processed separately. Having a 479 Signature Group per PRI value provides administrators with a 480 large degree of flexibility with regard to how to divide up the 481 processing of syslog messages and their signatures after they are 482 received, at the same time allowing Signature Blocks to follow 483 the corresponding syslog messages to their eventual destination. 485 c. "2" -- Each Signature Group contains a range of PRI values. 486 Signature Groups are assigned sequentially. A Signature Block 487 for a given Signature Group has its own SPRI value denoting the 488 highest PRI value of syslog messages in that Signature Group. 489 The lowest PRI value of syslog messages in that Signature Group 490 will be one larger than the SPRI value of the previous Signature 491 Group or "0" in case there is no other Signature Group with a 492 lower SPRI value. The specific Signature Groups and ranges they 493 are associated with are subject to configuration by a system 494 administrator. 496 d. "3" -- Signature Groups are not assigned with any of the above 497 relationships to PRI values of the syslog messages they sign. 498 Instead, another scheme is used, which is outside the scope of 499 this specification. There has to be some predefined arrangement 500 between the originator and the intended collectors as to which 501 syslog messages are to be included in which Signature Group, 502 requiring configuration by a system administrator. This provides 503 administrators also with the flexibility to group syslog messages 504 into Signature Groups according to criteria that are not tied to 505 the PRI value. 507 One reasonable way to configure some installations is to have only 508 one Signature Group, indicated with SG=0, and have the originator 509 send a copy of each Signature Block to each collector. In that case, 510 collectors that are not configured to receive every syslog message 511 will still receive signatures for every message, even ones they are 512 not supposed to receive. While the collector will not be able to 513 detect gaps in the messages (because the presence of a signature of a 514 message that is missing does not tell the collector whether or not 515 the corresponding message would be of the collector's concern), it 516 does allow all messages that do arrive at each collector to be put 517 into the right order and to be verified. It also allows each 518 collector to detect duplicates. Likewise, configuring only one 519 Signature Group can be a reasonable way to configure installations 520 that involve relay chains, where one or more interim relays may or 521 may not relay all messages to the same destination. 523 4.2.4. Global Block Counter 525 The Global Block Counter is a decimal value representing the number 526 of Signature Blocks sent by syslog-sign before the current one, in 527 this reboot session. This takes at least 1 octet and at most 10 528 octets displayed as a decimal counter. The acceptable values for 529 this are between 0 and 9999999999, starting with 0. Leading zeroes 530 MUST be omitted. If the value of the Global Block Counter has 531 reached 9999999999 and the Reboot Session ID has a value other than 0 532 (indicating the fact that persistence of the Reboot Session ID is 533 supported), then the Reboot Session ID MUST be incremented by 1 and 534 the Global Block Counter resumes at 0. When the Reboot Session ID is 535 0 (i.e., persistent Reboot Session IDs are not supported) and the 536 Global Block Counter reaches its maximum value, then the Global Block 537 Counter is reset to 0 and the Reboot Session ID MUST remain at 0. 539 Note that the Global Block Counter crosses Signature Groups; it 540 allows one to roughly synchronize when two messages were sent, even 541 though they went to different collectors and are part of different 542 Signature Groups. 544 Because a reboot results in the start of a new reboot session, the 545 originator MUST reset the Global Block Counter to 0 after a reboot 546 occurs. Applications need to take into account the possibility that 547 a reboot occurred when authenticating a log, and situations in which 548 reboots occur frequently may result in losing the ability to verify 549 the proper sequence in which messages were sent, hence jeopardizing 550 the integrity of the log. 552 4.2.5. First Message Number 554 This is a decimal value between 1 and 10 octets, with leading zeroes 555 omitted. It contains the unique message number within this Signature 556 Group of the first message whose hash appears in this block. The 557 very first message of the reboot session is numbered "1". This 558 implies that when the Reboot Session ID increases, the message number 559 is reset to 1. 561 For example, if this Signature Group has processed 1000 messages so 562 far and message number 1001 is the first message whose hash appears 563 in this Signature Block, then this field contains 1001. The message 564 number is relative to the Signature Group to which it belongs; hence, 565 a message number does not identify a message beyond its Signature 566 Group. 568 Should the message number reach 9999999999 within the same reboot 569 session and Signature Group, the message number subsequently restarts 570 at 1. In such event, the Global Block Counter will be vastly 571 different between two occurrences of the same message number. 573 4.2.6. Count 575 The count is a 1 or 2 octet field that indicates the number of 576 message hashes to follow. The valid values for this field are 1 577 through 99. The number of hashes included in the Signature Block 578 MUST be chosen such that the length of the resulting syslog message 579 does not exceed the maximum permissible syslog message length. 581 4.2.7. Hash Block 583 The hash block is a block of hashes, each separately encoded in base 584 64. Each hash in the hash block is the hash of the entire syslog 585 message represented by the hash, independent of the underlying 586 transport. Hashes are ordered from left to right in the order of 587 occurrence of the syslog messages that they represent. The space 588 character is used to separate the hashes. Note, the hash block 589 constitutes a single SD-Param; a Signature Block message MUST include 590 all its hashes in a single hash block and MUST NOT spread its hashes 591 across several hash blocks. 593 The "entire syslog message" refers to what is described as the syslog 594 message excluding transport parts that are described in [RFC5425] and 595 [RFC5426], and excluding other parts that may be defined in future 596 transports. The hash value will be the result of the hashing 597 algorithm run across the syslog message, starting with the "<" of the 598 PRI portion of the header part of the message. The hash algorithm 599 used and indicated by the Version field determines the size of each 600 hash, but the size MUST NOT be shorter than 160 bits without the use 601 of padding. It is base 64 encoded as per [RFC4648]. 603 The number of hashes in a hash block SHOULD be chosen such that the 604 resulting Signature Block message does not exceed a length of 2048 605 octets in order to avoid the possibility that truncation occurs. 606 When more hashes need to be sent than fit inside a Signature Block 607 message, it is advisable to start a new Signature Block. 609 4.2.8. Signature 611 This is a digital signature, encoded in base 64 per [RFC4648]. The 612 signature is calculated over the completely formatted Signature Block 613 message (starting from the first octet of PRI and continuing to the 614 last octet of MSG, or STRUCTURED-DATA if MSG is not present), before 615 the SIGN parameter (SD Parameter Name and the space before it [" 616 SIGN"], "=", and the corresponding value) is added. For the OpenPGP 617 DSA signature scheme, the value of the signature field contains the 618 DSA values r and s, encoded as two multiprecision integers (see 619 [RFC4880], Sections 5.2.2 and 3.2), concatenated, and then encoded in 620 base 64 [RFC4648]. 622 4.2.9. Example 624 An example of a Signature Block message is depicted below, broken 625 into lines to fit internet-draft publication rules. There is a space 626 at the end of each line, with the exception of the last line which 627 ends with "]" and the second-to-last line which ends with "ld6hg". 629 <110>1 2009-05-03T14:00:39.529966+02:00 host.example.org syslogd 2138 - 630 [ssign VER="0111" RSID="1" SG="0" SPRI="0" GBC="2" FMN="1" CNT="7" 631 HB="K6wzcombEvKJ+UTMcn9bPryAeaU= zrkDcIeaDluypaPCY8WWzwHpPok= 632 zgrWOdpx16ADc7UmckyIFY53icE= XfopJ+S8/hODapiBBCgVQaLqBKg= 633 J67gKMFl/OauTC20ibbydwIlJC8= M5GziVgB6KPY3ERU1HXdSi2vtdw= 634 Wxd/lU7uG/ipEYT9xeqnsfohyH0=" 635 SIGN="AKBbX4J7QkrwuwdbV7Taujk2lvOf8gCgC62We1QYfnrNHz7FzAvdySuMyfM="] 636 The message is of syslog-sign protocol version "01". It uses SHA1 as 637 hash algorithm and an OpenPGP DSA signature scheme. Its reboot 638 session ID is 1. Its Signature Group is 0 which means that all 639 syslog messages go to the same destination; its Signature Priority 640 (which can effectively be ignored because all syslog messages will be 641 signed regardless of their PRI value) is 0. Its Global Block Counter 642 is 2. The first message number is 1; the message contains 7 message 643 hashes. 645 5. Payload and Certificate Blocks 647 Certificate Blocks and Payload Blocks provide key management for 648 syslog-sign. Their purpose is to support key management that uses 649 public key cryptosystems. 651 5.1. Preliminaries: Key Management and Distribution Issues 653 A Payload Block contains public key certificate information that is 654 to be conveyed to the collector. A Payload Block is sent at the 655 beginning of a new reboot session, carrying public key information in 656 effect for the reboot session. However, a Payload Block is not sent 657 directly, but in (one or more) fragments. Those fragments are termed 658 Certificate Blocks. Therefore, originators send at least one 659 Certificate Block at the beginning of a new reboot session. 661 There are three key points to understand about Certificate Blocks: 663 a. They handle a variable-sized payload, fragmenting it if necessary 664 and transmitting the fragments as legal syslog messages. This 665 payload is built (as described below) at the beginning of a 666 reboot session and is transmitted in pieces with each Certificate 667 Block carrying a piece. There is exactly one Payload Block per 668 reboot session. 670 b. The Certificate Blocks are digitally signed. The originator does 671 not sign the Payload Block, but the signatures on the Certificate 672 Blocks ensure its authenticity. Note that it may not even be 673 possible to verify the signature on the Certificate Blocks 674 without the information in the Payload Block; in this case the 675 Payload Block is reconstructed, the key is extracted, and then 676 the Certificate Blocks are verified. (This is necessary even 677 when the Payload Block carries a certificate, because some other 678 fields of the Payload Block are not otherwise verified.) In 679 practice, most installations keep the same public key over long 680 periods of time, so that most of the time, it is easy to verify 681 the signatures on the Certificate Blocks, and use the Payload 682 Block to provide other useful per-session information. 684 c. The kind of Payload Block that is expected is determined by what 685 kind of key material is on the collector that receives it. The 686 originator and collector (or offline log viewer) both have some 687 key material (such as a root public key or pre-distributed public 688 key) and an acceptable value for the Key Blob Type in the Payload 689 Block, below. The collector or offline log viewer MUST NOT 690 accept a Payload Block of the wrong type. 692 5.2. Payload Block 694 The Payload Block is built when a new reboot session is started. 695 There is a one-to-one correspondence between reboot sessions and 696 Payload Blocks. An originator creates a new Payload Block after each 697 reboot. The Payload Block is used until the next reboot. 699 5.2.1. Block Format and Fields 701 A Payload Block MUST have the following fields: 703 a. Full local time stamp for the originator at the time the reboot 704 session started. This must be in the time stamp format specified 705 in [RFC5424] (essentially, time stamp format per [RFC3339] with 706 some further restrictions). 708 b. Key Blob Type, a one-octet field containing one of five values: 710 1. 'C' -- a PKIX certificate. 712 2. 'P' -- an OpenPGP certificate (a Transferable Public Key as 713 defined in [RFC4880], Section 11.1). 715 3. 'K' -- the public key whose corresponding private key is 716 being used to sign these messages. For the OpenPGP DSA 717 signature scheme, this field contains the DSA prime p, DSA 718 group order q, DSA group generator g, and DSA public-key 719 value y, encoded as four multiprecision integers (see 720 [RFC4880], Sections 5.5.2 and 3.2). 722 4. 'N' -- no key information sent; key is pre-distributed. 724 5. 'U' -- installation-specific key exchange information 726 c. The key blob, if any, base 64 encoded per [RFC4648] and 727 consisting of the raw key data. 729 The fields are separated by single space characters. Because a 730 Payload Block is not carried in a syslog message directly, only the 731 corresponding Certificate Blocks, it does not need to be encoded as 732 an SD ELEMENT. The Payload Block does not contain a field that 733 identifies the reboot session; instead, the reboot session can be 734 inferred from the Reboot Session ID parameter of the Certificate 735 Blocks that are used to carry the Payload Block. 737 When a PKIX certificate is used ("C" key blob type), it is the 738 certificate specified in ([RFC5280]). Per [RFC5425], syslog messages 739 may be transported over the TLS protocol, even where there is no PKI. 741 If that transport is used, then the device will already have a PKIX 742 certificate and it MAY use the private key associated with that 743 certificate to sign messages. In the case where there is no PKI, the 744 chain of trust of a PKIX certificate must still be established to 745 meet conventional security requirements. The methods for doing this 746 are described in [RFC5425]. 748 5.2.2. Originator Authentication and Authorization 750 When the collector receives a Payload Block, it needs to determine 751 whether the signatures are to be trusted. The following methods are 752 in scope of this specification: 754 a. X.509 certification path validation: The collector is configured 755 with one or more trust anchors (typically root CA certificates), 756 which allow it to verify a binding between the subject name and 757 the public key. Certification path validation is performed as 758 specified in [RFC5280]. 760 If the HOSTNAME contains an FQDN or an IP address, it is then 761 compared against the certificate as described in [RFC5425], 762 Section 5.2. Comparing other forms of HOSTNAMEs is beyond the 763 scope of this specification. 765 Collectors SHOULD support this method. 767 Note that due to message size restrictions, syslog-sign sends 768 only the end-entity certificate in the Payload Block. Depending 769 on the PKI deployment, the collector may need to obtain 770 intermediate certificates by other means (for example, from a 771 directory). 773 b. X.509 end-entity certificate matching: The collector is 774 configured with information necessary to identify the valid end- 775 entity certificates of its valid peers, and for each peer, the 776 HOSTNAME(s) it is authorized to use. 778 To ensure interoperability, implementations MUST support 779 fingerprints of X.509 certificates as described below. Other 780 methods MAY be supported. 782 Collectors MUST support key blob type 'C', and specifying the 783 list of valid peers using certificate fingerprints. The 784 fingerprint is calculated and formatted as specified in 785 [RFC5425], Section 4.2.2. 787 For each peer, the collector MUST support specifying a list of 788 HOSTNAME(s) this peer is allowed to use either as FQDNs or IP 789 addresses. Other forms of HOSTNAMEs are beyond the scope of this 790 specification. 792 If the locally configured FQDN is an internationalized domain 793 name, conforming implementations MUST convert it to the ASCII 794 Compatible Encoding (ACE) format for performing comparisons as 795 specified in Section 7 of [RFC5280]. An exact case-insensitive 796 string match MUST be supported, but the implementation MAY also 797 support wildcards of any type ("*", regular expressions, etc.) in 798 locally configured names. 800 Originator implementations MUST provide a means to generate a key 801 pair and self-signed certificate in the case that a key pair and 802 certificate are not available through another mechanism, and MUST 803 make the certificate fingerprint available through a management 804 interface. 806 c. OpenPGP V4 fingerprints: Like X.509 fingerprints, except key blob 807 type 'P' is used, and the fingerprint is calculated as specified 808 in [RFC4880], Section 12.2. When the fingerprint value is 809 display or configured, each byte is represented in hexadecimal 810 (using two uppercase ASCII characters), and space is added after 811 every second byte. For example: "0830 2A52 2CD1 D712 6E76 6EEC 812 32A5 CAE1 03C8 4F6E". 814 Originators and collectors MAY support this method. 816 Other methods, such as "web of trust", are beyond the scope of this 817 document. 819 5.3. Certificate Block 821 This section describes the format of the Certificate Block and the 822 fields used within the Certificate Block, as well as the syslog 823 messages used to carry Certificate Blocks. 825 5.3.1. syslog Messages Containing a Certificate Block 827 Certificate Blocks are used to get the Payload Block to the 828 collector. As with a Signature Block, each Certificate Block is 829 carried in its own syslog message, called Certificate Block message. 831 Because certificates can legitimately be much longer than 2048 832 octets, the Payload Block can be split up into several pieces, with 833 each Certificate Block carrying a piece of the Payload Block. Note 834 that the originator MAY make the Certificate Blocks of any legal 835 length (that is, any length that keeps the entire Certificate Block 836 message within 2048 octets) that holds all the required fields. 838 Software that processes Certificate Blocks MUST deal correctly with 839 blocks of any legal length. The length of the fragment of the 840 Payload Block that a Certificate Block carries MUST be at least 1 841 octet. The length SHOULD be chosen such that the length of the 842 Certificate Block message does not exceed 2048 octets. 844 A Certificate Block message is identified by the presence of an SD 845 ELEMENT with an SD-ID with the value "ssign-cert". In addition, a 846 Certificate Block message MUST contain valid APP-NAME, PROCID, and 847 MSGID fields to be compliant with syslog protocol. Syslog-sign does 848 not mandate particular values for these fields; however, for 849 consistency, an originator MUST use the same value for APP-NAME, 850 PROCID, and MSGID fields for every Certificate Block message, 851 whichever values are chosen. It MUST also use the same value for its 852 HOSTNAME field. To allow for the possibility of multiple originators 853 per host, the combination of APP-NAME and PROCID MUST be unique for 854 each such originator. If an originator daemon is restarted, it MAY 855 use a new PROCID for what is otherwise the same originator. The 856 combination of APP-NAME and PROCID MUST be the same that is used for 857 Signature Block messages of the same originator; however, a different 858 MSGID MAY be used for Signature Block and Certificate Block messages. 859 It is RECOMMENDED to use 110 as value for the PRI field, 860 corresponding to facility 13 and severity 6 (informational). The 861 Certificate Block is carried as Structured Data within the 862 Certificate Block message. It is also RECOMMENDED (but not required) 863 that a Certificate Block message carry no other Structured Data 864 besides the Structured Data of the Certificate Block itself. The MSG 865 part of a Certificate Block message SHOULD be empty. 867 5.3.2. Certificate Block Format and Fields 869 The contents of a Certificate Block message is the Certificate Block 870 itself. Like a Signature Block, the Certificate Block is encoded as 871 an SD ELEMENT. The SD-ID of the Certificate Block is "ssign-cert". 872 The Certificate Block is composed of the following fields, each of 873 which is encoded as an SD Parameter with parameter name as indicated. 874 Each field must be printable ASCII, and any binary values are base 64 875 encoded per [RFC4648]. 877 Field SD-PARAM-NAME Size in octets 878 ----- ------------- ---- -- ------ 880 Version VER 4 882 Reboot Session ID RSID 1-10 884 Signature Group SG 1 886 Signature Priority SPRI 1-3 888 Total Payload Block Length TPBL 1-8 890 Index into Payload Block INDEX 1-8 892 Fragment Length FLEN 1-4 894 Payload Block Fragment FRAG variable 895 (base 64 encoded binary) 897 Signature SIGN variable 898 (base 64 encoded binary) 900 The fields MUST be provided in the order listed. New SD parameters 901 MUST NOT be added unless a new Version of the protocol is defined. 902 (Implementations that wish to add proprietary extensions will need to 903 define a separate SD ELEMENT.) A Certificate Block is accordingly 904 encoded as follows, where xxx denotes a placeholder for the 905 particular values: 907 [ssign-cert VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" TPBL="xxx" 908 INDEX="xxx" FLEN="xxx" FRAG="xxx" SIGN="xxx"] 910 Values of the fields constitute SD parameter values and are hence 911 enclosed in quotes, per [RFC5424]. The fields are separated by 912 single spaces and are described below. Each SD parameter MUST occur 913 once and only once. 915 5.3.2.1. Version 917 The Version field is 4 octets in length. This field is identical in 918 format and meaning to the Version field described in Section 4.2.1. 920 5.3.2.2. Reboot Session ID 922 The Reboot Session ID is identical in format and meaning to the RSID 923 field described in Section 4.2.2. 925 5.3.2.3. Signature Group and Signature Priority 927 The SIG field is identical in format and meaning to the SIG field 928 described in Section 4.2.3. The SPRI field is identical in format 929 and meaning to the SPRI field described there. 931 5.3.2.4. Total Payload Block Length 933 The Total Payload Block Length is a value representing the total 934 length of the Payload Block in octets, expressed as a decimal with 935 one to eight octets with leading zeroes omitted. 937 5.3.2.5. Index into Payload Block 939 This is a decimal value between 1 and 8 octets, with leading zeroes 940 omitted. It contains the number of octets into the Payload Block at 941 which this fragment starts. The first octet of the first fragment is 942 numbered "1". (Note, it is not numbered "0".) 944 5.3.2.6. Fragment Length 946 The total length of this fragment expressed as a decimal integer with 947 one to four octets with leading zeroes omitted. The fragment length 948 must be at least 1. 950 5.3.2.7. Payload Block Fragment 952 The Payload Block Fragment contains a fragment of the payload block. 953 Its length must match the indicated fragment length. 955 5.3.2.8. Signature 957 This is a digital signature, encoded in base 64, as per [RFC4648]. 958 The Version field effectively specifies the original encoding of the 959 signature. The signature is calculated over the completely formatted 960 Certificate Block message, before the SIGN parameter is added (see 961 Section 4.2.8). For the OpenPGP DSA signature scheme, the value of 962 the signature field contains the DSA values r and s, encoded as two 963 multiprecision integers (see [RFC4880], Sections 5.2.2 and 3.2), 964 concatenated, and then encoded in base 64 [RFC4648]. 966 5.3.2.9. Example 968 An example of a Certificate Block message is is depicted below, 969 broken into lines to fit internet-draft publication rules. There are 970 no spaces at the end of the lines that contain the key blob and the 971 signature. 973 <110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd 2138 - 974 [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587" INDEX="1" 975 FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZNCV2NUAwe4RA 976 eAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1zcXADe03u5pmHoW 977 y5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQrAAenBweVMlBgV3ZA 978 5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9mN8n821BTTuQnz5hp40 979 d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry5X6482fUxbm+gOHVmYSD 980 tBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTMgDXyC+bSBMjRRCaeWhHrYY 981 dYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgCssS9E1qARM+h19KovIUOhl4V 982 zBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZFRC1B82Sub152zOqIcAWsgd4myC 983 CiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg==" 984 SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="] 986 The message is of syslog-sign protocol version "01". It uses SHA1 as 987 hash algorithm and an OpenPGP DSA signature scheme. Its reboot 988 session ID is 1. Its Signature Group is 0; its Signature Priority is 989 0. The Total Payload Block Length is 587. The index into the 990 payload block is 1 (meaning this is the first fragment). The length 991 of the fragment is 587 (meaning that the Certificate Block message 992 contains the entire Payload Block). The Payload Block has the time 993 stamp 2009-05-03T14:00:39.519005+02:00. The Key Blob Type is 'K', 994 meaning that it contains a public key whose corresponding private key 995 is being used to sign these messages. 997 Note that the Certificate Block message in this example has the same 998 time stamp as the Payload Block. This implies that this is the first 999 Certificate Block message sent in this reboot session; additional 1000 Certificate Block messages can be sent later with a later time stamp, 1001 which will carry the same Payload Block that will still contain the 1002 same time stamp. 1004 6. Redundancy and Flexibility 1006 As described in Section 8.5 of [RFC5424], a transport sender may 1007 discard syslog messages. Likewise, when syslog messages are sent 1008 over unreliable transport, they can be lost in transit. However, if 1009 a collector does not receive Signature and Certificate Blocks, many 1010 messages may not be able to be verified. The originator is allowed 1011 to send Signature and Certificate Blocks multiple times. Sending 1012 Signature and Certificate Blocks multiple times provides redundancy 1013 with the intent to ensure that the collector or relay does get the 1014 Signature Blocks and in particular the Payload Block at some point in 1015 time. In the meantime, any online review of logs as described in 1016 Section 7.2 is delayed until the needed blocks are received. The 1017 collector MUST ignore Signature Blocks and Certificate Blocks it has 1018 already received and authenticated. The originator can in principle 1019 change its redundancy level for any reason, without communicating 1020 this fact to the collector. 1022 The originator does not need to queue up other messages while sending 1023 redundant Certificate Block and Signature Block messages. It MAY 1024 send redundant Certificate Block messages even after Signature Block 1025 messages and regular syslog messages have been sent. By the same 1026 token, it MAY send redundant Signature Block messages even after 1027 newer syslog messages that are signed by a subsequent Signature Block 1028 have been sent, or even after a subsequent Signature Block message. 1030 In addition, the originator has flexibility in how many hashes to 1031 include within a Signature Block. It is legitimate for an originator 1032 to send short Signature Blocks to allow the collector to verify 1033 messages with minimal delay. 1035 6.1. Configuration parameters 1037 Although the transport sender is not constrained in how it decides to 1038 send redundant Signature and Certificate Blocks, or even in whether 1039 it decides to send along multiple copies of normal syslog messages, 1040 we define some redundancy parameters below which may be useful in 1041 controlling redundant transmission from the transport sender to the 1042 transport receiver, and which may be useful for administrators to 1043 configure. 1045 6.1.1. Configuration Parameters for Certificate Blocks 1047 Certificate Blocks are always sent at the beginning of a new reboot 1048 session. One technique to ensure reliable delivery (see Section 8.5) 1049 is to send multiple copies. This can be controlled by a 1050 "certInitialRepeat" parameter: 1052 certInitialRepeat = number of times each Certificate Block should 1053 be sent before the first message is sent. 1055 It is also useful to resend Certificate Blocks every now and then for 1056 long-lived reboot sessions. This can be controlled by the 1057 certResendDelay and certResendCount parameters: 1059 certResendDelay = maximum time delay in seconds until resending 1060 the Certificate Block. 1062 certResendCount = maximum number of other syslog messages to send 1063 until resending the Certificate Block. 1065 In some cases, it may be desirable to allow for configuration of the 1066 transport sender such that Certificate Blocks are not sent at all 1067 after the first normal syslog message has been sent. This could be 1068 expressed by setting both certResendDelay and certResendCount to "0". 1069 However, it is RECOMMENDED to configure the transport sender to send 1070 redundant Certificate Blocks even after the first message is sent 1071 when the UDP transport [RFC5426] is used. 1073 6.1.2. Configuration Parameters for Signature Blocks 1075 Verification of log messages involves a certain delay of time that is 1076 caused by the lag in time between the sending of the message itself 1077 and the corresponding Signature Block. The following configuration 1078 parameter can be useful to limit the time lag that will be incurred 1079 (note that the maximum message length may also force generating a 1080 Signature Block; see Sections Section 4.2.6 and Section 4.2.7): 1082 sigMaxDelay = generate a new Signature Block if this many seconds 1083 have elapsed since the message with the First Message Number of 1084 the Signature Block was sent. 1086 Retransmissions of Signature Blocks are not sent immediately after 1087 the original transmission, but slightly later. The following 1088 parameters control when those retransmissions are done: 1090 sigNumberResends = number of times a Signature Block is resent. 1091 (It is recommended so select a value of greater than "0" in 1092 particular when the UDP transport [RFC5426] is used.) 1094 sigResendDelay = send the next retransmission when this many 1095 seconds have elapsed since the previous sending of this Signature 1096 Block. 1098 sigResendCount = send the next retransmission when this many other 1099 syslog messages have been sent since the previous sending of this 1100 Signature Block. 1102 6.2. Overlapping Signature Blocks 1104 Notwithstanding the fact that the originator is not constrained in 1105 whether it decides to send redundant Signature Block messages, 1106 Signature Blocks SHOULD NOT overlap. This facilitates their 1107 processing by the receiving collector. This means that an originator 1108 of Signature Block messages, after having sent a first message with 1109 some First Message Number and a Count, SHOULD NOT send a second 1110 message with the same First Message Number but a different Count. It 1111 also means that an originator of Signature Block messages SHOULD NOT 1112 send a second message whose First Message Number is greater than the 1113 First Message Number, but smaller than the First Message Number plus 1114 the Count indicated in the first message. 1116 That said, the possibility of Signature Blocks that overlap does 1117 provide additional flexibility with regards to redundancy; it 1118 provides an additional option that may be desirable in some 1119 deployments. Therefore collectors MUST be designed in a way that 1120 they can cope with overlapping Signature Blocks when confronted with 1121 them. The collector MUST ignore hashes of messages that it has 1122 already received and validated. 1124 7. Efficient Verification of Logs 1126 The logs secured with syslog-sign may be reviewed either online or 1127 offline. Online review is somewhat more complicated and 1128 computationally expensive, but not prohibitively so. 1130 7.1. Offline Review of Logs 1132 When the collector stores logs to be reviewed later, they can be 1133 authenticated offline just before they are reviewed. Reviewing these 1134 logs offline is simple and relatively inexpensive in terms of 1135 resources used, so long as there is enough space available on the 1136 reviewing machine. Here, we presume that the stored log files 1137 containing Certificate Block and Signature Block messages have 1138 already been separated by originator (as identified by HOSTNAME, APP- 1139 NAME, PROCID), Reboot Session ID, and Signature Group. This can be 1140 done easily with a script file. We then do the following: 1142 a. First, we go through the raw log file and split its contents into 1143 three files. Each message in the raw log file is classified as a 1144 normal message, a Signature Block message, or a Certificate Block 1145 message. Signature Blocks and Certificate Blocks are then stored 1146 in their own files. Normal messages are stored in a keyed file, 1147 indexed on their hash values. 1149 b. We sort the Certificate Block file by INDEX value, and check to 1150 see whether we have a set of Certificate Blocks that can 1151 reconstruct the Payload Block. If so, we reconstruct the Payload 1152 Block, verify any key-identifying information, and then use this 1153 to verify the signatures on the Certificate Blocks we have 1154 received. When this is done, we have verified the reboot session 1155 and key used for the rest of the process. 1157 c. We sort the Signature Block file by First Message Number. We now 1158 create an authenticated log file, which consists of some header 1159 information and then a sequence of message number, message text 1160 pairs. We next go through the Signature Block file. We 1161 initialize a cursor for the last message number processed with 1162 the number 0. For each Signature Block in the file, we do the 1163 following: 1165 1. Verify the signature on the Signature Block. 1167 2. If the value of the First Message Number of the Signature 1168 Block is less than or equal to the last message number 1169 processed, skip the first (last message number processed 1170 minus First Message Number plus 1) hashes. 1172 3. For each remaining hashed message in the Signature Block: 1174 a. Look up the hash value in the keyed message file. 1176 b. If the message is found, write (message number, message 1177 text) to the authenticated log file. 1179 4. Set the last message number processed to the value of the 1180 First Message Number plus the Count of the Signature Block 1181 minus 1. 1183 5. Skip all other Signature Blocks with the same First Message 1184 Number unless one with a larger Count is encountered. 1186 The resulting authenticated log file contains all messages that 1187 have been authenticated. In addition, it implicitly indicates 1188 all gaps in the authenticated messages (specifically in the case 1189 when all messages of the same Signature Group are sent to the 1190 same collector), because their message numbers are missing. 1192 One can see that, assuming sufficient space for building the keyed 1193 file, this whole process is linear in the number of messages 1194 (generally two seeks, one to write and the other to read, per normal 1195 message received), and O(N lg N) in the number of Signature Blocks. 1196 This estimate comes with two caveats: first, the Signature Blocks 1197 arrive very nearly in sorted order, and so can probably be sorted 1198 more cheaply on average than O(N lg N) steps. Second, the signature 1199 verification on each Signature Block almost certainly is more 1200 expensive than the sorting step in practice. We have not discussed 1201 error-recovery, which may be necessary for the Certificate Blocks. 1202 In practice, a simple error-recovery strategy is probably enough: if 1203 the Payload Block is not valid, then we can just try alternate 1204 instances of each Certificate Block, if such are available, until we 1205 get the Payload Block right. 1207 It is easy for an attacker to flood us with plausible-looking 1208 messages, Signature Blocks, and Certificate Blocks. 1210 7.2. Online Review of Logs 1212 Some collector implementations may need to monitor log messages in 1213 close to real-time. This can be done with syslog-sign, though it is 1214 somewhat more complex than offline verification. This is done as 1215 follows: 1217 a. We have an authenticated message file, into which we write 1218 (message number, message text) pairs which have been 1219 authenticated. Again, we will assume that we are handling only 1220 one originator, Signature Group, and Reboot Session ID at any 1221 given time. 1223 b. We have three data structures: A queue in which (message number, 1224 hash of message) pairs are kept in sorted order, a queue in which 1225 (arrival sequence, hash of message) pairs are kept in sorted 1226 order, and a hash table that stores (message text, count) pairs 1227 indexed by hash value. In the hash table, count may be any 1228 number greater than zero; when count is zero, the entry in the 1229 hash table is cleared. 1231 c. We must receive all the Certificate Blocks before any other 1232 processing can really be done. (This is why they are sent 1233 first.) Once that is done, any additional Certificate Block 1234 message that arrives is discarded. Any syslog messages or 1235 Signature Block messages that arrive before all Certificate 1236 Blocks have been received need to be buffered. Once all 1237 Certificate Blocks have been received, the messages in the buffer 1238 can be retrieved and processed as if they were just arriving. 1240 d. Whenever a normal message arrives, we add (arrival sequence, hash 1241 of message) to our message queue. If our hash table has an entry 1242 for the message's hash value, we increment its count by one; 1243 otherwise, we create a new entry with count = 1. If the message 1244 queue is full, we roll the oldest messages off the queue by 1245 taking the oldest entry in the queue, and using it to index the 1246 hash table. If that entry has count 1, we delete the entry from 1247 the hash table; otherwise, we decrement its count. We then 1248 delete the oldest entry in the queue. 1250 e. Whenever a Signature Block message arrives, we check its 1251 originator (by way of HOSTNAME, APP-NAME, PROCID), Signature 1252 Group, and Reboot Session ID to ensure it matches our Certificate 1253 Blocks. We then check to see whether the First Message Number 1254 value is too old to still be of interest, or if another Signature 1255 Block with that First Message Number and the same Count or a 1256 greater Count has already been received. If so, we discard the 1257 Signature Block. Otherwise, we check its signature and discard 1258 it if the signature is not valid. A Signature Block contains a 1259 sequence hashes, each of which is associated with a message 1260 number, starting with the First Message Number for the first hash 1261 and incrementing by one for each subsequent hash. For each hash, 1262 we first check to see whether the message hash is in the hash 1263 table. If this is the case, we do the following: 1265 A. We check if a message with the same message number is already 1266 in the authenticated message queue. 1268 B. If that is not the case, we write the (message number, 1269 message text) into the authenticated message queue, otherwise 1270 the signed hash is a duplicate and we discard it. 1272 Otherwise (the message hash is not in the hash table), we write 1273 the (message number, message hash) to the message number queue. 1274 This generally involves rolling the oldest entry out of this 1275 queue: before this is done, that entry's hash value is again 1276 looked up in the hash table. If a matching entry is found, a 1277 check is made if the authenticated message file already contains 1278 an entry with the same message number and if that is not the 1279 case, the (message number, message text) pair is written to the 1280 authenticated message. In either case, the oldest entry is then 1281 discarded. 1283 f. The result of this is a sequence of messages in the authenticated 1284 message file, each of which has been authenticated, and which are 1285 labeled with numbers showing their order of original 1286 transmission. 1288 One can see that this whole process is roughly linear in the number 1289 of messages, and also in the number of Signature Blocks received. 1290 The process is susceptible to flooding attacks; an attacker can send 1291 enough normal messages that the messages roll off their queue before 1292 their Signature Blocks can be processed. 1294 8. Security Considerations 1296 Normal syslog event messages are unsigned and have most of the 1297 security attributes described in Section 8 of [RFC5424]. This 1298 document also describes Certificate Blocks and Signature Blocks, 1299 which are signed syslog messages. The Signature Blocks contain 1300 signature information for previously sent syslog event messages. All 1301 of this information can be used to authenticate syslog messages and 1302 to minimize or obviate many of the security concerns described in 1303 [RFC5424]. 1305 The model for syslog-sign is a direct trust system where the 1306 certificate transferred is its own trust anchor. If a transport 1307 sender sends a stream of syslog messages that is signed using a 1308 certificate, the operator or application will transfer to the 1309 transport receiver the certificate that was used when signing. There 1310 is no need for a certificate chain. 1312 8.1. Cryptographic Constraints 1314 As with any technology involving cryptography, it is advisable to 1315 check the current literature to determine whether any algorithms used 1316 here have been found to be vulnerable to attack. 1318 This specification uses Public Key Cryptography technologies. The 1319 proper party or parties have to control the private key portion of a 1320 public-private key pair. Any party that controls a private key can 1321 sign anything it pleases. 1323 Certain operations in this specification involve the use of random 1324 numbers. An appropriate entropy source SHOULD be used to generate 1325 these numbers. See [RFC4086] and [NIST800.90]. 1327 8.2. Packet Parameters 1329 As an originator, it is advisable to avoid message lengths exceeding 1330 2048 octets. Various problems might result if an originator were to 1331 send messages with a length greater than 2048 octets, because relays 1332 MAY truncate messages with lengths greater than 2048 octets which 1333 would make it impossible for collectors to validate a hash of the 1334 packet. To increase the chance of interoperability, it tends to be 1335 best to be conservative with what you send but liberal in what you 1336 are able to receive. 1338 Originators need to rigidly enforce the correctness of message 1339 bodies. Problems may arise if the collector does not fully accept 1340 the syslog packets sent from an originator, or if it has problems 1341 with the format of the Certificate Block or Signature Block messages. 1343 Collectors are not to malfunction in case they receive malformed 1344 syslog messages or messages containing characters other than those 1345 specified in this document. In other words, they are to ignore such 1346 messages and continue working. 1348 8.3. Message Authenticity 1350 Syslog does not strongly associate the message with the message 1351 originator. That association is established by the collector upon 1352 verification of the Signature Block. Before a Signature Block is 1353 used to ascertain the authenticity of an event message, it might be 1354 received, stored, and reviewed by a person or automated parser. It 1355 is advisable not to assume a message is authentic until after a 1356 message has been validated by checking the contents of the Signature 1357 Block. 1359 With the Signature Block checking, an attacker may only forge 1360 messages if he or she can compromise the private key of the true 1361 originator. 1363 8.4. Replaying 1365 Event messages might be recorded and replayed by an attacker. Using 1366 the information contained in the Signature Blocks, a reviewer can 1367 determine whether the received messages are the ones originally sent 1368 by an originator. The reviewer can also identify messages that have 1369 been replayed. 1371 8.5. Reliable Delivery 1373 Event messages sent over UDP might be lost in transit. [RFC5425] can 1374 be used for the reliable delivery of syslog messages; however, it 1375 does not protect against loss of syslog messages at the application 1376 layer, for example if the TCP connection or TLS session has been 1377 closed by the transport receiver for some reason. A reviewer can 1378 pinpoint any messages sent by the originator but not received by the 1379 collector by reviewing the Signature Block information. In addition, 1380 the information in subsequent Signature Blocks allows a reviewer to 1381 determine whether any Signature Block messages were lost in transit. 1383 8.6. Sequenced Delivery 1385 Syslog messages delivered over UDP might not only be lost, but also 1386 arrive out of sequence. A reviewer can determine the original order 1387 of syslog messages and identify which messages were delivered out of 1388 order by examining the information in the Signature Block along with 1389 any timestamp information in the message. 1391 8.7. Message Integrity 1393 Syslog messages might be damaged in transit. A review of the 1394 information in the Signature Block determines whether the received 1395 message was the intended message sent by the originator. A damaged 1396 Signature Block or Certificate Block is evident because the collector 1397 will not be able to validate that it was signed by the originator. 1399 8.8. Message Observation 1401 Unless TLS is used as a secure transport [RFC5425], event messages, 1402 Certificate Blocks, and Signature Blocks are all sent in plaintext. 1403 This allows network administrators to read the message when sniffing 1404 the wire. However, this also allows an attacker to see the contents 1405 of event messages and perhaps to use that information for malicious 1406 purposes. 1408 8.9. Man In The Middle Attacks 1410 It is conceivable that an attacker might intercept Certificate Block 1411 messages and insert its own Certificate information. In that case, 1412 the attacker would be able to receive event messages from the actual 1413 originator and then relay modified messages, insert new messages, or 1414 delete messages. It would then be able to construct a Signature 1415 Block and sign it with its own private key. Network administrators 1416 need to verify that the key contained in the Payload Block is indeed 1417 the key being used on the actual originator. If that is the case, 1418 then this MITM attack will not succeed. Methods for establishing a 1419 chain of trust are also described in [RFC5425]. 1421 8.10. Denial of Service 1423 An attacker might send invalid Signature Block messages to overwhelm 1424 the collector's processing capability and consume all available 1425 resources. For this reason, it can be appropriate to simply receive 1426 the Signature Block messages and process them only as time permits. 1428 An attacker might also just overwhelm a collector by sending more 1429 messages to it than it can handle. Implementers are advised to 1430 consider features that minimize this threat, such as only accepting 1431 syslog messages from known IP addresses. 1433 8.11. Covert Channels 1435 Nothing in this protocol attempts to eliminate covert channels. In 1436 fact, just about every aspect of syslog messages lends itself to the 1437 conveyance of covert signals. For example, a collusionist could send 1438 odd and even PRI values to indicate Morse Code dashes and dots. 1440 9. IANA Considerations 1442 9.1. Structured Data and syslog messages 1444 With regard to [RFC5424], IANA is requested to add the following 1445 values to the registry entitled "syslog Structured Data id values": 1447 SD-ID PARAM_NAME 1448 ----- ---------- 1449 ssign 1450 VER 1451 RSID 1452 SG 1453 SPRI 1454 GBC 1455 FMN 1456 CNT 1457 HB 1458 SIGN 1460 ssign-cert 1461 VER 1462 RSID 1463 SG 1464 SPRI 1465 TPBL 1466 INDEX 1467 FLEN 1468 FRAG 1469 SIGN 1471 In addition, several fields need to be controlled by the IANA in both 1472 the Signature Block and the Certificate Block, as outlined in the 1473 following sections. 1475 9.2. Version Field 1477 IANA is requested to create three registries, each associated with a 1478 different subfield of the Version field of Signature Blocks and 1479 Certificate Blocks, described in Section 4.2.1 and Section 5.3.2.1, 1480 respectively. 1482 The first registry that IANA is requested to create is entitled 1483 "syslog-sign protocol version values". It is for the values of the 1484 Protocol Version subfield. The Protocol Version subfield constitutes 1485 the first 2 octets in the Version field. New values shall be 1486 assigned by the IANA using the "IETF Review" policy defined in 1487 [RFC5226]. Assigned numbers are to be increased by 1, up to a 1488 maximum value of "50". Protocol Version numbers of "51" through "99" 1489 are vendor-specific; values in this range are not to be assigned by 1490 the IANA. 1492 IANA is requested to register the Protocol Version values shown 1493 below. 1495 VALUE PROTOCOL VERSION 1496 ----- ---------------- 1497 00 Reserved 1498 01 Defined in RFC yyyy 1500 The second registry that IANA is requested to create is entitled 1501 "syslog-sign hash algorithm values". It is for the values of the 1502 Hash Algorithm subfield. The Hash Algorithm subfield constitutes the 1503 third octet in the Version field Signature Blocks and Certificate 1504 Blocks. New values shall be assigned by the IANA using the "IETF 1505 Consensus" policy defined in [RFC5226]. Assigned values are to be 1506 increased sequentially, first up to a maximum value of "9", then from 1507 "a" to "z", then from "A" to "Z". The values are registered relative 1508 to the Protocol Version. This means that the same Hash Algorithm 1509 value can be reserved for different Protocol Versions, possibly 1510 referring to a different hash algorithm each time. This makes it 1511 possible to deal with future scenarios in which the single octet 1512 representation becomes a limitation, as more Hash Algorithms can be 1513 supported by defining additional Protocol Versions that 1514 implementations might support concurrently. 1516 IANA is requested to register the Hash Algorithm values shown below. 1518 VALUE PROTOCOL VERSION HASH ALGORITHM 1519 ----- ---------------- -------------- 1520 0 01 Reserved 1521 1 01 SHA1 1522 2 01 SHA256 1524 The third registry that IANA is requested to create is entitled 1525 "syslog-sign signature scheme values". It is for the values of the 1526 Signature Scheme subfield. The Signature Scheme subfield constitutes 1527 the fourth octet in the Version field of Signature Blocks and 1528 Certificate Blocks. New values shall be assigned by the IANA using 1529 the "IETF Consensus" policy defined in [RFC5226]. Assigned values 1530 are to be increased by 1, up to a maximum value of "9". This means 1531 that the same Signature Scheme value can be reserved for different 1532 Protocol Versions, possibly in each case referring to a different 1533 Signature Scheme each time. This makes it possible to deal with 1534 future scenarios in which the single octet representation becomes a 1535 limitation, as more Signature Schemes can be supported by defining 1536 additional Protocol Versions that implementations might support 1537 concurrently. 1539 IANA is requested to register the Signature Scheme values shown 1540 below. 1542 VALUE PROTOCOL VERSION SIGNATURE SCHEME 1543 ----- ---------------- ---------------- 1544 0 01 Reserved 1545 1 01 OpenPGP DSA 1547 9.3. SG Field 1549 IANA is requested to create a registry entitled "syslog-sign sg field 1550 values". It is for values of the SG Field as defined in 1551 Section 4.2.3. New values shall be assigned by the IANA using the 1552 "IETF Consensus" policy defined in [RFC5226]. Assigned values are to 1553 be incremented by 1, up to a maximum value of "7". Values "8" and 1554 "9" shall be left as vendor specific and shall not be assigned by the 1555 IANA. 1557 IANA is requested to register the SG Field values shown below. 1559 VALUE MEANING 1560 ----- ------- 1561 0 per RFC yyyy 1562 1 per RFC yyyy 1563 2 per RFC yyyy 1564 3 per RFC yyyy 1566 9.4. Key Blob Type 1568 IANA is requested to create a registry entitled "syslog-sign key blob 1569 type values". It is to register one-character identifiers for the 1570 key blob type, per Section 5.2. New values shall be assigned by the 1571 IANA using the "IETF Consensus" policy defined in [RFC5226]. 1572 Uppercase letters may be assigned as values. Lowercase letters are 1573 left as vendor specific and shall not be assigned by the IANA. 1575 IANA is requested to register the key blob type values shown below. 1577 VALUE KEY BLOB TYPE 1578 ----- ------------ 1579 'C' a PKIX certificate 1580 'P' an OpenPGP certificate 1581 'K' the public key whose corresponding private key is 1582 used to sign the messages 1583 'N' no key information sent, key is pre-distributed 1584 'U' installation-specific key exchange information 1586 10. Working Group 1588 The working group can be contacted via the mailing list: 1590 syslog@ietf.org 1592 The current Chairs of the Working Group can be contacted at: 1594 Chris Lonvick 1595 Cisco Systems 1596 Email: clonvick@cisco.com 1598 David Harrington 1599 Huawei Technologies (USA) 1600 Email: ietfdbh@comcast.net 1601 dharrington@huawei.com 1602 Tel: +1-603-436-8634 1604 11. Acknowledgements 1606 The authors wish to thank Alex Brown, Chris Calabrese, Steve Chang, 1607 Pasi Eronen, Carson Gaspar, Rainer Gerhards, Drew Gross, David 1608 Harrington, Chris Lonvick, Albert Mietus, Darrin New, Marshall Rose, 1609 Andrew Ross, Martin Schuette, Holt Sorenson, Rodney Thayer, and the 1610 many Counterpane Internet Security engineering and operations people 1611 who commented on various versions of this proposal. 1613 12. References 1615 12.1. Normative References 1617 [FIPS.186-2.2000] 1618 National Institute of Standards and Technology, "Digital 1619 Signature Standard", FIPS PUB 186-2, January 2000, . 1623 [FIPS.180-2.2002] 1624 National Institute of Standards and Technology, "Secure 1625 Hash Standard", FIPS PUB 180-2, August 2002, . 1628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1629 Requirement Levels", BCP 14, RFC 2119, March 1997. 1631 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1632 Encodings", RFC 4648, October 2006. 1634 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1635 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1637 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1638 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1639 May 2008. 1641 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1642 Housley, R., and W. Polk, "Internet X.509 Public Key 1643 Infrastructure Certificate and Certificate Revocation List 1644 (CRL) Profile", RFC 5280, May 2008. 1646 [RFC5424] Gerhards, R., "The syslog Protocol", RFC 5424, March 2009. 1648 [RFC5425] Miao, F., Yuzhi, M., and J. Salowey, "TLS Transport 1649 Mapping for syslog", RFC 5425, March 2009. 1651 [RFC5426] Okmianski, A., "Transmission of syslog Messages over UDP", 1652 RFC 5426, March 2009. 1654 12.2. Informative References 1656 [NIST800.90] 1657 National Institute of Standards and Technology, "NIST 1658 Special Publication 800-90: Recommendation for Random 1659 Number Generation using Deterministic Random Bit 1660 Generators", June 2006, . 1664 [RFC3164] Lonvick, C., "The BSD syslog Protocol", RFC 3164, 1665 August 2001. 1667 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1668 Timestamps", RFC 3339, July 2002. 1670 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1671 (USM) for version 3 of the Simple Network Management 1672 Protocol (SNMPv3)", RFC 3414, December 2002. 1674 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1675 Recommendations for Security", RFC 4086, June 2005. 1677 Authors' Addresses 1679 John Kelsey 1680 NIST 1682 Email: john.kelsey@nist.gov 1684 Jon Callas 1685 PGP Corporation 1687 Email: jon@callas.org 1689 Alexander Clemm 1690 Cisco Systems 1692 Email: alex@cisco.com