idnits 2.17.1 draft-ietf-syslog-sign-25.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 (March 30, 2009) is 5506 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: 3 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: October 1, 2009 PGP Corporation 6 A. Clemm 7 Cisco Systems 8 March 30, 2009 10 Signed syslog Messages 11 draft-ietf-syslog-sign-25.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 October 1, 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 . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. syslog Messages Containing a Signature Block . . . . . . . 9 72 4.2. Signature Block Format and Fields . . . . . . . . . . . . 9 73 4.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.2.2. Reboot Session ID . . . . . . . . . . . . . . . . . . 11 75 4.2.3. Signature Group and Signature Priority . . . . . . . . 12 76 4.2.4. Global Block Counter . . . . . . . . . . . . . . . . . 14 77 4.2.5. First Message Number . . . . . . . . . . . . . . . . . 15 78 4.2.6. Count . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4.2.7. Hash Block . . . . . . . . . . . . . . . . . . . . . . 15 80 4.2.8. Signature . . . . . . . . . . . . . . . . . . . . . . 16 81 4.2.9. Example . . . . . . . . . . . . . . . . . . . . . . . 16 82 5. Payload and Certificate Blocks . . . . . . . . . . . . . . . . 18 83 5.1. Preliminaries: Key Management and Distribution Issues . . 18 84 5.2. Payload Block . . . . . . . . . . . . . . . . . . . . . . 19 85 5.2.1. Block Format and Fields . . . . . . . . . . . . . . . 19 86 5.2.2. Originator Authentication and Authorization . . . . . 20 87 5.3. Certificate Block . . . . . . . . . . . . . . . . . . . . 21 88 5.3.1. syslog Messages Containing a Certificate Block . . . . 21 89 5.3.2. Certificate Block Format and Fields . . . . . . . . . 22 90 6. Redundancy and Flexibility . . . . . . . . . . . . . . . . . . 26 91 6.1. Configuration parameters . . . . . . . . . . . . . . . . . 26 92 6.1.1. Configuration Parameters for Certificate Blocks . . . 26 93 6.1.2. Configuration Parameters for Signature Blocks . . . . 27 94 6.2. Overlapping Signature Blocks . . . . . . . . . . . . . . . 28 95 7. Efficient Verification of Logs . . . . . . . . . . . . . . . . 29 96 7.1. Offline Review of Logs . . . . . . . . . . . . . . . . . . 29 97 7.2. Online Review of Logs . . . . . . . . . . . . . . . . . . 30 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 99 8.1. Cryptographic Constraints . . . . . . . . . . . . . . . . 33 100 8.2. Packet Parameters . . . . . . . . . . . . . . . . . . . . 33 101 8.3. Message Authenticity . . . . . . . . . . . . . . . . . . . 34 102 8.4. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 34 103 8.5. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 34 104 8.6. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 34 105 8.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 35 106 8.8. Message Observation . . . . . . . . . . . . . . . . . . . 35 107 8.9. Man In The Middle Attacks . . . . . . . . . . . . . . . . 35 108 8.10. Denial of Service . . . . . . . . . . . . . . . . . . . . 35 109 8.11. Covert Channels . . . . . . . . . . . . . . . . . . . . . 35 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 111 9.1. Structured Data and syslog messages . . . . . . . . . . . 36 112 9.2. Version Field . . . . . . . . . . . . . . . . . . . . . . 36 113 9.3. SG Field . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 9.4. Key Blob Type . . . . . . . . . . . . . . . . . . . . . . 38 115 10. Working Group . . . . . . . . . . . . . . . . . . . . . . . . 40 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 42 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 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 The collector of the previous messages may verify that the hash of 161 each received message matches the signed hash contained in the 162 Signature Block. A collector may process these Signature Blocks as 163 they arrive, building an authenticated log file. Alternatively, it 164 may store all the log messages in the order they were received. This 165 allows a network operator to authenticate the log file at the time 166 the logs are reviewed. 168 The mechanism described in this specification is intended to be used 169 in conjunction with the syslog protocol as defined in [RFC5424] as 170 its message delivery mechanism and uses the concept of STRUCTURED- 171 DATA elements defined in that document. In fact, this specification 172 mandates implementation of syslog protocol. Nevertheless, it is 173 conceivable that the concepts underlying this mechanism could also be 174 used in conjunction with other message delivery mechanisms. 175 Designers of other efforts to define event notification mechanisms 176 are therefore encouraged to consider this specification in their 177 designs. 179 2. Conventions Used in this Document 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 3. syslog Message Format 187 This specification is intended to be used in conjunction with the 188 syslog protocol as defined in [RFC5424]. The syslog protocol 189 therefore MUST be supported by implementations of this specification. 191 Because the originator generating the Signature Block message signs 192 each message in its entirety, the messages MUST NOT be changed in 193 transit. By the same token, the syslog-sign messages MUST NOT be 194 changed in transit. [RFC3164] describes relay behavior in which 195 syslog messages are altered. If such behavior were to occur in 196 conjunction with syslog-sign, it would render any signing invalid and 197 hence make the mechanism useless. Likewise, any truncation of 198 messages that occurs between sending and receiving renders the 199 mechanism useless. For this reason, syslog originator and collector 200 implementations implementing this specification MUST support messages 201 of up to and including 2048 octets in length, in order to minimize 202 the chance of truncation. While syslog originator and collector 203 implementations MAY support messages with a length larger than 2048 204 octets, implementers need to be aware that any message truncations 205 that occur render the mechanism useless. 207 This specification uses the syslog message format described in 208 [RFC5424]. Along with other fields, that document describes the 209 concept of Structured Data (SD). Structured Data is defined in terms 210 of SD ELEMENTS (SDEs). An SDE consists of a name and a set of 211 parameter name - value pairs. The SDE name is referred to as SD-ID. 212 The name-value pairs are referred to as SD-PARAM, or SD Parameters, 213 with the name constituting the SD-PARAM-NAME, and the value 214 constituting the SD-PARAM-VALUE. 216 The syslog messages defined in this document carry the signature and 217 certificate data as Structured Data. The special syslog messages 218 defined in this document include for this purpose definitions of SDEs 219 to convey parameters that relate to the signing of syslog messages. 220 The MSG part of the syslog messages defined in this document SHOULD 221 simply be empty -- the content of the messages is not intended for 222 interpretation by humans but by applications that use those messages 223 to build an authenticated log. 225 Because the syslog messages defined in this document adhere to the 226 format described in [RFC5424], they identify the machine that 227 originates the syslog message in the HOSTNAME field. Therefore, the 228 signature and certificate data do not need to include any additional 229 parameter to identify the machine that orginates the message. 231 4. Signature Blocks 233 This section describes the format of the Signature Block and the 234 fields used within the Signature Block, as well as the syslog 235 messages used to carry the Signature Block. 237 4.1. syslog Messages Containing a Signature Block 239 There is a need to distinguish the Signature Block itself from the 240 syslog message that is used to carry a Signature Block. Signature 241 Blocks MUST be encompassed within completely formed syslog messages. 242 Syslog messages that contain a Signature Block are also referred to 243 as Signature Block messages. 245 A Signature Block message is identified by the presence of an SD 246 ELEMENT with an SD-ID with the value "ssign". In addition, a 247 Signature Block message MUST contain valid APP-NAME, PROCID, and 248 MSGID fields to be compliant with [RFC5424]. This specification does 249 not mandate particular values for these fields; however, for 250 consistency, originators MUST use the same values for APP-NAME, 251 PROCID, and MSGID fields for every Signature Block message that is 252 sent, whichever values are chosen. To allow for the possibility of 253 multiple originators per host, the combination of APP-NAME, PROCID, 254 and MSGID MUST be unique for each such originator. If an originator 255 daemon is restarted, it MAY use a new PROCID for what is otherwise 256 the same originator but MUST continue to use the same APP-NAME and 257 MSGID. It is RECOMMENDED (but not required) to use 110 as value for 258 the PRI field, corresponding to facility 13 and severity 6 259 (informational). The Signature Block is carried as Structured Data 260 within the Signature Block message, per the definitions that follow 261 in the next section. A Signature Block message MAY carry other 262 Structured Data besides the Structured Data of the Signature Block 263 itself. The MSG part of a Signature Block message SHOULD be empty. 265 The syslog messages defined as part of syslog-sign themselves 266 (Signature Block messages and Certificate Block messages) MUST NOT be 267 signed by a Signature Block. Collectors that implement syslog-sign 268 know to distinguish syslog messages that are associated with syslog- 269 sign from those that are subjected to signing and process them 270 differently. The intent of syslog-sign is to sign a stream of syslog 271 messages, not to alter it. 273 4.2. Signature Block Format and Fields 275 The content of a Signature Block message is the Signature Block. The 276 Signature Block MUST be encoded as an SD ELEMENT, as defined in 277 [RFC5424]. 279 The SD-ID MUST have the value of "ssign". 281 The SDE contains the fields of the Signature Block encoded as SD 282 Parameters, as specified in the following. The Signature Block is 283 composed of the following fields. The value of each field MUST be 284 printable ASCII, and any binary values MUST be base 64 encoded, as 285 defined in [RFC4648]. 287 Field SD-PARAM-NAME Size in octets 288 ----- ------------- ---- -- ------ 290 Version VER 4 292 Reboot Session ID RSID 1-10 294 Signature Group SG 1 296 Signature Priority SPRI 1-3 298 Global Block Counter GBC 1-10 300 First Message Number FMN 1-10 302 Count CNT 1-2 304 Hash Block HB variable, size of hash 305 times the number of hashes 306 (base 64 encoded binary) 308 Signature SIGN variable 309 (base 64 encoded binary) 311 The fields MUST be provided in the order listed. Each SD parameter 312 MUST occur once and only once in the Signature Block. New SD 313 parameters MUST NOT be added unless a new Version of the protocol is 314 defined. (Implementations that wish to add proprietary extensions 315 will need to define a separate SD ELEMENT.) A Signature Block is 316 accordingly encoded as follows, where xxx denotes a placeholder for 317 the particular values: 319 [ssign VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" GBC="xxx" FMN="xxx" 320 CNT="xxx" HB="xxx" SIGN="xxx"] 322 Values of the fields constitute SD parameter values and are hence 323 enclosed in quotes, per [RFC5424]. The fields are separated by 324 single spaces and are described in the subsequent subsections. 326 4.2.1. Version 328 The Signature Block Version field is an alphanumeric value that has a 329 length of 4 octets, which may include leading zeroes. The first two 330 octets and the last octet contain a decimal character in the range of 331 "0" to "9", whereas the third octet contains an alphanumeric 332 character in the range of "0" to "9", "a" to "z", or "A" to "Z". The 333 value in this field specifies the version of the syslog-sign 334 protocol. This is extensible to allow for different hash algorithms 335 and signature schemes to be used in the future. The value of this 336 field is the grouping of the protocol version (2 octets), the hash 337 algorithm (1 octet) and the signature scheme (1 octet). 339 Protocol Version - 2 octets, with "01" as the value for the 340 protocol version that is described in this document. 342 Hash Algorithm - 1 octet, where, in conjunction with Protocol 343 Version 01, a value of "1" denotes SHA1 and a value of "2" denotes 344 SHA256, as defined in [FIPS.180-2.2002]. (This is the octet that 345 can have a value of not just "0" to "9" but also "a" to "z" and 346 "A" to "Z".) 348 Signature Scheme - 1 octet, where, in conjunction with Protocol 349 Version 01, a value of "1" denotes OpenPGP DSA, defined in 350 [RFC4880] and [FIPS.186-2.2000]. 352 The version, hash algorithm and signature scheme defined in this 353 document would accordingly be represented as "0111" (if SHA1 is used 354 as Hash Algorithm) and "0121" (if SHA256 is used as Hash Algorithm), 355 respectively (without the quotation marks). 357 The values of the Hash Algorithm and Signature Scheme are defined 358 relative to the Protocol Version. If the single-octet representation 359 of the values for Hash Algorithm and Signature Scheme were to ever 360 represent a limitation, this limitation could be overcome by defining 361 a new Protocol Version with additional Hash Algorithms and/or 362 Signature Schemes, and having implementations support both Protocol 363 Versions concurrently. 365 4.2.2. Reboot Session ID 367 The Reboot Session ID is a decimal value that has a length between 1 368 and 10 octets. The acceptable values for this are between 0 and 369 9999999999. Leading zeroes MUST be omitted. 371 A Reboot Session ID is expected to strictly monotonically increase 372 (i.e., to never repeat or decrease) whenever an originator reboots in 373 order to allow collectors to distinguish messages and message 374 signatures across reboots. There are several ways in which this may 375 be accomplished. In one way, the Reboot Session ID may increase by 376 1, starting with a value of 1. Note that in this case, an originator 377 is required to retain the previous Reboot Session ID across reboots. 378 In another way, a value of the unix time (number of seconds since 1 379 January 1970) may be used. Implementers of this method need to 380 beware of the possibility of multiple reboots occurring within a 381 single second. Implementers need to also beware of the year 2038 382 problem, which will cause the unix time to wrap in the year 2038. In 383 yet another way, implementers wish to consider using the 384 snmpEngineBoots value as a source for this counter as defined in 385 [RFC3414]. 387 In cases where an originator is not able to guarantee that the Reboot 388 Session ID is always increased after a reboot, the Reboot Session ID 389 MUST always be set to a value of 0. If the value can no longer be 390 increased (e.g., because it reaches 9999999999), then manual 391 intervention may be required to subsequently reset it. 393 If a reboot of an originator takes place, Signature Block messages 394 MAY use a new PROCID. However, Signature Block messages of the same 395 originator MUST continue to use the same APP-NAME and MSGID. 397 4.2.3. Signature Group and Signature Priority 399 The SG parameter may take any value from 0-3 inclusive. The SPRI 400 parameter may take any value from 0-191 inclusive. These fields 401 taken together allow network administrators to associate groupings of 402 syslog messages with appropriate Signature Blocks and Certificate 403 Blocks. Groupings of syslog messages that are signed together are 404 also called Signature Groups. A Signature Block contains only hashes 405 of those syslog messages that are part of the same Signature Group. 407 For example, in some cases, network administrators might have 408 originators send syslog messages of Facilities 0 through 15 to one 409 collector and those with Facilities 16 through 23 to another. In 410 such cases, associated Signature Blocks should likely be sent to the 411 corresponding collectors as well, signing the syslog messages that 412 are intended for each collector separately. This way, each collector 413 receives Signature Blocks for all syslog messages that it receives, 414 and only for those. The ability to associate different categories of 415 syslog messages with different Signature Groups, signed in separate 416 Signature Blocks, provides administrators with flexibility in this 417 regard. 419 Syslog-sign provides four options for handling Signature Groups, 420 linking them with PRI values so they may be routed to the destination 421 commensurate with the corresponding syslog messages. In all cases, 422 no more than 192 distinct Signature Groups (0-191) are permitted. 424 The Signature Group to which a Signature Block pertains is indicated 425 by the Signature Priority (SPRI) field. The Signature Group (SG) 426 field indicates how to interpret the Signature Priority field. (Note 427 that the SG field does not indicate the Signature Group itself, as 428 its name might suggest.) The SG field can have one of the following 429 values: 431 a. "0" -- There is only one Signature Group. In this case, the 432 administrators want all Signature Blocks to be sent to a single 433 destination; in all likelihood, all of the syslog messages will 434 also be going to that same destination. Signature Blocks sign 435 all messages regardless of their PRI value. This means that, in 436 effect, the Signature Block's SPRI value can be ignored. 437 However, it is RECOMMENDED that a single SPRI value be used for 438 all Signature Blocks. Furthermore, it is RECOMMENDED to set that 439 value to the same value as the PRI field of the Signature Block 440 message. This way, the PRI of the Signature Block message 441 matches the SPRI of the Signature Block that it contains. 443 b. "1" -- Each PRI value is associated with its own Signature Group. 444 Signature Blocks for a given Signature Group have SPRI = PRI for 445 that Signature Group. In other words, the SPRI of the Signature 446 Block matches the PRI value of the syslog messages that are part 447 of the Signature Group and hence signed by the Signature Block. 448 An SG value of 1 can, for example, be used when the administrator 449 of an originator does not know where any of the syslog messages 450 will ultimately go but anticipates that messages with different 451 PRI values will be collected and processed separately. Having a 452 Signature Group per PRI value provides administrators with a 453 large degree of flexibility with regard to how to divide up the 454 processing of syslog messages and their signatures after they are 455 received, at the same time allowing Signature Blocks to follow 456 the corresponding syslog messages to their eventual destination. 458 c. "2" -- Each Signature Group contains a range of PRI values. 459 Signature Groups are assigned sequentially. A Signature Block 460 for a given Signature Group has its own SPRI value denoting the 461 highest PRI value of syslog messages in that Signature Group. 462 The lowest PRI value of syslog messages in that Signature Group 463 will be one larger than the SPRI value of the previous Signature 464 Group or "0" in case there is no other Signature Group with a 465 lower SPRI value. The specific Signature Groups and ranges they 466 are associated with are subject to configuration by a system 467 administrator. 469 d. "3" -- Signature Groups are not assigned with any of the above 470 relationships to PRI values of the syslog messages they sign. 471 Instead, another scheme is used, which is outside the scope of 472 this specification. There has to be some predefined arrangement 473 between the originator and the intended collectors as to which 474 syslog messages are to be included in which Signature Group, 475 requiring configuration by a system administrator. This provides 476 administrators also with the flexibility to group syslog messages 477 into Signature Groups according to criteria that are not tied to 478 the PRI value. 480 One reasonable way to configure some installations is to have only 481 one Signature Group, indicated with SG=0, and have the originator 482 send a copy of each Signature Block to each collector. In that case, 483 collectors that are not configured to receive every syslog message 484 will still receive signatures for every message, even ones they are 485 not supposed to receive. While the collector will not be able to 486 detect gaps in the messages (because the presence of a signature of a 487 message that is missing does not tell the collector whether or not 488 the corresponding message would be of the collector's concern), it 489 does allow all messages that do arrive at each collector to be put 490 into the right order and to be verified. It also allows each 491 collector to detect duplicates. Likewise, configuring only one 492 Signature Group can be a reasonable way to configure installations 493 that involve relay chains, where one or more interim relays may or 494 may not relay all messages to the same destination. 496 4.2.4. Global Block Counter 498 The Global Block Counter is a decimal value representing the number 499 of Signature Blocks sent by syslog-sign before the current one, in 500 this reboot session. This takes at least 1 octet and at most 10 501 octets displayed as a decimal counter. The acceptable values for 502 this are between 0 and 9999999999, starting with 0. Leading zeroes 503 MUST be omitted. If the value of the Global Block Counter has 504 reached 9999999999 and the Reboot Session ID has a value other than 0 505 (indicating the fact that persistence of the Reboot Session ID is 506 supported), then the Reboot Session ID MUST be incremented by 1 and 507 the Global Block Counter resumes at 0. When the Reboot Session ID is 508 0 (i.e., persistent Reboot Session IDs are not supported) and the 509 Global Block Counter reaches its maximum value, then the Global Block 510 Counter is reset to 0 and the Reboot Session ID MUST remain at 0. 512 Note that the Global Block Counter crosses Signature Groups; it 513 allows one to roughly synchronize when two messages were sent, even 514 though they went to different collectors and are part of different 515 Signature Groups. 517 Because a reboot results in the start of a new reboot session, the 518 originator MUST reset the Global Block Counter to 0 after a reboot 519 occurs. Applications need to take into account the possibility that 520 a reboot occurred when authenticating a log, and situations in which 521 reboots occur frequently may result in losing the ability to verify 522 the proper sequence in which messages were sent, hence jeopardizing 523 the integrity of the log. 525 4.2.5. First Message Number 527 This is a decimal value between 1 and 10 octets, with leading zeroes 528 omitted. It contains the unique message number within this Signature 529 Group of the first message whose hash appears in this block. The 530 very first message of the reboot session is numbered "1". This 531 implies that when the Reboot Session ID increases, the message number 532 is reset to 1. 534 For example, if this Signature Group has processed 1000 messages so 535 far and message number 1001 is the first message whose hash appears 536 in this Signature Block, then this field contains 1001. The message 537 number is relative to the Signature Group to which it belongs; hence, 538 a message number does not identify a message beyond its Signature 539 Group. 541 Should the message number reach 9999999999 within the same reboot 542 session and Signature Group, the message number subsequently restarts 543 at 1. In such event, the Global Block Counter will be vastly 544 different between two occurrences of the same message number. 546 4.2.6. Count 548 The count is a 1 or 2 octet field that indicates the number of 549 message hashes to follow. The valid values for this field are 1 550 through 99. The number of hashes included in the Signature Block 551 MUST be chosen such that the length of the resulting syslog message 552 does not exceed the maximum permissible syslog message length. 554 4.2.7. Hash Block 556 The hash block is a block of hashes, each separately encoded in base 557 64. Each hash in the hash block is the hash of the entire syslog 558 message represented by the hash, independent of the underlying 559 transport. Hashes are ordered from left to right in the order of 560 occurrence of the syslog messages that they represent. The space 561 character is used to separate the hashes. Note, the hash block 562 constitutes a single SD-Param; a Signature Block message MUST include 563 all its hashes in a single hash block and MUST NOT spread its hashes 564 across several hash blocks. 566 The "entire syslog message" refers to what is described as the syslog 567 message excluding transport parts that are described in [RFC5425] and 568 [RFC5426], and excluding other parts that may be defined in future 569 transports. The hash value will be the result of the hashing 570 algorithm run across the syslog message, starting with the "<" of the 571 PRI portion of the header part of the message. The hash algorithm 572 used and indicated by the Version field determines the size of each 573 hash, but the size MUST NOT be shorter than 160 bits without the use 574 of padding. It is base 64 encoded as per [RFC4648]. 576 The number of hashes in a hash block SHOULD be chosen such that the 577 resulting Signature Block message does not exceed a length of 2048 578 octets in order to avoid the possibility that truncation occurs. 579 When more hashes need to be sent than fit inside a Signature Block 580 message, it is advisable to start a new Signature Block. 582 4.2.8. Signature 584 This is a digital signature, encoded in base 64 per [RFC4648]. The 585 signature is calculated over the completely formatted Signature Block 586 message (starting from the first octet of PRI and continuing to the 587 last octet of MSG, or STRUCTURED-DATA if MSG is not present), before 588 the SIGN parameter (SD Parameter Name and the space before it [" 589 SIGN"], "=", and the corresponding value) is added. For the OpenPGP 590 DSA signature scheme, the value of the signature field contains the 591 DSA values r and s, encoded as two multiprecision integers (see 592 [RFC4880], Sections 5.2.2 and 3.2), concatenated, and then encoded in 593 base 64 [RFC4648]. 595 4.2.9. Example 597 An example of a Signature Block message is depicted below, broken 598 into lines to fit internet-draft publication rules. There is a space 599 at the end of each line, with the exception of the last line which 600 ends with "]" and the second-to-last line which ends with "ld6hg". 602 <110>1 2008-10-16T20:23:03+02:00 host.example.org syslogd 5660 - 603 [ssign VER="0111" RSID="1" SG="0" SPRI="0" GBC="1" FMN="1" CNT="15" 604 HB="W1knzOeMETXgCymaK7W8UAxDgP8= zTxfthW8WqmtFhOG4k/+ZxkirTA= 605 j9dubU1GNVp7qWShwph/w32nD08= XQDLZ/NuwirmLdMORtm84r9kIW4= 606 RNDFNCo7hiCsK/EKumsPBbFHNZA= ANiE3KbY948J6cEB640fAtWXuO4= 607 e2M/OqjHDfxLVUSPt1CsNJHm9wU= Y+racQst7F1gR8eEUh8O7o+M53s= 608 JAMULRxjMPbOO5EhhKbsUkAwbl0= pd+N5kmlnyQ0BoItELd/KWQrcMg= 609 dsMQSzPHIS6S3Vaa23/t7U8JAJ4= i4rE3x7N4qyQGTkmaWHsWDFP9SY= 610 qgTqV4EgfUFd3uZXNPvJ25erzBI= XW0YrME5kQEh+fxhg1fetnWxfIc= 611 7YPcRHsDwXWnQuGRWaJtFWw9hus=" SIGN="MC0CFQCEGQKze8v5Xde+ywQdzXUCBld6hg 612 IUcyWxzgIO7ouJcReGxHsPBhD+bBM="] 613 The message is of syslog-sign protocol version "01". It uses SHA1 as 614 hash algorithm and an OpenPGP DSA signature scheme. Its reboot 615 session ID is 1. Its Signature Group is 0 which means that all 616 syslog messages go to the same destination; its Signature Priority 617 (which can effectively be ignored because all syslog messages will be 618 signed regardless of their PRI value) is 0. Its Global Block Counter 619 is 1. The first message number is 1; the message contains 15 message 620 hashes. 622 5. Payload and Certificate Blocks 624 Certificate Blocks and Payload Blocks provide key management for 625 syslog-sign. Their purpose is to support key management that uses 626 public key cryptosystems. 628 5.1. Preliminaries: Key Management and Distribution Issues 630 A Payload Block contains public key certificate information that is 631 to be conveyed to the collector. A Payload Block is sent at the 632 beginning of a new reboot session, carrying public key information in 633 effect for the reboot session. However, a Payload Block is not sent 634 directly, but in (one or more) fragments. Those fragments are termed 635 Certificate Blocks. Therefore, originators send at least one 636 Certificate Block at the beginning of a new reboot session. 638 There are three key points to understand about Certificate Blocks: 640 a. They handle a variable-sized payload, fragmenting it if necessary 641 and transmitting the fragments as legal syslog messages. This 642 payload is built (as described below) at the beginning of a 643 reboot session and is transmitted in pieces with each Certificate 644 Block carrying a piece. There is exactly one Payload Block per 645 reboot session. 647 b. The Certificate Blocks are digitally signed. The originator does 648 not sign the Payload Block, but the signatures on the Certificate 649 Blocks ensure its authenticity. Note that it may not even be 650 possible to verify the signature on the Certificate Blocks 651 without the information in the Payload Block; in this case the 652 Payload Block is reconstructed, the key is extracted, and then 653 the Certificate Blocks are verified. (This is necessary even 654 when the Payload Block carries a certificate, because some other 655 fields of the Payload Block are not otherwise verified.) In 656 practice, most installations keep the same public key over long 657 periods of time, so that most of the time, it is easy to verify 658 the signatures on the Certificate Blocks, and use the Payload 659 Block to provide other useful per-session information. 661 c. The kind of Payload Block that is expected is determined by what 662 kind of key material is on the collector that receives it. The 663 originator and collector (or offline log viewer) both have some 664 key material (such as a root public key or pre-distributed public 665 key) and an acceptable value for the Key Blob Type in the Payload 666 Block, below. The collector or offline log viewer MUST NOT 667 accept a Payload Block of the wrong type. 669 5.2. Payload Block 671 The Payload Block is built when a new reboot session is started. 672 There is a one-to-one correspondence between reboot sessions and 673 Payload Blocks. An originator creates a new Payload Block after each 674 reboot. The Payload Block is used until the next reboot. 676 5.2.1. Block Format and Fields 678 A Payload Block MUST have the following fields: 680 a. Full local time stamp for the originator at the time the reboot 681 session started. This must be in the time stamp format specified 682 in [RFC5424] (essentially, time stamp format per [RFC3339] with 683 some further restrictions). 685 b. Key Blob Type, a one-octet field containing one of five values: 687 1. 'C' -- a PKIX certificate. 689 2. 'P' -- an OpenPGP certificate (a Transferable Public Key as 690 defined in [RFC4880], Section 11.1). 692 3. 'K' -- the public key whose corresponding private key is 693 being used to sign these messages. For the OpenPGP DSA 694 signature scheme, this field contains the DSA prime p, DSA 695 group order q, DSA group generator g, and DSA public-key 696 value y, encoded as four multiprecision integers (see 697 [RFC4880], Sections 5.5.2 and 3.2). 699 4. 'N' -- no key information sent; key is pre-distributed. 701 5. 'U' -- installation-specific key exchange information 703 c. The key blob, if any, base 64 encoded per [RFC4648] and 704 consisting of the raw key data. 706 The fields are separated by single space characters. Because a 707 Payload Block is not carried in a syslog message directly, only the 708 corresponding Certificate Blocks, it does not need to be encoded as 709 an SD ELEMENT. The Payload Block does not contain a field that 710 identifies the reboot session; instead, the reboot session can be 711 inferred from the Reboot Session ID parameter of the Certificate 712 Blocks that are used to carry the Payload Block. 714 When a PKIX certificate is used ("C" key blob type), it is the 715 certificate specified in ([RFC5280]). Per [RFC5425], syslog messages 716 may be transported over the TLS protocol, even where there is no PKI. 718 If that transport is used, then the device will already have a PKIX 719 certificate and it MAY use the private key associated with that 720 certificate to sign messages. In the case where there is no PKI, the 721 chain of trust of a PKIX certificate must still be established to 722 meet conventional security requirements. The methods for doing this 723 are described in [RFC5425]. 725 5.2.2. Originator Authentication and Authorization 727 When the collector receives a Payload Block, it needs to determine 728 whether the signatures are to be trusted. The following methods are 729 in scope of this specification: 731 a. X.509 certification path validation: The collector is configured 732 with one or more trust anchors (typically root CA certificates), 733 which allow it to verify a binding between the subject name and 734 the public key. Certification path validation is performed as 735 specified in [RFC5280]. 737 If the HOSTNAME contains an FQDN or an IP address, it is then 738 compared against the certificate as described in [RFC5425], 739 Section 5.2. Comparing other forms of HOSTNAMEs is beyond the 740 scope of this specification. 742 Collectors SHOULD support this method. 744 Note that due to message size restrictions, syslog-sign sends 745 only the end-entity certificate in the Payload Block. Depending 746 on the PKI deployment, the collector may need to obtain 747 intermediate certificates by other means (for example, from a 748 directory). 750 b. X.509 end-entity certificate matching: The collector is 751 configured with information necessary to identify the valid end- 752 entity certificates of its valid peers, and for each peer, the 753 HOSTNAME(s) it is authorized to use. 755 To ensure interoperability, implementations MUST support 756 fingerprints of X.509 certificates as described below. Other 757 methods MAY be supported. 759 Collectors MUST support key blob type 'C', and specifying the 760 list of valid peers using certificate fingerprints. The 761 fingerprint is calculated and formatted as specified in 762 [RFC5425], Section 4.2.2. 764 For each peer, the collector MUST support specifying a list of 765 HOSTNAME(s) this peer is allowed to use either as FQDNs or IP 766 addresses. Other forms of HOSTNAMEs are beyond the scope of this 767 specification. 769 If the locally configured FQDN is an internationalized domain 770 name, conforming implementations MUST convert it to the ASCII 771 Compatible Encoding (ACE) format for performing comparisons as 772 specified in Section 7 of [RFC5280]. An exact case-insensitive 773 string match MUST be supported, but the implementation MAY also 774 support wildcards of any type ("*", regular expressions, etc.) in 775 locally configured names. 777 Originator implementations MUST provide a means to generate a key 778 pair and self-signed certificate in the case that a key pair and 779 certificate are not available through another mechanism, and MUST 780 make the certificate fingerprint available through a management 781 interface. 783 c. OpenPGP V4 fingerprints: Like X.509 fingerprints, except key blob 784 type 'P' is used, and the fingerprint is calculated as specified 785 in [RFC4880], Section 12.2. When the fingerprint value is 786 display or configured, each byte is represented in hexadecimal 787 (using two uppercase ASCII characters), and space is added after 788 every second byte. For example: "0830 2A52 2CD1 D712 6E76 6EEC 789 32A5 CAE1 03C8 4F6E". 791 Originators and collectors MAY support this method. 793 Other methods, such as "web of trust", are beyond the scope of this 794 document. 796 5.3. Certificate Block 798 This section describes the format of the Certificate Block and the 799 fields used within the Certificate Block, as well as the syslog 800 messages used to carry Certificate Blocks. 802 5.3.1. syslog Messages Containing a Certificate Block 804 Certificate Blocks are used to get the Payload Block to the 805 collector. As with a Signature Block, each Certificate Block is 806 carried in its own syslog message, called Certificate Block message. 808 Because certificates can legitimately be much longer than 2048 809 octets, the Payload Block can be split up into several pieces, with 810 each Certificate Block carrying a piece of the Payload Block. Note 811 that the originator MAY make the Certificate Blocks of any legal 812 length (that is, any length that keeps the entire Certificate Block 813 message within 2048 octets) that holds all the required fields. 815 Software that processes Certificate Blocks MUST deal correctly with 816 blocks of any legal length. The length of the fragment of the 817 Payload Block that a Certificate Block carries MUST be at least 1 818 octet. The length SHOULD be chosen such that the length of the 819 Certificate Block message does not exceed 2048 octets. 821 A Certificate Block message is identified by the presence of an SD 822 ELEMENT with an SD-ID with the value "ssign-cert". In addition, a 823 Certificate Block message MUST contain valid APP-NAME, PROCID, and 824 MSGID fields to be compliant with syslog protocol. Syslog-sign does 825 not mandate particular values for these fields; however, for 826 consistency, implementations MUST use the same value for APP-NAME, 827 PROCID, and MSGID fields for every Certificate Block message, 828 whichever values are chosen. To allow for the possibility of 829 multiple originators per host, the combination of APP-NAME, PROCID, 830 and MSGID MUST be unique for each such originator. If an originator 831 daemon is restarted, it MAY use a new PROCID for what is otherwise 832 the same originator. The combination of APP-NAME and PROCID MUST be 833 the same that is used for Signature Block messages of the same 834 originator; however, a different MSGID MAY be used. It is 835 RECOMMENDED to use 110 as value for the PRI field, corresponding to 836 facility 13 and severity 6 (informational). The Certificate Block is 837 carried as Structured Data within the Certificate Block message. It 838 is also RECOMMENDED (but not required) that a Certificate Block 839 message carry no other Structured Data besides the Structured Data of 840 the Certificate Block itself. The MSG part of a Certificate Block 841 message SHOULD be empty. 843 5.3.2. Certificate Block Format and Fields 845 The contents of a Certificate Block message is the Certificate Block 846 itself. Like a Signature Block, the Certificate Block is encoded as 847 an SD ELEMENT. The SD-ID of the Certificate Block is "ssign-cert". 848 The Certificate Block is composed of the following fields, each of 849 which is encoded as an SD Parameter with parameter name as indicated. 850 Each field must be printable ASCII, and any binary values are base 64 851 encoded per [RFC4648]. 853 Field SD-PARAM-NAME Size in octets 854 ----- ------------- ---- -- ------ 856 Version VER 4 858 Reboot Session ID RSID 1-10 860 Signature Group SG 1 862 Signature Priority SPRI 1-3 864 Total Payload Block Length TBPL 1-8 866 Index into Payload Block INDEX 1-8 868 Fragment Length FLEN 1-4 870 Payload Block Fragment FRAG variable 871 (base 64 encoded binary) 873 Signature SIGN variable 874 (base 64 encoded binary) 876 The fields MUST be provided in the order listed. New SD parameters 877 MUST NOT be added unless a new Version of the protocol is defined. 878 (Implementations that wish to add proprietary extensions will need to 879 define a separate SD ELEMENT.) A Certificate Block is accordingly 880 encoded as follows, where xxx denotes a placeholder for the 881 particular values: 883 [ssign-cert VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" TBPL="xxx" 884 INDEX="xxx" FLEN="xxx" FRAG="xxx" SIGN="xxx"] 886 Values of the fields constitute SD parameter values and are hence 887 enclosed in quotes, per [RFC5424]. The fields are separated by 888 single spaces and are described below. Each SD parameter MUST occur 889 once and only once. 891 5.3.2.1. Version 893 The Signature Group version field is 4 octets in length. This field 894 is identical in format and meaning to the Version field described in 895 Section 4.2.1. 897 5.3.2.2. Reboot Session ID 899 The Reboot Session ID is identical in format and meaning to the RSID 900 field described in Section 4.2.2. 902 5.3.2.3. Signature Group and Signature Priority 904 The SIG field is identical in format and meaning to the SIG field 905 described in Section 4.2.3. The SPRI field is identical in format 906 and meaning to the SPRI field described there. 908 5.3.2.4. Total Payload Block Length 910 The Total Payload Block Length is a value representing the total 911 length of the Payload Block in octets, expressed as a decimal with 912 one to eight octets. 914 5.3.2.5. Index into Payload Block 916 This is a decimal value between 1 and 8 octets, with leading zeroes 917 omitted. It contains the number of octets into the Payload Block at 918 which this fragment starts. The first octet of the first fragment is 919 numbered "1". (Note, it is not numbered "0".) 921 5.3.2.6. Fragment Length 923 The total length of this fragment expressed as a decimal integer with 924 one to four octets. The fragment length must be at least 1. 926 5.3.2.7. Payload Block Fragment 928 The Payload Block Fragment contains a fragment of the payload block. 929 Its length must match the indicated fragment length. 931 5.3.2.8. Signature 933 This is a digital signature, encoded in base 64, as per [RFC4648]. 934 The Version field effectively specifies the original encoding of the 935 signature. The signature is calculated over the completely formatted 936 Certificate Block message, before the SIGN parameter is added (see 937 Section Section 4.2.8). For the OpenPGP DSA signature scheme, the 938 value of the signature field contains the DSA values r and s, encoded 939 as two multiprecision integers (see [RFC4880], Sections 5.2.2 and 940 3.2), concatenated, and then encoded in base 64 [RFC4648]. 942 5.3.2.9. Example 944 An example of a Certificate Block message is is depicted below, 945 broken into lines to fit internet-draft publication rules. There are 946 no spaces at the end of the lines that contain the key blob and the 947 signature. 949 <110>1 2008-10-16T20:23:03+02:00 host.example.org syslogd 5660 - 950 [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TBPL="620" INDEX="1" 951 FLEN="620" FRAG="2008-10-16T20:23:03+02:00 K MIIBtzCCASsGByqGSM44BAEwg 952 gEeAoGBAMLIwiyd1U0y+RhrEGAxaN+aWG1Zgk0+iUFierI2dDV0G+ghM57CflHrLGZH6oR 953 UtMgfZI+7miyAt7jZD5w/q+/b25DuImlOi5Okmqcj678vE0BKg2g7CaP1vrOU+EZbyRlRr 954 JDdzrjc8g3IZJ820wULq8f1R5C23mrnPLSYGQtPAhUAheczQhwDxb8YICnE0QYVX17Y9yk 955 CgYBL7bGxbNoBJeMh73rOsyVSzqyFlXfB+O+WSixO2RDQm5AMTwcfE50muQE+5NEb84Z4R 956 BHiGVLb4xj0KMI8JCKd6TnhXKSpkO55KpryU4Y42hpCqt8XFyE8Uobllh4c/131iEQwDg4 957 f+pPTbnkgwQz/BuYpo1qbs9hpYoXAbCN9qAOBhQACgYEAlyws12Zm/psJ/hc0yJ8VaxdxI 958 GeZRyXV7PdWBslkL4pNRgXxTV6ktQ7sKz8kn2eGHSk4UmahmCX0GLgpdaUQwOMW2wSITB1 959 yZ6r+hRZkUxXcfAMGvqWOpL1iIsTnGob3k5W9ju7ETVDV9bUrbEUmsRD8JV9lkjEXfJnfr 960 7B4GJ4=" SIGN="MCwCFFX85jQ0QK1aosxAH1lpgmEkSNspAhQ2elzq3h/wVU6u2CJ3KAD 961 uWsyzdg=="] 963 The message is of syslog-sign protocol version "01". It uses SHA1 as 964 hash algorithm and an OpenPGP DSA signature scheme. Its reboot 965 session ID is 1. Its Signature Group is 0; its Signature Priority is 966 0. The Total Payload Block Length is 620. The index into the 967 payload block is 1 (meaning this is the first fragment). The length 968 of the fragment is 620 (meaning that the Certificate Block message 969 contains the entire Payload Block). The Payload Block has the time 970 stamp 2008-10-16T20:23:03+02:00. The Key Blob Type is 'K', meaning 971 that it contains a public key whose corresponding private key is 972 being used to sign these messages. 974 Note that the Certificate Block message in this example has the same 975 time stamp as the Payload Block. This implies that this is the first 976 Certificate Block message sent in this reboot session; additional 977 Certificate Block messages can be sent later with a later time stamp, 978 which will carry the same Payload Block that will still contain the 979 same time stamp. 981 6. Redundancy and Flexibility 983 As described in Section 8.5 of [RFC5424], a transport sender may 984 discard syslog messages. Likewise, when syslog messages are sent 985 over unreliable transport, they can be lost in transit. However, if 986 a collector does not receive Signature and Certificate Blocks, many 987 messages may not be able to be verified. The originator is allowed 988 to send Signature and Certificate Blocks multiple times. Sending 989 Signature and Certificate Blocks multiple times provides redundancy 990 with the intent to ensure that the collector or relay does get the 991 Signature Blocks and in particular the Payload Block at some point in 992 time. In the meantime, any online review of logs as described in 993 Section 7.2 is delayed until the needed blocks are received. The 994 collector MUST ignore Signature Blocks and Certificate Blocks it has 995 already received and authenticated. The originator can in principle 996 change its redundancy level for any reason, without communicating 997 this fact to the collector. 999 The originator does not need to queue up other messages while sending 1000 redundant Certificate Block and Signature Block messages. It MAY 1001 send redundant Certificate Block messages even after Signature Block 1002 messages and regular syslog messages have been sent. By the same 1003 token, it MAY send redundant Signature Block messages even after 1004 newer syslog messages that are signed by a subsequent Signature Block 1005 have been sent, or even after a subsequent Signature Block message. 1007 In addition, the originator has flexibility in how many hashes to 1008 include within a Signature Block. It is legitimate for an originator 1009 to send short Signature Blocks to allow the collector to verify 1010 messages with minimal delay. 1012 6.1. Configuration parameters 1014 Although the transport sender is not constrained in how it decides to 1015 send redundant Signature and Certificate Blocks, or even in whether 1016 it decides to send along multiple copies of normal syslog messages, 1017 we define some redundancy parameters below which may be useful in 1018 controlling redundant transmission from the transport sender to the 1019 transport receiver, and which may be useful for administrators to 1020 configure. 1022 6.1.1. Configuration Parameters for Certificate Blocks 1024 Certificate Blocks are always sent at the beginning of a new reboot 1025 session. One technique to ensure reliable delivery (see Section 8.5) 1026 is to send multiple copies. This can be controlled by a 1027 "certInitialRepeat" parameter: 1029 certInitialRepeat = number of times each Certificate Block should 1030 be sent before the first message is sent. 1032 It is also useful to resend Certificate Blocks every now and then for 1033 long-lived reboot sessions. This can be controlled by the 1034 certResendDelay and certResendCount parameters: 1036 certResendDelay = maximum time delay in seconds until resending 1037 the Certificate Block. 1039 certResendCount = maximum number of other syslog messages to send 1040 until resending the Certificate Block. 1042 In some cases, it may be desirable to allow for configuration of the 1043 transport sender such that Certificate Blocks are not sent at all 1044 after the first normal syslog message has been sent. This could be 1045 expressed by setting both certResendDelay and certResendCount to "0". 1046 However, it is RECOMMENDED to configure the transport sender to send 1047 redundant Certificate Blocks even after the first message is sent 1048 when the UDP transport [RFC5426] is used. 1050 6.1.2. Configuration Parameters for Signature Blocks 1052 Verification of log messages involves a certain delay of time that is 1053 caused by the lag in time between the sending of the message itself 1054 and the corresponding Signature Block. The following configuration 1055 parameter can be useful to limit the time lag that will be incurred 1056 (note that the maximum message length may also force generating a 1057 Signature Block; see Sections Section 4.2.6 and Section 4.2.7): 1059 sigMaxDelay = generate a new Signature Block if this many seconds 1060 have elapsed since the message with the First Message Number of 1061 the Signature Block was sent. 1063 Retransmissions of Signature Blocks are not sent immediately after 1064 the original transmission, but slightly later. The following 1065 parameters control when those retransmissions are done: 1067 sigNumberResends = number of times a Signature Block is resent. 1068 (It is recommended so select a value of greater than "0" in 1069 particular when the UDP transport [RFC5426] is used.) 1071 sigResendDelay = send the next retransmission when this many 1072 seconds have elapsed since the previous sending of this Signature 1073 Block. 1075 sigResendCount = send the next retransmission when this many other 1076 syslog messages have been sent since the previous sending of this 1077 Signature Block. 1079 6.2. Overlapping Signature Blocks 1081 Notwithstanding the fact that the originator is not constrained in 1082 whether it decides to send redundant Signature Block messages, 1083 Signature Blocks SHOULD NOT overlap. This facilitates their 1084 processing by the receiving collector. This means that an originator 1085 of Signature Block messages, after having sent a first message with 1086 some First Message Number and a Count, SHOULD NOT send a second 1087 message with the same First Message Number but a different Count. It 1088 also means that an originator of Signature Block messages SHOULD NOT 1089 send a second message whose First Message Number is greater than the 1090 First Message Number, but smaller than the First Message Number plus 1091 the Count indicated in the first message. 1093 That said, the possibility of Signature Blocks that overlap does 1094 provide additional flexibility with regards to redundancy; it 1095 provides an additional option that may be desirable in some 1096 deployments. Therefore collectors MUST be designed in a way that 1097 they can cope with overlapping Signature Blocks when confronted with 1098 them. The collector MUST ignore hashes of messages that it has 1099 already received and validated. 1101 7. Efficient Verification of Logs 1103 The logs secured with syslog-sign may be reviewed either online or 1104 offline. Online review is somewhat more complicated and 1105 computationally expensive, but not prohibitively so. 1107 7.1. Offline Review of Logs 1109 When the collector stores logs to be reviewed later, they can be 1110 authenticated offline just before they are reviewed. Reviewing these 1111 logs offline is simple and relatively inexpensive in terms of 1112 resources used, so long as there is enough space available on the 1113 reviewing machine. Here, we presume that the stored log files have 1114 already been separated by originator, Reboot Session ID, and 1115 Signature Group. This can be done easily with a script file. We 1116 then do the following: 1118 a. First, we go through the raw log file and split its contents into 1119 three files. Each message in the raw log file is classified as a 1120 normal message, a Signature Block message, or a Certificate Block 1121 message. Signature Blocks and Certificate Blocks are then stored 1122 in their own files. Normal messages are stored in a keyed file, 1123 indexed on their hash values. 1125 b. We sort the Certificate Block file by INDEX value, and check to 1126 see whether we have a set of Certificate Blocks that can 1127 reconstruct the Payload Block. If so, we reconstruct the Payload 1128 Block, verify any key-identifying information, and then use this 1129 to verify the signatures on the Certificate Blocks we have 1130 received. When this is done, we have verified the reboot session 1131 and key used for the rest of the process. 1133 c. We sort the Signature Block file by First Message Number. We now 1134 create an authenticated log file, which consists of some header 1135 information and then a sequence of message number, message text 1136 pairs. We next go through the Signature Block file. We 1137 initialize a cursor for the last message number processed with 1138 the number 0. For each Signature Block in the file, we do the 1139 following: 1141 1. Verify the signature on the Signature Block. 1143 2. If the value of the First Message Number of the Signature 1144 Block is less than or equal to the last message number 1145 processed, skip the first (last message number processed 1146 minus First Message Number plus 1) hashes. 1148 3. For each remaining hashed message in the Signature Block: 1150 a. Look up the hash value in the keyed message file. 1152 b. If the message is found, write (message number, message 1153 text) to the authenticated log file. 1155 4. Set the last message number processed to the value of the 1156 First Message Number plus the Count of the Signature Block 1157 minus 1. 1159 5. Skip all other Signature Blocks with the same First Message 1160 Number unless one with a larger Count is encountered. 1162 The resulting authenticated log file contains all messages that 1163 have been authenticated. In addition, it implicitly indicates 1164 all gaps in the authenticated messages (specifically in the case 1165 when all messages of the same Signature Group are sent to the 1166 same collector), because their message numbers are missing. 1168 One can see that, assuming sufficient space for building the keyed 1169 file, this whole process is linear in the number of messages 1170 (generally two seeks, one to write and the other to read, per normal 1171 message received), and O(N lg N) in the number of Signature Blocks. 1172 This estimate comes with two caveats: first, the Signature Blocks 1173 arrive very nearly in sorted order, and so can probably be sorted 1174 more cheaply on average than O(N lg N) steps. Second, the signature 1175 verification on each Signature Block almost certainly is more 1176 expensive than the sorting step in practice. We have not discussed 1177 error-recovery, which may be necessary for the Certificate Blocks. 1178 In practice, a simple error-recovery strategy is probably enough: if 1179 the Payload Block is not valid, then we can just try alternate 1180 instances of each Certificate Block, if such are available, until we 1181 get the Payload Block right. 1183 It is easy for an attacker to flood us with plausible-looking 1184 messages, Signature Blocks, and Certificate Blocks. 1186 7.2. Online Review of Logs 1188 Some collector implementations may need to monitor log messages in 1189 close to real-time. This can be done with syslog-sign, though it is 1190 somewhat more complex than offline verification. This is done as 1191 follows: 1193 a. We have an authenticated message file, into which we write 1194 (message number, message text) pairs which have been 1195 authenticated. Again, we will assume that we are handling only 1196 one Signature Group and only one Reboot Session ID at any given 1197 time. 1199 b. We have three data structures: A queue in which (message number, 1200 hash of message) pairs are kept in sorted order, a queue in which 1201 (arrival sequence, hash of message) pairs are kept in sorted 1202 order, and a hash table that stores (message text, count) pairs 1203 indexed by hash value. In the hash table, count may be any 1204 number greater than zero; when count is zero, the entry in the 1205 hash table is cleared. 1207 c. We must receive all the Certificate Blocks before any other 1208 processing can really be done. (This is why they are sent 1209 first.) Once that is done, any additional Certificate Block 1210 message that arrives is discarded. Any syslog messages or 1211 Signature Block messages that arrive before all Certificate 1212 Blocks have been received need to be buffered. Once all 1213 Certificate Blocks have been received, the messages in the buffer 1214 can be retrieved and processed as if they were just arriving. 1216 d. Whenever a normal message arrives, we add (arrival sequence, hash 1217 of message) to our message queue. If our hash table has an entry 1218 for the message's hash value, we increment its count by one; 1219 otherwise, we create a new entry with count = 1. If the message 1220 queue is full, we roll the oldest messages off the queue by 1221 taking the oldest entry in the queue, and using it to index the 1222 hash table. If that entry has count 1, we delete the entry from 1223 the hash table; otherwise, we decrement its count. We then 1224 delete the oldest entry in the queue. 1226 e. Whenever a Signature Block message arrives, we first check to see 1227 whether the First Message Number value is too old to still be of 1228 interest, or if another Signature Block with that First Message 1229 Number and the same Count or a greater Count has already been 1230 received. If so, we discard the Signature Block. Otherwise, we 1231 check its signature and discard it if the signature is not valid. 1232 A Signature Block contains a sequence hashes, each of which is 1233 associated with a message number, starting with the First Message 1234 Number for the first hash and incrementing by one for each 1235 subsequent hash. For each hash, we first check to see whether 1236 the message hash is in the hash table. If this is the case, we 1237 do the following: 1239 A. We check if a message with the same message number is already 1240 in the authenticated message queue. 1242 B. If that is not the case, we write the (message number, 1243 message text) into the authenticated message queue, otherwise 1244 the signed hash is a duplicate and we discard it. 1246 Otherwise (the message hash is not in the hash table), we write 1247 the (message number, message hash) to the message number queue. 1248 This generally involves rolling the oldest entry out of this 1249 queue: before this is done, that entry's hash value is again 1250 looked up in the hash table. If a matching entry is found, a 1251 check is made if the authenticated message file already contains 1252 an entry with the same message number and if that is not the 1253 case, the (message number, message text) pair is written to the 1254 authenticated message. In either case, the oldest entry is then 1255 discarded. 1257 f. The result of this is a sequence of messages in the authenticated 1258 message file, each of which has been authenticated, and which are 1259 labeled with numbers showing their order of original 1260 transmission. 1262 One can see that this whole process is roughly linear in the number 1263 of messages, and also in the number of Signature Blocks received. 1264 The process is susceptible to flooding attacks; an attacker can send 1265 enough normal messages that the messages roll off their queue before 1266 their Signature Blocks can be processed. 1268 8. Security Considerations 1270 Normal syslog event messages are unsigned and have most of the 1271 security attributes described in Section 8 of [RFC5424]. This 1272 document also describes Certificate Blocks and Signature Blocks, 1273 which are signed syslog messages. The Signature Blocks contain 1274 signature information for previously sent syslog event messages. All 1275 of this information can be used to authenticate syslog messages and 1276 to minimize or obviate many of the security concerns described in 1277 [RFC5424]. 1279 The model for syslog-sign is a direct trust system where the 1280 certificate transferred is its own trust anchor. If a transport 1281 sender sends a stream of syslog messages that is signed using a 1282 certificate, the operator or application will transfer to the 1283 transport receiver the certificate that was used when signing. There 1284 is no need for a certificate chain. 1286 8.1. Cryptographic Constraints 1288 As with any technology involving cryptography, it is advisable to 1289 check the current literature to determine whether any algorithms used 1290 here have been found to be vulnerable to attack. 1292 This specification uses Public Key Cryptography technologies. The 1293 proper party or parties have to control the private key portion of a 1294 public-private key pair. Any party that controls a private key can 1295 sign anything it pleases. 1297 Certain operations in this specification involve the use of random 1298 numbers. An appropriate entropy source SHOULD be used to generate 1299 these numbers. See [RFC4086] and [NIST800.90]. 1301 8.2. Packet Parameters 1303 As an originator, it is advisable to avoid message lengths exceeding 1304 2048 octets. Various problems might result if an originator were to 1305 send messages with a length greater than 2048 octets, because relays 1306 MAY truncate messages with lengths greater than 2048 octets which 1307 would make it impossible for collectors to validate a hash of the 1308 packet. To increase the chance of interoperability, it tends to be 1309 best to be conservative with what you send but liberal in what you 1310 are able to receive. 1312 Originators need to rigidly enforce the correctness of message 1313 bodies. Problems may arise if the collector does not fully accept 1314 the syslog packets sent from an originator, or if it has problems 1315 with the format of the Certificate Block or Signature Block messages. 1317 Collectors are not to malfunction in case they receive malformed 1318 syslog messages or messages containing characters other than those 1319 specified in this document. In other words, they are to ignore such 1320 messages and continue working. 1322 8.3. Message Authenticity 1324 Syslog does not strongly associate the message with the message 1325 originator. That association is established by the collector upon 1326 verification of the Signature Block. Before a Signature Block is 1327 used to ascertain the authenticity of an event message, it might be 1328 received, stored, and reviewed by a person or automated parser. It 1329 is advisable not to assume a message is authentic until after a 1330 message has been validated by checking the contents of the Signature 1331 Block. 1333 With the Signature Block checking, an attacker may only forge 1334 messages if he or she can compromise the private key of the true 1335 originator. 1337 8.4. Replaying 1339 Event messages might be recorded and replayed by an attacker. Using 1340 the information contained in the Signature Blocks, a reviewer can 1341 determine whether the received messages are the ones originally sent 1342 by an originator. The reviewer can also identify messages that have 1343 been replayed. 1345 8.5. Reliable Delivery 1347 Event messages sent over UDP might be lost in transit. [RFC5425] can 1348 be used for the reliable delivery of syslog messages; however, it 1349 does not protect against loss of syslog messages at the application 1350 layer, for example if the TCP connection or TLS session has been 1351 closed by the transport receiver for some reason. A reviewer can 1352 pinpoint any messages sent by the originator but not received by the 1353 collector by reviewing the Signature Block information. In addition, 1354 the information in subsequent Signature Blocks allows a reviewer to 1355 determine whether any Signature Block messages were lost in transit. 1357 8.6. Sequenced Delivery 1359 Syslog messages delivered over UDP might not only be lost, but also 1360 arrive out of sequence. A reviewer can determine the original order 1361 of syslog messages and identify which messages were delivered out of 1362 order by examining the information in the Signature Block along with 1363 any timestamp information in the message. 1365 8.7. Message Integrity 1367 Syslog messages might be damaged in transit. A review of the 1368 information in the Signature Block determines whether the received 1369 message was the intended message sent by the originator. A damaged 1370 Signature Block or Certificate Block is evident because the collector 1371 will not be able to validate that it was signed by the originator. 1373 8.8. Message Observation 1375 Unless TLS is used as a secure transport [RFC5425], event messages, 1376 Certificate Blocks, and Signature Blocks are all sent in plaintext. 1377 This allows network administrators to read the message when sniffing 1378 the wire. However, this also allows an attacker to see the contents 1379 of event messages and perhaps to use that information for malicious 1380 purposes. 1382 8.9. Man In The Middle Attacks 1384 It is conceivable that an attacker might intercept Certificate Block 1385 messages and insert its own Certificate information. In that case, 1386 the attacker would be able to receive event messages from the actual 1387 originator and then relay modified messages, insert new messages, or 1388 delete messages. It would then be able to construct a Signature 1389 Block and sign it with its own private key. Network administrators 1390 need to verify that the key contained in the Payload Block is indeed 1391 the key being used on the actual originator. If that is the case, 1392 then this MITM attack will not succeed. Methods for establishing a 1393 chain of trust are also described in [RFC5425]. 1395 8.10. Denial of Service 1397 An attacker might send invalid Signature Block messages to overwhelm 1398 the collector's processing capability and consume all available 1399 resources. For this reason, it can be appropriate to simply receive 1400 the Signature Block messages and process them only as time permits. 1402 An attacker might also just overwhelm a collector by sending more 1403 messages to it than it can handle. Implementers are advised to 1404 consider features that minimize this threat, such as only accepting 1405 syslog messages from known IP addresses. 1407 8.11. Covert Channels 1409 Nothing in this protocol attempts to eliminate covert channels. In 1410 fact, just about every aspect of syslog messages lends itself to the 1411 conveyance of covert signals. For example, a collusionist could send 1412 odd and even PRI values to indicate Morse Code dashes and dots. 1414 9. IANA Considerations 1416 9.1. Structured Data and syslog messages 1418 With regard to [RFC5424], IANA is requested to add the following 1419 values to the registry entitled "syslog Structured Data id values": 1421 SD-ID PARAM_NAME 1422 ----- ---------- 1423 ssign 1424 VER 1425 RSID 1426 SG 1427 SPRI 1428 GBC 1429 FMN 1430 CNT 1431 HB 1432 SIGN 1434 ssign-cert 1435 VER 1436 RSID 1437 SG 1438 SPRI 1439 TBPL 1440 INDEX 1441 FLEN 1442 FRAG 1443 SIGN 1445 In addition, several fields need to be controlled by the IANA in both 1446 the Signature Block and the Certificate Block, as outlined in the 1447 following sections. 1449 9.2. Version Field 1451 IANA is requested to create three registries, each associated with a 1452 different subfield of the Version field of Signature Blocks and 1453 Certificate Blocks, described in Section 4.2.1 and Section 5.3.2.1, 1454 respectively. 1456 The first registry that IANA is requested to create is entitled 1457 "syslog-sign protocol version values". It is for the values of the 1458 Protocol Version subfield. The Protocol Version subfield constitutes 1459 the first 2 octets in the Version field. New values shall be 1460 assigned by the IANA using the "IETF Review" policy defined in 1461 [RFC5226]. Assigned numbers are to be increased by 1, up to a 1462 maximum value of "50". Protocol Version numbers of "51" through "99" 1463 are vendor-specific; values in this range are not to be assigned by 1464 the IANA. 1466 IANA is requested to register the Protocol Version values shown 1467 below. 1469 VALUE PROTOCOL VERSION 1470 ----- ---------------- 1471 00 Reserved 1472 01 Defined in RFC yyyy 1474 The second registry that IANA is requested to create is entitled 1475 "syslog-sign hash algorithm values". It is for the values of the 1476 Hash Algorithm subfield. The Hash Algorithm subfield constitutes the 1477 third octet in the Version field Signature Blocks and Certificate 1478 Blocks. New values shall be assigned by the IANA using the "IETF 1479 Consensus" policy defined in [RFC5226]. Assigned values are to be 1480 increased sequentially, first up to a maximum value of "9", then from 1481 "a" to "z", then from "A" to "Z". The values are registered relative 1482 to the Protocol Version. This means that the same Hash Algorithm 1483 value can be reserved for different Protocol Versions, possibly 1484 referring to a different hash algorithm each time. This makes it 1485 possible to deal with future scenarios in which the single octet 1486 representation becomes a limitation, as more Hash Algorithms can be 1487 supported by defining additional Protocol Versions that 1488 implementations might support concurrently. 1490 IANA is requested to register the Hash Algorithm values shown below. 1492 VALUE PROTOCOL VERSION HASH ALGORITHM 1493 ----- ---------------- -------------- 1494 0 01 Reserved 1495 1 01 SHA1 1496 2 01 SHA256 1498 The third registry that IANA is requested to create is entitled 1499 "syslog-sign signature scheme values". It is for the values of the 1500 Signature Scheme subfield. The Signature Scheme subfield constitutes 1501 the fourth octet in the Version field of Signature Blocks and 1502 Certificate Blocks. New values shall be assigned by the IANA using 1503 the "IETF Consensus" policy defined in [RFC5226]. Assigned values 1504 are to be increased by 1, up to a maximum value of "9". This means 1505 that the same Signature Scheme value can be reserved for different 1506 Protocol Versions, possibly in each case referring to a different 1507 Signature Scheme each time. This makes it possible to deal with 1508 future scenarios in which the single octet representation becomes a 1509 limitation, as more Signature Schemes can be supported by defining 1510 additional Protocol Versions that implementations might support 1511 concurrently. 1513 IANA is requested to register the Signature Scheme values shown 1514 below. 1516 VALUE PROTOCOL VERSION SIGNATURE SCHEME 1517 ----- ---------------- ---------------- 1518 0 01 Reserved 1519 1 01 OpenPGP DSA 1521 9.3. SG Field 1523 IANA is requested to create a registry entitled "syslog-sign sg field 1524 values". It is for values of the SG Field as defined in 1525 Section 4.2.3. New values shall be assigned by the IANA using the 1526 "IETF Consensus" policy defined in [RFC5226]. Assigned values are to 1527 be incremented by 1, up to a maximum value of "7". Values "8" and 1528 "9" shall be left as vendor specific and shall not be assigned by the 1529 IANA. 1531 IANA is requested to register the SG Field values shown below. 1533 VALUE MEANING 1534 ----- ------- 1535 0 per RFC yyyy 1536 1 per RFC yyyy 1537 2 per RFC yyyy 1538 3 per RFC yyyy 1540 9.4. Key Blob Type 1542 IANA is requested to create a registry entitled "syslog-sign key blob 1543 type values". It is to register one-character identifiers for the 1544 key blob type, per Section 5.2. New values shall be assigned by the 1545 IANA using the "IETF Consensus" policy defined in [RFC5226]. 1546 Uppercase letters may be assigned as values. Lowercase letters are 1547 left as vendor specific and shall not be assigned by the IANA. 1549 IANA is requested to register the key blob type values shown below. 1551 VALUE KEY BLOB TYPE 1552 ----- ------------ 1553 'C' a PKIX certificate 1554 'P' an OpenPGP certificate 1555 'K' the public key whose corresponding private key is 1556 used to sign the messages 1557 'N' no key information sent, key is pre-distributed 1558 'U' installation-specific key exchange information 1560 10. Working Group 1562 The working group can be contacted via the mailing list: 1564 syslog@ietf.org 1566 The current Chairs of the Working Group can be contacted at: 1568 Chris Lonvick 1569 Cisco Systems 1570 Email: clonvick@cisco.com 1572 David Harrington 1573 Huawei Technologies (USA) 1574 Email: ietfdbh@comcast.net 1575 dharrington@huawei.com 1576 Tel: +1-603-436-8634 1578 11. Acknowledgements 1580 The authors wish to thank Alex Brown, Chris Calabrese, Steve Chang, 1581 Pasi Eronen, Carson Gaspar, Rainer Gerhards, Drew Gross, David 1582 Harrington, Chris Lonvick, Albert Mietus, Darrin New, Marshall Rose, 1583 Andrew Ross, Martin Schuette, Holt Sorenson, Rodney Thayer, and the 1584 many Counterpane Internet Security engineering and operations people 1585 who commented on various versions of this proposal. 1587 12. References 1589 12.1. Normative References 1591 [FIPS.186-2.2000] 1592 National Institute of Standards and Technology, "Digital 1593 Signature Standard", FIPS PUB 186-2, January 2000, . 1597 [FIPS.180-2.2002] 1598 National Institute of Standards and Technology, "Secure 1599 Hash Standard", FIPS PUB 180-2, August 2002, . 1602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1603 Requirement Levels", BCP 14, RFC 2119, March 1997. 1605 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1606 Encodings", RFC 4648, October 2006. 1608 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1609 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1611 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1612 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1613 May 2008. 1615 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1616 Housley, R., and W. Polk, "Internet X.509 Public Key 1617 Infrastructure Certificate and Certificate Revocation List 1618 (CRL) Profile", RFC 5280, May 2008. 1620 [RFC5424] Gerhards, R., "The syslog Protocol", RFC 5424, March 2009. 1622 [RFC5425] Miao, F., Yuzhi, M., and J. Salowey, "TLS Transport 1623 Mapping for syslog", RFC 5425, March 2009. 1625 [RFC5426] Okmianski, A., "Transmission of syslog Messages over UDP", 1626 RFC 5426, March 2009. 1628 12.2. Informative References 1630 [NIST800.90] 1631 National Institute of Standards and Technology, "NIST 1632 Special Publication 800-90: Recommendation for Random 1633 Number Generation using Deterministic Random Bit 1634 Generators", June 2006, . 1638 [RFC3164] Lonvick, C., "The BSD syslog Protocol", RFC 3164, 1639 August 2001. 1641 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1642 Timestamps", RFC 3339, July 2002. 1644 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1645 (USM) for version 3 of the Simple Network Management 1646 Protocol (SNMPv3)", RFC 3414, December 2002. 1648 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1649 Recommendations for Security", RFC 4086, June 2005. 1651 Authors' Addresses 1653 John Kelsey 1654 NIST 1656 Email: john.kelsey@nist.gov 1658 Jon Callas 1659 PGP Corporation 1661 Email: jon@callas.org 1663 Alexander Clemm 1664 Cisco Systems 1666 Email: alex@cisco.com