idnits 2.17.1 draft-ietf-syslog-sign-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 2) being 104 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 51 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 698 has weird spacing: '...h Block vari...' == 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 (October 26, 2003) is 7459 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) -- Looks like a reference, but probably isn't: 'ABNF' on line 419 == Unused Reference: '4' is defined on line 1775, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1787, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1797, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1800, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1833, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1839, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1750 (ref. '7') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 1983 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') ** Obsolete normative reference: RFC 2279 (ref. '13') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2234 (ref. '14') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2373 (ref. '15') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2434 (ref. '16') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2440 (ref. '17') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2574 (ref. '18') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 3164 (ref. '19') (Obsoleted by RFC 5424) -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 15 errors (**), 0 flaws (~~), 13 warnings (==), 8 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 Expires: April 25, 2004 J. Callas 5 PGP Corporation 6 October 26, 2003 8 The syslog Protocol and Signed syslog Messages 9 draft-ietf-syslog-sign-13.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that = 18 other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six = 22 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 25, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document describes the syslog protocol and a mechanism to add 42 origin authentication, message integrity, replay-resistance, message 43 sequencing, and detection of missing messages to the transmitted 44 syslog messages. 46 =0C 47 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 49 October 2003 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 54 4 55 2. Required syslog Format . . . . . . . . . . . . . . . . . . . = 56 6 57 2.1 PRI Part . . . . . . . . . . . . . . . . . . . . . . . . . . = 58 6 59 2.2 HEADER Part . . . . . . . . . . . . . . . . . . . . . . . . = 60 7 61 2.3 MSG Part . . . . . . . . . . . . . . . . . . . . . . . . . . = 62 10 63 2.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . = 64 11 65 3. Signature Block Format and Fields . . . . . . . . . . . . . = 66 13 67 3.1 syslog Packets Containing a Signature Block . . . . . . . . = 68 13 69 3.2 Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . = 70 14 71 3.3 Version . . . . . . . . . . . . . . . . . . . . . . . . . . = 72 14 73 3.4 Reboot Session ID . . . . . . . . . . . . . . . . . . . . . = 74 14 75 3.5 Signature Group and Signature Priority . . . . . . . . . . . = 76 14 77 3.6 Global Block Counter . . . . . . . . . . . . . . . . . . . . = 78 16 79 3.7 First Message Number . . . . . . . . . . . . . . . . . . . . = 80 17 81 3.8 Count . . . . . . . . . . . . . . . . . . . . . . . . . . . = 82 17 83 3.9 Hash Block . . . . . . . . . . . . . . . . . . . . . . . . . = 84 17 85 3.10 Signature . . . . . . . . . . . . . . . . . . . . . . . . . = 86 17 87 4. Payload and Certificate Blocks . . . . . . . . . . . . . . . = 88 18 89 4.1 Preliminaries: Key Management and Distribution Issues . . . = 90 18 91 4.2 Building the Payload Block . . . . . . . . . . . . . . . . . = 92 18 93 4.3 Building the Certificate Block . . . . . . . . . . . . . . . = 94 19 95 4.3.1 Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . = 96 20 97 4.3.2 Version . . . . . . . . . . . . . . . . . . . . . . . . . . = 98 20 99 4.3.3 Reboot Session ID . . . . . . . . . . . . . . . . . . . . . = 100 20 101 4.3.4 Signature Group and Signature Priority . . . . . . . . . . . = 102 21 103 4.3.5 Total Payload Block Length . . . . . . . . . . . . . . . . . = 104 21 105 4.3.6 Index into Payload Block . . . . . . . . . . . . . . . . . . = 106 21 107 4.3.7 Fragment Length . . . . . . . . . . . . . . . . . . . . . . = 108 21 109 4.3.8 Signature . . . . . . . . . . . . . . . . . . . . . . . . . = 110 21 111 5. Redundancy and Flexibility . . . . . . . . . . . . . . . . . = 112 22 113 5.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . = 114 22 115 5.1.1 Certificate Blocks . . . . . . . . . . . . . . . . . . . . . = 116 22 117 5.1.2 Signature Blocks . . . . . . . . . . . . . . . . . . . . . . = 118 22 119 5.2 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . = 120 23 121 6. Efficient Verification of Logs . . . . . . . . . . . . . . . = 122 24 123 6.1 Offline Review of Logs . . . . . . . . . . . . . . . . . . . = 124 24 125 6.2 Online Review of Logs . . . . . . . . . . . . . . . . . . . = 126 25 127 7. Security Considerations . . . . . . . . . . . . . . . . . . = 128 27 129 7.1 Cryptography Constraints . . . . . . . . . . . . . . . . . . = 130 27 131 7.2 Packet Parameters . . . . . . . . . . . . . . . . . . . . . = 132 27 133 7.3 Message Authenticity . . . . . . . . . . . . . . . . . . . . = 134 27 135 7.4 Sequenced Delivery . . . . . . . . . . . . . . . . . . . . . = 136 28 137 7.5 Replaying . . . . . . . . . . . . . . . . . . . . . . . . . = 138 28 139 7.6 Reliable Delivery . . . . . . . . . . . . . . . . . . . . . = 140 28 141 7.7 Sequenced Delivery . . . . . . . . . . . . . . . . . . . . . = 142 28 143 7.8 Message Integrity . . . . . . . . . . . . . . . . . . . . . = 144 29 146 =0C 147 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 149 October 2003 151 7.9 Message Observation . . . . . . . . . . . . . . . . . . . . = 152 29 153 7.10 Man In The Middle . . . . . . . . . . . . . . . . . . . . . = 154 29 155 7.11 Denial of Service . . . . . . . . . . . . . . . . . . . . . = 156 29 157 7.12 Covert Channels . . . . . . . . . . . . . . . . . . . . . . = 158 29 159 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . = 160 31 161 8.1 Version Field . . . . . . . . . . . . . . . . . . . . . . . = 162 31 163 8.2 SIG Field . . . . . . . . . . . . . . . . . . . . . . . . . = 164 33 165 8.3 Key Blob Type . . . . . . . . . . . . . . . . . . . . . . . = 166 33 167 9. Authors and Working Group Chair . . . . . . . . . . . . . . = 168 34 169 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 170 35 171 References . . . . . . . . . . . . . . . . . . . . . . . . . = 172 36 173 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 174 37 175 Intellectual Property and Copyright Statements . . . . . . . = 176 38 178 =0C 179 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 181 October 2003 183 1. Introduction 185 The informational document RFC 3164 [19] describes a general format 186 of syslog messages as they have been seen on the wire, and as the 187 original author intended. Over time that format has been modified 188 and extended in several ways, usually to meet new requirements. = 189 This 190 document provides a standard format for all syslog messages, that 191 adheres to the original intent of the message format but also 192 contains enhancements that are consistent with many of the 193 innovations put forth through the years. Some components have been 194 adjusted in this document to allow for backwards compatibility. 195 However, the greatest benefit to automated log message parsers and 196 people reading the log messages will come from adherence to the = 197 newly 198 defined fields. The adherence of syslog messages to the format 199 defined in this document may present problems to older syslog = 200 message 201 receivers even though efforts were made to keep the message format 202 similar to the format described in RFC 3164 [19]. People deploying 203 devices that generate messages following the protocol described here 204 should verify that they don't present problems to their existing 205 syslog receivers. 207 This document also describes a mechanism that adds origin 208 authentication, message integrity, replay resistance, message 209 sequencing, and detection of missing messages to syslog. 210 Essentially, this is accomplished by sending a cryptographically 211 signed syslog message containing the signatures of previously sent 212 syslog messages. The contents of this message is called a Signature 213 Block. Each Signature Block contains, in effect, a detached = 214 signature 215 on some number of previously sent messages. While most 216 implementations of syslog involve only a single device as the 217 generator of each message and a single receiver as the collector of 218 each message, provisions need to be made to cover messages being = 219 sent 220 to multiple receivers. This is generally performed based upon the 221 Priority value of the individual messages. For example, messages = 222 from 223 any Facility with a Severity value of 3, 2, 1 or 0 may be sent to = 224 one 225 collector while all messages of Facilities 4, 10, 13, and 14 may be 226 sent to another collector. Appropriate syslog-sign messages must be 227 kept with their proper syslog messages. To address this, syslog-sign 228 uses a signature-group. A signature group identifies a group of 229 messages that are all kept together for signing purposes by the 230 device. A Signature Block always belongs to exactly one signature 231 group and it always signs messages belonging only to that signature 232 group. 234 Additionally, a device will send a Certificate Block to provide key 235 management information between the sender and the receiver. This 236 Certificate Block has a field to denote the type of key material 237 which may be such things as a PKIX certificate, an OpenPGP 239 =0C 240 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 242 October 2003 244 certificate, or even an indication that a key had been 245 predistributed. In all cases, these messages still use the syslog 246 packet format described in this document. In the cases of 247 certificates being sent, the certificates may have to be split = 248 across 249 multiple packets. 251 The receiver of the previous messages may verify that the digital 252 signature of each received message matches the signature contained = 253 in 254 the Signature Block. A collector may process these Signature Blocks 255 as they arrive, building an authenticated log file. Alternatively, = 256 it 257 may store all the log messages in the order they were received. This 258 allows a network operator to authenticate the log file at the time 259 the logs are reviewed. 261 =0C 262 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 264 October 2003 266 2. Required syslog Format 268 The essential format of a syslog message is defined in RFC 3164. The 269 basis of that format is that anything delivered to UDP port 514 will 270 be accepted as a valid syslog message. However, this document 271 REQUIRES a defined format for syslog messages. Packets conforming = 272 to 273 this specification REQUIRE this format. 275 The full format of a syslog sign message seen on the wire has three 276 discernable parts. The first part is called the PRI, the second part 277 is the HEADER, and the third part is the MSG. The total length of = 278 the 279 packet MUST be 1024 bytes or less. There is no minimum length of the 280 syslog message although sending a syslog packet with no contents is 281 worthless and SHOULD NOT be transmitted. 283 The definitions of the fields are slightly changed in this document 284 from RFC 3164. While the format described in RFC 3164 is correct for 285 packet formation, the Working Group evaluating this work determined 286 that it would be better if the TAG field were to become a part of = 287 the 288 HEADER part rather than the CONTENT part. While IETF documentation 289 does not allow the specification of an API, people developing code = 290 to 291 adhere to this specification have found it helpful to think about = 292 the 293 parts in this format. 295 Signature Block syslog messages and Certificate Block syslog = 296 messages 297 from devices MUST conform to this format. If they do not conform to 298 this format, they may be reformatted by a relay as described in 299 Section 4.3 of RFC 3164. That would change the format of the = 300 original 301 messages and any cryptographic signature of the original message 302 would not match the cryptographic signature of the changed message. 303 In line with this, a relay or collector of syslog messages MUST NOT 304 change the format, nor drop any information contained in the 305 Signature Block and Certificate Block messages. Additionally, they 306 MUST NOT change the format, nor drop any information contained in = 307 the 308 originally transmitted messages as that would also interfere with = 309 the 310 cryptographic processes. 312 2.1 PRI Part 314 The PRI part MUST have three, four, or five characters and will be 315 bound with angle brackets as the first and last characters. The PRI 316 part starts with a leading "<" ('less-than' character), followed by = 317 a 318 number, which is followed by a ">" ('greater-than' character). The 319 code set used in this part MUST be seven-bit ASCII in an eight- bit 320 field as described in RFC 2234 [14]. These are the ASCII codes as 321 defined in "USA Standard Code for Information Interchange" 322 ANSI.X3-4.1968 [3]. In this, the "<" character is defined as the 323 Augmented Backus-Naur Form (ABNF) %d60, and the ">" character has 325 =0C 326 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 328 October 2003 330 ABNF value %d62. The number contained within these angle brackets is 331 known as the Priority value and represents both the Facility and 332 Severity as described below. The Priority value consists of one, = 333 two, 334 or three decimal integers (ABNF DIGITS) using values of %d48 (for 335 "0") through %d57 (for "9"). 337 The Facilities and Severities of the messages are defined in RFC 338 3164. The Priority value is calculated by first multiplying the 339 Facility number by 8 and then adding the numerical value of the 340 Severity. For example, a kernel message (Facility=3D0) with a = 341 Severity 342 of Emergency (Severity=3D0) would have a Priority value of 0. Also, = 343 a 344 "local use 4" message (Facility=3D20) with a Severity of Notice 345 (Severity=3D5) would have a Priority value of 165. In the PRI part = 346 of a 347 syslog message, these values would be placed between the angle 348 brackets as <0> and <165> respectively. The only time a value of "0" 349 follows the "<" is for the Priority value of "0". Otherwise, leading 350 "0"s MUST NOT be used. 352 2.2 HEADER Part 354 The HEADER part contains a time stamp, an indication of the hostname 355 or IP address of the device, and a string indicating the source of 356 the message. The HEADER part of the syslog packet MUST contain 357 visible (printing) characters. The code set used MUST also been 358 seven-bit ASCII in an eight-bit field like that used in the PRI = 359 part. 360 In this code set, the only allowable characters are the ABNF VCHAR 361 values (%d33-126) and spaces (SP value %d32). 363 The HEADER contains three fields called the TIMESTAMP, the HOSTNAME, 364 and the TAG fields. The TIMESTAMP immediately follows the trailing 365 ">" from the PRI part and single space characters MUST follow each = 366 of 367 the TIMESTAMP and HOSTNAME fields. HOSTNAME contains the hostname, = 368 as 369 it knows itself. If it does not have a hostname, then it contains = 370 its 371 own IP address. If a device has multiple IP addresses, it has = 372 usually 373 been seen to use the IP address from which the message is 374 transmitted. An alternative to this behavior has also been seen. In 375 that case, a device may be configured to send all messages using a 376 single source IP address regardless of the interface from which the 377 message is sent. This provides a single consistent HOSTNAME for all 378 messages sent from a device. 380 The TIMESTAMP field is either a timestamp as defined in RFC 3164 381 denoted as TIMESTAMP-3164, or as a formalized timestamp as taken = 382 from 383 RFC 3339 [21]. A sender SHOULD format the timestamp as a RFC 3339 384 timestamp described below as TIMESTAMP-3339. A receiver MUST accept 385 both formats. 387 A single space character MUST follow the TIMESTAMP field regardless 389 =0C 390 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 392 October 2003 394 of the format used. 396 The TIMESTAMP-3164 is the local time and is in the format of "Mmm dd 397 hh:mm:ss" (without the quote marks) where: 399 Mmm is the English language abbreviation for the month of the = 400 year 401 with the first character in uppercase and the other two = 402 characters 403 in lowercase. The following are the only acceptable values: 405 Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec 407 dd is the day of the month. If the day of the month is less than 408 10, then it MUST be represented as a space and then the number. 409 For example, the 7th day of August would be represented as "Aug 410 7", with two spaces between the "g" and the "7". 412 hh:mm:ss is the local time. The hour (hh) is represented in a 413 24-hour format. Valid entries are between 00 and 23, inclusive. 414 The minute (mm) and second (ss) entries are between 00 and 59 415 inclusive. 417 The following syntax MUST be used when using a TIMESTAMP-3339. This 418 is specified using the syntax description notation defined in = 419 [ABNF]. 421 date-fullyear =3D 4DIGIT 422 date-month =3D 2DIGIT ; 01-12 423 date-mday =3D 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on 424 ; month/year 425 time-hour =3D 2DIGIT ; 00-23 426 time-minute =3D 2DIGIT ; 00-59 427 time-second =3D 2DIGIT ; 00-58, 00-59, 00-60 based on leap 428 ; second rules 429 time-secfrac =3D "." 1*DIGIT 430 time-numoffset =3D ("+" / "-") time-hour ":" time-minute 431 time-offset =3D "Z" / time-numoffset 433 partial-time =3D time-hour ":" time-minute ":" time-second 434 [time-secfrac] 435 full-date =3D date-fullyear "-" date-month "-" date-mday 436 full-time =3D partial-time time-offset 438 date-time =3D full-date "T" full-time 440 RFC 3339 makes allowances for multiple syntaxes for a timestamp to = 441 be 442 used in various cases. This document mandates a single syntax. The 443 primary characteristics of TIMESTAMP-3339 used in this document are 444 as follows. 446 =0C 447 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 449 October 2003 451 o the "T" and "Z" characters in this syntax MUST be upper case. 453 o usage of the "T" character is mandatory. It MUST NOT be replaced 454 by any other character (like a space character). 456 o the sender SHOULD include time-secfrac (fractional seconds) if = 457 its 458 clock accuracy permits. 460 o the entire length of the TIMESTAMP-3339 field MUST NOT exceed 32 461 characters. 463 Two samples of this format are: 465 1985-04-12T23:20:50.52Z 467 1985-04-12T18:20:50.52-06:00 469 The first represents 20 minutes and 50.52 seconds after the 23rd = 470 hour 471 of April 12th, 1985 in UTC. The second represents the same time but 472 expressed in the Eastern US timezone (daylight savings time being 473 observed). 475 Messages containing Signature Blocks and Certificate Blocks as 476 described in this document SHOULD use the TIMESTAMP-3339 format in 477 the TIMESTAMP field. It is not mandated that they do so at this = 478 time 479 since most of the receivers in use today will not be able to 480 understand that format and may modify those packets in accordance 481 with Section 4.3 of RFC 3164. 483 A single space character MUST follow the TIMESTAMP field. 485 Receivers parsing the date format SHOULD check if the TIMESTAMP is a 486 TIMESTAMP-3339. The "T" character at position 11 of the string can = 487 be 488 used as a rough indication for this. However, the receiver MUST NOT 489 rely solely on the "T" character but also parse the other data for 490 validity. A receiver SHOULD check for TIMESTAMP-3339 format first 491 and, if unsuccessful, assume a TIMESTAMP-3164. If it is also not a 492 TIMESTAMP-3164 format, the receiver MUST NOT try any other timestamp 493 format but consider the TIMESTAMP to be invalid or missing from the 494 received syslog message. 496 If a relay receives a TIMESTAMP-3164, it SHOULD forward the message 497 with a TIMESTAMP-3164 but MAY reformat it to a TIMESTAMP-3339 if 498 configured to do so. Relays should be aware that the TIMESTAMP-3339 499 may be longer than the TIMESTAMP-3164 and a replacement of the 500 TIMESTAMP-3164 with a TIMESTAMP-3339 may increase the length of the 501 entire packet beyond 1024 bytes. If a relay receives a 502 TIMESTAMP-3339 it MUST forward the message with a TIMESTAMP-3339. It 504 =0C 505 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 507 October 2003 509 MUST NOT reformat it to a TIMESTAMP-3164. 511 The HOSTNAME field contains an indication of the originator of the 512 message in one of four formats: only the hostname, the hostname and 513 domainname, the IPv4 address, or the IPv6 address. The preferred 514 value is the hostname and domainname in the format specified in STD 515 13 [5]. This format will be referred to in this document as 516 HOSTNAME-STD13. If only the hostname is used, the HOSTNAME field 517 MUST contain the hostname only of the device as specified in STD 13. 518 This format is discouraged but provides for legacy compatability = 519 with 520 the format described in RFC 3164. This format will be referred to = 521 in 522 this document as HOSTNAME-3164. In this format, the Domain Name = 523 MUST 524 NOT be included in the HOSTNAME field. If the IPv4 address is used, 525 it MUST be shown as the dotted decimal notation as used in STD 13 526 [6], and will be referred to as HOSTNAME-IPV4. If an IPv6 address = 527 is 528 used, any valid representation used in RFC 2373 [15] MAY be used and 529 will be referred to as HOSTNAME-IPV6. A single space character MUST 530 also follow the HOSTNAME field. 532 Messages containing Signature Blocks and Certificate Blocks as 533 described in this document MUST use the HOSTNAME-STD13 format in the 534 HOSTNAME field. 536 The TAG is a string of ABNF alphanumeric characters and other = 537 certain 538 special characters, that MUST NOT exceed 32 characters in length. 539 There are four special characters that are acceptable to use in this 540 field as well. 542 [ ABNF %d91 543 ] ABNF %d93 544 : ABNF %d58 545 . ABNF %d46 547 The first occurrence of a colon (":") character terminates the TAG 548 field. Generally, the TAG contains the name of the process that 549 generated the message. It may OPTIONALLY contain additional 550 information such as the numerical process ID of that process bound 551 within square brackets ("[" and "]"). A colon MUST be the last 552 character in this field. 554 To be consistent with the format described in RFC 3164, a space 555 character need not follow the colon in normal syslog packets. 556 However, a space character MUST follow the colon in Signature Block 557 and Payload Block messages as described below. 559 2.3 MSG Part 561 The MSG part contains the details of the message. This has 563 =0C 564 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 566 October 2003 568 traditionally been a freeform message that gives some detailed 569 information of the event. The MSG part of all syslog packets MUST 570 contain visible (printing) characters. The code set traditionally 571 and most often used has also been seven-bit ASCII in an eight-bit 572 field. In this code set, the only allowable characters are the ABNF 573 VCHAR values (%d33-126) and spaces (SP value %d32). However, no 574 indication of the code set used within the MSG is required, nor is = 575 it 576 expected. Other code sets MAY be used as long as the characters used 577 in the MSG part are exclusively visible characters and spaces = 578 similar 579 to those described above. For example, the UTF-8 RFC 2279 [13] 580 character set may be used. The selection of a code set used in the 581 MSG part SHOULD be made with thoughts of the intended receiver. A 582 message containing characters in a code set that cannot be viewed or 583 understood by a recipient will yield no information of value to an 584 operator or administrator looking at it. 586 As noted, there is no indication of the contents contained in the = 587 MSG 588 part. However, the mechanism for signing the previously sent syslog 589 messages is to send Certifate Blocks and Signature Blocks within 590 valid syslog messages. To accomplish this, special indicators will 591 appear at the start of the MSG part. The indicators will be called 592 Cookies and they are described below for Certificate Blocks and 593 Signature Blocks. In these Certificate Blocks and Certificate 594 Blocks, the code set used MUST also been seven-bit ASCII in an 595 eight-bit field. In this code set, the only allowable characters are 596 the ABNF VCHAR values (%d33-126) and spaces (SP value %d32). Unless 597 otherwise stated, binary data is base64 encoded, as defined in RFC 598 2045 [9]. While it may be that some programs that calculate base64 599 encoded strings place a newline at the end of the string, it must be 600 noted that base64 encoded strings in this protocol MUST NOT contain = 601 a 602 trailing newline character. 604 2.4 Examples 606 The following examples are given. 608 Example 1 610 <34>Oct 11 22:14:15 mymachine su: 'su root' failed for 611 lonvick on /dev/pts/8 613 In this example, as it was originally described in RFC 3164, the PRI 614 part is "<34>". In this work, however, the HEADER part consists of 615 the TIMESTAMP, the HOSTNAME, and the TAG fields. The TIMESTAMP is 616 "Oct 11 22:14:15 ", the HOSTNAME is "mymachine ", and the TAG value 617 is "su:". The CONTENT field is " 'su root' failed for lonvick...". 618 The CONTENT field starts with a leading space character in this = 619 case. 621 =0C 622 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 624 October 2003 626 Example 2 628 <165>Aug 24 05:34:00 10.1.1.1 myproc[10]:%% It's time to 629 make the do-nuts. %% Ingredients: Mix=3DOK, Jelly=3DOK # 630 Devices: Mixer=3DOK, Jelly_Injector=3DOK, Frier=3DOK # = 631 Transport: 632 Conveyer1=3DOK, Conveyer2=3DOK # %% 634 In this example, the PRI part is <165> denoting that it came from a 635 locally defined facility (local4) with a severity of Notice. The 636 HEADER part has a proper TIMESTAMP field in the message. A relay = 637 will 638 not modify this message before sending it. The HOSTNAME is an IPv4 639 address and the TAG field is "myproc[10]:". The MSG part starts with 640 "%% It's time to make the do-nuts. %% Ingredients: Mix=3DOK, ..." = 641 this 642 time without a leading space character. 644 =0C 645 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 647 October 2003 649 3. Signature Block Format and Fields 651 Since the device generating the Signature Block message signs the 652 entire syslog message, it is imperative that the message MUST NOT be 653 changed in transit. In adherence with Section 4 of RFC 3164, a fully 654 formed syslog message containing a PRI part and a HEADER part 655 containing TIMESTAMP and HOSTNAME fields MUST NOT be changed or 656 modified by any relay. 658 3.1 syslog Packets Containing a Signature Block 660 Signature Block messages MUST be completely formed syslog messages. 661 Signature Block messages have PRI, HEADER, and MSG parts as = 662 described 663 in this document. The PRI part MUST have a valid Priority value 664 bounded by angled brackets. The HEADER part SHOULD have a valid 665 TIMESTAMP-3339 field as well as a HOSTNAME-STD13 field. As stated in 666 Section 2.2 above, it is not mandated that they use TIMESTAMP-3339 667 nor HOSTNAME-STD13 fields for backwards compatibility since current 668 receivers may not understand these fields. It SHOULD also contain a 669 valid TAG field. It is RECOMMENDED that the TAG field have the value 670 of "syslog " (without the double quotes) to signify that this = 671 message 672 was generated by the syslog process. The CONTENT field of the syslog 673 Signature Block messages MUST have the following fields. Each of 674 these fields are separated by a single space character. 676 The Signature Block is composed of the following fields. Each field 677 must be printable ASCII, and any binary values are base-64 encoded. 679 Field Designation Size in bytes 680 ----- ----------- ---- -- ----- 682 Cookie Cookie 8 684 Version Ver 4 686 Reboot Session ID RSID 1-10 688 Signature Group SIG 1 690 Signature Priority SPRI 1-3 692 Global Block Counter GBC 1-10 694 First Message Number FMN 1-10 696 Count Count 1-2 698 Hash Block Hash Block variable, size of=20 699 hash 701 =0C 702 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 704 October 2003 706 (base-64 encoded=20 707 binary) 709 Signature Signature variable 710 (base-64 encoded=20 711 binary) 713 These fields are described below. 715 3.2 Cookie 717 The cookie is a eight-byte sequence to signal that this is a 718 Signature Block. This sequence is "@#sigSIG" (without the double 719 quotes). As noted, a space character follows this, and all other 720 fields. 722 3.3 Version 724 The signature group version field is 4 characters in length and is 725 terminated with a space character. The value in this field specifies 726 the version of the syslog-sign protocol. This is extensible to allow 727 for different hash algorithms and signature schemes to be used in = 728 the 729 future. The value of this field is the grouping of the protocol 730 version (2 bytes), the hash algorithm (1 byte) and the signature 731 scheme (1 byte). 733 Protocol Version - 2 bytes with the first version as described in 734 this document being value of 01 to denote Version 1. 736 Hash Algorithm - 1 byte with the definition that 1 denotes SHA1 = 737 as 738 defined in FIPS-180-1.1995 [2]. 740 Signature Scheme - 1 byte with the definition that 1 denotes 741 OpenPGP DSA - RFC 2440 [17], FIPS.186-1.1998 [1]. 743 As such, the version, hash algorithm and signature scheme defined in 744 this document may be represented as "0111" (without the quote = 745 marks). 747 3.4 Reboot Session ID 749 The reboot session ID is a value between 1 and 10 bytes, which is 750 required to never repeat or decrease. The acceptable values for = 751 this 752 are between 0 and 9999999999. If the value latches at 9999999999, 753 then manual intervention may be required to reset it to 0. 754 Implementors MAY wish to consider using the snmpEngineBoots value as 755 a source for this counter as defined in RFC 2574 [18]. 757 3.5 Signature Group and Signature Priority 759 The SIG identifier as described above may take on any value from 0-3 761 =0C 762 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 764 October 2003 766 inclusive. The SPRI may take any value from 0-191. Each of these 767 fields are followed by a space character. These fields taken 768 together allows network administrators to associate groupings of 769 syslog messages with appropriate Signature Blocks and Certificate 770 Blocks. For example, in some cases, network administrators may send 771 syslog messages of Facilities 0 through 15 to one destination while 772 sending messages with Facilities 16 through 23 to another. 773 Associated Signature Blocks should be sent to these different syslog 774 servers as well. 776 In some cases, an administrator may wish the Signature Blocks to go 777 to the same destination as the syslog messages themselves. This may 778 be to different syslog servers if the destinations of syslog = 779 messages 780 is being controlled by the Facilities or the Severities of the 781 messages. In other cases, administrators may wish to send the 782 Signature Blocks to an altogether different destination. 784 Syslog-sign provides four options for handling signature groups, 785 linking them with PRI values so they may be routed to the = 786 destination 787 commensurate with the appropriate syslog messages. In all cases, no 788 more than 192 signature groups (0-191) are permitted. 790 a. '0' -- There is only one signature group. All Signature Block 791 messages use a single PRI value which is the same SPRI value. = 792 In 793 this case, the administrators want all Signature Blocks to be 794 sent to a single destination. In all likelihood, all of the 795 syslog messages will also be going to that same destination. As 796 one example, if SIG=3D0, then PRI and SPRI may be 46 to indicate 797 that they are informational messages from the syslog daemon. If 798 the device is configured to send all messages with the local5 799 Facility (21), then the PRI and SPRI may be 174 to indicate that 800 they are also from the local5 Facility with a Severity of 6. 802 b. '1' -- Each PRI value has its own signature group. Signature 803 Blocks for a given signature group have SPRI =3D PRI for that 804 signature group. In this case, the administrator of a device = 805 may 806 not know where any of the syslog messages will ultimately go. 807 This use ensures that a Signature Block follows each of the 808 syslog messages to each destination. This may be seen to be 809 inefficient if groups of syslog messages are actually going to 810 the same syslog server. Examine an example of a device being 811 configured to have a SIG value of 1, which generates 16 syslog 812 messages with 814 4 from PRI=3D132 (Facility 16, Severity 4), 815 4 from PRI=3D148 (Facility 18, Severity 4), 816 4 from PRI=3D164, (Facility 20, Severity 4), and 817 4 from PRI=3D180 (Facility 22, Severity 4). 819 =0C 820 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 822 October 2003 824 In actuality, the messages from Facilities local0 and local2 go 825 to one syslog server and messages from Facilities local4 and 826 local6 go to a different one. Then, the first syslog server 827 receives 2 Signature Blocks, the first with PRI=3D134 and the 828 second from PRI=3D150 - the PRI values matching the SPRI values. 829 The second syslog server would also receive two Signature Block 830 messages, the first from PRI=3D164 and the second from PRI=3D180. = 831 In 832 each of those Signature Blocks, the SPRI values matches their 833 respective PRI values. In each of these cases, the Signature 834 Blocks going to each respective syslog server could have been 835 combined. One way to do this more efficiently is explained = 836 using 837 SIG=3D2. 839 c. '2' -- Each signature group contains a range of PRI values. 840 Signature groups are assigned sequentially. A Signature Block = 841 for 842 a given signature group has its own SPRI value denoting the 843 highest PRI value in that signature group. For flexibility, the 844 PRI does not have to be that upper-boundary SPRI value. 845 Continuing the above example, the administrator of the device = 846 may 847 configure SIG=3D2 with upper-bound SPRIs of 151 and 191. The = 848 lower 849 group contains all PRIs between 0 and 151, and the second group 850 contains all PRIs between 152 and 191. The administrator may 851 then wish to configure the lower group to send all of the lower 852 group Signature Blocks using PRI=3D150 (Facility 18, Severity = 853 6), 854 and the upper group using PRI=3D182 (Facility 22, Severity 6). = 855 The 856 receiving syslog servers then each receive a single Signature 857 Block describing the 8 syslog messages sent to it. 859 d. '3' -- Signature groups are not assigned with any simple 860 relationship to PRI values. This has to be some predefined 861 arrangement between the sender and the intended receivers. In 862 this case, the administrators of the devices and syslog servers 863 may, as an example, use SIG=3D3 with a SPRI of 1 to denote that = 864 all 865 Warning and above syslog messages from all Facilities are sent 866 using a PRI of 46 (Facility 5, Severity 6). 868 One reasonable way to configure some installations is to have only 869 one signature group with SIG=3D0. The devices send messages to many 870 collectors and also send a copy of each Signature Block to each 871 collector. This won't allow any collector to detect gaps in the 872 messages, but it allows all messages that arrive at each collector = 873 to 874 be put into the right order, and to be verified. It also allows = 875 each 876 collector to detect duplicates and any messages that are not 877 associated with a Signature Block. 879 3.6 Global Block Counter 881 The global block counter is a value representing the number of 883 =0C 884 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 886 October 2003 888 Signature Blocks sent out by syslog-sign before this one, in this 889 reboot session. This takes at least 1 byte and at most 10 bytes 890 displayed as a decimal counter and the acceptable values for this = 891 are 892 between 0 and 9999999999. If the value latches at 9999999999, then 893 the reboot session counter must be incremented by 1 and the global 894 block counter resumes at 0. Note that this counter crosses = 895 signature 896 groups; it allows us to roughly synchronize when two messages were 897 sent, even though they went to different collectors. 899 3.7 First Message Number 901 This is a value between 1 and 10 bytes. It contains the unique 902 message number within this signature group of the first message = 903 whose 904 hash appears in this block. The very first message of the reboot 905 session will be numbered "1". 907 For example, if this signature group has processed 1000 messages so 908 far and message number 1001 is the first message whose hash appears 909 in this Signature Block, then this field contains 1001. 911 3.8 Count 913 The count is a 1 or 2 byte field displaying the number of message 914 hashes to follow. The valid values for this field are between 1 and 915 99. 917 3.9 Hash Block 919 The hash block is a block of hashes, each separately encoded in 920 base-64. Each hash in the hash block is the hash of the entire = 921 syslog 922 message represented by the hash. The hashing algorithm used 923 effectively specified by the Version field determines the size of 924 each hash, but the size MUST NOT be shorter than 160 bits. It is 925 base-64 encoded as per RFC 2045. 927 3.10 Signature 929 This is a digital signature, encoded in base-64, as per RFC 2045. = 930 The 931 signature is calculated over all fields but excludes the space 932 characters between them. The Version field effectively specifies = 933 the 934 original encoding of the signature. The signature is a signature = 935 over 936 the entire data, including all of the PRI, HEADER, and hashes in the 937 hash block. To reiterate, the signature is calculated over the 938 completely formatted syslog-message, excluding spaces between = 939 fields, 940 and also excluding this signature field. 942 =0C 943 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 945 October 2003 947 4. Payload and Certificate Blocks 949 Certificate Blocks and Payload Blocks provide key management in 950 syslog-sign. 952 4.1 Preliminaries: Key Management and Distribution Issues 954 The purpose of Certificate Blocks is to support key management using 955 public key cryptosystems. All devices send at least one Certificate 956 Block at the beginning of a new reboot session, carrying useful 957 information about the reboot session. 959 There are three key points to understand about Certificate Blocks: 961 a. They handle a variable-sized payload, fragmenting it if = 962 necessary 963 and transmitting the fragments as legal syslog messages. This 964 payload is built (as described below) at the beginning of a 965 reboot session and is transmitted in pieces with each = 966 Certificate 967 Block carrying a piece. Note that there is exactly one Payload 968 Block per reboot session. 970 b. The Certificate Blocks are digitally signed. The device does not 971 sign the Payload Block, but the signatures on the Certificate 972 Blocks ensure its authenticity. Note that it may not even be 973 possible to verify the signature on the Certificate Blocks 974 without the information in the Payload Block; in this case the 975 Payload Block is reconstructed, the key is extracted, and then 976 the Certificate Blocks are verified. (This is necessary even = 977 when 978 the Payload Block carries a certificate, since some other fields 979 of the Payload Block aren't otherwise verified.) In practice, 980 most installations keep the same public key over long periods of 981 time, so that most of the time, it's easy to verify the 982 signatures on the Certificate Blocks, and use the Payload Block 983 to provide other useful per-session information. 985 c. The kind of Payload Block that is expected is determined by what 986 kind of key material is on the collector that receives it. The 987 device and collector (or offline log viewer) has both some key 988 material (such as a root public key, or predistributed public 989 key), and an acceptable value for the Key Blob Type in the 990 Payload Block, below. The collector or offline log viewer MUST 991 NOT accept a Payload Block of the wrong type. 993 4.2 Building the Payload Block 995 The Payload Block is built when a new reboot session is started. 996 There is a one-to-one correspondence of reboot sessions to Payload 998 =0C 999 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1001 October 2003 1003 Blocks. That is, each reboot session has only one Payload Block, 1004 regardless of how many signature groups it may support. Like syslog 1005 packets containing the Signature Block, Payload Block messages MUST 1006 be completely formed syslog messages. Payload Block messages have 1007 PRI, HEADER, and MSG parts as described in this document. The PRI 1008 part MUST have a valid Priority value bounded by angled brackets. = 1009 The 1010 HEADER part MUST have a valid TIMESTAMP-3339 field as well as a 1011 HOSTNAME-STD13 field. It SHOULD also contain a valid TAG field. It = 1012 is 1013 RECOMMENDED that the TAG field have the value of "syslog " (without 1014 the double quotes) to signify that this message was generated by the 1015 syslog process. The CONTENT field of the syslog Payload Block 1016 messages MUST have the following fields. Each of these fields are 1017 separated by a single space character. 1019 a. Unique identifier of sender; by default, the sender's IP address 1020 in dotted-decimal (IPv4) or colon-separated (IPv6) notation. 1022 b. Full local time stamp for the device at the time the reboot 1023 session started. This must be in TIMESTAMP-3339 format. 1025 c. Key Blob Type, a one-byte field which holds one of five values: 1027 1. 'C' -- a PKIX certificate. 1029 2. 'P' -- an OpenPGP certificate. 1031 3. 'K' -- the public key whose corresponding private key is 1032 being used to sign these messages. 1034 4. 'N' -- no key information sent; key is predistributed. 1036 5. 'U' -- installation-specific key exchange information 1038 d. The key blob, consisting of the raw key data, if any, base-64 1039 encoded. 1041 4.3 Building the Certificate Block 1043 The Certificate Block must get the Payload Block to the collector. 1044 Since certificates can legitimately be much longer than 1024 bytes, 1045 each Certificate Block carries a piece of the Payload Block. Note 1046 that the device MAY make the Certificate Blocks of any legal length 1047 (that is, any length less than 1024 bytes) which holds all the 1048 required fields. Software that processes Certificate Blocks MUST = 1049 deal 1050 correctly with blocks of any legal length. 1052 The Certificate Block is composed of the following fields. Each = 1053 field 1055 =0C 1056 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1058 October 2003 1060 must be printable ASCII, and any binary values are base-64 encoded. 1062 Field Designation Size in bytes 1063 ----- ----------- ---- -- ----- 1065 Cookie Cookie 8 1067 Version Ver 4 1069 Reboot Session ID RSID 1-10 1071 Signature Group SIG 1 1073 Signature Priority SPRI 1-3 1075 Total Payload Block Length TPBL 1-8 1077 Index into Payload Block Index 1-8 1079 Fragment Length FragLen 1-3 1081 Payload Block Fragment Fragment variable 1082 (base-64 encoded=20 1083 binary) 1085 Signature Signature variable 1086 (base-64 encoded=20 1087 binary) 1089 4.3.1 Cookie 1091 The cookie is a eight-byte sequence to signal that this is a 1092 Signature Block. This sequence is "@#sigCER" (without the double 1093 quotes). As noted, a space character follows this, and all other 1094 fields. 1096 4.3.2 Version 1098 The signature group version field is 4 characters in length and is 1099 terminated with a space character. This field is identical to the 1100 Version field described in Section 3. As such, the version, hash 1101 algorithm and signature scheme defined in this document may be 1102 represented as "0111" (without the quote marks). 1104 4.3.3 Reboot Session ID 1106 The Reboot Session ID is identical to the RSID field described in 1107 Section 3. 1109 =0C 1110 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1112 October 2003 1114 4.3.4 Signature Group and Signature Priority 1116 The SIG field is identical to the SIG field described in Section 3. 1117 Also, the SPRI field is identical to the SPRI field described there. 1119 4.3.5 Total Payload Block Length 1121 The Total Payload Block Length is a value representing the total 1122 length of the Payload Block in bytes in decimal. This will be one = 1123 to 1124 eight bytes. 1126 4.3.6 Index into Payload Block 1128 This is a value between 1 and 8 bytes. It contains the number of 1129 bytes into the Payload Block where this fragment starts. The first 1130 byte of the first fragment is numbered "1". 1132 4.3.7 Fragment Length 1134 The total length of this fragment expressed as a decimal integer. 1135 This will be one to three bytes. 1137 4.3.8 Signature 1139 This is a digital signature, encoded in base-64, as per RFC 2045. = 1140 The 1141 signature is calculated over all fields but excludes the space 1142 characters between them. The Version field effectively specifies = 1143 the 1144 original encoding of the signature. The signature is a signature = 1145 over 1146 the entire data, including all of the PRI, HEADER, and hashes in the 1147 hash block. This is consistent with the method of calculating the 1148 signature as specified in Section 3.10. To reiterate, the signature 1149 is calculated over the completely formatted syslog-message, = 1150 excluding 1151 spaces between fields, and also excluding this signature field. 1153 =0C 1154 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1156 October 2003 1158 5. Redundancy and Flexibility 1160 There is a general rule that determines how redundancy works and = 1161 what 1162 level of flexibility the device and collector have in message 1163 formats: in general, the device is allowed to send Signature and 1164 Certificate Blocks multiple times, to send Signature and Certificate 1165 Blocks of any legal length, to include fewer hashes in hash blocks, 1166 etc. 1168 5.1 Redundancy 1170 Syslog messages are sent over unreliable transport, which means that 1171 they can be lost in transit. However, the collector must receive 1172 Signature and Certificate Blocks or many messages may not be able to 1173 be verified. Sending Signature and Certificate Blocks multiple times 1174 provides redundancy; since the collector MUST ignore Signature/ 1175 Certificate Blocks it has already received and authenticated, the 1176 device can in principle change its redundancy level for any reason, 1177 without communicating this fact to the collector. 1179 Although the device isn't constrained in how it decides to send 1180 redundant Signature and Certificate Blocks, or even in whether it 1181 decides to send along multiple copies of normal syslog messages, = 1182 here 1183 we define some redundancy parameters below which may be useful in 1184 controlling redundant transmission from the device to the collector. 1186 5.1.1 Certificate Blocks 1188 certInitialRepeat =3D number of times each Certificate Block should = 1189 be 1190 sent before the first message is sent. 1192 certResendDelay =3D maximum time delay in seconds to delay before = 1193 next 1194 redundant sending. 1196 certResendCount =3D maximum number of sent messages to delay before 1197 next redundant sending. 1199 5.1.2 Signature Blocks 1201 sigNumberResends =3D number of times a Signature Block is resent. 1203 sigResendDelay =3D maximum time delay in seconds from original 1204 sending to next redundant sending. 1206 sigResendCount =3D maximum number of sent messages to delay before 1207 next redundant sending. 1209 =0C 1210 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1212 October 2003 1214 5.2 Flexibility 1216 The device may change many things about the makeup of Signature and 1217 Certificate Blocks in a given reboot session. The things it cannot 1218 change are: 1220 * The version 1222 * The number or arrangements of signature groups 1224 It is legitimate for a device to send out short Signature Blocks, in 1225 order to keep the collector able to verify messages quickly. In 1226 general, unless something verified by the Payload Block or 1227 Certificate Blocks is changed within the reboot session ID, any 1228 change is allowed to the Signature or Certificate Blocks during the 1229 session. 1231 =0C 1232 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1234 October 2003 1236 6. Efficient Verification of Logs 1238 The logs secured with syslog-sign may either be reviewed online or 1239 offline. Online review is somewhat more complicated and 1240 computationally expensive, but not prohibitively so. 1242 6.1 Offline Review of Logs 1244 When the collector stores logs and reviewed later, they can be 1245 authenticated offline just before they are reviewed. Reviewing these 1246 logs offline is simple and relatively cheap in terms of resources 1247 used, so long as there is enough space available on the reviewing 1248 machine. Here, we consider that the stored log files have already 1249 been separated by sender, reboot session ID, and signature group. 1250 This can be done very easily with a script file. We then do the 1251 following: 1253 a. First, we go through the raw log file, and split its contents 1254 into three files. Each message in the raw log file is classified 1255 as a normal message, a Signature Block, or a Certificate Block. 1256 Certificate Blocks and Signature Blocks are stored in their own 1257 files. Normal messages are stored in a keyed file, indexed on 1258 their hash values. 1260 b. We sort the Certificate Block file by index value, and check to 1261 see if we have a set of Certificate Blocks that can reconstruct 1262 the Payload Block. If so, we reconstruct the Payload Block, 1263 verify any key-identifying information, and then use this to 1264 verify the signatures on the Certificate Blocks we've received. 1265 When this is done, we have verified the reboot session and key 1266 used for the rest of the process. 1268 c. We sort the Signature Block file by firstMessageNumber. We now 1269 create an authenticated log file, which consists of some header 1270 information, and then a sequence of message number, message text 1271 pairs. We next go through the Signature Block file. For each 1272 Signature Block in the file, we do the following: 1274 1. Verify the signature on the Block. 1276 2. For each hashed message in the Block: 1278 a. Look up the hash value in the keyed message file. 1280 b. If the message is found, write (message number, message 1281 text) to the authenticated log file. 1283 =0C 1284 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1286 October 2003 1288 3. Skip all other Signature Blocks with the same 1289 firstMessageNumber. 1291 d. The resulting authenticated log file contains all messages that 1292 have been authenticated, and implicitly indicates (by missing 1293 message numbers) all gaps in the authenticated messages. 1295 It's pretty easy to see that, assuming sufficient space for building 1296 the keyed file, this whole process is linear in the number of 1297 messages (generally two seeks, one to write and the other to read, 1298 per normal message received), and O(N lg N) in the number of 1299 Signature Blocks. This estimate comes with two caveats: first, the 1300 Signature Blocks arrive very nearly in sorted order, and so can 1301 probably be sorted more cheaply on average than O(N lg N) steps. 1302 Second, the signature verification on each Signature Block almost 1303 certainly is more expensive than the sorting step in practice. We 1304 haven't discussed error-recovery, which may be necessary for the 1305 Certificate Blocks. In practice, a very simple error-recovery 1306 strategy is probably good enough -- if the Payload Block doesn't = 1307 come 1308 out as valid, then we can just try an alternate instance of each 1309 Certificate Block, if such are available, until we get the Payload 1310 Block right. 1312 It's easy for an attacker to flood us with plausible-looking 1313 messages, Signature Blocks, and Certificate Blocks. 1315 6.2 Online Review of Logs 1317 Some processes on the collector machine may need to monitor log 1318 messages in something very close to real-time. This can be done with 1319 syslog-sign, though it is somewhat more complex than the offline 1320 analysis. This is done as follows: 1322 a. We have an output queue, into which we write (message number, 1323 message text) pairs which have been authenticated. Again, we'll 1324 assume we're handling only one signature group, and only one 1325 reboot session ID, at any given time. 1327 b. We have three data structures: A queue into which (message 1328 number, hash of message) pairs is kept in sorted order, a queue 1329 into which (arrival sequence, hash of message) is kept in sorted 1330 order, and a hash table which stores (message text, count) 1331 indexed by hash value. In this file, count may be any number 1332 greater than zero; when count is zero, the entry in the hash 1333 table is cleared. 1335 c. We must receive all the Certificate Blocks before any other 1336 processing can really be done. (This is why they're sent first.) 1338 =0C 1339 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1341 October 2003 1343 Once that's done, any Certificate Block that arrives is 1344 discarded. 1346 d. Whenever a normal message arrives, we add (arrival sequence, = 1347 hash 1348 of message) to our message queue. If our hash table has an entry 1349 for the message's hash value, we increment its count by one; 1350 otherwise, we create a new entry with count =3D 1. When the = 1351 message 1352 queue is full, we roll the oldest messages off the queue by 1353 taking the last entry in the queue, and using it to index the 1354 hash table. If that entry has count is 1, we delete the entry in 1355 the hash table; otherwise, we decrement its count. We then = 1356 delete 1357 the last entry in the queue. 1359 e. Whenever a Signature Block arrives, we first check to see if the 1360 firstMessageNumber value is too old, or if another Signature 1361 Block with that firstMessageNumber has already been received. If 1362 so, we discard the Signature Block unread. Otherwise, we check 1363 its signature, and discard it if the signature isn't valid. A 1364 Signature Block contains a sequence of (message number, message 1365 hash) pairs. For each pair, we first check to see if the message 1366 hash is in the hash table. If so, we write out the (message 1367 number, message text) in the authenticated message queue. 1368 Otherwise, we write the (message number, message hash) to the 1369 message number queue. This generally involves rolling the oldest 1370 entry out of this queue: before this is done, that entry's hash 1371 value is again searched for in the hash table. If a matching 1372 entry is found, the (message number, message text) pair is 1373 written out to the authenticated message queue. In either case, 1374 the oldest entry is then discarded. 1376 f. The result of this is a sequence of messages in the = 1377 authenticated 1378 message queue, each of which has been authenticated, and which 1379 are combined with numbers showing their order of original 1380 transmission. 1382 It's not too hard to see that this whole process is roughly linear = 1383 in 1384 the number of messages, and also in the number of Signature Blocks 1385 received. The process is susceptible to flooding attacks; an = 1386 attacker 1387 can send enough normal messages that the messages roll off their 1388 queue before their Signature Blocks can be processed. 1390 =0C 1391 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1393 October 2003 1395 7. Security Considerations 1397 Normal syslog event messages are unsigned and have most of the 1398 security attributes described in Section 6 of RFC 3164. This 1399 document also describes Certificate Blocks and Signature Blocks = 1400 which 1401 are signed syslog messages. The Signature Blocks contains signature 1402 information of previously sent syslog event messages. All of this 1403 information may be used to authenticate syslog messages and to 1404 minimize or obviate many of the security concerns described in RFC 1405 3164. 1407 7.1 Cryptography Constraints 1409 As with any technology involving cryptography, you should check the 1410 current literature to determine if any algorithms used here have = 1411 been 1412 found to be vulnerable to attack. 1414 This specification uses Public Key Cryptography technologies. The 1415 proper party or parties must control the private key portion of a 1416 public-private key pair. Any party that controls a private key may 1417 sign anything they please. 1419 Certain operations in this specification involve the use of random 1420 numbers. An appropriate entropy source should be used to generate 1421 these numbers. See RFC 1750 [7]. 1423 7.2 Packet Parameters 1425 The message length must not exceed 1024 bytes. Various problems may 1426 result if a device sends out messages with a length greater than = 1427 1024 1428 bytes. In this case, as with all others, it is best to be 1429 conservative with what you send but liberal in what you receive, and 1430 accept more than 1024 bytes. 1432 Similarly, senders must rigidly enforce the correctness of the 1433 message body. It is hoped that all devices adopt the newly defined 1434 HOSTNAME-STD13 and TIMESTAMP-3339 formats. However, until that 1435 happens, receivers may become upset at the receipt of messages with 1436 these fields. Knowledgeable humans should review the senders and 1437 receivers to ensure that no problems arise from this. 1439 Finally, receivers must not malfunction if they receive syslog 1440 messages containing characters other than those specified in this 1441 document. 1443 7.3 Message Authenticity 1445 Event messages being sent through syslog do not strongly associate 1447 =0C 1448 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1450 October 2003 1452 the message with the message sender. That fact is established by = 1453 the 1454 receiver upon verification of the Signature Block as described = 1455 above. 1456 Before a Signature Block is used to ascertain the authenticity of an 1457 event message, it may be received, stored and reviewed by a person = 1458 or 1459 automated parser. Both of these should maintain doubt about the 1460 authenticity of the message until after it has been validated by 1461 checking the contents of the Signature Block. 1463 With the Signature Block checking, an attacker may only forge 1464 messages if they can compromise the private key of the true sender. 1466 7.4 Sequenced Delivery 1468 Event messages may be recorded and replayed by an attacker. However 1469 the information contained in the Signature Blocks allows a reviewer 1470 to determine if the received messages are the ones originally sent = 1471 by 1472 a device. This process also alerts the reviewer to replayed 1473 messages. 1475 7.5 Replaying 1477 Event messages may be recorded and replayed by an attacker. However 1478 the information contained in the Signature Blocks will allow a 1479 reviewer to determine if the received messages are the ones 1480 originally sent by a device. This process will also alert the 1481 reviewer to replayed messages. 1483 7.6 Reliable Delivery 1485 RFC 3195 may be used for the reliable delivery of all syslog 1486 messages. This document acknowledges that event messages sent over 1487 UDP may be lost in transit. A proper review of the Signature Block 1488 information may pinpoint any messages sent by the sender but not 1489 received by the receiver. The overlap of information in subsequent 1490 Signature Block information allows a reviewer to determine if any 1491 Signature Block messages were also lost in transit. 1493 7.7 Sequenced Delivery 1495 Related to the above, syslog messages delivered over UDP not only = 1496 may 1497 be lost, but they may arrive out of sequence. The information 1498 contained in the Signature Block allows a receiver to correctly = 1499 order 1500 the event messages. Beyond that, the extended timestamp information 1501 contained in the TIMESTAMP-3339 format should help the reviewer to 1502 visually order received messages even if they are received out of 1503 order. 1505 =0C 1506 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1508 October 2003 1510 7.8 Message Integrity 1512 syslog messages may be damaged in transit. A review of the 1513 information in the Signature Block determines if the received = 1514 message 1515 was the intended message sent by the sender. A damaged Signature 1516 Block or Certificate Block will be evident since the receiver will 1517 not be able to validate that it was signed by the sender. 1519 7.9 Message Observation 1521 Event messages, Certificate Blocks and Signature Blocks are all sent 1522 in plaintext. Generally this has had the benefit of allowing network 1523 administrators to read the message when sniffing the wire. However, 1524 this also allows an attacker to see the contents of event messages 1525 and perhaps to use that information for malicious purposes. 1527 7.10 Man In The Middle 1529 It is conceivable that an attacker may intercept Certificate Blocks 1530 and insert their own Certificate information. In that case, the 1531 attacker would be able to receive event messages from the actual 1532 sender and then relay modified messages, insert new messages, or 1533 deleted messages. They would then be able to construct a Signature 1534 Block and sign it with their own private key. The network 1535 administrators should verify that the key contained in the 1536 Certificate Block is indeed the key being used on the actual device. 1537 If that is indeed the case, then this MITM attack will not succeed. 1539 7.11 Denial of Service 1541 An attacker may be able to overwhelm a receiver by sending it = 1542 invalid 1543 Signature Block messages. If the receiver is attempting to process 1544 these messages online, it may consume all available resources. For 1545 this reason, it may be appropriate to just receive the Signature 1546 Block messages and process them as time permits. 1548 As with any system, an attacker may also just overwhelm a receiver = 1549 by 1550 sending more messages to it than can be handled by the = 1551 infrastructure 1552 or the device itself. Implementors should attempt to provide = 1553 features 1554 that minimize this threat. Such as only receiving syslog messages 1555 from known IP addresses. 1557 7.12 Covert Channels 1559 Nothing in this protocol attempts to eliminate covert channels. 1560 Indeed, the unformatted message syntax in the packets could be very 1561 amenable to sending embedded secret messages. In fact, just about 1562 every aspect of syslog messages lends itself to the conveyance of 1564 =0C 1565 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1567 October 2003 1569 covert signals. For example, a collusionist could send odd and even 1570 PRI values to indicate Morse Code dashes and dots. 1572 =0C 1573 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1575 October 2003 1577 8. IANA Considerations 1579 Two syslog packet types are specified in this document; the = 1580 Signature 1581 Block and the Certificate Block. Each of these has several fields 1582 specified that should be controlled by the IANA. Essentially these 1583 packet types may be differentiated based upon the value in the = 1584 Cookie 1585 field. The Signature Block packet may be identified by a value of 1586 "@#sigSIG" in the Cookie field. The Certificate Block packet may be 1587 identified by a value of "@#sigCER" in the Cookie field. Each of 1588 these packet types share fields that should be consistent; 1589 specifically, the Certificate Block packet types may be considered = 1590 to 1591 be an announcement of capabilities and the Signature Block packets 1592 SHOULD have the same values in the fields described in this section. 1593 This document allows that there may be some really fine reason for 1594 the values to be different between the two packet types but the 1595 authors and contributors can't see any valid reason for that at this 1596 time. 1598 This document also upholds the Facilities and Severities listed in 1599 RFC 3164 [19]. Those values range from 0 to 191. This document = 1600 also 1601 instructs the IANA to reserve all other possible values of the 1602 Severities and Facilities above the value of 191 and to distribute 1603 them via the consensus process as defined in RFC 2434 [16]. 1605 The following fields are to be controlled by the IANA in both the 1606 Signature Block packets and the Certificate Block packets. 1608 8.1 Version Field 1610 The Version field (Ver) is a 4 byte field. The first two bytes of 1611 this field define the version of the Signature Block packets and the 1612 Certificate Block Packets. This allows for future efforts to 1613 redefine the subsequent fields in the Signature Block packets and 1614 Certificate Block packets. A value of "00" is reserved and not = 1615 used. 1616 This document describes the fields for the version value of "01". = 1617 It 1618 is expected that this value be incremented monotonically with = 1619 decimal 1620 values up through "50" for IANA assigned values. Values "02" through 1621 "50" will be assigned by the IANA using the "IETF Consensus" policy 1622 defined in RFC 2434 [16]. It is not anticipated that these values 1623 will be reused. Values of "51" through "99" will be vendor-specific, 1624 and values in this range are not to be assigned by the IANA. 1626 In the case of vendor-specific assigned Version numbers, all 1627 subsequent values defined in the packet will then have 1628 vendor-specific meaning. They may, or may not, align with the = 1629 values 1630 assigned by the IANA for these fields. For example, a vendor may 1631 choose to define their own Version of "51" still containing values = 1632 of 1633 "1" for the Hash Algorithm and Signature Scheme which aligns with = 1634 the 1636 =0C 1637 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1639 October 2003 1641 IANA assigned values as defined in this document. However, they may 1642 then choose to define a value of "5" for the Signature Group for 1643 their own reasons. 1645 The third byte of the Ver field defines the Hash Algorithm. It is 1646 envisioned that this will also be a monotonically increasing value 1647 with a maximum value of "9". The value of "1" is defined in this 1648 document as the first assigned value and is SHA1 FIPS-180-1.1995 = 1649 [2]. 1650 Subsequent values will be assigned by the IANA using the "IETF 1651 Consensus" policy defined in RFC 2434 [16]. 1653 The forth and final byte of the Ver field defines the Signature 1654 Scheme. It is envisioned that this too will be a monotonically 1655 increasing value with a maximum value of "9". The value of "1" is 1656 defined in this document as OpenPGP DSA - RFC 2440 [17], 1657 FIPS.186-1.1998 [1]. Subsequent values will be assigned by the IANA 1658 using the "IETF Consensus" policy defined in RFC 2434 [16]. The 1659 fields, values assigned in this document and ranges are illustrated 1660 in the following table. 1662 Field Value Defined IANA Assigned Vendor Specific 1663 in this Document Range Range 1664 ----- ---------------- ------------- --------------- 1665 Ver 1666 ver 01 01-50 50-99 1667 hash 1 0-9 -none- 1668 sig 1 0-9 -none- 1670 If either the Hash Algorithm field or the Signature Scheme field is 1671 needed to go beyond "9" within the current version (first two = 1672 bytes), 1673 the IANA should increment the first two bytes of this 4 byte field = 1674 to 1675 be the next value with the definition that all of the subsequent 1676 values of fields described in this section are reset to "0" while 1677 retaining the latest definitions given by the IANA. For example, 1678 consider the case that the first two characters are "23" and the 1679 latest Signature Algorithm is 4. Let's say that the latest Hash 1680 Algorithm value is "9" but a better Hash Algorithm is defined. In 1681 that case, the IANA will increment the first two bytes to become 1682 "24", retain the current Hash Algorithm to be "0", define the new 1683 Hash Algorithm to be "1" in this scheme, and define the current 1684 Signature Scheme to also be "0". This example is illustrated in the 1685 following table. 1687 Current New - Equivalent New with Later 1688 to "Current" Algorithms 1689 ------- -------------- --------------- 1690 ver =3D 23 ver =3D 24 ver =3D 24 1691 hash =3D 9 hash =3D 0 hash =3D 1 1693 =0C 1694 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1696 October 2003 1698 sig =3D 4 sig =3D 0 sig =3D 0 1700 8.2 SIG Field 1702 The SIG field values are numbers as defined in section Section 3.5. 1703 Values "0" through "3" are assigned in this document. The IANA = 1704 shall 1705 assign values "4" through "7" using the "IETF Consensus" policy 1706 defined in RFC 2434 [16]. Values "8" and "9" shall be left as vendor 1707 specific and shall not be assigned by the IANA. 1709 8.3 Key Blob Type 1711 Section Section 4.2 defines five, one character identifiers for the 1712 key blob type. These are the uppercase letters, "C", "P", "K", "N", 1713 and "U". All other uppercase letters shall be assigned by the IANA 1714 using the "IETF Consensus" policy defined in RFC 2434 [16]. 1715 Lowercase letters are left as vendor specific and shall not be 1716 assigned by the IANA. 1718 =0C 1719 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1721 October 2003 1723 9. Authors and Working Group Chair 1725 The working group can be contacted via the mailing list: 1727 syslog-sec@employees.org 1729 The current Chair of the Working Group may be contacted at: 1731 Chris Lonvick 1732 Cisco Systems 1733 Email: clonvick@cisco.com 1735 The authors of this draft are: 1737 John Kelsey 1738 Email: kelsey.j@ix.netcom.com 1740 Jon Callas 1741 Email: jon@callas.org 1743 =0C 1744 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1746 October 2003 1748 10. Acknowledgements 1750 The authors wish to thank Alex Brown, Chris Calabrese, Carson = 1751 Gaspar, 1752 Drew Gross, Chris Lonvick, Darrin New, Marshall Rose, Holt Sorenson, 1753 Rodney Thayer, Andrew Ross, Rainer Gerhards, Albert Mietus, and the 1754 many Counterpane Internet Security engineering and operations people 1755 who commented on various versions of this proposal. 1757 =0C 1758 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1760 October 2003 1762 References 1764 [1] National Institute of Standards and Technology, "Digital 1765 Signature Standard", FIPS PUB 186-1, December 1998, . 1768 [2] National Institute of Standards and Technology, "Secure Hash 1769 Standard", FIPS PUB 180-1, April 1995, . 1772 [3] American National Standards Institute, "USA Code for 1773 Information Interchange", ANSI X3.4, 1968. 1775 [4] Menezes, A., van Oorschot, P. and S. Vanstone, ""Handbook of 1776 Applied Cryptography", CRC Press", 1996. 1778 [5] Mockapetris, P., "Domain names - concepts and facilities", STD 1779 13, RFC 1034, November 1987. 1781 [6] Mockapetris, P., "Domain names - implementation and 1782 specification", STD 13, RFC 1035, November 1987. 1784 [7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1785 Recommendations for Security", RFC 1750, December 1994. 1787 [8] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. 1789 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1790 Extensions (MIME) Part One: Format of Internet Message = 1791 Bodies", 1792 RFC 2045, November 1996. 1794 [10] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with 1795 Replay Prevention", RFC 2085, February 1997. 1797 [11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1798 for Message Authentication", RFC 2104, February 1997. 1800 [12] Bradner, S., "Key words for use in RFCs to Indicate = 1801 Requirement 1802 Levels", BCP 14, RFC 2119, March 1997. 1804 [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", = 1805 RFC 1806 2279, January 1998. 1808 [14] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1809 Specifications: ABNF", RFC 2234, November 1997. 1811 [15] Hinden, R. and S. Deering, "IP Version 6 Addressing 1812 Architecture", RFC 2373, July 1998. 1814 =0C 1815 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1817 October 2003 1819 [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1820 Considerations Section in RFCs", BCP 26, RFC 2434, October 1821 1998. 1823 [17] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, = 1824 "OpenPGP 1825 Message Format", RFC 2440, November 1998. 1827 [18] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 1828 for version 3 of the Simple Network Management Protocol 1829 (SNMPv3)", RFC 2574, April 1999. 1831 [19] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 1833 [20] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, 1834 November 2001. 1836 [21] Klyne, G. and C. Newman, "Date and Time on the Internet: 1837 Timestamps", RFC 3339, July 2002. 1839 [22] Schneier, B., "Applied Cryptography Second Edition: protocols, 1840 algorithms, and source code in C", 1996. 1842 Authors' Addresses 1844 John Kelsey 1846 EMail: kelsey.j@ix.netcom.com 1848 Jon Callas 1849 PGP Corporation 1851 EMail: jon@callas.org 1853 =0C 1854 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1856 October 2003 1858 Intellectual Property Statement 1860 The IETF takes no position regarding the validity or scope of any 1861 intellectual property or other rights that might be claimed to 1862 pertain to the implementation or use of the technology described in 1863 this document or the extent to which any license under such rights 1864 might or might not be available; neither does it represent that it 1865 has made any effort to identify any such rights. Information on the 1866 IETF's procedures with respect to rights in standards-track and 1867 standards-related documentation can be found in BCP-11. Copies of 1868 claims of rights made available for publication and any assurances = 1869 of 1870 licenses to be made available, or the result of an attempt made to 1871 obtain a general license or permission for the use of such 1872 proprietary rights by implementors or users of this specification = 1873 can 1874 be obtained from the IETF Secretariat. 1876 The IETF invites any interested party to bring to its attention any 1877 copyrights, patents or patent applications, or other proprietary 1878 rights which may cover technology that may be required to practice 1879 this standard. Please address the information to the IETF Executive 1880 Director. 1882 Full Copyright Statement 1884 Copyright (C) The Internet Society (2003). All Rights Reserved. 1886 This document and translations of it may be copied and furnished to 1887 others, and derivative works that comment on or otherwise explain it 1888 or assist in its implementation may be prepared, copied, published 1889 and distributed, in whole or in part, without restriction of any 1890 kind, provided that the above copyright notice and this paragraph = 1891 are 1892 included on all such copies and derivative works. However, this 1893 document itself may not be modified in any way, such as by removing 1894 the copyright notice or references to the Internet Society or other 1895 Internet organizations, except as needed for the purpose of 1896 developing Internet standards in which case the procedures for 1897 copyrights defined in the Internet Standards process must be 1898 followed, or as required to translate it into languages other than 1899 English. 1901 The limited permissions granted above are perpetual and will not be 1902 revoked by the Internet Society or its successors or assignees. 1904 This document and the information contained herein is provided on an 1905 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1906 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1907 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1909 =0C 1910 Internet-Draft The syslog Protocol and Signed syslog Messages =20= 1912 October 2003 1914 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1915 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1917 Acknowledgment 1919 Funding for the RFC Editor function is currently provided by the 1920 Internet Society. 1922 =0C