idnits 2.17.1 draft-ietf-syslog-sign-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1390. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 20, 2006) is 6399 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) == Unused Reference: '3' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1265, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1268, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1271, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1285, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1288, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1291, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1296, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1302, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1304, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 1333, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2440 (ref. '9') (Obsoleted by RFC 4880) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '15') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 3164 (ref. '19') (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3548 (ref. '22') (Obsoleted by RFC 4648) == Outdated reference: A later version (-23) exists of draft-ietf-syslog-protocol-17 == Outdated reference: A later version (-12) exists of draft-ietf-syslog-transport-udp-07 == Outdated reference: A later version (-14) exists of draft-ietf-syslog-transport-tls-03 Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 syslog Working Group J. Kelsey 3 Internet-Draft 4 Intended status: Standards Track J. Callas 5 Expires: March 24, 2007 PGP Corporation 6 A. Clemm 7 Cisco Systems 8 September 20, 2006 10 Signed syslog Messages 11 draft-ietf-syslog-sign-19.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 24, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes a mechanism to add origin authentication, 45 message integrity, replay-resistance, message sequencing, and 46 detection of missing messages to the transmitted syslog messages. 47 This specification draws upon the work defined in RFC xxxx, "The 48 syslog Protocol", however it may be used atop any message delivery 49 mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", 50 or in the RAW mode of "RFC 3195, "The Reliable Delivery of syslog". 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions Used in this Document . . . . . . . . . . . . . . 6 56 3. syslog Message Format . . . . . . . . . . . . . . . . . . . . 7 57 4. Signature Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.1. syslog Messages Containing a Signature Block . . . . . . . 9 59 4.2. Signature Block Format and Fields . . . . . . . . . . . . 9 60 4.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 10 61 4.2.2. Reboot Session ID . . . . . . . . . . . . . . . . . . 11 62 4.2.3. Signature Group and Signature Priority . . . . . . . . 11 63 4.2.4. Global Block Counter . . . . . . . . . . . . . . . . . 13 64 4.2.5. First Message Number . . . . . . . . . . . . . . . . . 13 65 4.2.6. Count . . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.2.7. Hash Block . . . . . . . . . . . . . . . . . . . . . . 14 67 4.2.8. Signature . . . . . . . . . . . . . . . . . . . . . . 14 68 5. Payload and Certificate Blocks . . . . . . . . . . . . . . . . 16 69 5.1. Preliminaries: Key Management and Distribution Issues . . 16 70 5.2. Payload Block . . . . . . . . . . . . . . . . . . . . . . 17 71 5.3. Certificate Block . . . . . . . . . . . . . . . . . . . . 17 72 5.3.1. syslog Messages Containing a Certificate Block . . . . 18 73 5.3.2. Certificate Block Format and Fields . . . . . . . . . 18 74 6. Redundancy and Flexibility . . . . . . . . . . . . . . . . . . 21 75 6.1. Redundancy . . . . . . . . . . . . . . . . . . . . . . . . 21 76 6.1.1. Configuration Parameters for Certificate Blocks . . . 21 77 6.1.2. Configuration Parameters for Signature Blocks . . . . 21 78 6.2. Flexibility . . . . . . . . . . . . . . . . . . . . . . . 22 79 7. Efficient Verification of Logs . . . . . . . . . . . . . . . . 23 80 7.1. Offline Review of Logs . . . . . . . . . . . . . . . . . . 23 81 7.2. Online Review of Logs . . . . . . . . . . . . . . . . . . 24 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 83 8.1. Cryptography Constraints . . . . . . . . . . . . . . . . . 26 84 8.2. Packet Parameters . . . . . . . . . . . . . . . . . . . . 26 85 8.3. Message Authenticity . . . . . . . . . . . . . . . . . . . 27 86 8.4. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 27 87 8.5. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 27 88 8.6. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 27 89 8.7. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 27 90 8.8. Message Integrity . . . . . . . . . . . . . . . . . . . . 28 91 8.9. Message Observation . . . . . . . . . . . . . . . . . . . 28 92 8.10. Man In The Middle . . . . . . . . . . . . . . . . . . . . 28 93 8.11. Denial of Service . . . . . . . . . . . . . . . . . . . . 28 94 8.12. Covert Channels . . . . . . . . . . . . . . . . . . . . . 28 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 96 9.1. Structured data and syslog messages . . . . . . . . . . . 30 97 9.2. Version Field . . . . . . . . . . . . . . . . . . . . . . 30 98 9.3. SG Field . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 9.4. Key Blob Type . . . . . . . . . . . . . . . . . . . . . . 32 100 10. Authors and Working Group Chairs . . . . . . . . . . . . . . . 33 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 104 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 106 Intellectual Property and Copyright Statements . . . . . . . . . . 38 108 1. Introduction 110 This document describes a mechanism that adds origin authentication, 111 message integrity, replay resistance, message sequencing, and 112 detection of missing messages to syslog. Essentially, this is 113 accomplished by sending a special syslog message. The contents of 114 this syslog message is called a Signature Block. Each Signature 115 Block contains, in effect, a detached signature on some number of 116 previously sent messages. It is cryptographically signed and 117 contains the hashes of previously sent syslog messages. 119 While most implementations of syslog involve only a single device as 120 the generator of each message and a single receiver as the collector 121 of each message, provisions need to be made to cover situations in 122 which messages are sent to multiple receivers. This concerns in 123 particular situations in which different messages are sent to 124 different receivers, meaning that some messages are sent to some 125 receivers but not to others. The required differentiation of 126 messages is generally performed based on the Priority value of the 127 individual messages. For example, messages from any Facility with a 128 Severity value of 3, 2, 1 or 0 may be sent to one collector while all 129 messages of Facilities 4, 10, 13, and 14 may be sent to another 130 collector. Appropriate syslog-sign messages must be kept with their 131 proper syslog messages. To address this, syslog-sign uses a 132 signature-group. A signature group identifies a group of messages 133 that are all kept together for signing purposes by the device. A 134 Signature Block always belongs to exactly one signature group and it 135 always signs messages belonging only to that signature group. 137 Additionally, a device will send a Certificate Block to provide key 138 management information between the sender and the receiver. This 139 Certificate Block has a field to denote the type of key material 140 which may be such things as a PKIX certificate, an OpenPGP 141 certificate, or even an indication that a key had been 142 predistributed. In the cases of certificates being sent, the 143 certificates may have to be split across multiple packets. 145 The receiver of the previous messages may verify that the digital 146 signature of each received message matches the signature contained in 147 the Signature Block. A collector may process these Signature Blocks 148 as they arrive, building an authenticated log file. Alternatively, 149 it may store all the log messages in the order they were received. 150 This allows a network operator to authenticate the log file at the 151 time the logs are reviewed. 153 This specification is independent of the actual transport protocol 154 selected. The best application of this mechanism will be to use it 155 with the syslog protocol as defined in RFC xxxx [23] as it utilizes 156 the STRUCTURED-DATA elements defined in that document. It may be 157 used with syslog packets over traditional UDP [4] as described in RFC 158 3164 [19]. It may also be used with the Reliable Delivery of syslog 159 as described in RFC 3195 [20], and it may be used with other message 160 delivery mechanisms. Other efforts to define event notification 161 messages should consider this specification in their design. 163 NOTE to RFC editor: replace xxxx with actual RFC number for this 164 document and remove this note 166 2. Conventions Used in this Document 168 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [18]. 172 3. syslog Message Format 174 This specification does not rely upon any specific syslog message 175 format. It is RECOMMENDED to be used within the syslog protocol as 176 defined in RFC xxxx [23]. It MAY be transported over a traditional 177 syslog message format such as that defined in the informational RFC 178 3164 [19], or it MAY be used over the Reliable Delivery of syslog 179 Messages as defined in RFC 3195 [20]. 181 Care must be taken when choosing a transport for this mechanism, 182 however. Since the device generating the Signature Block message 183 signs each message in its entirety, it is imperative that the 184 messages MUST NOT be changed in transit. It is equally imperative 185 that the syslog-sign messages MUST NOT be changed in transit. 186 Specifically, a relay as described in RFC 3164 MAY make changes to a 187 syslog packet if specific fields are not found. If this occurs, the 188 entire mechanism described in this document is rendered useless. 189 Likewise, any truncation of messages that occurs between sending and 190 receiving renders the mechanism useless. For this reason, syslog 191 sender and receiver implementations implementing this specification 192 MUST support messages of up to and including 2048 octets in length, 193 in order to minimize the chances of truncation from happening. 194 Likewise, while syslog sender and receiver implementations MAY 195 support messages with a length larger than 2048 octets, implementors 196 need to be aware that any message truncations that occur render the 197 mechanism useless. 199 For convenience, this document will use the syslog message format in 200 the terms described in RFC xxxx [23]. Along with the other fields, 201 that document describes the concept of STRUCTURED DATA (SD). 202 STRUCTURED DATA is defined in the form of SD ELEMENTS (SDEs). An SDE 203 consists of a name and a set of parameter name - value pairs. The 204 SDE name is referred to as SD-ID. The name-value pairs are referred 205 to as SD-PARAM, or SD Parameters, with the name constituting the SD- 206 PARAM-NAME, the value constituting the SD-PARAM-VALUE. The special 207 syslog messages that are defined in this document include definitions 208 of SDEs to convey parameters that relate to the signing of syslog 209 messages. 211 When used in conjunction with RFC xxxx [23], the syslog messages 212 defined in this document will carry the signature and certificate 213 data as STRUCTURED DATA, as defined, while the MSG part of the syslog 214 messages will simply be empty - the contents of the messages is not 215 intended for interpretation by humans but by applications that use 216 those messages to build an authenticated log. Having said that, as 217 stated above, the mechanism defined in this document should be 218 applicable to other message transports as well. When used in 219 conjunction with a syslog message format other than the one defined 220 in RFC xxxx [23], specifically, a syslog message format that does not 221 include STRUCTURED DATA, the format of the message payload will 222 simply happen to follow STRUCTURED DATA format. 224 4. Signature Blocks 226 This section describes the Signature Block format and the fields used 227 within the Signature Block, as well as the syslog messages used to 228 carry the Signature Block. 230 4.1. syslog Messages Containing a Signature Block 232 There is a need to distinguish the Signature Block itself from the 233 syslog message that is used to carry a Signature Block Signature 234 Blocks MUST be encompassed within completely formed syslog messages. 235 Syslog messages that contain a Signature Block are also referred to 236 as Signature Block messages. 238 A Signature Block message that is compliant with RFC xxxx [23] MUST 239 contain valid APP-NAME, PROCID, and MSGID fields. Specifically, as 240 value for APP-NAME, it is RECOMMENDED to use "syslog" (without the 241 double quotes). As value for MSG-ID, it is RECOMMENDED to use "sig" 242 (without the double quotes). As value for the PRI field, it is 243 RECOMMENDED to use 110, corresponding to facility 13 and severity 6 244 (informational). The Signature Block is carried as Structured Data 245 within the Signature Block message, per the definitions that follow 246 in the next section. 248 Similarly, when used with traditional syslog [19], the Signature 249 Block message SHOULD contain a valid TAG field. It is RECOMMENDED 250 that the TAG field have the value of "syslog" (without the double 251 quotes) to signify that this message was generated by the syslog 252 process. The Signature Block is carried as part of the MSG part, 253 whose syntax happens to follow structured data format per RFC xxxx 254 [23], as specified in the next section. 256 Again, note that all of those fields pertain to the syslog message 257 used to carry the Signature Block. They are not part of the 258 Signature Block itself. 260 4.2. Signature Block Format and Fields 262 The content of a Signature Block message is the Signature Block. The 263 Signature Block MUST be encoded as an SD ELEMENT, as defined in RFC 264 xxxx [23]. 266 The SD-ID must have the value of "ssign". 268 The SDE contains the fields of the Signature Block encoded as SD 269 Parameters, as specified in the following. The Signature Block is 270 composed of the following fields. The value of each field must be 271 printable ASCII, and any binary values are base 64 encoded, as 272 defined in RFC 3548 [22]. 274 Field SD-PARAM-NAME Size in bytes 275 ----- ------------- ---- -- ----- 277 Version VER 4 279 Reboot Session ID RSID 1-10 281 Signature Group SG 1 283 Signature Priority SPRI 1-3 285 Global Block Counter GBC 1-10 287 First Message Number FMN 1-10 289 Count CNT 1-2 291 Hash Block HB variable, size of hash 292 (base 64 encoded binary) 294 Signature SIGN variable 295 (base 64 encoded binary) 297 A Signature Block is accordingly encoded as follows (xxx denoting a 298 placeholder for the particular value: 300 "[ssign VER=xxx RSID=xxx SG=xxx SPRI=xxx GBC=xxx FMN=xxx CNT=xxx 301 HB=xxx SIGN=xxx]". 303 The fields are described below. 305 4.2.1. Version 307 The Signature Block version field is 4 characters in length and is 308 terminated with a space character. The value in this field specifies 309 the version of the syslog-sign protocol. This is extensible to allow 310 for different hash algorithms and signature schemes to be used in the 311 future. The value of this field is the grouping of the protocol 312 version (2 bytes), the hash algorithm (1 byte) and the signature 313 scheme (1 byte). 315 Protocol Version - 2 bytes with the first version as described in 316 this document being value of 01 to denote Version 1. 318 Hash Algorithm - 1 byte with the definition that 1 denotes SHA1 as 319 defined in FIPS-180-1.1995 [2]. 321 Signature Scheme - 1 byte with the definition that 1 denotes 322 OpenPGP DSA - RFC 2440 [9], FIPS.186-1.1998 [1]. 324 As such, the version, hash algorithm and signature scheme defined in 325 this document may be represented as "0111" (without the quote marks). 327 4.2.2. Reboot Session ID 329 The reboot session ID is a value that has a length between 1 and 10 330 bytes. The acceptable values for this are between 0 and 9999999999. 331 A reboot session ID is expected to increase whenever a device reboots 332 in order to allow receivers to uniquely distinguish messages and 333 message signatures across reboots. A device needs to hence support 334 persisting previous reboot session ID across reboots. In cases where 335 a device does not support this capability, the reboot session ID MUST 336 always be set to a value of 0, which indicates that this capability 337 is not supported. Otherwise, it MUST increase whenever a device 338 reboots, starting with a value of 1. If the value latches at 339 9999999999, then manual intervention may be required to reset it to 340 1. Implementors MAY wish to consider using the snmpEngineBoots value 341 as a source for this counter as defined in RFC 3414 [10]. 343 4.2.3. Signature Group and Signature Priority 345 The SG identifier may take on any value from 0-3 inclusive. The SPRI 346 may take on any value from 0-191 inclusive. These fields taken 347 together allow network administrators to associate groupings of 348 syslog messages with appropriate Signature Blocks and Certificate 349 Blocks. Groupings of syslog messages that are signed together are 350 also referred to as signature groups. A Signature Block will contain 351 only hashes of those syslog messages that are part of the same 352 signature group. 354 For example, in some cases, network administrators may send syslog 355 messages of Facilities 0 through 15 to one destination while sending 356 messages with Facilities 16 through 23 to another. In such cases, 357 associated Signature Blocks should likely be sent to these different 358 syslog servers as well, signing the syslog messages that are intended 359 for each destination separately. This way, each syslog destination 360 is able to receive Signature Blocks for all syslog messages that it 361 receives, and only for those. The ability to to associate different 362 categories of syslog messages with different signature groups, signed 363 in separate Signature Blocks, provides administrators with 364 flexibility to that regard. 366 Syslog-sign provides four options for handling signature groups, 367 linking them with PRI values so they may be routed to the destination 368 commensurate with the appropriate syslog messages. In all cases, no 369 more than 192 distinct signature groups (0-191) are permitted. 371 The signature group that a Signature Block pertains to is indicated 372 by the signature priority (SPRI) field. The signature group (SG) 373 field indicates how to interpret the signature priority field. Note 374 that the SG field does not indicate the signature group, as its name 375 may suggest. The SG field can have one of the following values: 377 a. '0' -- There is only one signature group. In this case, the 378 administrators want all Signature Blocks to be sent to a single 379 destination; in all likelihood, all of the syslog messages will 380 also be going to that same destination. Signature Blocks sign 381 all messages regardless of their PRI value. This means that in 382 effect, the Signature Block's SPRI value can be ignored. 383 However, it is RECOMMENDED that a single SPRI value is used for 384 all Signature Blocks. Furthermore, it is RECOMMENDED to use the 385 same value that is used for the PRI field of the Signature Block 386 message, so that the PRI of the Signature Block message matches 387 the SPRI of the Signature Block that it contains. 389 b. '1' -- Each PRI value is associated with its own signature group. 390 Signature Blocks for a given signature group have SPRI = PRI for 391 that signature group. In other words, the SPRI of the Signature 392 Block matches the PRI value of the syslog messages that are part 393 of the signature group and hence signed by the Signature Block. 394 An SG value of 1 can for example be used when the administrator 395 of a device does not know where any of the syslog messages will 396 ultimately go but anticipates that messages with different PRI 397 values will be collected and processed separately. Having a 398 signature group per PRI value provides administrators with a 399 large degree of flexibility with regards to how to divide up the 400 processing syslog messages and their signatures after they are 401 received. 403 c. '2' -- Each signature group contains a range of PRI values. 404 Signature groups are assigned sequentially. A Signature Block 405 for a given signature group has its own SPRI value denoting the 406 highest PRI value of syslog messages in that signature group. 407 The lowest PRI value of syslog messages in that signature group 408 will be one larger than the SPRI value of the next signature 409 group or "0" in case there is no other signature group with a 410 lower SPRI value. The specific signature groups and ranges they 411 are associated with are subject to configuration by a system 412 administrator. 414 d. '3' -- Signature groups are not assigned with any simple or even 415 fixed relationship to PRI values of the syslog messages they 416 sign. This has to be some predefined arrangement between the 417 sender and the intended receivers as to which syslog messages are 418 to be included in which signature group, requiring configuration 419 by a system administrator. This provides administrators with the 420 flexibility to group syslog messages into signature groups along 421 criteria that are not directly tied to the PRI value. 423 One reasonable way to configure some installations is to have only 424 one signature group, indicated with SG=0, and have the device send a 425 copy of each Signature Block to each collector. In that case, 426 collectors that are not configured to receive every syslog message 427 will still receive signatures for every message, even ones they are 428 not supposed to receive. While the collector will not be able to 429 detect gaps in the messages (because the presence of a signature does 430 not tell the collector whether or not the corresponding message would 431 be of the collector's concern), it does allow all messages that do 432 arrive at each collector to be put into the right order and to be 433 verified. It also allows each collector to detect duplicates. 435 4.2.4. Global Block Counter 437 The global block counter is a value representing the number of 438 Signature Blocks sent out by syslog-sign before this one, in this 439 reboot session. This takes at least 1 byte and at most 10 bytes 440 displayed as a decimal counter and the acceptable values for this are 441 between 0 and 9999999999. If the value latches at 9999999999, then 442 the reboot session counter must be incremented by 1 and the global 443 block counter resumes at 0. Note that this counter crosses signature 444 groups; it allows us to roughly synchronize when two messages were 445 sent, even though they went to different collectors. 447 In case a device does not support an incrementing reboot session ID 448 (that is, the value of the reboot session ID is 0), a device MAY 449 reset the global block counter to 0 after a reboot occurs. Note that 450 in this case, applications need to apply extra consideration when 451 authenticating a log, and situations in which reboots occur 452 frequently may result in losing the ability to verify the proper 453 sequence in which messages were sent and hence jeopardizing integrity 454 of the log. 456 4.2.5. First Message Number 458 This is a value between 1 and 10 bytes. It contains the unique 459 message number within this signature group of the first message whose 460 hash appears in this block. The very first message of the reboot 461 session will be numbered "1". 463 For example, if this signature group has processed 1000 messages so 464 far and message number 1001 is the first message whose hash appears 465 in this Signature Block, then this field contains 1001. 467 4.2.6. Count 469 The count is a 1 or 2 byte field displaying the number of message 470 hashes to follow. The valid values for this field are between 1 and 471 99. Note that the number of hashes that are included in the 472 Signature Block MUST be chosen such that the length of the resulting 473 syslog message does not exceed the maximum permissable syslog message 474 length. 476 4.2.7. Hash Block 478 The hash block is a block of hashes, each separately encoded in base 479 64. Each hash in the hash block is the hash of the entire syslog 480 message represented by the hash, independent of the underlying 481 transport. Hashes are ordered from left to right in the order of 482 occurrence of the syslog messages that they represent. 484 With RFC xxxx [23], the "entire syslog message" refers to what is 485 described as the syslog message excluding transport parts that are 486 described in RFC xxxx [24] and RFC xxxx [25], and excluding other 487 parts that may be defined in future transports. The hash value will 488 be the result of the hashing algorithm run across the syslog message, 489 starting with the < of the PRI portion of the header part of the 490 message and ending with the Unicode byte order mask, BOM. The 491 hashing algorithm used effectively specified by the Version field 492 determines the size of each hash, but the size MUST NOT be shorter 493 than 160 bits. It is base 64 encoded as per RFC 2045. 495 Analogously, with syslog messages per RFC 3164 [19], the "entire 496 syslog message" refers to the message starting with the < of the PRI 497 portion of the header part of the message and ending with the 498 character preceding the < of the subsequent message, and the hashing 499 algoritm is applied accordingly. 501 The number of hashes in a hash block SHOULD be chosen such that the 502 resulting Signature Block message does not exceed a length of 2048 503 octets. When more more hashes need to sent than fit inside a 504 Signature Block message, it is advisable to start a new Signature 505 Block. 507 4.2.8. Signature 509 This is a digital signature, encoded in base 64 per RFC 3548 [22]. 510 The signature is calculated over all fields but excludes the space 511 characters between them. The Version field effectively specifies the 512 original encoding of the signature. The signature is a signature 513 over the entire data, including all of the PRI, HEADER, and hashes in 514 the hash block. To reiterate, the signature is calculated over the 515 completely formatted syslog-message, excluding spaces between fields, 516 and also excluding this signature field (the value of the signature 517 SD Parameter). 519 5. Payload and Certificate Blocks 521 Certificate Blocks and Payload Blocks provide key management in 522 syslog-sign. Their purpose is to support key management using public 523 key cryptosystems. 525 5.1. Preliminaries: Key Management and Distribution Issues 527 A Payload Block contains public key certificate information that is 528 to be conveyed to the receiver. A Payload Block is not sent 529 directly, but in (one or more) fragments. Those fragments are termed 530 Certificate Blocks. All devices send at least one Certificate Block 531 at the beginning of a new reboot session, carrying public key 532 information that is to be in effect for the reboot session. 534 There are three key points to understand about Certificate Blocks: 536 a. They handle a variable-sized payload, fragmenting it if necessary 537 and transmitting the fragments as legal syslog messages. This 538 payload is built (as described below) at the beginning of a 539 reboot session and is transmitted in pieces with each Certificate 540 Block carrying a piece. Note that there is exactly one Payload 541 Block per reboot session. 543 b. The Certificate Blocks are digitally signed. The device does not 544 sign the Payload Block, but the signatures on the Certificate 545 Blocks ensure its authenticity. Note that it may not even be 546 possible to verify the signature on the Certificate Blocks 547 without the information in the Payload Block; in this case the 548 Payload Block is reconstructed, the key is extracted, and then 549 the Certificate Blocks are verified. (This is necessary even 550 when the Payload Block carries a certificate, since some other 551 fields of the Payload Block aren't otherwise verified.) In 552 practice, most installations keep the same public key over long 553 periods of time, so that most of the time, it's easy to verify 554 the signatures on the Certificate Blocks, and use the Payload 555 Block to provide other useful per-session information. 557 c. The kind of Payload Block that is expected is determined by what 558 kind of key material is on the collector that receives it. The 559 device and collector (or offline log viewer) has both some key 560 material (such as a root public key, or predistributed public 561 key), and an acceptable value for the Key Blob Type in the 562 Payload Block, below. The collector or offline log viewer MUST 563 NOT accept a Payload Block of the wrong type. 565 5.2. Payload Block 567 The Payload Block is built when a new reboot session is started. 568 There is a one-to-one correspondence of reboot sessions to Payload 569 Blocks. That is, each reboot session has only one Payload Block, 570 regardless of how many signature groups it may support. A Payload 571 Block MUST have the following fields. Each of these fields are 572 separated by a single space character. (Note that because a Payload 573 Block is not carried in a syslog message directly, only the 574 corresponding Certificate Blocks, it does not need to be encoded as 575 an SD ELEMENT.) 577 a. Unique identifier of sender; by default, the sender's IP address 578 in dotted-decimal (IPv4) or colon-separated (IPv6) notation. 580 b. Full local time stamp for the device at the time the reboot 581 session started. This must be in TIMESTAMP-3339 format. 583 c. Key Blob Type, a one-byte field which holds one of five values: 585 1. 'C' -- a PKIX certificate. 587 2. 'P' -- an OpenPGP certificate. 589 3. 'K' -- the public key whose corresponding private key is 590 being used to sign these messages. 592 4. 'N' -- no key information sent; key is predistributed. 594 5. 'U' -- installation-specific key exchange information 596 d. The key blob, if any, base 64 encoded per RFC 3548 [22] and 597 consisting of the raw key data. 599 5.3. Certificate Block 601 The Certificate Block must get the Payload Block to the collector. 602 The Certificate Block itself needs to be distinguished from the 603 syslog message that carries it, refererred to as a Certificate Block 604 message. 606 Since certificates can legitimately be much longer than 2048 bytes, 607 each Certificate Block carries a piece of the Payload Block. Note 608 that the device MAY make the Certificate Blocks of any legal length 609 (that is, any length less than 2048 bytes) which holds all the 610 required fields. Software that processes Certificate Blocks MUST 611 deal correctly with blocks of any legal length. The length of the 612 piece of the Payload Block that a Certificate Block is to carry 613 SHOULD be chosen such that the length of the Certificate Block 614 message does not exceed 2048 octets. 616 5.3.1. syslog Messages Containing a Certificate Block 618 Like a Signature Block, the Certificate Block is carried in its own 619 syslog message, referred to as a Certificate Block message. 621 When used with RFC xxxx [23], the Certificate Block message MUST 622 contain valid APP-NAME, PROCID, and MSGID fields. Specifically, as 623 value for APP-NAME, it is RECOMMENDED to use "syslog" (without the 624 double quotes). As value for MSG-ID, it is RECOMMENDED to use "cert" 625 (without the double quotes). As value for the the PRI field, it is 626 RECOMMENDED to use the value 110, corresponding to facility 13 and 627 severity 6 (informational). The Certificate Block is carried as 628 Structured Data within the Certificate Block message, per the 629 definitions that follow in the next section. 631 Similarly, when used with traditional syslog [19], the Certificate 632 Block message SHOULD contain a valid TAG field. It is RECOMMENDED 633 that the TAG field have the value of "syslog" (without the double 634 quotes) to signify that this message was generated by the syslog 635 process. The Certificate Block is carried as part of the MSG part, 636 whose syntax happens to follow structured data format per RFC xxxx 637 [23], as specified in the next section. 639 Again, note that all of those fields pertain to the syslog message 640 used to carry the Certificate Block. They are not part of the 641 Signature Block itself. 643 5.3.2. Certificate Block Format and Fields 645 The contents of a Certificate Block message is the Certificate Block 646 itself. Like a Signature Block, the Certificate Block is encoded as 647 an SD Element per RFC xxxx [23]. The SD-ID of the Certificate Block 648 is "ssign-cert". The Certificate Block is composed of the following 649 fields, each of which is encoded as an SD Parameter with parameter 650 name as indicated. Each field must be printable ASCII, and any 651 binary values are base 64 encoded. 653 Field SD-PARAM-NAME Size in bytes 654 ----- ------------- ---- -- ----- 656 Version VER 4 658 Reboot Session ID RSID 1-10 660 Signature Group SG 1 662 Signature Priority SPRI 1-3 664 Total Payload Block Length TPBL 1-8 666 Index into Payload Block INDEX 1-8 668 Fragment Length FLEN 1-3 670 Payload Block Fragment FRAG variable 671 (base 64 encoded binary) 673 Signature SIGN variable 674 (base 64 encoded binary) 676 A Certificate Block is accordingly encoded as follows (xxx denoting a 677 placeholder for the particular value: 679 "[ssign-cert VER=xxx RSID=xxx SG=xxx SPRI=xxx TBPL=xxx INDEX=xxx 680 FLEN=xxx FRAG=xxx SIGN=xxx]". 682 The fields will be explained below. 684 5.3.2.1. Version 686 The signature group version field is 4 characters in length and is 687 terminated with a space character. This field is identical in nature 688 to the Version field described in Section 4.2.1. As such, the 689 version, hash algorithm and signature scheme defined in this document 690 may be represented as "0111" (without the quote marks). 692 5.3.2.2. Reboot Session ID 694 The Reboot Session ID is identical in characteristics to the RSID 695 field described in Section 4.2.2. 697 5.3.2.3. Signature Group and Signature Priority 699 The SIG field is identical in characteristics to the SIG field 700 described in Section 4.2.8. Also, the SPRI field is identical to the 701 SPRI field described there. 703 5.3.2.4. Total Payload Block Length 705 The Total Payload Block Length is a value representing the total 706 length of the Payload Block in bytes in decimal. This will be one to 707 eight bytes. 709 5.3.2.5. Index into Payload Block 711 This is a value between 1 and 8 bytes. It contains the number of 712 bytes into the Payload Block where this fragment starts. The first 713 byte of the first fragment is numbered "1". 715 5.3.2.6. Fragment Length 717 The total length of this fragment expressed as a decimal integer. 718 This will be one to three bytes. 720 5.3.2.7. Signature 722 This is a digital signature, encoded in base 64, as per RFC 2045. 723 The signature is calculated over all fields but excludes the space 724 characters between them. The Version field effectively specifies the 725 original encoding of the signature. The signature is a signature 726 over the entire data, including all of the PRI, HEADER, and hashes in 727 the hash block. This is consistent with the method of calculating 728 the signature as specified in Section 4.2.8. To reiterate, the 729 signature is calculated over the completely formatted syslog-message, 730 excluding spaces between fields, and also excluding this signature 731 field. 733 6. Redundancy and Flexibility 735 There is a general rule that determines how redundancy works and what 736 level of flexibility the device and collector have in message 737 formats: in general, the device is allowed to send Signature and 738 Certificate Blocks multiple times, to send Signature and Certificate 739 Blocks of any legal length, to include fewer hashes in hash blocks, 740 etc. 742 6.1. Redundancy 744 Syslog messages are sent over unreliable transport, which means that 745 they can be lost in transit. However, the collector must receive 746 Signature and Certificate Blocks or many messages may not be able to 747 be verified. Sending Signature and Certificate Blocks multiple times 748 provides redundancy; since the collector MUST ignore Signature/ 749 Certificate Blocks it has already received and authenticated, the 750 device can in principle change its redundancy level for any reason, 751 without communicating this fact to the collector. 753 Although the device isn't constrained in how it decides to send 754 redundant Signature and Certificate Blocks, or even in whether it 755 decides to send along multiple copies of normal syslog messages, here 756 we define some redundancy parameters below which may be useful in 757 controlling redundant transmission from the device to the collector, 758 and which may be useful for administrators to configure. 760 6.1.1. Configuration Parameters for Certificate Blocks 762 certInitialRepeat = number of times each Certificate Block should be 763 sent before the first message is sent. 765 certResendDelay = maximum time delay in seconds to delay before next 766 redundant sending. 768 certResendCount = maximum number of sent messages to delay before 769 next redundant sending. 771 6.1.2. Configuration Parameters for Signature Blocks 773 sigNumberResends = number of times a Signature Block is resent. 775 sigResendDelay = maximum time delay in seconds from original sending 776 to next redundant sending. 778 sigResendCount = maximum number of sent messages to delay before next 779 redundant sending. 781 6.2. Flexibility 783 The device may change many things about the makeup of Signature and 784 Certificate Blocks in a given reboot session. The things it cannot 785 change are: 787 * The version 789 * The number or arrangements of signature groups 791 It is legitimate for a device to send out short Signature Blocks, in 792 order to keep the collector able to verify messages quickly. In 793 general, unless something verified by the Payload Block or 794 Certificate Blocks is changed within the reboot session ID, any 795 change is allowed to the Signature or Certificate Blocks during the 796 session. 798 7. Efficient Verification of Logs 800 The logs secured with syslog-sign may either be reviewed online or 801 offline. Online review is somewhat more complicated and 802 computationally expensive, but not prohibitively so. 804 7.1. Offline Review of Logs 806 When the collector stores logs and reviewed later, they can be 807 authenticated offline just before they are reviewed. Reviewing these 808 logs offline is simple and relatively cheap in terms of resources 809 used, so long as there is enough space available on the reviewing 810 machine. Here, we consider that the stored log files have already 811 been separated by sender, reboot session ID, and signature group. 812 This can be done very easily with a script file. We then do the 813 following: 815 a. First, we go through the raw log file, and split its contents 816 into three files. Each message in the raw log file is classified 817 as a normal message, a Signature Block, or a Certificate Block. 818 Certificate Blocks and Signature Blocks are stored in their own 819 files. Normal messages are stored in a keyed file, indexed on 820 their hash values. 822 b. We sort the Certificate Block file by index value, and check to 823 see if we have a set of Certificate Blocks that can reconstruct 824 the Payload Block. If so, we reconstruct the Payload Block, 825 verify any key-identifying information, and then use this to 826 verify the signatures on the Certificate Blocks we've received. 827 When this is done, we have verified the reboot session and key 828 used for the rest of the process. 830 c. We sort the Signature Block file by firstMessageNumber. We now 831 create an authenticated log file, which consists of some header 832 information, and then a sequence of message number, message text 833 pairs. We next go through the Signature Block file. For each 834 Signature Block in the file, we do the following: 836 1. Verify the signature on the Block. 838 2. For each hashed message in the Block: 840 a. Look up the hash value in the keyed message file. 842 b. If the message is found, write (message number, message 843 text) to the authenticated log file. 845 3. Skip all other Signature Blocks with the same 846 firstMessageNumber. 848 d. The resulting authenticated log file contains all messages that 849 have been authenticated, and implicitly indicates (by missing 850 message numbers) all gaps in the authenticated messages. 852 It's pretty easy to see that, assuming sufficient space for building 853 the keyed file, this whole process is linear in the number of 854 messages (generally two seeks, one to write and the other to read, 855 per normal message received), and O(N lg N) in the number of 856 Signature Blocks. This estimate comes with two caveats: first, the 857 Signature Blocks arrive very nearly in sorted order, and so can 858 probably be sorted more cheaply on average than O(N lg N) steps. 859 Second, the signature verification on each Signature Block almost 860 certainly is more expensive than the sorting step in practice. We 861 haven't discussed error-recovery, which may be necessary for the 862 Certificate Blocks. In practice, a very simple error-recovery 863 strategy is probably good enough -- if the Payload Block doesn't come 864 out as valid, then we can just try an alternate instance of each 865 Certificate Block, if such are available, until we get the Payload 866 Block right. 868 It's easy for an attacker to flood us with plausible-looking 869 messages, Signature Blocks, and Certificate Blocks. 871 7.2. Online Review of Logs 873 Some processes on the collector machine may need to monitor log 874 messages in something very close to real-time. This can be done with 875 syslog-sign, though it is somewhat more complex than the offline 876 analysis. This is done as follows: 878 a. We have an output queue, into which we write (message number, 879 message text) pairs which have been authenticated. Again, we'll 880 assume we're handling only one signature group, and only one 881 reboot session ID, at any given time. 883 b. We have three data structures: A queue into which (message 884 number, hash of message) pairs is kept in sorted order, a queue 885 into which (arrival sequence, hash of message) is kept in sorted 886 order, and a hash table which stores (message text, count) 887 indexed by hash value. In this file, count may be any number 888 greater than zero; when count is zero, the entry in the hash 889 table is cleared. 891 c. We must receive all the Certificate Blocks before any other 892 processing can really be done. (This is why they're sent first.) 893 Once that's done, any Certificate Block that arrives is 894 discarded. 896 d. Whenever a normal message arrives, we add (arrival sequence, hash 897 of message) to our message queue. If our hash table has an entry 898 for the message's hash value, we increment its count by one; 899 otherwise, we create a new entry with count = 1. When the 900 message queue is full, we roll the oldest messages off the queue 901 by taking the last entry in the queue, and using it to index the 902 hash table. If that entry has count is 1, we delete the entry in 903 the hash table; otherwise, we decrement its count. We then 904 delete the last entry in the queue. 906 e. Whenever a Signature Block arrives, we first check to see if the 907 firstMessageNumber value is too old, or if another Signature 908 Block with that firstMessageNumber has already been received. If 909 so, we discard the Signature Block unread. Otherwise, we check 910 its signature, and discard it if the signature isn't valid. A 911 Signature Block contains a sequence of (message number, message 912 hash) pairs. For each pair, we first check to see if the message 913 hash is in the hash table. If so, we write out the (message 914 number, message text) in the authenticated message queue. 915 Otherwise, we write the (message number, message hash) to the 916 message number queue. This generally involves rolling the oldest 917 entry out of this queue: before this is done, that entry's hash 918 value is again searched for in the hash table. If a matching 919 entry is found, the (message number, message text) pair is 920 written out to the authenticated message queue. In either case, 921 the oldest entry is then discarded. 923 f. The result of this is a sequence of messages in the authenticated 924 message queue, each of which has been authenticated, and which 925 are combined with numbers showing their order of original 926 transmission. 928 It's not too hard to see that this whole process is roughly linear in 929 the number of messages, and also in the number of Signature Blocks 930 received. The process is susceptible to flooding attacks; an 931 attacker can send enough normal messages that the messages roll off 932 their queue before their Signature Blocks can be processed. 934 8. Security Considerations 936 Normal syslog event messages are unsigned and have most of the 937 security attributes described in Section 6 of RFC 3164. This 938 document also describes Certificate Blocks and Signature Blocks which 939 are signed syslog messages. The Signature Blocks contains signature 940 information of previously sent syslog event messages. All of this 941 information may be used to authenticate syslog messages and to 942 minimize or obviate many of the security concerns described in RFC 943 3164. 945 8.1. Cryptography Constraints 947 As with any technology involving cryptography, you should check the 948 current literature to determine if any algorithms used here have been 949 found to be vulnerable to attack. 951 This specification uses Public Key Cryptography technologies. The 952 proper party or parties must control the private key portion of a 953 public-private key pair. Any party that controls a private key may 954 sign anything they please. 956 Certain operations in this specification involve the use of random 957 numbers. An appropriate entropy source should be used to generate 958 these numbers. See RFC 1750 [15]. 960 8.2. Packet Parameters 962 The message length must not exceed 1024 bytes. Various problems may 963 result if a device sends out messages with a length greater than 1024 964 bytes. As seen in RFC 3164, relays MAY truncate messages with 965 lengths greater than 1024 bytes which would result in a problem for 966 receivers trying to validate a hash of the packet. In this case, as 967 with all others, it is best to be conservative with what you send but 968 liberal in what you receive, and accept more than 1024 bytes. 970 Similarly, senders must rigidly enforce the correctness of the 971 message body. This document specifies an enhancement to the syslog 972 protocol but does not stipulate any specific syslog message format. 973 Nonetheless, problems may arise if the receiver does not fully accept 974 the syslog packets sent from a device, or if it has problems with the 975 format of the Certificate Block or Signature Block messages. 977 Finally, receivers must not malfunction if they receive syslog 978 messages containing characters other than those specified in this 979 document. 981 8.3. Message Authenticity 983 Event messages being sent through syslog do not strongly associate 984 the message with the message sender. That fact is established by the 985 receiver upon verification of the Signature Block as described above. 986 Before a Signature Block is used to ascertain the authenticity of an 987 event message, it may be received, stored and reviewed by a person or 988 automated parser. Both of these should maintain doubt about the 989 authenticity of the message until after it has been validated by 990 checking the contents of the Signature Block. 992 With the Signature Block checking, an attacker may only forge 993 messages if they can compromise the private key of the true sender. 995 8.4. Sequenced Delivery 997 Event messages may be recorded and replayed by an attacker. However 998 the information contained in the Signature Blocks allows a reviewer 999 to determine if the received messages are the ones originally sent by 1000 a device. This process also alerts the reviewer to replayed 1001 messages. 1003 8.5. Replaying 1005 Event messages may be recorded and replayed by an attacker. However 1006 the information contained in the Signature Blocks will allow a 1007 reviewer to determine if the received messages are the ones 1008 originally sent by a device. This process will also alert the 1009 reviewer to replayed messages. 1011 8.6. Reliable Delivery 1013 RFC 3195 may be used for the reliable delivery of all syslog 1014 messages. This document acknowledges that event messages sent over 1015 UDP may be lost in transit. A proper review of the Signature Block 1016 information may pinpoint any messages sent by the sender but not 1017 received by the receiver. The overlap of information in subsequent 1018 Signature Block information allows a reviewer to determine if any 1019 Signature Block messages were also lost in transit. 1021 8.7. Sequenced Delivery 1023 Related to the above, syslog messages delivered over UDP not only may 1024 be lost, but they may arrive out of sequence. The information 1025 contained in the Signature Block allows a receiver to correctly order 1026 the event messages. Beyond that, the timestamp information contained 1027 in the packet may help the reviewer to visually order received 1028 messages even if they are received out of order. 1030 8.8. Message Integrity 1032 syslog messages may be damaged in transit. A review of the 1033 information in the Signature Block determines if the received message 1034 was the intended message sent by the sender. A damaged Signature 1035 Block or Certificate Block will be evident since the receiver will 1036 not be able to validate that it was signed by the sender. 1038 8.9. Message Observation 1040 Event messages, Certificate Blocks and Signature Blocks are all sent 1041 in plaintext. Generally this has had the benefit of allowing network 1042 administrators to read the message when sniffing the wire. However, 1043 this also allows an attacker to see the contents of event messages 1044 and perhaps to use that information for malicious purposes. 1046 8.10. Man In The Middle 1048 It is conceivable that an attacker may intercept Certificate Blocks 1049 and insert their own Certificate information. In that case, the 1050 attacker would be able to receive event messages from the actual 1051 sender and then relay modified messages, insert new messages, or 1052 deleted messages. They would then be able to construct a Signature 1053 Block and sign it with their own private key. The network 1054 administrators should verify that the key contained in the 1055 Certificate Block is indeed the key being used on the actual device. 1056 If that is indeed the case, then this MITM attack will not succeed. 1058 8.11. Denial of Service 1060 An attacker may be able to overwhelm a receiver by sending it invalid 1061 Signature Block messages. If the receiver is attempting to process 1062 these messages online, it may consume all available resources. For 1063 this reason, it may be appropriate to just receive the Signature 1064 Block messages and process them as time permits. 1066 As with any system, an attacker may also just overwhelm a receiver by 1067 sending more messages to it than can be handled by the infrastructure 1068 or the device itself. Implementors should attempt to provide 1069 features that minimize this threat. Such as only receiving syslog 1070 messages from known IP addresses. 1072 8.12. Covert Channels 1074 Nothing in this protocol attempts to eliminate covert channels. 1075 Indeed, the unformatted message syntax in the packets could be very 1076 amenable to sending embedded secret messages. In fact, just about 1077 every aspect of syslog messages lends itself to the conveyance of 1078 covert signals. For example, a collusionist could send odd and even 1079 PRI values to indicate Morse Code dashes and dots. 1081 9. IANA Considerations 1083 9.1. Structured data and syslog messages 1085 This document specifies two syslog message types to carry Signature 1086 Blocks and Certificate Blocks, respectively: the Signature Block 1087 message and the Certificate Block message. Each of these has values 1088 for several syslog message fields specified that need to be 1089 controlled by the IANA. 1091 Specifically, with regards to RFC xxxx [23], IANA is instructed to 1092 add the following Structured Data Elements to the appropriate 1093 registry, consisting of SD-ID and and PARAM-NAME values as follows: 1095 SD-ID "ssign" (without the double quotes), with the associated PARAM- 1096 NAME values: VER, RSID, SG, SPRI, GBC, FMN, CNT, HB, SIGN 1098 SD-ID "ssign-cert" (without the double quotes), with the associated 1099 PARAM-NAME values: VER, RSID, SG, SPRI, TBPL, INDEX, FLEN, FRAG, SIGN 1101 In addition, IANA is instructed to add values for the APP-NAME and 1102 MSGID of syslog messages per RFC xxxx [23] to an appropriate 1103 registry, as follows: 1105 APP-NAME field: value "syslog" (without the double quotes), with the 1106 following values for MSGID fields: "sig", "cert" (without the double 1107 quotes) 1109 This document also upholds the Facilities and Severities listed in 1110 RFC xxxx [23]. Those values range from 0 to 191. This document also 1111 instructs the IANA to reserve all other possible values of the 1112 Severities and Facilities above the value of 191 and to distribute 1113 them via the consensus process as defined in RFC 2434 [8]. 1115 In addition, several fields need to be controlled by the IANA in both 1116 the Signature Block and the Certificate Block, as outlined in the 1117 following sections. 1119 9.2. Version Field 1121 The Version field (Ver) is a 4 byte field. The first two bytes of 1122 this field define the version of the Signature Block packets and the 1123 Certificate Block Packets. This allows for future efforts to 1124 redefine the subsequent fields in the Signature Block packets and 1125 Certificate Block packets. A value of "00" is reserved and not used. 1126 This document describes the fields for the version value of "01". It 1127 is expected that this value be incremented monotonically with decimal 1128 values up through "50" for IANA assigned values. Values "02" through 1129 "50" will be assigned by the IANA using the "IETF Consensus" policy 1130 defined in RFC 2434 [8]. It is not anticipated that these values 1131 will be reused. Values of "51" through "99" will be vendor-specific, 1132 and values in this range are not to be assigned by the IANA. 1134 In the case of vendor-specific assigned Version numbers, all 1135 subsequent values defined in the packet will then have vendor- 1136 specific meaning. They may, or may not, align with the values 1137 assigned by the IANA for these fields. For example, a vendor may 1138 choose to define their own Version of "51" still containing values of 1139 "1" for the Hash Algorithm and Signature Scheme which aligns with the 1140 IANA assigned values as defined in this document. However, they may 1141 then choose to define a value of "5" for the Signature Group for 1142 their own reasons. 1144 The third byte of the Ver field defines the Hash Algorithm. It is 1145 envisioned that this will also be a monotonically increasing value 1146 with a maximum value of "9". The value of "1" is defined in this 1147 document as the first assigned value and is SHA1 FIPS-180-1.1995 [2]. 1148 Subsequent values will be assigned by the IANA using the "IETF 1149 Consensus" policy defined in RFC 2434 [8]. 1151 The forth and final byte of the Ver field defines the Signature 1152 Scheme. It is envisioned that this too will be a monotonically 1153 increasing value with a maximum value of "9". The value of "1" is 1154 defined in this document as OpenPGP DSA - RFC 2440 [9], FIPS.186- 1155 1.1998 [1]. Subsequent values will be assigned by the IANA using the 1156 "IETF Consensus" policy defined in RFC 2434 [8]. The fields, values 1157 assigned in this document and ranges are illustrated in the following 1158 table. 1160 Field Value Defined IANA Assigned Vendor Specific 1161 in this Document Range Range 1162 ----- ---------------- ------------- --------------- 1163 Ver 1164 ver 01 01-50 50-99 1165 hash 1 0-9 -none- 1166 sig 1 0-9 -none- 1168 If either the Hash Algorithm field or the Signature Scheme field is 1169 needed to go beyond "9" within the current version (first two bytes), 1170 the IANA should increment the first two bytes of this 4 byte field to 1171 be the next value with the definition that all of the subsequent 1172 values of fields described in this section are reset to "0" while 1173 retaining the latest definitions given by the IANA. For example, 1174 consider the case that the first two characters are "23" and the 1175 latest Signature Algorithm is 4. Let's say that the latest Hash 1176 Algorithm value is "9" but a better Hash Algorithm is defined. In 1177 that case, the IANA will increment the first two bytes to become 1178 "24", retain the current Hash Algorithm to be "0", define the new 1179 Hash Algorithm to be "1" in this scheme, and define the current 1180 Signature Scheme to also be "0". This example is illustrated in the 1181 following table. 1183 Current New - Equivalent New with Later 1184 to "Current" Algorithms 1185 ------- -------------- --------------- 1186 ver = 23 ver = 24 ver = 24 1187 hash = 9 hash = 0 hash = 1 1188 sig = 4 sig = 0 sig = 0 1190 9.3. SG Field 1192 The SG field values are numbers as defined in Section 4.2.3. Values 1193 "0" through "3" are assigned in this document. The IANA shall assign 1194 values "4" through "7" using the "IETF Consensus" policy defined in 1195 RFC 2434 [8]. Values "8" and "9" shall be left as vendor specific 1196 and shall not be assigned by the IANA. 1198 9.4. Key Blob Type 1200 Section Section 5.2 defines five, one character identifiers for the 1201 key blob type. These are the uppercase letters, "C", "P", "K", "N", 1202 and "U". All other uppercase letters shall be assigned by the IANA 1203 using the "IETF Consensus" policy defined in RFC 2434 [8]. Lowercase 1204 letters are left as vendor specific and shall not be assigned by the 1205 IANA. 1207 10. Authors and Working Group Chairs 1209 Comments are solicited and should be addressed to the working group's 1210 mailing list and/or the authors. 1212 The working group can be contacted via the mailing list: 1214 syslog-sec@employees.org 1216 The current Chairs of the Working Group may be contacted at: 1218 Chris Lonvick 1219 Cisco Systems 1220 Email: clonvick@cisco.com 1222 David Harrington 1223 Huawei Technologies (USA) 1224 Email: ietfdbh@comcast.net 1225 dharrington@huawei.com 1226 Tel: +1-603-436-8634 1228 The authors of this draft are: 1230 John Kelsey 1231 Email: kelsey.j@ix.netcom.com 1233 Jon Callas 1234 Email: jon@callas.org 1236 Alexander Clemm 1237 Email: alex@cisco.com 1239 11. Acknowledgements 1241 The authors wish to thank Alex Brown, Chris Calabrese, Carson Gaspar, 1242 Drew Gross, Chris Lonvick, Darrin New, Marshall Rose, Holt Sorenson, 1243 Rodney Thayer, Andrew Ross, Rainer Gerhards, Albert Mietus, and the 1244 many Counterpane Internet Security engineering and operations people 1245 who commented on various versions of this proposal. 1247 12. References 1249 12.1. Normative References 1251 [1] National Institute of Standards and Technology, "Digital 1252 Signature Standard", FIPS PUB 186-1, December 1998, 1253 . 1255 [2] National Institute of Standards and Technology, "Secure Hash 1256 Standard", FIPS PUB 180-1, April 1995, 1257 . 1259 [3] American National Standards Institute, "USA Code for 1260 Information Interchange", ANSI X3.4, 1968. 1262 [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1263 August 1980. 1265 [5] Mockapetris, P., "Domain names - concepts and facilities", 1266 STD 13, RFC 1034, November 1987. 1268 [6] Mockapetris, P., "Domain names - implementation and 1269 specification", STD 13, RFC 1035, November 1987. 1271 [7] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with 1272 Replay Prevention", RFC 2085, February 1997. 1274 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1275 Considerations Section in RFCs", BCP 26, RFC 2434, 1276 October 1998. 1278 [9] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1279 "OpenPGP Message Format", RFC 2440, November 1998. 1281 [10] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 1282 for version 3 of the Simple Network Management Protocol 1283 (SNMPv3)", December 2002. 1285 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1286 November 2003. 1288 [12] Hinden, R. and S. Deering, "IP Version 6 Addressing 1289 Architecture", February 2006. 1291 [13] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1292 Specifications: ABNF", October 2005. 1294 12.2. Informative References 1296 [14] Menezes, A., van Oorschot, P., and S. Vanstone, ""Handbook of 1297 Applied Cryptography", CRC Press", 1996. 1299 [15] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1300 Recommendations for Security", RFC 1750, December 1994. 1302 [16] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. 1304 [17] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1305 for Message Authentication", RFC 2104, February 1997. 1307 [18] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1308 Levels", BCP 14, RFC 2119, March 1997. 1310 [19] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 1312 [20] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, 1313 November 2001. 1315 [21] Klyne, G. and C. Newman, "Date and Time on the Internet: 1316 Timestamps", RFC 3339, July 2002. 1318 [22] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1319 RFC 3548, July 2003. 1321 [23] Gerhards, R., "The syslog Protocol, 1322 draft-ietf-syslog-protocol-17.txt (work in progress)", 1323 June 2006. 1325 [24] Okmianski, A., "Transmission of syslog Messages over UDP, 1326 draft-ietf-syslog-transport-udp-07.txt (work in progress)", 1327 May 2006. 1329 [25] Miao, F. and M. Yuzhi, "TLS Transport Mapping for syslog, 1330 draft-ietf-syslog-transport-tls-03.txt (work in progress)", 1331 August 2006. 1333 [26] Schneier, B., "Applied Cryptography Second Edition: protocols, 1334 algorithms, and source code in C", 1996. 1336 Authors' Addresses 1338 John Kelsey 1340 Email: kelsey.j@ix.netcom.com 1342 Jon Callas 1343 PGP Corporation 1345 Email: jon@callas.org 1347 Alexander Clemm 1348 Cisco Systems 1350 Email: alex@cisco.com 1352 Full Copyright Statement 1354 Copyright (C) The Internet Society (2006). 1356 This document is subject to the rights, licenses and restrictions 1357 contained in BCP 78, and except as set forth therein, the authors 1358 retain all their rights. 1360 This document and the information contained herein are provided on an 1361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1363 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1364 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1365 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1368 Intellectual Property 1370 The IETF takes no position regarding the validity or scope of any 1371 Intellectual Property Rights or other rights that might be claimed to 1372 pertain to the implementation or use of the technology described in 1373 this document or the extent to which any license under such rights 1374 might or might not be available; nor does it represent that it has 1375 made any independent effort to identify any such rights. Information 1376 on the procedures with respect to rights in RFC documents can be 1377 found in BCP 78 and BCP 79. 1379 Copies of IPR disclosures made to the IETF Secretariat and any 1380 assurances of licenses to be made available, or the result of an 1381 attempt made to obtain a general license or permission for the use of 1382 such proprietary rights by implementers or users of this 1383 specification can be obtained from the IETF on-line IPR repository at 1384 http://www.ietf.org/ipr. 1386 The IETF invites any interested party to bring to its attention any 1387 copyrights, patents or patent applications, or other proprietary 1388 rights that may cover technology that may be required to implement 1389 this standard. Please address the information to the IETF at 1390 ietf-ipr@ietf.org. 1392 Acknowledgment 1394 Funding for the RFC Editor function is provided by the IETF 1395 Administrative Support Activity (IASA).