idnits 2.17.1 draft-debeaupuis-saf-00.txt: -(91): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(101): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(124): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(133): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(146): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(150): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(151): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(296): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 14 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC2350]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (19 May 1999) is 9106 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2234' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'US-ASCII' is defined on line 287, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Duplicate reference: RFC2234, mentioned in 'RFC2350', was also mentioned in 'RFC2234'. ** Obsolete normative reference: RFC 2234 (ref. 'RFC2350') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-debeaupuis-saf-00.txt T. Debeaupuis 2 INTERNET DRAFT HSC 3 Expires: 19 November 1999 19 May 1999 5 Security Advisory Format 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 This is first drafty Internet-draft of the Security Advisory Format. 13 A lot of work still to be done in clarifying, removing mistakes and 14 work on the specification of unique names for components impacted by 15 vulnerabilities. Internet-Drafts are working documents of the 16 Internet Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working documents 18 as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet-Draft, please check the 32 3id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim), 35 ds.internic.net (US East Coast). 37 Distribution of this document is unlimited. 39 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 40 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 41 'OPTIONAL' in this document are to be interpreted as described in 42 RFC 2119 [RFC2119]. 44 Abstract 46 This memo describes a format for security advisories. An advisory is 47 a document describing a vulnerability of a program, an operating 48 system or, more generally, a software or hardware component of the 49 information system. 51 This specification tries to minimize changes in issuer and readers 52 current practices (messages style), and by trying to help a program 53 re-read the advisory tries also to keep advisories easily and 54 friendly readable by humans. It focuses on structure of documents. 56 This specification is primarily useful for advisories issuers such as 57 CSIRTs [RFC2350] and users and is linked with intrusion detection. 59 Copyright Notice 61 Copyright (C) The Internet Society (1998). All Rights Reserved. 63 1. Table of Contents 65 1. Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Changes since last version . . . . . . . . . . . . . . . . . . . 2 67 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 68 4. Design goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 5. Security Advisory Format . . . . . . . . . . . . . . . . . . . . 3 70 5.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 5.2. Advisory encoding . . . . . . . . . . . . . . . . . . . . . . . 4 72 5.3. Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 5.4. SAF grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 8. APPENDIX 1 - Current advisories semantics . . . . . . . . . . . . 7 78 2. Changes since last version 80 Not applicable at this time. 82 3. Introduction 84 We face different information issuers : 85 - CSIRTs 86 - Vendors 87 - Groups of people studying vulnerabilities 89 Different needs : 90 - Advisory submitters will find in this format a more efficient way 91 to inform the or their community. Internally to the Advisory submit� 92 ter organisation, this format can also be used to ease the handling 93 of advisories. 95 - IT security officers : within organizations, IT security officers 96 need to know know what are the vulnerabilities of a specific 97 operating system or software, and in a more general way, a software 98 or hardware component. 100 - Numerous categories of people (intrusion detection people, 101 researchers, vendors, security consulting firms) are commonly work� 102 ing on advisories as a building block of their work : investiga� 103 tions, auditing softwares (on system or network). A common format 104 will help them entering datas in the databases without spending time 105 to re-organized and formalized advisories. This format aim will 106 also be useful for management tools (IDS frameworks, network secu� 107 rity management) to correlate alarms and advisories. 109 The problem that we are facing today is a lake of standardization 110 between the different formats used to report vulnerabilities. 112 4. Design goals 114 The design goals of SAF are as follows : 116 (1) SAF must suit to security advisory issuers as of users of 117 those advisories, 119 (2) SAF must be parsable by a program, 121 (3) SAF should not modify too much current practices and ways of 122 working. SAF should not modify too much advisories looks-and-feel. 124 (4) SAF must not impose content or order of informations in advi� 125 sories. 127 5. Security Advisory Format 129 5.1. Definitions 131 Advisory : 132 A text document announcing to a community a vulnerability in a 133 component of an information system. For example, a software appli� 134 cation, a packaging of an application, an operating system, a 135 router hardware. 137 Vulnerability : 138 An intrinsic or external provocted fail of a component of the 139 information system leading to decrease the security protection 140 level of a resource. 142 Impact : 143 the damage provoked if the vulnerability is exploited. 145 Patch : 146 a peace of software replacing the misfunctioning parts of the com� 147 ponent to eradicate the vulnerability. 149 Workaround : 150 a procedure describing a change in the configuration that can pro� 151 tect the component from being corrupted by a the exploit of a vul� 152 nerability without applying patches. 154 5.2. Advisory encoding 156 SAF is a token based labeling language. A SAF advisory is a 7 bit US- 157 ASCII document or 8 bit ISO 8859-1 text document. Implementations 158 MUST support both encodings. 160 5.3. Sections 162 Advisories are composed of sections. Sections order is NOT enforced. 164 5.4. SAF grammar 166 A SAF document can be encoded intro two formats : an XML document 167 conforming the DTD provided in this document, or a readable and 168 parsable text format (to be defined). 170 171 172 173 174 175 178 179 184 186 189 192 197 199 200 201 202 203 205 207 209 210 212 213 215 216 218 219 221 222 224 225 226 228 229 231 232 234 235 237 238 239 240 241 247 248 249 251 252 254 255 257 258 260 261 266 268 6. Security Considerations 270 This document describes a format which aim is not to improve security 271 of advisories (transmission, trust, archiving). It can help security 272 officers having a better view of the vulnerabilities impacts on their 273 systems by facilitating advisories re-treatment by automatic or semi- 274 automatic programs. 276 7. References 278 [RFC2234] "Augmented BNF for Syntax Specifications: ABNF", D. 279 Crocker, P. Overall, RFC 2234, November 1997. 281 [RFC2350] "Expectations for Computer Security Incident Response" N. 282 Brownlee, E. Guttman, RFC 2234, June 1998. 284 [RFC2119] Key works for use in RFCs to Indicate Requirement Levels, 285 S. Bradner, RFC 2119, March 1997. 287 [US-ASCII] United States of America Standards Institute (now American 288 National Standards Institute), X3.4, 1968, "USA Code for Information 289 Interchange". ANSI X3.4-1968 has been replaced by newer versions with 290 slight modifications, but the 1968 version remains definitive for the 291 Internet. 293 8. APPENDIX 1 - Current advisories semantics 295 Note : the annexes are only for information. They are helpful and 296 will be deleted in the future because we are not trying to standard� 297 ize CSIRTs current formats, but to propose an evolution and a merge 298 of those formats. 300 This section uses ABNF but is not a lexical definition of advisories 301 but rather a semantical grammar description of advisories. 303 CERT 305 Types of advisories : 306 - Vendor initiated bulletins 308 = 309 310 311 313 - CERT advisories 315 = 316 317 318 319 * 320 321 322 323 325 = 1* 327 = 328 330 - Advisories released by other CSIRTs and forwarded by CERT with or 331 without 332 added-value. 333 - CERT Summaries 335 CIAC 337 - CIAC Bulletin 339 = 340 * 342 = crlf crlf crlf crlf 343 crlf <DATE><ADVISORY-NUMBER> 345 <SUMUP> = <HRULE> crlf <PROBLEM> crlf <PLATFORM> crlf <DAMAGE> 346 crlf <SOLUTION> crlf <HRULE> <VULNERABILITY> crlf 347 <ASSESSMENT> 349 <DESCRIPTION> = 351 <VENDOR-SPECIFIC-INFORMATION> = 353 AUSCERT 355 <AUSCERT-ADVISORY> = <TITLE-BANNER> crlf 356 <SUMMARY> crlf 357 <CONTENT> 359 <TITLE-BANNER> = <PARTNUM> 360 <TITLE> 361 <DATE> 362 <LAST-REVISED> 363 <INTRODUCTION> 365 <LAST-REVISED> = <DATE> " " <ACTION> 367 <CONTENT> = <DESCRIPTION> 368 <IMPACT> 369 <WORKAROUND> 370 <MOREINFO> 371 <THANKS> 372 <WARRANTY> 373 <ADDRESS> 374 <REVISION-HISTORY> 376 MICROSOFT 378 - Paragraphs are left aligned, close to the border 379 - Lists are indented at 1 and 3 spaces 380 - Sections are introduced by a section name without number, under� 381 lined with "=". 382 A blank line is used before a section title and the section text is 383 directly 384 added on the line following the section underlines. 385 - Tokens are : 387 Originally Posted : date of first release of the advisory, 389 Summary : sum-up. What is affected, on which systems, what's the 390 impact, is there are patches, workarounds ? 392 Issue : What's the technical problem of the vulnerability ? 394 Affected Software Versions : list of affected components 396 What Microsoft is Doing : tell if patches (fixes), knowledge base 397 article are available, tell the fix references for each impacted 398 components. 400 What customers should do : explanation of fixes (supported but not 401 regression tested). No specific information. 403 More Information : references (URLs) for this advisory, and the 404 Knowledge Base article. 406 Obtaining Support on this Issue : Reference to subscribe to sup� 407 port. 409 Acknowledgements : thanks to people who has reported the problem. 411 Revisions : list of revision of this document. For each revision, 412 date of revision and comment are given. 414 <MICROSOFT-BULLETIN> = <TITLE> 415 <POSTED-DATE> 416 <REVISED-DATE> 417 <SUMMARY> 418 <ISSUE> 419 <AFFECTED-SOFTWARE> 420 <WHAT-MICROSOFT-DOING> 421 <WHAT-TO-DO> 422 <WORKAROUND> 423 <MORE-INFORMATION> 424 <REVISIONS> 425 <WARRANTY> 426 <COPYRIGHT> 427 <MAILING-LIST-INFO> 429 CISCO 431 <CISCO-SECURITY-NOTICE> = <FIELD-NOTICE> <HRULE> 432 <REVISION> 433 <RELEASE-DATE> 434 <CONFIDENTIALITY> 435 <SUMMARY> 436 <AFFECTED-TEXT> 437 <IMPACT> 438 <BUGREF> 439 <LIST-OF-AFFECTED-AND-PATCHES> 440 <WORKAROUND> 441 <EXPLOITATION> 442 <NOTICE-STATUS> 443 <DISTRIBUTION-REFERENCES> 444 <REVISION-HISTORY> 445 <CISCO-SECURITY-PROCEDURES> 446 <HRULE> 447 <COPYRIGHT> 449 <SGI-ADVISORY> = <HEADINGS> 450 <WARNING> 451 <DESCRIPTION> 452 <IMPACT> 453 <WORKAROUND>? 454 <SOLUTION> 455 <ACKNOWLEDGMENTS> 456 <SGI-CONTACTS> 458 <HEADINGS> = <TITLE> 459 <NUMBER> 460 <DATE> 462 <SOLUTION> = <PATCH-URL> 463 1*(<OS-NAME> <VULNERABLE> <PATCH-NUMBER> 464 <ACTION>) 466 L0pht 468 <L0PHT-ADVISORY> = <HEADINGS> 469 <DESCRIPTION> 470 <IMPACT> 471 <SOLUTION> 473 <HEADINGS> = <URL-REF> 474 <RELEASE-DATE> 475 <COMPONENT-IMPACTED> 476 <OPERATING-SYSTEM> 477 <IMPACT> 478 <PATCH-AVAILABILITY> 480 - Repent Security Incorporated, RSI 482 <RSI-ADVISORY> = <TITLE> 484 <TITLE> = <PART-NUM> 485 <BANNER> 487 - Herv� Schauer Consultants, HSC 489 <HSC-ADVISORY> = "(" <SOURCE> ") " <TITLE> "(" <DATE> ")" crlf 490 <OBJETS-TOUCHES> 491 <IMPACT> 492 <DESCRIPTION> 493 <PARADE> 494 <CORRECTIFS> 496 <OBJETS-TOUCHES> = *<OBJET-TOUCHE> 498 <CORRECTIFS> = 500 Acknowledgements 502 Many thanks to Barbara Fraser and Jean-Michel Cornu for there support. 504 Author's Address 506 Tristan Debeaupuis 507 Herv� Schauer Consultants 508 142, rue de Rivoli 509 75001 Paris 510 France 512 Phone: +33 141 409 700 514 Email: Tristan.Debeaupuis@hsc.fr 516 Comments should be sent directly to the author.