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