idnits 2.17.1 draft-staniford-cidf-data-formats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3.1 Introduction' ) ** The document seems to lack a Security Considerations section. ** 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 833: '...extension SID MUST follow the SID or e...' RFC 2119 keyword, line 918: '...he referent SIDs MAY carry actual sema...' RFC 2119 keyword, line 967: '... header. A producer MUST NOT re-use a...' RFC 2119 keyword, line 1058: '...into a GIDO, the SID MUST be used with...' RFC 2119 keyword, line 1060: '...ix B). The SID's argument(s) MUST have...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 draft-staniford-cidf-data-formats-00.txt 4 Expires September 18th, 1998 6 The Common Intrusion Detection Framework - Data Formats 8 Stuart Staniford-Chen, UC Davis 9 Brian Tung, ISI 10 Phil Porras, SRI 11 Cliff Kahn, The Open Group 12 Dan Schnackenberg, Boeing Corp. 13 Rich Feiertag, Trusted Information Systems. 14 Maureen Stillman, Odyssey Research Associates 16 Status Of This Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference material 26 or to cite them other than as "work in progress." 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 31 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 32 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This document defines portions of the Common Intrusion Detection 37 Framework (CIDF), specifically the data formats used. CIDF is designed 38 to allow intrusion detection systems (IDS) to interoperate with one 39 another. 41 Two layered formats are defined here: Gidos, which are a high-level data 42 structure intended to allow IDS systems to exchange messages describing 43 the state of the world, events occurring, and recommended actions with 44 somewhat standardized semantics. Gidos can be encoded in CIDF messages, 45 the format for which is also defined here. 47 Contents 49 0: Preamble 50 0.1 Introduction 51 0.2 Organization of this document 52 1 Architecture 53 1.1 Introduction 54 1.2 Functional decomposition (E-boxes, A-boxes etc). 55 1.3 Layering scheme 56 2 Gidos and S-expressions 57 2.1 Introduction to the gido format 58 2.2 Gido Requirements and Rationale 59 2.3 GIDO S-expression format 60 2.4 Parts of a GIDO payload 61 2.5 Detailed Examples 62 2.6 Rules and Guidelines for Defining SIDs 63 2.7 Example CIDF Module GIDO Sets 64 2.8 Negotiation 65 3 Encoding Gidos in Bytes 66 3.1 Introduction 67 3.2 Gido header 68 3.3 S-expression encoding 69 4 CIDF Communication 70 4.1 CIDF message layer formats 71 4.2 CIDF Message Processing 72 A. Primitive Type Definitions 73 B. SIDS List 74 ======================================================================== 75 = 0.1: Introduction to CIDF 76 ======================================================================== 78 The goal of the Common Intrusion Detection Framework is a set of 79 specifications which allow 80 * different intrusion detection systems to inter-operate and 81 share information as richly as possible, 82 * components of intrusion detection systems to be easily re-used 83 in contexts different from those they were designed for. 85 The CIDF working group came together originally in January 1997 at the 86 behest of Teresa Lunt at DARPA in order to develop standards to 87 accomplish the goals outlined in the previous section. She was 88 particularly concerned that the various intrusion detection efforts she 89 was funding be usable and reusable together and have lasting value to 90 customers of intrusion detection systems. 92 During the life of the effort, it became clear that this was of wider 93 value than just to DARPA contractors, and the group was broadened to 94 include representatives from a number of government, commercial, and 95 academic organizations. After the first few months, membership in the 96 CIDF working group was open to any individuals or organizations that 97 wished to contribute. No cost was involved (except to defray meeting 98 expenses). 100 Major decisions were made at regular (every few months) meetings of the 101 working group. Those decisions were made by rough consensus of all 102 attendees. That is, the meeting facilitator attempted to reach 103 consensus, but in situations where only one or two individuals were 104 protesting a decision, they were overruled in the interest of 105 efficiency. No decisions were taken in the face of opposition from a 106 sizeable minority, rather the issue was tabled for further 107 consideration. Meetings were fun and the working group had a good time 108 doing this (well, most of them, anyway). 110 In between meetings, most of the writing was done by small subgroups or 111 individuals. Their text was brought back for approval/changes at 112 meetings. Discussions were also carried on in the working group mailing 113 list, but few decisions were made that way. 115 The CIDF working group is now seeking to become an IETF working group. 117 ======================================================================== 118 = 0.2: Organization of this document 119 ======================================================================== 121 This section describes the organization of this internet draft on CIDF 122 data formats. 124 CIDF consists of the following things: 126 1) A set of architectural conventions for how different parts 127 of intrusion detection systems can be modeled as CIDF 128 components. 130 2) A way to represent gidos (generalized intrusion detection 131 objects). Gidos can 132 * describe events that have happened in the systems mo 133 by an IDS, 134 * instruct an IDS to carry out some action 135 * query an IDS as to what has happened. 136 * describe an IDS component. 138 3) A way to encode gidos into streams of bytes suitable for 139 transmission over a network or storage in a file. 141 4) Protocols for CIDF components to find each other over a 142 network and exchange gidos. 144 5) Application Programming Interfaces to re-use CIDF 145 components. 147 This internet draft is mainly concerned with the Gido data structure, 148 (appearing in Chapter 2), how gidos get encoded on the wire (appearing 149 in Chapter 3), and the message formats (in chapter 4). However, as an 150 orientation, the architectural view is covered in Chapter 1. 152 APIs and mechanisms for location of components are not discussed in this 153 draft. 155 0.2.1: Format 157 This document complies with the requirements for RFC 1543, the format 158 for ASCII Internet RFCs. In summary, this means that lines are at most 159 72 characters long and that they are terminated with a carriage-return, 160 line-feed pair. Pages are at most 58 lines long and are terminated with 161 a form-feed character. Paragraphs are single spaced and are separated 162 by blank lines. 164 Lines in the text beginning with "#" denote editorial comments which 165 should be removed before the final version. 167 The document is also divided into sections which are further divided 168 into subsections, subsubsections, and so on. The numbering convention 169 is as "3.4.1", which describes the first subsubsection of the fourth 170 subsection of the third section. Appendices are lettered, and so an 171 Appendix subsection might be B.4.2. 173 ======================================================================== 174 ======================================================================== 175 = 176 = 1: CIDF Architecture 177 = 178 ======================================================================== 179 ======================================================================== 180 = 181 ======================================================================== 182 = 1.1: Introduction 183 ======================================================================== 185 This section introduces the architectural framework that CIDF assumes 186 will structure an intrusion detection system. This scheme is basically 187 a framework around which interfaces and the communication protocols are 188 organized. It is not mandated that CIDF-conformant intrusion detection 189 systems must be organized in exactly this way. But they must support 190 interfaces that are so organized. 192 Section 1.2 introduces the various different kinds of components that 193 CIDF believes are needed in IDS systems. Section 1.3 covers the 194 communication layering scheme, and section 1.4 discusses how components 195 are named and located. 197 ======================================================================== 198 = 1.2: CIDF Functional Decomposition 199 ======================================================================== 201 All CIDF components deal in *gidos* (generalized intrusion detection 202 objects) which are represented via a standard common format. Gidos are 203 data that is moved around in the intrusion detection system. Gidos can 204 represent events that occurred in the system, analysis of those events, 205 prescriptions to be carried out, or queries about events. 207 CIDF defines four interfaces that CIDF components may implement: 209 || Push-style | Pull-style 210 =========++========================+======================= 211 || Produces gidos when it | Produces gidos 212 Producer || wants to, typically in | when queried. 213 || response to events. | 214 ---------++------------------------+----------------------- 215 || Mates with push-style | Mates with pull- 216 Consumer || producer. | style producer. 217 || | 219 Each of these interfaces takes two forms: a callable form, which permits 220 reuse of the component, and a protocol form, which permits the component 221 to interoperate with other CIDF components. 223 CIDF defines several types of preferred components: 225 * Event generators 226 * Analyzers 227 * Databases 228 * Response units 230 Figure 1.1 presents a schematic view of these components in a 231 hypothetical intrusion detection system. The solid boxes labeled E1, 232 E2, A1, A2, D, etc represent the various components of some hypothetical 233 intrusion detection system. It is convenient to think of these as 234 objects in the object-oriented programming sense (this does not dictate 235 an implementation in an object-oriented language or framework). 237 | | | 238 ,-------|--------|---------|---------. 239 | | | | | 240 | V V V | 241 | ,------. ,------. ,------. | 242 | | E1 | | E2 | | E3 | | 243 | `------' `------' `------' | 244 | ^ ^ ^ | 245 | | | ,------' | 246 | | ,-------' | | 247 | | | ,---------' ,------. | 248 | V V V ,------>| A1 | | 249 <---------->| ,------. | `------' | 250 | | C |<-----' | 251 | | |<-----. | 252 | `------' | ,------. | 253 | ^ ^ `------>| A2 | | 254 | | | `------' | 255 | | `-----------. | 256 | | | | 257 | V V | 258 | ,------. ,------. | 259 | | D | | R | | 260 | `------' `------' | 261 | | | 262 `--------------------|---------------' 263 | 264 V 266 Figure 1.1: Types of CIDF components 268 Whether the individual components are separate processes or images, or 269 merely conceptually separate parts of the code in a single image is not 270 specified - both possibilities are covered by the CIDF specification. 272 CIDF allows for components to be aggregated together to masquerade as a 273 single component. In other words, a large number of (possibly 274 distributed) components can be tied together and present themselves to 275 the outside world through a single CIDF interface. 277 ##################################################################### 278 # 279 # Stuart comment: 280 # It is not clear at present how this last requirement is to 281 # be achieved. 282 # 283 ##################################################################### 285 1.2.1 Configuration and Directory Service 286 The box labelled C in Figure 1.1 represents the configuration and 287 directory services that tie components together via their standard CIDF 288 interfaces. A component initiating communication may avoid using these 289 services if it knows how to address its target directly, or uses non- 290 CIDF means to do so. Otherwise, these services allow a component either 291 to look up its target explicitly or to derive its communication 292 "partners" by looking up "gido classes". 294 Gido classes specify types of data that may be exchanged between 295 components. Components that wish to receive certain kinds of gidos 296 describe what they want; components producing event records describe 297 what it is they produce. The directory service, augmented by 298 intelligence local to each component, then takes care of associating 299 GIDO producers with appropriate GIDO consumers. In this mode of use, 300 components are thus relieved of the burden of identifying or locating 301 their partners in the intrusion-detection system. 303 This service is not discussed further 304 in this Internet draft. 306 1.2.2 Event Generators 308 The boxes labelled Ei in Figure 1.1 are event generators. Their role is 309 to obtain events from the larger computational environment outside the 310 intrusion detection system (symbolized by the arrows coming from outside 311 the large box), and provide them in the CIDF standard gido format to the 312 rest of the system. For example, event generators might be simple 313 filters that take C2 audit trails and convert them into the standard 314 format. Another event generator may passively monitor a network and 315 generate events based on the traffic thereon. A third might be 316 application code in an SQL database program which generates events 317 describing database transactions. 319 It seems that event generators are likely to be reusable in that CIDF 320 has a standard data format, and so converting features of typical 321 computational environments into that format will be a task that many 322 groups will need to perform. Hence, it is useful to specify a preferred 323 way to configure and use event generators. 325 Preferred event generators implement the push-style producer interface. 326 They create only gidos describing raw events, not gidos describing 327 analyses or prescriptions. 329 Preferred event generators provide events as soon as they occur (with 330 the possible exception of transport queuing). Storage of events is 331 handled in gido databases. 333 1.2.2 Event Analyzers 335 Analyzers are labeled by Ai in Figure 1.1. They are the components we 336 typically think of in the intrusion detection context. They obtain 337 gidos from other components, analyze them, and return new gidos (which 338 hopefully represent some kind of synthesis or summary of the input). 340 Thus for example, an analyzer might be a statistical profiling tool that 341 examines whether events being supplied to it now are statistically 342 unlikely to be from the same time series as events supplied to it in the 343 past. Another example is a signature tool that examines sequences of 344 events looking for particular patterns that represent known misuse of 345 the system. Another example would be a correlator that simply examines 346 events and attempts to determine whether they are causally related to 347 one another, and then puts them together into composite events which can 348 be further analyzed. Simple analyzers might be just filters that throw 349 away events that match certain patterns, or caches that only forward 350 events dissimilar from recently seen events. 352 A preferred event analyzer implements the push-style consumer interface, 353 whereby it obtains input, and the push-style producer interface, whereby 354 it reports analyses. The gidos it produces are analysis results, not 355 raw events nor prescriptions. 357 Again, preferred gido analyzers immediately pass through gidos (with the 358 exception of some processing delay). No provision is made for storage of 359 gidos by analyzers. 361 1.2.3 Event Databases 363 Databases are labeled by Di in Figure 1.1. These components exist 364 simply to give persistence to CIDF gidos where that is necessary. The 365 interfaces allow other components to pass gidos to the database, and to 366 query the database for gidos that it is holding. Databases are not 367 expected to change or process the gidos in any way (or at least to 368 maintain the illusion that they don't). 370 A preferred gido database implements the push-style consumer interface, 371 whereby it receives any sort of gido, 372 and the pull-style producer interface, whereby it responds 373 to queries. 375 It is not assumed that the database is a complex application (such as a 376 relational database). It may simply be a file. 378 1.2.4 Response Units 380 Response units are the soldier ants of the CIDF ant-heap. They carry 381 out prescriptions - gidos that instruct them to act on behalf of other 382 CIDF components. This is where functionality such as killing processes, 383 resetting connections, etc. would reside. Response units are not 384 expected to produce output except as acknowledgements. 386 A preferred response unit implements the push-style consumer interface, 387 whereby it receives prescriptions. It may also implement the push-style 388 producer interface, whereby it reports on its efforts to carry out the 389 prescriptions. 391 1.2.5 Other Components 393 Many other useful types of component are compatible with CIDF. For 394 example, a subsystem may record events in a non-CIDF format, but may 395 implement the pull-style producer interface so that CIDF components can 396 query its record of events. 398 A component may record gidos for archival purposes, thus needing only a 399 push-style consumer interface. 401 A component may observe the world and do some analysis or filtering 402 before creating gidos. Such a component implements the push-style 403 producer interface. 405 An event analyzer may consult a gido database. The analyzer would need 406 a pull-style consumer interface beside the usual push-style producer and 407 push-style consumer interfaces. 409 A component may carry out responses, like a response unit, but also 410 produce analyses, like an event analyzer. 412 ======================================================================== 413 = 1.3: Communication Layers 414 ======================================================================== 416 1.3.1: Background 418 CIDF supports both interoperability and reusability of components. As 419 such, a component may be communicating with another across the network, 420 or as part of the same executable. In addition, to the extent feasible, 421 CIDF avoids specifying a particular language or choice of network 422 protocols. To support this flexibility, the design is structured in 423 layers. Figure 1.2 shows the layers. 425 ------------------ 426 | APIs | 427 |----------------| 428 | Gido layer | 429 |----------------| 430 | message | 431 | layer | 432 |----------------| 433 | (negotiated) | 434 | transport | 435 | layer | 436 ------------------ 438 Figure 1.2 440 1.3.2: API Layer 442 At the top of figure 1.2 is an API layer indicating code-based 443 interfaces to the layers below. This is not discussed in this draft. 445 1.3.3: Gido layer 447 Independent of programming language, network protocols, etc, CIDF 448 defines common formats for intrusion detection data. This data comes in 449 discrete packages called gidos (generalized intrusion detection 450 objects). The organization of the data, its semantics for an IDS 451 component, and a way to encode it in bytes are all defined at this 452 level. 454 The rationale for this is to separate the issue of how data is organized 455 and what it means (gido layer) from how it is gotten in and out of 456 components (API layer) and moved across networks (message layer). Gidos 457 are discussed in sections 2 and 3 of this document. 459 1.3.4: Message layer 460 Gidos must be moved across networks. Certain features of this process 461 must be present for CIDF purposes and may not be provided by underlying 462 transport mechanisms (such as cryptography, CIDF addressing, etc). The 463 CIDF message layer is intended to provide this functionality. This 464 layer is addressed in section 4. Use of this layer is mandated for CIDF 465 components that are to be interoperable across a network. 467 1.3.5: Transport layer 469 The figure below illustrates the notion of two independently developed 470 CIDF modules that build to a common interface specification. CIDF 471 supports 473 For the two modules to communicate, they are required to employ the same 474 transport protocols that will establish the communication channel and 475 handle message passing. The introduction of the transport layer is 476 handled during the integration phase, as module developers negotiate and 477 agree upon a common transport channel. For example, both developers may 478 agree that sockets will be used for this communication session. Other 479 developers may decide they wish to employ secure RPC for a different 480 session. CIDF provides the flexibility to use different transport 481 mechanisms, and a negotiation mechanism to choose amongst them. The 482 reason for having an independent transport layer below the message layer 483 is that our only requirement is that the components understand the 484 messages. This is independent of the way in which messages are 485 transmitted. Different applications will require different transport 486 mechanisms. All components are required to support a default transport 487 mechanism, namely UDP. This is necessary in order to guarantee that two 488 components can talk at least enough to negotiate about which other 489 transport mechanism they might prefer. 491 Interoperation Among Independently-Developed 492 Intrusion-Detection Modules 494 +-------------+ +---+ +---+ +-------------+ 495 | Intrusion | | T | | T | | Intrusion | 496 | Detection | | R | | R | | Detection | 497 | Module X | | A | communication | A | | Module Y | 498 | | | N | interface | N | | | 499 | Developer 1 | | S | <-------------------->| S | | Developer 2 | 500 | | | P | negotiated | P | | | 501 | Language A | | O | during | O | | Language B | 502 | OS X | | R | integration | R | | OS Y | 503 +-------------+ | T | phase | T | +-------------+ 504 ^ +---+ +---+ ^ 505 / \ / \ 506 | | 507 | | 508 | Build-to +------------------+ Build-to | 509 | | | | 510 +-----------------| Common Interface |------------------+ 511 | Specification | 512 +------------------+ 514 Figure 1.3 516 ======================================================================== 517 = 2.1: Introduction to the gido format 518 ======================================================================== 520 2.1.1: Overview 522 This chapter specifies a standard gido format for use by CIDF 523 components. These components shall use this standard for disseminating 524 event records, analysis results, and countermeasure directives, to IDS 525 modules. The document both defines the syntactic structure of these 526 messages, and provides a method for defining the semantic content 527 necessary for interpreting the various data elements embedded within the 528 structure. 530 2.1.2: Organization 532 This section is organized as follows. Section 2.2 discusses the 533 requirements for the gido format and the rationale for our choice. 534 Section 2.3 summarizes S-expressions as we define them and use them for 535 gidos. Section 2.4 begins serious discussion of the semantic 536 identifiers we use, and how to put gido-sentences together. Section 2.5 537 provides some detailed examples. Section 2.6 contains some rules and 538 guidelines for defining new SIDS. Section 2.7 identifies the recommended 539 set of GIDOs (primarily internal status information) that all CIDF- 540 compliant modules should be able to produce. Section 2.8 discusses 541 requirements for gido format negotiation protocols. 543 Readers will probably wish also to consult Appendices A and B which list 544 all the currently defined data types and SIDS. 546 ======================================================================== 547 = 2.2: Gido Requirements and Rationale. 548 ======================================================================== 550 Under the CIDF data sharing model, components receive an input stream, 551 use this input to drive their internal analytical processing, and pass 552 the results to other components within an overall intrusion detection 553 architecture. The output of one component may be the input of another 554 component. Therefore, this specification closely coordinates the 555 structures of event records, analysis reports, and countermeasure 556 prescriptions. In many cases, current state information must also be 557 used in order to fully understand the meaning of events, hence this is 558 also encoded in gidos. This adoption of a single standard for both E-, 559 A-, and R-boxes provides significant advantages in the reduction of 560 interface complexity. In addition, this approach provides great 561 flexibility as intrusion-detection objectives move from component 562 analysis, to systems analysis, to system of systems analysis. 564 However, this relationship between event records and analysis results 565 does not necessarily extend beyond the specification of identical 566 gido structures. Event records, analysis results, and 567 countermeasure prescriptions remain dissimilar in significant ways: 569 o Event records represent the operational activity of the 570 analysis target, and may be produced in large volumes. Minor 571 losses of event records, while potentially damaging, will not 572 necessarily imply a significant compromise to operational security. 574 o Analysis results represent significant conclusions derived from 575 an analytical review of an event stream, and should represent a 576 significant reduction in volume from that of the event stream. 577 Minor losses of analysis results are far more critical to the 578 operation security of the target system than event records. 580 o Countermeasure results likewise should be low volume and sensitive 581 to loss. 583 Thus, while gidos encode events, analysis results, and countermeasure 584 prescriptions identically, other processing layers such as transport may 585 handle them differently. For example, specifications for event 586 transport may derive requirements that emphasize performance (e.g., 587 stateless UDP transmission), while analysis results dissemination 588 protocols may emphasize ensured delivery and accurate reassembly over 589 issues of performance (e.g., TCP transmission). Protocols for event 590 dissemination and analysis results reporting may also handle other 591 issues differently, such as security requirements. 593 The GIDO structure contains the actual data representing the event 594 record, analysis results, and countermeasure directives produced by 595 their respective CIDF components. The encoding scheme requires the 596 ability to express complex, self-defining data structures, while 597 providing efficient high-volume transmissions of predefined structures. 598 This specification uses S-expressions as the basic payload format. 600 S-expressions are a self-defining formatting scheme for representing 601 arbitrarily complex data structures. This message encoding 602 specification employs a very simplified form of S-expressions for event 603 record, analysis report, and countermeasure directive representation. 604 One of the motivations for this choice is that S-expressions in general 605 allow for an impressive degree of reasoning and formalism. 607 The design goals for the gido format are: 609 -- generality: Gidos should be capable of representing arbitrarily 610 complex data. 611 -- self-defining: Extensions to payload formatting should be 612 semantically defined within the payload itself. Consumers should 613 be able to learn or adjust to alterations in the expected format 614 or comprehend entirely new payload format. 615 -- simplicity: The encoding scheme should produce messages that 616 do not force complex parsing logic upon IDS module developers if tha 617 is not necessary in their application. The encoding scheme should b 618 easily understandable and gidos should have a human readable 619 representation. 620 -- efficiency: Payload expressions should represent data compactly. 621 The overhead of semantic self-definitions should be removable 622 when predefined messages are transported in bulk. 623 -- flexible: Payload expressions must be open to modification and 624 extensions to new data types, semantic information, and new 625 data structures. 626 -- independent of call semantics: Payload expression must be 627 supportive of both embedded data (call by value) messages and 628 data independent (call by reference) messages. 630 ======================================================================== 631 = 2.3 GIDO S-expression format 632 ======================================================================== 634 2.3.1 Preamble 636 In this section, we define how S-expressions are put together at a low 637 level in CIDF. This is the human readable format; the wire format is 638 defined in terms of this one in section 3.3. 640 In addition to questions of encoding format, this specification also 641 enumerates a set of CIDF-compliant default primitive data types and 642 semantic-identifiers (SIDs) used when expressing individual payload 643 fields. How SIDS should be combined into S-expressions that form 644 meaningful gidos is discussed in section 2.4 646 The primitive data types, presented in Appendix A, define the available 647 encoding used for field representation. Semantic-identifiers (SIDs), in 648 Appendix B, provide standard identifiers that gido consumers may use to 649 interpret the various data fields within a payload expression. 651 2.3.2 S-Expression Grammar 653 Following is the grammar for CIDF S-expressions in BNF. Terminal symbols 654 are represented in upper case. Literal characters are enclosed in 655 quotes ("). 657 ::= | "(" item-list ")" | 658 659 ::= "(" ")" | 660 "(" "def" SID ")" 661 ::= | 662 "(" ")" 663 ::= | 664 665 ::= SID | TYPE | NAME 666 ::= | 667 668 ::= DATA | 669 "(" ")" 671 Using this grammar, data fields are coupled with semantic identifiers 672 parenthetically. A SID indicates how its associated data element is 673 syntactically represented as well as the data element's semantic 674 content. A collection of parenthetical SID/Data tuples can themselves 675 be grouped together in outer parentheses, indicating an explicit 676 *association* of the SID/Data tuples (i.e., they represent attributes of 677 a larger element in the expression). SID grouping is discussed further, 678 with illustrations, in Section 2.3. 680 A SID is a unique token for a semantic identifier. TYPE is one of the 681 primitive types specified in Appendix A. NAME identifies a named element 682 of a structure. DATA is a data literal. 684 2.3.3: GIDO S-expression Examples 686 The following sections illustrate low-level ways of using S-expressions 687 to encode gido data structures. We give these examples for 688 concreteness, but see the next section for more information on how to 689 form gidos. 691 2.3.3.1: Embedded Semantics and Data Payload Example 693 This form is used for expressing field-oriented lists of data, where the 694 data is embedded within the message. The format consists of a series of 695 tuples, one tuple per data field. Each tuple consists of a semantic 696 identifier followed by its associated data item: 698 Format: (SID-1 data-exp-1)(SID-2 data-exp-2) . . . (SID-N data-exp-N) 700 In this format, their is a SID with each data item, providing a self- 701 defining message format. A consumer can parse the message for those 702 SIDs it understands and desires to analyze, and discard data fields 703 containing unknown or unwanted SIDs. As discussed in Appendix B, each 704 SID has an associated data type, which completes the self-definition of 705 the message. Thus, by parsing the SID tokens, the consumer knows both 706 how to interpret each data element semantically, and how the data 707 elements are syntactically represented. 709 2.3.3.2 Pre-defined Constant Payload Format 711 This form allows for semantics of predefined message structures to be 712 conveyed to consumers once. From that point forward, consumers can 713 receive and interpret raw data structures without the overhead of 714 embedded SIDs. This form is highly efficient for transporting high- 715 volumes of the same message type. This form is also used for 716 enumerating a pre-defined set of CIDF E/A-box messages (see Section 717 2.5). 719 A gido producer begin the message exchange by sending the consumer a 720 message definition statement. The "def" defines a new SID that can be 721 used subsequently. SID indicates the semantic identifier being defined. 722 SIDs are special identifiers in the language. Attempting to define a 723 SID that is already defined is an error. arg-list is a list of dummy 724 arguments that will be matched with the actual arguments in use to 725 evaluate the S-expression. sid-exp-1 defines the SID in terms of SIDs 726 and TYPEs that are already defined. sid-exp-1 may only contain SIDS 727 that have been predefined either because they are included in an 728 appendix to this document or they have been defined in a prior 729 definition. 731 Format1: (def SID arg-list sid-exp-1) 733 ##################################################################### 734 # Editor's Comment: The event subgroup has not resolved the 735 # issue of scope for dynamically defined SIDS. 736 ##################################################################### 737 ======================================================================== 738 = 2.4 Parts of a GIDO payload 739 ======================================================================== 741 2.4.1 Introduction 743 A GIDO consists of the GIDO header--which gives information pertaining 744 to the encapsulation of the GIDO, such as its version number, its 745 length, and so forth--and the GIDO payload. In this section, we will 746 describe how SIDs are put together to compose the GIDO payload using S- 747 expressions described in the last section. The Gido header is discussed 748 in section 3.2 750 A well-formed GIDO payload consists of one or more top-level 751 *sentences*. 753 Sentences are S-expressions that can be said to "assert" something. A 754 typical sentence might describe the state of a machine at a given time, 755 or it might report that a given event had taken place, or it might also 756 recommend that an action be taken to counter an attack. 758 A sentence may be composed of other sentences, connected in some way; 759 such a sentence is called a *compound sentence*. A sentence which is not 760 compound is called a *simple sentence*. Broadly speaking, a simple 761 sentence contains a *verb*, which describes what happened, and other S- 762 expressions that describe who verbed what, where, when, and how, and so 763 forth. 765 In the following sections, we will examine how each of these may be 766 denoted and described, and finally, put together to form a complete 767 sentence. 769 2.4.2. Verb SIDs 771 At the heart of a sentence is the *verb*. Normally, we think of verbs as 772 denoting some action (which may sound somewhat event-centric), but they 773 may also denote a recommendation, for instance, or description of state. 774 Each sentence has one main verb. An example of a verb SID is "Execute". 776 Verb SIDs, unlike most other SIDs, do not take a concrete data type for 777 an argument. Instead they take a sequence of one or more S-expressions. 778 These S-expressions describe the various "players" for the verb. In the 779 case of "Execute", we would be interested in what (program) was 780 executed, who executed it, where and when it was executed, and so on. 782 2.4.3. Role SIDs 784 A verb has little value until we describe who and what that verb applies 785 to. This is accomplished using *role* SIDs. A role denotes what part 786 an entity, or set of attributes, plays in a sentence. Examples of roles 787 are "Initiator" and "Operand". 789 Role SIDs, like verb SIDs, take a sequence of one or more S-expressions 790 as argument. These S-expressions describe the object, roughly speaking, 791 which is playing that role in the sentence. 793 Example: 795 (Initiator (RealName "Joe Cool") (UserName "joe") (UserID "1618")) 797 denotes a user, with real name "Joe Cool", user name "joe", and user ID 798 "1618", acting as Initiator. (Typically, an Initiator is someone who 799 causes an action to take place--such as executing a program.) 801 An S-expression headed by a role SID is called a *role clause*. 803 2.4.4. Extension SIDs 805 It is not expected that any component will understand all SIDs. A 806 component concerned with Unix notions will often not be worried about 807 X.500-related SIDs. Nevertheless, many X.500-related SIDs have their 808 complements in the Unix world, and the Unix component will want to 809 capture this information, even if it isn't cognizant of the exact use of 810 this information in the X.500 world. For instance, a user's real name 811 is a user's real name, although in Unix it might be the name in 812 /etc/passwd associated with the user's account, and in X.500 it may be a 813 Common Name. If these two concepts were expressed with two completely 814 distinct SIDs, then we would lose much of the benefits of data sharing. 816 Extension SIDs are designed to address this. Extension SIDs allow one 817 to specify information in a relatively generic fashion, and then give 818 more specialized receivers extra information about a SID that specifies 819 more precisely how it is to be used. For instance, an X.500 Common Name 820 would be expressed as follows: 822 (RealName (ExtendedBy X500CommonName) "Joe Cool") 824 Most components would be able to understand the RealName SID, and would 825 be able to capture the fact that the a user with the real name "Joe 826 Cool" is in question here. Additionally, any component who understands 827 X.500 would implement the X500CommonName extension, so that it knows 828 that the real name is registered as a Common Name, along with any 829 implications of that fact. 831 In general, a SID is *extended* by following it with a sequence of one 832 or more SID-pairs, each of which is tagged with the ExtendedBy SID. An 833 extension SID MUST follow the SID or extension which it extends. For 834 example, the following is well-formed: 836 (ObjectName (ExtendedBy DeviceName) (Extendedby UnixFullDeviceName) 837 ... 838 ) 840 where the ellipsis indicates the sequence of S-expressions qualifying 841 the ChangePrivilege verb. 843 An extended SID always takes the same *type* as the unextended (base) 844 SID. In fact, if one knows that a message will *only* be used by someone 845 who recognizes the extension, then it may omit the base class 846 altogether, and refer only to the extension. Therefore, for instance, 847 one could write 849 (X500CommonName "Joe Cool") 851 2.4.5. Conjunction SIDs 853 Conjunction SIDs join sentences at the same "level" together. Two 854 sentences that are simply juxtaposed together are presumed to mean that 855 both hold. That is, 857 859 means that both Sentence1 and Sentence2 hold. Other relationships are 860 indicated by the appropriate conjunction SID. For instance, to indicate 861 that Sentence1, Sentence2, and Sentence3 all had a common cause, one 862 writes 864 (CommonCause ) 866 2.4.6. Open S-Expressions 868 An open S-expression is one in which not all the data values are "filled 869 in", so to speak. It is used to express concepts such as " 870 removed ." Its only currently defined usage is in the def 871 construct, as follows: 873 (def RemoveFile ($username $filename) 874 (Remove 875 (Initiator (UserName $username)) 876 (Operand (ObjectType file) (ObjectName $filename)) 877 ) 878 ) 880 In later usage, we can express "The user with user name joe removed the 881 file /etc/passwd" in this way: 883 (RemoveFile "joe" "/etc/passwd") 885 Its general format is 887 (def () ) 889 2.4.7. Referent SIDs 891 There is a last special type of SIDs, called Referent SIDs. They are 892 placed at the end of this chapter, because they are not restricted to 893 the construction of a single sentence, but instead allow one to link two 894 or more sentences together (though they are often used to refer to other 895 parts of the same sentence). 897 The two referent SIDs are ReferAs and ReferTo. They take a string as 898 their data type. A SID-pair headed by a referent SID is called a 899 *referent clause*. A referent clause may be placed into either a 900 sentence or a role clause. Their interpretation varies depending on 901 where they appear: 903 * If a ReferAs clause is placed into a sentence, it can be said 904 to *refer* to that sentence, *except* for any ReferAs clauses. 905 (It is considered bad form to use more than one ReferAs clause 906 in the same sentence at the top level.) Thereafter, a use of 907 the corresponding ReferTo clause can be used in place of that 908 sentence (although see warning below). 910 * If a ReferAs clause is placed into a role clause, it is said 911 to refer to the object described by the sequence of S-expressions 912 following that role, *except* for any ReferAs clauses. (It is 913 considered bad form to use more than one ReferAs clause in the 914 same role clause.) Thereafter, a use of the corresponding 915 ReferTo clause can be used in place of that object description 916 (again, see warning below). 918 * WARNING. The referent SIDs MAY carry actual semantics, and are 919 not simply macros. If a ReferAs clause is placed into a sentence, 920 and that sentence refers to an event (say), then the ReferTo 921 clause refers specifically to that specific event, and not simply 922 to an event with the same attributes (which after all may not be 923 uniquely identifying). Similarly, if a ReferAs clause is placed 924 into a role clause, and that role clause describes an object (say) 925 then the ReferTo clause refers specifically to the same object, 926 and not simply to an object with the same attributes. 928 Of course, if no specific item is denoted by the ReferAs clause, 929 then this warning does not apply. For example, if ReferAs occurs 930 in an assertion of state, then it can be interpreted as simply a 931 macro, since there is no unique item being denoted. 933 As an example, consider the following sequence: 935 (Remove 936 (Initiator (RealName "Joe Cool")) 937 (Operand (FileName (ExtendedBy UnixPathName) "/etc/passwd")) 938 (AtTime (Time "1998 Feb 25 12:40:32 PST")) 939 (ReferAs "JoesDeletion") 940 ) 942 followed by 944 (HelpedCause 945 (ReferTo "JoesDeletion") 946 (Login 947 (Initiator (RealName "Mary Worth")) 948 (To (HostName "host.work.com")) 949 (Outcome (ExtendedBy UnixErrno) (ReturnCode 13)) 950 ) 951 ) 953 This indicates that the act of Joe Cool deleting /etc/passwd later 954 helped to prevent Mary Worth from logging in to host.work.com. Note 955 that this specific instance of Joe Cool deleting /etc/passwd is referred 956 to here. Even if (by resetting the clock, say) Joe Cool were to delete 957 /etc/passwd a second time with the same attributes, this construction 958 would still show that it was the *first* deletion that helped prevent 959 Mary Worth from logging in. 961 Since referent SIDs act across GIDOs, and hence potentially across 962 multiple messages (although not necessarily so), the question of scope 963 arises. The scope rule applying to Referent SIDs is as follows: The 964 value of a referent clause is the verb or role within which it is found 965 (roughly speaking), provided that that verb or role is in the same 966 thread. A thread is defined as the conjunction of the originator ID and 967 thread ID fields in the GIDO header. A producer MUST NOT re-use a 968 referent (such as "JoesDeletion") within the same thread, for 969 perpetuity. 971 2.4.8. Guidelines for Putting SIDs Together to Form Sentences 973 In this section, we describe how to use verb SIDs, role SIDs, 974 conjunction SIDs, and other kinds of SIDs to construct sentences. 976 2.4.8.1. Basic Organization 978 As noted above, a simple sentence is an S-expression headed by a verb 979 SID (which may be extended). This verb SID is followed by a sequence of 980 one or more S-expressions that describe the various entities that play 981 parts in the sentence, or qualify the verb. 983 The S-expressions denoting the roles of the sentence are headed by a 984 role SID, which may also be extended. This role SID is again followed 985 by a sequence of one or more S-expressions that may describe attributes 986 of the entity playing that role. It may also describe a sentence that 987 plays a role within the sentence. 989 A BNF-like grammar that specifies this structure is as follows. 991 ::= 992 | 993 ::= "(" 994 ")" 995 | "(" ") 996 | "(" ") 997 | "(" "def" ")" 998 ::= 999 | 1000 ::= "(" ") 1001 | "(" ") 1002 | "(" ")" 1003 | "(" "ReferAs" ")" 1004 ::= 1005 | 1006 ::= "(" "ExtendedBy" ")" 1007 ::= 1008 | 1009 ::= "(" "ReferTo" ")" 1011 In English: A GIDO payload is a SentenceList, which is a list of 1012 Sentences. 1014 A Sentence may be a ConjunctionSID, followed by a list of the Sentences 1015 it conjoins, or it may be a VerbSID, followed by a list of Qualifiers of 1016 that VerbSID. 1018 A Qualifier may be a RoleSID, followed by a list of Qualifiers of that 1019 RoleSID. A Qualifier may also be an AtomSID followed by its data. 1021 Any list of Qualifiers may contain a ReferAs clause. Thereafter, use of 1022 the corresponding ReferTo clause may stand in for that list of 1023 Qualifiers. 1025 Any SID may be followed by a list of Extensions. 1027 2.4.8.2. Understanding Sentences and the Principle of Connectedness 1029 The Principle of Connectedness simply states that when a component 1030 reading a GIDO encounters a SID it does not understand, the component 1031 must strictly ignore the S-expression that the SID heads. The component 1032 MUST NOT reject the GIDO on this ground. For instance, in the example 1033 below 1035 (InOrder 1036 (Delete 1037 (Initiator (FullName "Joe Hacker")) 1038 (Operand (ObjectType file) (ObjectName "/etc/passwd")) 1039 ) 1040 (Execute 1041 (Initiator (UserName "sysadmin")) 1042 (Operand (ObjectType program) (ProgramName "SystemCheck")) 1043 ) 1044 ) 1046 if a component does not understand the Delete verb SID, it may not make 1047 use of the Initiator and Operand SIDs within that sentence, even if it 1048 understands those, because it will not understand what they are the 1049 Initiator and Operand *of*. 1051 This is called the Principle of Connectedness because the portion of the 1052 GIDO which is understood must form a connected tree. If a parent is not 1053 understood, its children should not be interpreted, as its relation to 1054 the portion of the tree contain the parent is unknown. 1056 2.4.8.3. Rules and Guidelines for Using SIDs 1058 Whenever a component puts a SID into a GIDO, the SID MUST be used with 1059 the number of arguments (usually one) that the SID's definition calls 1060 for (see the definitions in Appendix B). The SID's argument(s) MUST have 1061 the syntax and meaning that the SID's definition calls for. Otherwise 1062 the component is OUT OF CONFORMANCE with the SID's definition. 1064 A component that generates GIDOs MUST generate them in conformance with 1065 all of the SID definitions in this specification. 1067 Whenever the above rule permits, a component generating a GIDO SHOULD 1068 use a SID from this specification and SHOULD avoid the SIDs defined in 1069 the Uninterpreted SIDs section. If the only suitable SID in this 1070 specification is in the Uninterpreted SIDs section, then an 1071 implementation MAY use it or define a new SID; defining a new SID is 1072 usually better. 1074 If a component generating GIDOs uses a SID from a particular 1075 specification, and if that specification defines two applicable SIDs, 1076 one of which is strictly more specific than another, then the component 1077 SHOULD use the more specific one. 1079 If CIDF component X creates a sentence and CIDF component Y later has a 1080 copy of the sentence and passes it verbatim to CIDF component Z, then Y 1081 MAY do so even if the sentence violates the above rules and guidelines. 1082 The sentence MUST be passed verbatim and SHOULD be clearly ascribed to 1083 its originator. This provision frees D-boxes and such from having to 1084 thoroughly understand and validate every GIDO they process. 1086 However, if the CIDF component modifies any part of the sentence, then 1087 it is responsible for the sentence's compliance with the above rules and 1088 guidelines. 1090 ======================================================================== 1091 = 2.5. Detailed Examples 1092 ======================================================================== 1094 Now that the basic components of an S-expression have been presented, we 1095 illustrate how to utilize these components to express various records 1096 structures and messages that intrusion detection systems may wish to 1097 express. In the following examples, we walk the reader through the 1098 process of translating raw event structures, analysis results, and other 1099 candidate message structures into S-expressions. 1101 2.5.1. Translating a Basic Security Module Audit Record 1103 One very well-known form of security audit records are those introduced 1104 in Sun Microsystems' SunOS 4.1.X Basic Security Module (BSM). There are 1105 a variety of ways to translate BSM audit records into S-expressions, 1106 depending on the data elements that a CIDF module may be directed to 1107 filter or incorporate within its GIDOs. In this example we demonstrate 1108 the translation of a BSM audit record generated as a result of a 1109 successful rlogin request. 1111 2.5.1.1. BSM Record Description 1113 The raw BSM record describes an event in which an external user performs 1114 a successful remote login to target.machine.com from source.machine.com. 1115 A session is established in which the resulting real and effective user 1116 IDs are set to thomas, the real and effective group IDs are set to 1117 staff, terminal 6 is assigned to the session, and the process and 1118 session IDs are set to 5345. 1120 The event is captured by the audit daemon on target.machine.com, which 1121 records the event as follows: 1123 Raw BSM Audit Record 1125 [header,86,2,login - rlogin,,Sat Jul 29 20:43:01 1995, 1126 + 280009000 msec subject,thomas,thomas,staff,thomas,staff, 1127 5345,5345,0 6, source.machine.com text,successful login return, 1128 success,0] 1130 2.5.1.2. BSM to S-Expression Translation Process 1132 Now we illustrate the underlying rationale used to translate a common 1133 event structure such as a BSM audit record into a CIDF S-Expression. As 1134 discussed in Section 3.2, we begin our S-expression construction by 1135 first defining the verb of our sentence in its most general form. In 1136 this case, the operation recorded in the BSM audit record is the 1137 establishment of a communication session between two entities via 1138 rlogin. As we parse the potential Verb SIDs available in Appendix B.2, 1139 we find that the SID most closely matching the rlogin operation is the 1140 BeginSession SID. While BeginSession captures well the underyling action 1141 represented in the audit record, we note that a Unix-specific extension 1142 is available for further refinement (as discussed in Section 3.4). The 1143 resulting S-expression is as follows: 1145 Example 2.5.1.2a BSM Rlogin S-Expression: 1147 - -->(BeginSession (ExtendedBy UnixRlogin) 1148 : 1149 : 1150 : 1151 - -->) 1153 The next step is to qualify the verb with supporting S-expressions that 1154 further enumerate the attributes of the event. In this case, the verb 1155 BeginSession has a series of supporting role clauses that can be derived 1156 from the BSM record (Section 3.4). These role clauses include: 1158 o the observer from which the event was recorded 1159 o the initiator of the BeginSession operation 1160 o the entity to whom the BeginSession was directed 1161 o the resulting state changes or resource(s) produced or 1162 destroyed by the operation (in our case this involves the 1163 attributes of the session established by the rlogin 1164 o and the outcome of the event 1166 >From the above categories of attributes we augment the S-expression 1167 with the following relevant role-clauses: 1169 Example 2.5.1.2b BSM Rlogin S-Expression: 1171 (BeginSession (ExtendedBy UnixRlogin) 1172 - --> (Observer (S-expression ...) ) 1173 - --> (Initiator (S-expression ...) ) 1174 - --> (To (S-expression ...) ) 1175 - --> (Operand (S-expression ...) ) 1176 - --> (Outcome (S-expression ...) ) 1177 ) 1179 Role clauses are selected for grouping associated datafields under a 1180 common contextual usage in the S-expression sentence. At this point, we 1181 switch our attention to incorporating associated datafields within the 1182 above role clauses. Datafields that cannot correctly be associated 1183 within the context of one of the available role clauses can still be 1184 incorporated in the S-expression independent simple sentences within the 1185 S-expression. 1187 In our example, the Observer clause provides a contextual association 1188 with all datafields that describe attributes of the oberserve, including 1189 when, where, and through which means (i.e., BSM data) the observation 1190 was recorded. The initiator clause is used to associate datafields that 1191 describe the entity responsible for the event. In this case, the BSM 1192 record provides very little information, other than hostname from which 1193 the request was sent. Similarly, the BSM record provides only the 1194 hostname of the recipient, which we document in the To clause. The 1195 Operand clause is used to describe object that has been affected by the 1196 event, which in this case was the creation of the session. - From the 1197 BSM audit record, we can include under the Operand clause the session's 1198 associated user attributes, group attributes, process/session 1199 attributes, and the device through which the session is supported. 1200 Lastl we enumerate the attributes of the outcome. 1202 Example 2.5.1.2.c Final BSM Rlogin S-Expression: 1204 Section Ref. 1205 ------------ 1206 (BeginSession (ExtendedBy UnixRlogin) -- B.2.5 1207 (Observer -- B.3.7 1208 - --> (AtTime (Time "Sat Jul 29 20:43:01 PDT 1995")) -- B.3.2 1209 - --> (HostName "target.machine.com") -- B.5.4 1210 - --> (ObservationSourceType "BSM-SunOS") -- B.5.1 1211 ) 1212 (Initiator -- B.3.1 1213 - --> (HostName "source.machine.com") -- B.5.4 1214 ) 1215 (To -- B.3.3 1216 - --> (HostName "target.machine.com") -- B.5.4 1217 ) 1218 (Operand -- B.3.1 1219 - --> (UnixAUserName "thomas") -- B.5.9.6 1220 - --> (UnixUserName "thomas") -- " 1221 - --> (UnixEUserName "thomas") -- " 1222 - --> (UnixGroupName "staff") -- " 1223 - --> (UnixEGroupName "staff") -- " 1224 - --> (ProcessID 5345) -- B.5.2 1225 - --> (SessionID 5345) -- B.5.2 1226 - --> (Through -- B.3.3 1227 - --> (ObjectName -- B.5.1 1228 - --> (ExtendedBy UnixFullDeviceName) -- B.5.1 1229 - --> "/dev/tty06") 1230 ) 1231 ) 1232 (Outcome -- B.3.6 1233 - --> (Severity 3) -- B.5.1 1234 - --> (ReturnCode -- B.5.1 1235 - --> (ExtendedBy UnixErrno) -- B.5.1 1236 - --> 0) -- B.5.1 1237 - --> (Comment "successful login") -- B.5.1 1238 ) 1239 ) 1240 2.5.2. Translating a TCP/IP Packet 1242 In the next example, we'll see how to translate the contents of an FTP 1243 connection request captured by a TCP/IP packet sniffer. Here the TCP/IP 1244 packet is observed being sent from an external client to the target 1245 host's FTP control port. The packet is translated by a CIDF module that 1246 attempts to describe the transaction from the perspecti of analyzing 1247 data sent to the application-layer (i.e, FTP) network servi 1249 2.5.2.1. TCP/IP Packet Description 1251 The observer in this example is a CIDF E-box that parses sniffed pacekts 1252 from a Sun Microsystem's Solaris machine. The observer's host platform 1253 i named snoopmachine.machine.com, and from this machine the observer 1254 attem to capture and translate traffic to and from the FTP control port 1255 of server.machine.com using the Solaris snoop(1) command: 1257 snoopmachine% snoop -v -d le0 -t a host server port 21 1259 The following is an example snoop-formatted packet produced be the 1260 observer: 1262 Raw TCP/IP Packet 1264 ETHER: ----- Ether Header ----- 1265 ETHER: 1266 ETHER: Packet 7 arrived at 8:59:49.05 1267 ETHER: Packet size = 70 bytes 1268 ETHER: Destination = 0:01:02:03:04:05, Western Digital 1269 ETHER: Source = 0:aa:bb:cc:dd:ee, 1270 ETHER: Ethertype = 0800 (IP) 1271 ETHER: 1272 IP: ----- IP Header ----- 1273 IP: 1274 IP: Version = 4 1275 IP: Header length = 20 bytes 1276 IP: Type of service = 0x00 1277 IP: xxx. .... = 0 (precedence) 1278 IP: ...0 .... = normal delay 1279 IP: .... 0... = normal throughput 1280 IP: .... .0.. = normal reliability 1281 IP: Total length = 56 bytes 1282 IP: Identification = 63187 1283 IP: Flags = 0x4 1284 IP: .1.. .... = do not fragment 1285 IP: ..0. .... = last fragment 1286 IP: Fragment offset = 0 bytes 1287 IP: Time to live = 38 seconds/hops 1288 IP: Protocol = 6 (TCP) 1289 IP: Header checksum = 69a3 1290 IP: Source address = 999.998.997.996, client.machine.com 1291 IP: Destination address = 111.121.131.141, server.machine.com 1292 IP: No options 1293 IP: 1294 TCP: ----- TCP Header ----- 1295 TCP: 1296 TCP: Source port = 12406 1297 TCP: Destination port = 21 (FTP) 1298 TCP: Sequence number = 820300070 1299 TCP: Acknowledgement number = 3095138926 1300 TCP: Data offset = 20 bytes 1301 TCP: Flags = 0x18 1302 TCP: ..0. .... = No urgent pointer 1303 TCP: ...1 .... = Acknowledgement 1304 TCP: .... 1... = Push 1305 TCP: .... .0.. = No reset 1306 TCP: .... ..0. = No Syn 1307 TCP: .... ...0 = No Fin 1308 TCP: Window = 61320 1309 TCP: Checksum = 0x4e8d 1310 TCP: Urgent pointer = 0 1311 TCP: No options 1312 TCP: 1313 FTP: ----- FTP: ----- 1314 FTP: "USER anonymous\r\n" 1315 The packet consists for four layers of structure: the Ethernet header, 1316 the IP header, the TCP header, and the FTP data portion. Working from 1317 the bottom up, we see that the packet represents an FTP "USER anonymous" 1318 request, which for FTP is equivalent to a BeginSession request for an 1319 anonymous FTP session. Above the FTP header are the TCP fields, 1320 containing, among other things, the source and destination ports (note 1321 the destination port is port 21, the FTP control protocol port). Above 1322 the TCP layer are the IP and Ethernet header, both containing datafields 1323 that could be of use to further identify the initiator and recipient of 1324 the FTP request. 1326 2.5.2.2. TCP/IP Packet to S-Expression Translation Process 1328 As with the BSM exaample, we begin our S-expression by defining the verb 1329 of our sentence. In this example, the E-box is monitoring traffic to 1330 the FTP control port when it encouters a TCP/IP packet that contains an 1331 FTP USER command request for anonymous access. As a result, we again 1332 choose BeginSession as the verb. The resulting S-expression is as 1333 follows: 1335 Example 2.5.2.2a FTP BeginSession S-Expression Example: 1337 - --> (BeginSession 1338 : 1339 : 1340 : 1341 - --> ) 1343 Next, we qualify the verb with supporting S-expressions that further 1344 enumerate the attributes of the event. As with BeginSession in our BSM 1345 example, we can support a series of role clauses from the information in 1346 our FTP packet. These role clauses include: 1348 o the observer from which the event was recorded 1349 o the initiator of the BeginSession operation 1350 o the entity to whom the BeginSession was directed 1351 o the resulting state changes or resource(s) produced or 1352 destroyed by the operation (in our case this involves the 1353 attributes of the session established by the rlogin 1354 o the command or tool used in the event 1355 o and the outcome of the event 1357 - From the above categories of attributes, we augment the S-expression 1358 with the following relevant role-clauses: 1360 Example 2.5.2.2b FTP BeginSession S-Expression Example: 1362 (BeginSession 1363 - --> (Observer (S-expression ...) ) 1364 - --> (Initiator (S-expression ...) ) 1365 - --> (To (S-expression ...) ) 1366 - --> (Operand (S-expression ...) ) 1367 - --> (Using (S-expression ...) ) 1368 - --> (Outcome (S-expression ...) ) 1369 ) 1371 The Observer clause can include a variety of datafield attributes, 1372 including the timestamp and the host platform of the sniffer. The 1373 initiator of the BeginSession could also be viewed as attributes of the 1374 location from which the request was sent. Because both the "Initiator" 1375 and "From" roles both provide accurate context to the set of attributes 1376 that represent the entity responsible for the BeginSession Event, we 1377 chose to recognize the two clause using referent SIDS (Section 3.7). The 1378 entity responsible for the event can be described through a variety of 1379 attributes within the packet, including the Ethernet address, IP 1380 address, TCPPort, and hostname. The recipient can be identified from a 1381 similar set of corresponding datafields. Unlike the BSM record, there 1382 is very little information in the packet to describe the session, other 1383 than the session will be associated with the anonymous user account. 1384 The means used in this event is an FTP command, "USER". 1386 Lastly, we identify the outcome of this event as pending, in that at 1387 this point we cannot determine whether the BeginSession will succeed. 1388 The outcome will be determined in subsequent GIDOs, which require an 1389 association with this S-expression through a common thread ID define in 1390 their GIDO headers. We use the CIDFReturnCode extension of ReturnCode 1391 to express this condition. The GIDO recipient must consult the other 1392 GIDOs in the thread until it encounters an Outcome with a ReturnCode 1393 that is not pending. 1395 Example 2.5.2.2.c Final FTP BeginSession S-Expression: 1397 Section Ref. 1398 ------------ 1399 (BeginSession (ExtendedBy FtpCommand) "USER" -- B.2.5 1400 (Observer -- B.3.7 1401 - --> (AtTime (Time "08:59:49.1 PDT")) -- B.3.2 1402 - --> (HostName "snoopmachine.machine.com") -- B.5.4 1403 - --> (ObservationSourceType "Packet") -- B.5.1 1404 ) 1405 (Initiator -- B.3.1 1406 - --> (ReferTo "the-client") -- B.5.1 1407 ) 1408 (From 1409 - --> (ReferAs "the-client") -- B.5.1 1410 - --> (HostName client.machine.com) -- B.5.5 1411 - --> (EthernetAddress 0:aa:bb:cc:dd:ee) -- B.5.5.1 1412 - --> (IPv4Address 999.998.997.999) -- B.5.5.2 1413 - --> (TCPPort 12406) -- B.5.5.3 1414 ) 1415 (To -- B.3.3 1416 - --> (EthernetAddress 0:01:02:03:04:05) -- B.5.5.1 1417 - --> (IPv4Address 111.121.131.141) -- B.5.5.2 1418 - --> (Hostname "server.machine.com") -- B.5.5 1419 - --> (TCPPort 21) -- B.5.5.3 1420 ) 1421 (Operand -- B.3.1 1422 - --> (UserName -- B.5.4 1423 - --> (ExtendedBy UnixUserName) -- B.5.9.6 1424 - --> "anonymous") 1425 ) 1426 (Using -- B.3.1 1427 - --> (FTPCommand "USER") -- B.5.9.5 1428 ) 1429 (Outcome -- B.3.6 1430 - --> (ReturnCode -- B.5.1 1431 - --> (ExtendedBy CIDFReturnCode) -- B.5.1 1432 - --> pending) 1433 ) 1434 ) 1435 ======================================================================== 1436 = 2.6 Rules and Guidelines for Defining SIDs 1437 ======================================================================== 1439 Other specifications MAY define SIDs for use with the CIDF framework. 1440 If a CIDF component generates or uses those SIDs, those SIDs MUST be 1441 defined in conformance to the rules here and SHOULD be defined in 1442 conformance with the guidelines here. 1444 o Every SID MUST have a unique name. 1445 o Every SID's definition MUST include precise syntax. 1446 o Every SID's definition SHOULD include precise semantics. 1447 o The SID description must fully explain the intended use of 1448 SID (i.e., the intended data arguments must be described) 1450 # Editor's note: The Event Subgroup is investigating naming 1451 # conventions and rules for SID enumeration to eliminate the 1452 # potential for SID reuse. 1454 Specifiers SHOULD avoid defining a SID whose meaning overlaps another, 1455 unless one SID is strictly more specific than another (unless the first 1456 one provides all the information that the second one provides and more). 1458 A SID MUST be so defined that when the SID heads an S-expression, the 1459 truth of its S-expression is independent of the peer S-expressions, the 1460 containing S-expression's peers, the peers of the container of the 1461 containing S-expression, and so on. 1463 Thus, an S-expression cannot *modify* the meaning of a peer S- 1464 expression. It can only augment the the peer S-expression. (The 1465 logical relationship between peer S-expressions is conjunction.) This is 1466 critical because a consumer may ignore some peer S-expressions. 1468 Specifiers should be wary when defining a set of closely related SIDs, 1469 since a consumer may understand some of the SIDs and not others. If two 1470 data items can be properly understood together but cannot be properly 1471 understood singly, then it is advisable to define a single SID that 1472 takes both data items as arguments. 1474 ======================================================================== 1475 ======================================================================== 1476 = 1477 = 3: Encoding Gidos 1478 = 1479 ======================================================================== 1480 ======================================================================== 1481 = 1482 ======================================================================== 1483 = 3.1: Introduction to Gido Encoding 1484 ======================================================================== 1486 In encoding a gido into actual bytes for storage, tranmission, etc, two 1487 things are involved. Firstly, every gido is accompanied (in perpetuity) 1488 by a static format header which contains basic information about that 1489 gido. This header format is described in section 3.2. 1491 Secondly, the S-expression which forms the payload of the gido must also 1492 be encoded. The method for doing this is covered in section 3.3 1493 ======================================================================== 1494 = 3.2: Gido Header 1495 ======================================================================== 1497 3.2.1: Introduction 1499 The header definition, presented in this section, consists of a series 1500 of constant fields that gido consumers can reliably parse to read basic 1501 data common across all gidos. The gido s-expression payload, presented 1502 in a preceding section, contains the actual IDS component-specific data 1503 structures, including semantic identifiers that allow gido consumers to 1504 decode and interpret individual fields. 1506 The gido header is used to convey information about the gido itself, 1507 rather than details of the event, analysis report, or response 1508 prescription (which are captured in the payload). Each CIDF-compliant 1509 gido generated by any component MUST contain these fields in this order 1510 (for this version). Consult Appendix A for details on type definition. 1512 3.2.2: The Header Fields 1514 1. Version ID (type revision). Indicates the format revision used 1515 to encode this gido. Initially, the Version ID will indicate 1516 CIDF Version 1.0 (major = 1, minor = 0). This Version ID will be 1517 incremented as future versions are introduced. All current and 1518 future versions of this specification must reserve the first 1519 field of the gido header for the Version ID. Gido consumers 1520 may reliably use this field to detect the format of the remainder 1521 of the gido. 1523 ##################################################################### 1524 # Editor's Comment: This field suggests that CIDF revision 1525 # identifiers will follow a major.minor format. The CIDF working 1526 # group must decide if this is the proper revision format, and must 1527 # then define the meaning of major and minor revision indicators. 1528 ##################################################################### 1530 2. Gido Length (4 octets, big-endian). Indicates the byte length 1531 of the entire gido, including this header but excluding any 1532 optional digital signature. This field may be used to cross- 1533 check gido completeness. 1535 3. Time Stamp (4 octets, big-endian). Indicates the seconds since 1536 Unix epoch 1970. This time refers to the moment that this report 1537 or request was generated. Specifically, it does not refer to the 1538 time that any events were first detected, or when they occurred; 1539 these (if they are known) are to be placed in the message payload 1540 itself. 1542 4. Thread ID (4 octets). Used to identify gidos with some 1543 common thread; all gidos about a given event (e.g., first 1544 report followed by successive updates) would share the same 1545 Thread ID. 1547 5. Class ID (2 octets). Indicates the 1548 category that the event, analysis, or response generator believes 1549 the gido falls under. Class IDs are defined in Section 1550 3.2.3. This field is intended to allow receivers to process 1551 high-priority gidos in a given field of expertise before all 1552 others. Note that some codes are reserved for user-defined 1553 Class IDs; the receiver must check to see if prior agreement 1554 exists between sender and receiver on these codes. 1556 6. Originator ID (unknown type). A unique identifier associated with 1557 the component generating this gido. 1559 ##################################################################### 1560 # Editor's Comment: The format and semantics of the Originator ID 1561 # is an open issue that requires resolution by the CIDF working group. 1562 # Specifically, how will CIDF modules be uniquely identified from other 1563 # CIDF modules? 1564 ##################################################################### 1566 7. Flags (1 octet). The bits of this flags octet are to be 1567 interpreted according to the following table: 1569 Bit Meaning 1570 --- ------- 1571 0 (LSB) set = optional signature present (see below). 1572 clear = no optional signature 1573 1-7 (MSB) reserved (MSB = most significant bit) 1575 The gido payload, plain or compressed, immediately follows the header. 1576 If bit 0 in Flags is cleared, indicating no optional signature, the gido 1577 ends with the payload (indicated by the Gido Length header field). 1578 Otherwise, if bit 0 is set, indicating that a digital signature of the 1579 content is present, this signature is contained in a structure following 1580 the gido payload. Recall that the Gido Length header field indicates 1581 the end of the gido payload, not including the signature structure. 1583 The signature structure has the following fields in it: 1585 1. Signature Length (2 octets). Indicates the length, including this 1586 field (signature length), of the signature structure, in octets. 1588 2. Key ID (type unknown). Uniquely identifies the key used to 1589 generate the signature. This ID may be understood only by a 1590 given receiver if the gido is to be sent one-to-one. This 1591 field also implies the signature algorithm. 1593 ##################################################################### 1594 # Editor's Comment: This issues is tied up with that of originator-id 1595 # 1596 ##################################################################### 1597 3. Signature data. The entire gido represented by the Gido 1598 Length header field is passed through a gido digest, resulting 1599 in a short, fixed-length quantity. This quantity is then signed 1600 using the applicable encryption/signature algorithm, and the 1601 result of this operation placed in this field. 1603 3.2.3 Class ID Codes 1605 The following default Class ID codes are defined for events and analysis 1606 results. Under this scheme, class ids 0 thru 15 are reserved for 1607 CIDF event priorities, and 16 thru 31 are reserved for analysis report 1608 priorities. In addition, class ids 32 thru 127 are reserved for 1609 future CIDF extensions. IDS developers may use the 1610 remaining range (128 thru 255) for application-specific purposes. 1612 (Default Event Class IDs) 1613 00 - Complete Event 1614 01 - Intermediate Event 1615 02 - Incomplete Event 1616 03 - E-box Internal Error Report 1617 04 - E-box Internal Warning Report 1618 05 - E-box Internal Status Message 1619 06 - Reserved for E 1620 07 - Reserved for E 1621 : 1622 15 - Reserved for 1623 (Default Analysis Class IDs) 1624 16 - Critical Security Violation 1625 17 - Potential Security Violation 1626 18 - Suspicious Report 1627 19 - Warning Report 1628 20 - Intermediate Result 1629 21 - Informational Report 1630 22 - A-box Internal Error Report 1631 23 - A-box Internal Warning Report 1632 24 - Reserved for A 1633 25 - Reserved for A 1634 : 1635 31 - Reserved for A 1636 (Reserved Priority Code Range) 1637 ##################################################################### 1638 # Editor's Comment: Class ID code range 32-48 is reserved for 1639 # R-Box countermeasure directives. 1640 ##################################################################### 1641 32 - Reserved for future use 1642 33 - Reserved for future use 1643 : 1644 127 - Reserved for future use 1645 (Undefined Priority Codes) 1646 128 - Undefined 1647 : 1648 : (Undefined values may be employed for 1649 : application-specific purposes.) 1651 255 - Undefined 1652 ======================================================================== 1653 = 3.3: Encoding S-Expressions 1654 ======================================================================== 1656 GIDO payloads consist of S-expressions. However, these S-expressions 1657 are translated to an octet encoding format for efficient transmission or 1658 storage. 1660 The octet encoding of message payloads support highly efficient 1661 transmissions of messages. This section describes how to transform an 1662 S-expression into the appropriate octet encoding. This encoding is 1663 designed to meet the following objectives: 1665 * It must indicate the structure, so that a component ignorant 1666 of the elements within the S-expressions will still be able 1667 to parse the S-expressions. 1668 * It must allow for pre-defined and distributed-out-of-band 1669 SIDs. 1670 * It should be as compact as possible. 1672 3.3.1: Octet Codes 1674 The following codes will be used to represent various octet values in 1675 the succeeding encoding specifications. They are *not* S-expression 1676 atoms. 1678 Code Value Interpretation 1679 ---- ----- -------------- 1680 SEP 0xff Used as separator. 1681 SOPEN 0xfe S-expression open. 1682 PTR 0xfd Pointer (referred to as @). 1683 SID 0xfc Prelude to SID 2-octet code. 1684 TYPE 0xfb Indicates concrete syntax type. 1686 3.3.2: Encoding of S-Expression Grammar 1688 What follows is the grammar for CIDF S-expressions. After each line we 1689 give the encoding applicable to that line. 1691 ::= 1692 E() = E() 1694 ::= ( ) 1695 E() = E() 1697 ::= 1698 E() = E() E() 1700 ::= ( ) 1701 E() = SOPEN E(length{E() E()}) 1702 E() E() 1703 E(length{X}) = var_encode(X) 1705 ::= ( @ ) 1706 E() = SOPEN PTR E() E() 1707 E() = ascii_encode() 1709 ::= ( def ) 1710 E() = SOPEN 1711 E(length{E(def) E() E() E() 1712 E(def) E() E() E() 1713 E() = SID sid_encode() 1714 E() = ascii_encode() 1716 ::= 1717 E() = sid_encode() 1719 ::= ': 1720 E() = TYPE type_encode() sid_encode() 1722 ::= ( ) 1723 E() = SOPEN E(length{E()}) 1724 E() 1726 ::= 1727 E() = E() 1729 ::= 1730 E() = E() E() 1732 ::= 1733 E() = E() 1735 ::= 1736 E() = E() E() 1738 ::= 1739 E() = E() 1741 ::= ( ) 1742 E() = SOPEN E(length{E() E()}) 1743 E() E() 1745 3.3.3: Auxiliary Functions 1747 The following functions are used in the above syntax and encoding: 1749 ascii_encode() returns the ASCII-encoding of . 1750 short_encode() returns the big-endian expression of 1751 . (E.g., short_encode(1234) = 0xd204.) 1752 sid_encode() returns the 2-octet code for . 1753 type_encode() returns the SEP-terminated code for . 1755 var_encode() encodes an arbitrarily long integer. It is encoded as 1756 follows: 1758 L1 | 1760 where L1 is one byte containing the length of , which is expressed 1761 in big-endian order. 1763 3.3.4: Encoding Data 1765 Data may be encoded in one of two ways. If the applicable SID had a 1766 fixed-length data type, then the data is encoded exactly as specified by 1767 the type; e.g., a ulong is encoded as four octets in big-endian order. 1769 Otherwise, the data is encoded as follows: 1771 var_encode(length{Data}) | Data 1773 Thus, if Data is a variable-length data structure that is 84,000 bytes 1774 long, then it is encoded as follows: 1776 03 01 48 20 xx xx xx ... 1778 3.3.5: SID Codes 1780 SIDs are ordinarily encoded as 2-octet values. A list of pre-defined 1781 SIDs is given in Appendix B; if one exists for the purpose, it SHOULD be 1782 used. However, this encoding furnishes the ability to define new SIDs 1783 should no applicable one exist, using the "def" operative. For the 1784 purposes of encoding, "def" is treated as a SID as well (i.e., it has 1785 its own 2-octet code). 1787 As noted in Section 3.3.2, this requires one to define a new SID code. 1788 These SID codes may be unrestricted, but they should conform to the 1789 following standard: 1791 * The code is a 2-octet value, as stated above. 1792 * The MSB (bit 7) of the first octet is the DYNAMIC bit. If this 1793 bit is set, this is a dynamically-defined SID, and the code for 1794 the actual SID is given by bit 5 of the first octet through the 1795 LSB (bit 0) of the second octet. If it is clear, this is a 1796 statically-defined SID, and the code for the SID is as given in 1797 the appendix. 1798 * If the DYNAMIC bit is set, the 2-octet value is followed by a 1799 4-octet value representing the UUID of the SID designer. Also, 1800 the next bit (bit 6 of the first octet) is the EXPERIMENTAL bit. 1801 If *this* bit is set, then the SID is ephemeral and cannot be 1802 relied on in future encodings. If it is clear, then this is a 1803 stable SID. 1805 ======================================================================== 1806 ======================================================================== 1807 = 1808 = 4: CIDF Communication 1809 = 1810 ======================================================================== 1811 ======================================================================== 1812 = 1813 ======================================================================== 1814 = 4.1: Message Layer 1815 ======================================================================== 1817 4.1.1: Rationale for Message Layer 1819 The CIDF message layer was developed to solve problems of 1820 synchronization (i.e., blocking vs. non-blocking processes) and 1821 problems of different data formats for different operating systems. It 1822 also solves the problem that different groups will use different 1823 programming languages. In other words, the use of a messaging format 1824 achieves the following goals: 1826 * Independent of blocking/non-blocking processes 1827 * Data format independent 1828 * Operating system independent 1829 * Programming language independent 1831 4.1.2: Objectives of the CIDF Message Layer 1833 The top-level objectives for the CIDF message layer are to 1835 * Provide an open architecture. 1836 * Avoid imposing architectural constraints or assumptions on the 1837 systems or modules. 1838 * Allow messaging independent of language, operating system, and 1839 network protocol. 1840 * Support easy addition of new components to the CIDF. 1841 * Support security requirements for authentication and privacy. 1842 * Support devices that don't want to fully support CIDF. 1844 4.1.3: Message Format 1846 This message structure resides on top of the negotiated transport layer 1847 service. Note that all reserved fields are set to 0 on transmission and 1848 ignored on receipt. 1850 0 1 2 3 1851 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Version | Control Byte | Checksum | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | Next Header | Reserved | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Length | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Sequence Number | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Time Stamp | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Destination Address | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Options (variable) | 1866 ~ ~ 1867 | | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Payload Data (variable) | 1870 ~ ~ 1871 | | 1872 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | | Privacy Trailer* (variable) | 1874 +-+-+-+-+-+-+-+-+ ~ 1875 | | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 * if privacy option is used 1880 Options all have a common type-length-value format described below. 1882 * Version - 1 octet. CIDF message-layer version (1 for this 1883 initial version). 1885 * Control Byte - 1 octet. Used by the message layer to support 1886 reliable transmission, flow control, and security association 1887 management. 1888 - Acknowledgement of a delivered message (1). 1889 - Message received, but not delivered because of lack of 1890 resources (2). 1891 - Message received, but the supplied security association was 1892 not available to all processing (4). 1894 * Checksum - 2 octets. A checksum across the entire CIDF message, 1895 prior to application of cryptographic mechanisms (i.e., privacy 1896 and authentication transforms). The checksum is computed as 1897 specified in the TCP standard (RFC 793). 1899 * Next Header - 1 octet. Defines the type of either the next 1900 message layer option or application. The following are the 1901 currently defined types. 1902 - Application Header (1) 1903 - Route List (4) 1904 - Privacy Header (50) 1905 - Authentication Header (51) 1907 * Length - 4 octets. Length of the CIDF message, including 1908 message header. 1910 * Sequence Number - 4 octets. Message layer sequence number used 1911 for message reliability (acknowledgement and duplicate removal) 1912 and to support protection against message replay. 1914 * Time Stamp - 4 octets. Used to provide loose time 1915 synchronization between CIDF communicating parties and to 1916 support tardy delivery detection (from denial of service). 1918 * Destination Address - 4 octets. IP address of the target of 1919 this message. This field identifies the eventual recipient of 1920 the CIDF message and is used to route CIDF messages through 1921 intermediate CIDF nodes that cannot be traversed by normal 1922 network routing (e.g., firewalls). 1924 4.1.4: Message Layer Protocol Options 1926 Except for the CIDF privacy option, CIDF message options use the 1927 following format. 1929 0 1 2 3 1930 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Next Header | Length | | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1934 | Option Data (variable) | 1935 ~ ~ 1936 | | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 * Next Header - 1 octet. Defines the type of either the next 1940 message layer option or application, with the same permitted 1941 values as defined above. 1943 * Length - 1 octet. Specifies the number of 32-bit words for this 1944 option, including the next type and length fields. 1946 * Option Data - variable length. The option data field is always 1947 padded to a 32-bit aligned size. 1949 4.1.4.1: Route List Option 1950 Route List is a variable length field that specifies the CIDF nodes 1951 through which the message is to be routed for source routing, and 1952 through which the message has been routed for recorded routing. The 1953 Subtype field indicates whether this is a source or record route. The 1954 Route List has the following format. The route list option is used when 1955 the message destination and source are separated by CIDF nodes that 1956 cannot be traversed by normal network routing (e.g., firewalls). 1958 0 1 2 3 1959 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Next Header | Length | Subtype | Index | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Route Data (variable) | 1964 ~ ~ 1965 | | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 * Next Header and Length are defined above. 1970 * Subtype - 1 octet. Specifies whether this is a recorded route 1971 or a source route. 1972 - Recorded Route (1) 1973 - Source Route (2) 1975 * Index - 1 octet. Index into the array of addresses specifying 1976 the current address to be processed. For source routing, this 1977 is the address of the next CIDF hop. For recorded routes, this 1978 is the address of the last transmitting CIDF node. 1980 * Route Data - variable length. This field is an array of 1981 Internet addresses. Each internet address is 32 bits or 4 1982 octets. For a source route, if the index is greater than the 1983 length, the source route is empty and the routing is to be based 1984 on the destination address field. For a recorded route, if the 1985 index is greater than the length, the recorded route list is full. 1987 4.1.4.2: Privacy Option 1989 The CIDF privacy option supports both unicast or multicast privacy. For 1990 multicast privacy, one node of the multicast group is selected to 1991 generate the keys. The keys are then distributed to each multicast 1992 group member. For unicast privacy, each node generates its own privacy 1993 keys which are distributed to the remote party. 1995 0 1 2 3 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | Key Generator Identity | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | Security Parameters Index (SPI) | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | Payload Data* (variable) | 2003 ~ ~ 2004 | | 2005 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | | Padding (0-255 bytes) | 2007 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | | Pad Length | Next Header | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 * (foot note) if the cryptographic algorithm requires use of an 2012 initialization vector, then that vector is placed as clear text 2013 between the SPI and Payload Data. 2015 * Key Generator Identity - 4 octets. This value identifies 2016 the CIDF entity that generated the key. The initial use of 2017 this field is to specify either the key generator's IP address 2018 or for multicast applications the multicast address for the 2019 multicast group using this security association. 2021 * Security Parameters Index (SPI) - 4 octets. The SPI is an 2022 arbitrary 32-bit value that uniquely identifies the Security 2023 Association for this message, relative to the key generator 2024 identity. 2026 * Padding - variable length. The transmitter may add up to 255 2027 bytes of padding if required to support the block size of the 2028 cryptographic algorithm. Padding is required to ensure that 2029 after the privacy option is applied, the message ends on a 2030 4-byte boundary. 2032 * Pad Length - 1 octet. The number of padding bytes immediately 2033 preceding it. The range of valid values is 0-255, where a 2034 value of zero indicates that no Padding bytes are present. 2036 * Next Header is defined above. 2038 4.1.4.3: Authentication Header Option 2039 0 1 2 3 2040 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | Next Header | Length | Reserved | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | Key Generator Identity | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | Security Parameters Index (SPI) | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | Authentication Data (variable) | 2049 ~ ~ 2050 | | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 * Next Header and Length are defined above. 2055 * Key Generator Identity - 4 octets. This value identifies 2056 the CIDF entity that generated the key. The initial use of 2057 this field is to specify either the key generator's IP address 2058 or for multicast applications the multicast address for the 2059 multicast group using this security association. 2061 * Security Parameters Index (SPI) - 4 octets. The SPI is an 2062 arbitrary 32-bit value that uniquely identifies the Security 2063 Association for this message, relative to the key generator 2064 identity. 2066 * Authentication Data - variable number of 32-bit words. The data 2067 (e.g., digital signature or keyed hash) used to provide 2068 cryptographic authentication. 2070 4.1.5: Cryptographic Mechanisms 2072 The CIDF message layer protocol provides data integrity and source 2073 authentication services for the negotiation phase of CIDF communication. 2074 This enables components to reliably establish communications with 2075 minimal security overhead. During the negotiation phase, the client and 2076 server determine the specific cryptographic services to be provided for 2077 further communication. 2079 The message layer provides the cryptographic mechanisms as options, 2080 enabling use of lower-level services (e.g., IPSEC), CIDF-specific 2081 mechanisms, or no cryptographic services, depending on application 2082 requirements. 2084 The mechanisms used are determined by the client based on the mechanisms 2085 supported by the server. The message layer mechanisms provide the 2086 fields necessary to (1) determine the cryptographic services applied (if 2087 any), (2) determine the cryptographic context, and (3) provide 2088 timeliness and replay protection. 2090 4.1.6: Negotiation Mechanism 2092 4.1.6.1: Introduction 2093 Our approach is to use the simplest reliable transport mechanism 2094 available (i.e., reliable CIDF messaging over UDP) as the default CIDF 2095 transport protocol. This simple protocol can then be used to negotiate 2096 a more or less complex protocol for those components requiring 2097 additional transport-layer services. This allows simple devices to 2098 participate easily, while allowing complex devices to take full 2099 advantage of other transport-layer mechanisms. The message layer 2100 provides optional services to compensate for weaknesses in the transport 2101 layer. The combination of the CIDF message layer with transport-layer 2102 options provides a range of communication capabilities that can be used 2103 to support different application requirements. The following types of 2104 transport/messaging are initially envisioned: 2106 * No assured delivery over a connection-less transport. That is, 2107 the CIDF message layer without acknowledgement and 2108 retransmission directly over UDP. 2110 * Assured delivery over a connection-less transport. That is, the 2111 CIDF message layer with reliable delivery (acknowledgement, 2112 retransmission, and duplicate removal) over UDP. 2114 * Assured delivery over a connection-oriented transport. That is, 2115 the CIDF message layer directly over TCP. 2117 * Object-oriented transport. That is, the CIDF operations over 2118 CORBA. 2120 To enable support for components that must use minimal communication 2121 infrastructure, the default transport mechanism is based on UDP. The 2122 following sections define the default transport layer protocol, CIDF 2123 security services, and the transport negotiation mechanisms. 2125 4.1.6.1.1: Rationale for negotiated transport layer 2127 The simplest approach would be to mandate the use of a single transport 2128 protocol. But there is no one protocol that can adapt to the varying 2129 requirements of all anticipated CIDF applications. Depending on whether 2130 an application is concerned with real-time traffic or simple accrual of 2131 a database of events, different transport mechanisms are appropriate. 2133 Specifically, some CIDF applications require a very light-weight 2134 communication channel that does not have the resource usage required by 2135 current TCP implementations, while other applications require a flexible 2136 and robust communication channel such as TCP. Other requirements include 2137 application-specific support for multicast, which is not supported by 2138 TCP. Therefore, we have requirements for connectionless communication, 2139 reliable connectionless communication, and reliable connection-oriented 2140 communication. Additionally, we have varying requirements for security 2141 services. In some applications and environments, the infrastructure 2142 provides adequate security services. In other applications, we require 2143 CIDF-layer security services for authentication, privacy, or both. 2145 Nevertheless, communications clearly cannot begin between two specific 2146 components until a channel is agreed upon. At the very least, this 2147 implies that if we don't agree on a single channel for all transport, we 2148 need to agree on a single channel for transport negotiation. 2150 This channel needs to be widely supported and freely available. 2151 Components are allowed to share data on whatever channel they wish, but 2152 they must support channel negotiation on the common mechanism. 2154 To support this range of requirements we provide a protocol based on the 2155 reliable UDP variant of CIDF that enables applications to agree upon the 2156 desired transport protocol, plus the desired CIDF message-layer security 2157 services. This exchange is only necessary if the participants have not 2158 previously agreed upon a transport mechanism through external mechanisms 2159 (e.g., local configuration settings or through the CIDF directory 2160 service). 2162 4.1.6.2: Default Transport Layer 2164 The default transport layer protocol for CIDF messages is reliable CIDF 2165 messaging over UDP. Other transport layer protocols may be used 2166 following a negotiation using the default of protocols and services 2167 required and supported by the CIDF client and server. Until we acquire 2168 a well-known CIDF port number, we will use 0x0CDF as the CIDF port. The 2169 CIDF message layer will listen on the CIDF well-known port for incoming 2170 CIDF messages. 2172 4.1.6.3: Conformant transport options 2174 * CIDF message layer without acknowledgement and retransmission 2175 directly over UDP. 2177 * CIDF message layer with acknowledgement and retransmission over 2178 UDP. 2180 * CIDF message layer directly over TCP. 2182 4.1.6.4: Option Negotiation Message Formats 2184 The negotiation for more advanced communication services occurs over a 2185 UDP channel using only the CIDF message layer with authentication 2186 mechanisms enabled. This enables components that do not support TCP to 2187 participate in CIDF. Negotiation occurs by the client querying the 2188 server's capabilities. In response, the server specifies the class of 2189 CIDF operations supported, message services supported, and whether 2190 extensions are supported. The client then selects the services and 2191 message mechanisms. This information can also be provided by the 2192 directory server. 2194 The CIDF transport negotiation protocol resides directly over the CIDF 2195 message layer. The query-response data format is shown below. We 2196 assume that for cryptographic services, the negotiation of the specific 2197 algorithms and modes is handled by the key distribution mechanism. 2199 0 1 2 3 2200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | Type | Length | Reserved | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Option Request (variable) | 2205 ~ ~ 2206 | | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 * Type - 1 octet. Specifies the type of request. For option 2210 negotiation messages, this value is 1. 2212 * Length - 1 octet. Specifies the number of 32-bit words for this 2213 message, including the type and length fields. 2215 Option Requests are formatted as follows. 2217 0 1 2 3 2218 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | Request | Length | Option | Selection | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Option Parameters (variable) | 2223 ~ ~ 2224 | | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 * Request - 1 octet. Specifies the type of request. The 2228 following request types are currently supported. 2229 - Want (1) - Preferred service. 2230 - Can (2) - Sender is capable of using this service. 2232 * Length - 1 octet. Specifies the number of 32-bit words for this 2233 option request, including the request and length fields. 2235 * Option - 1 octet. The option being negotiated. The following 2236 option types are currently supported. 2237 - Transport (1) 2238 - Privacy (2) 2239 - Authentication (3) 2241 * Selection - 1 octet. The option value being negotiated. The 2242 meaning of this fields depends on the option being negotiated. 2243 The following selection values are currently supported. 2245 For Transport negotiation. 2246 - None (0). Used to reject communication with another CIDF node 2247 when no acceptable options are received. 2248 - UDP (1) 2249 - Reliable UDP (2) 2250 - TCP (3) 2251 For Privacy negotiation. 2252 - None (0) 2253 - IPSEC (1) 2254 - SSL (2) 2255 - CIDF (3) 2257 For Authentication negotiation. 2258 - None (0) 2259 - IPSEC (1) 2260 - SSL (2) 2261 - CIDF (3) 2263 Currently, the only option parameter specified is the selection of 2264 TCP/UDP port number for transport negotiation, which is formatted as 2265 follows. 2267 0 1 2 3 2268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | Type | Length | Transport Port Number | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 * Type - 1 octet. Specifies the type of option parameter. For port 2274 numbers, this value is 1. 2276 * Length - 1 octet. Specifies the number of 32-bit words for this 2277 message, including the type and length fields. 2279 * Transport Port Number - 2 octets. This specifies on which port 2280 number the sender of the message will listen following completion 2281 of negotiation. Both ends of the channel select their own 2282 respective ports. 2284 4.1.6.5: Protocol Description 2286 Identification of the remote CIDF component's IP address is handled 2287 either through manual configuration or through the CIDF directory 2288 service. Note that this service may also indicate the CIDF component's 2289 capabilities (can) and preferences (want) for transport and security 2290 services. 2292 When Sender S wishes to communicate with Receiver R, and the two 2293 components have not yet agreed on a transport mechanism, then S must 2294 initiate transport mechanism negotiation. 2296 S sends a negotiation message to R on the CIDF well-known port 2297 indicating the services preferred (if any) and permitted. S includes a 2298 separate option request for each supported option, indicating the 2299 preferred option (if any). 2301 When R receives an option negotiation, R selects the desired value using 2302 local preferences if supported by S, S's preferences if supported 2303 locally, or the intersection of local and S's capabilities if the 2304 preferences are not specified or supported. 2306 If the local and remote capabilities do not permit communication, the R 2307 selects a transport option of None, indicating that communication is not 2308 feasible. 2310 R responds with only the selected options for transport, privacy, and 2311 authentication identified as preferred options. 2313 ======================================================================== 2314 = 4.2: Message Layer Processing 2315 ======================================================================== 2317 4.2.1: Introduction 2319 This section describes the processing of CIDF message layer messages. 2320 The standard procedures are used for CIDF messages independent of the 2321 transport layer. The reliable transmission procedures describe 2322 additional procedures to be used when the transport mechanisms is 2323 reliable UDP. CIDF privacy and authentication procedures describe the 2324 procedures used in providing CIDF layer privacy and authentication 2325 mechanisms, respectively. 2327 4.2.2: Standard Procedures 2329 Each CIDF message uses the standard CIDF header. 2331 4.2.2.1: Outbound Message Processing 2333 On request by the application layer to transmit a CIDF message, the CIDF 2334 message layer shall build the message header and append the message. 2336 If the application indicates that this message requires source routing, 2337 then the CIDF message layer shall use the supplied source route list. 2339 If the application indicates that this message requires recorded 2340 routing, then the CIDF message layer shall initialize the record route 2341 list, placing the outgoing IP address as the first entry on the route 2342 list. 2344 The CIDF message layer shall insert the current CIDF version number, the 2345 application-provided destination, and the current time as the CIDF 2346 header time-stamp. 2348 The CIDF message layer shall insert a new sequence number. The sequence 2349 number is initialize to 0, and incremented for each message sent by the 2350 CIDF message layer. 2352 The CIDF message layer shall compute the total message length and insert 2353 that length into the Length field. 2355 The CIDF message layer should compute and insert the checksum prior to 2356 message transmission. The checksum is inserted prior to applying CIDF 2357 privacy or authentication mechanisms. 2359 If CIDF privacy or authentication is being used, the CIDF message layer 2360 shall encrypt and generate the authentication data for the message based 2361 on the current security association in use with the recipient. If CIDF 2362 privacy or authentication is being used and no security association 2363 exists, then the message transmission request should be rejected. 2365 4.2.2.2: Inbound Message Processing 2367 If the Version field is not a valid CIDF version number (currently 1), 2368 the CIDF message layer shall discard the message. 2370 If CIDF privacy or authentication is being used, the CIDF message layer 2371 shall decrypt and authenticate the message, and discard the message on 2372 failure. On failure, due to lack of a valid security association, the 2373 CIDF message layer should send a response to the source. The response 2374 is the CIDF message layer header, with the Control Byte set to 4. 2376 If the Checksum field is not 0, the CIDF message layer shall compute the 2377 message checksum (using the method described in RFC 793 and discard the 2378 message if the Checksum check fails. 2380 If the Time Stamp field indicates an unexpected delay, the CIDF message 2381 layer should notify the application. 2383 If the Destination Address is not the local CIDF node (i.e., the 2384 destination does not match the local node's address or any multicast 2385 address that the local node is using), the CIDF message layer shall 2386 determine the next CIDF hop (using the source route, if provided) and 2387 forward the message after adjusting the Sequence Number and Time Stamp. 2388 If the message includes a record route option, then the CIDF message 2389 layer shall enter its outgoing IP address if there is sufficient room in 2390 the record route structure and increment the route index. After 2391 processing, the CIDF node should compute the checksum as specified in 2392 RFC 793, and place the checksum in the Checksum field. Finally, the 2393 message layer shall apply the privacy and authentication transforms for 2394 the next CIDF hop and transmit the message. 2396 4.2.3: Reliable Transmission Procedures 2398 4.2.3.1: Outbound Message Processing 2400 For reliable message transmission, the CIDF message layer shall maintain 2401 the round-trip latency and mean deviation values for each node with 2402 which the local component communicates. These values are used in 2403 determining the timeout values for message transmission. The CIDF 2404 message layer shall use the standard TCP algorithm for computing message 2405 layer timeouts. 2407 On reliable message transmission, the CIDF message layer shall retain a 2408 copy of the message for retransmission purposes and set a timer for the 2409 message. If the timer expires before the message is acknowledged, the 2410 message layer shall retransmit the message up to an maximum of 5 2411 retries. 2413 On reception of an acknowledgement for the CIDF message, the CIDF 2414 message layer shall remove the message from the retransmission queue. 2416 4.2.3.2: Inbound Message Processing 2418 On message reception, the CIDF message layer shall send a CIDF 2419 acknowledgement to the source. If the message layer can deliver the 2420 message to the application layer, then the Control Byte shall be 1. 2421 Otherwise, the Control Byte shall be 2. The acknowledgement message is 2422 identical to the original message header except for the Control Byte. 2424 The CIDF message layer shall use the source IP address and the sequence 2425 number to ensure that duplicate messages are not delivered to the 2426 application layer. 2428 4.2.4: CIDF Privacy Procedures 2430 4.2.4.1: Outbound Message Processing 2432 The CIDF message layer encapsulates the CIDF Application Data with an 2433 CIDF privacy header and Trailer, encrypts the CIDF Application Data and 2434 CIDF privacy trailer. The original CIDF Header is retained, except the 2435 CIDF Next Type, which is modified to indicate that this is an CIDF 2436 encrypted message. 2438 On message transmission, if the CIDF message layer is applying CIDF 2439 privacy mechanisms for the message, the CIDF message layer shall 2440 determine the security association (which determines the algorithm) for 2441 the message target, add any required padding, compute and insert the 2442 padding length in the trailer, insert the next header in the trailer, 2443 perform the cryptographic transform over the resulting plain-text 2444 message, and shall insert the security association identity (Key 2445 Generator Identity and SPI) before the resulting ciphertext. If an 2446 initialization vector is required for the cryptographic transform, it 2447 shall be inserted between the resulting ciphertext and the privacy 2448 header. 2450 The next header in the CIDF message layer is then set to 50. 2452 4.2.4.1.1 Message Encryption 2454 The CIDF message layer encapsulates the original CIDF application data 2455 into the CIDF Application Data field, that includes any necessary 2456 padding, and encrypts the result (Application Data, Padding, Pad Length, 2457 and Next Header) using the Message Encryption Key, encryption algorithm, 2458 and algorithm mode indicated by the security association. 2460 4.2.4.1.2 Encryption Algorithms 2461 The security association specifies the encryption algorithm to be used. 2462 The CIDF privacy option is designed for use with symmetric encryption 2463 algorithms. Because the messages may arrive out of order, each message 2464 must carry any data required to allow the receiver to establish 2465 cryptographic synchronization for decryption. This data may be carried 2466 explicitly in the Application Data field (e.g., as an IV as described 2467 above) or the data may be derived from the message header. Since the 2468 CIDF privacy option makes provision for padding of the plain-text, 2469 encryption algorithms employed with the CIDF privacy option may exhibit 2470 either block or stream mode characteristics. 2472 4.2.4.2 Inbound Message Processing 2474 Upon receipt of an CIDF message containing an CIDF privacy header, the 2475 CIDF message layer looks up the security association, and regenerates 2476 the CIDF application data. 2478 4.2.4.2.1 Security Association Lookup 2480 The Security Association information is included in the CIDF privacy 2481 header. 2483 The CIDF message layer looks up the appropriate algorithm and Message 2484 Encryption Key for decryption, based on the SPI and Key Generator's 2485 identity from the CIDF privacy header. 2487 If no valid algorithm and key exists for this message, the receiver MUST 2488 discard the message. 2490 4.2.4.2.2 Message Decryption 2492 The receiver decrypts the CIDF Application Data, Padding, Pad Length, 2493 and Next Header using the neighborhood Message Encryption Key that has 2494 been established for this neighborhood traffic. If an explicit IV is 2495 present in the payload field, it is input to the decryption algorithm 2496 per the algorithm specification. If an implicit IV is employed, a local 2497 version of the IV is constructed and input to the decryption algorithm 2498 per the algorithm specification. 2500 After decryption, the original CIDF message is reconstructed and 2501 processed per the normal CIDF protocol specification. At a minimum, the 2502 Next Header field in the CIDF privacy trailer should be moved to the 2503 Next Header field in the CIDF header. 2505 Note that there are two ways in which the decryption can "fail". The 2506 selected security association may not be correct or the encrypted CIDF 2507 message could be corrupted. (The latter case would be detected if 2508 authentication is selected for the security association, as would 2509 tampering with the SPI.) 2511 4.2.5: CIDF Authentication Procedures 2513 4.2.5.1 Outbound Message Processing 2514 On message transmission, if the CIDF message layer is applying CIDF 2515 authentication mechanisms for the message, the CIDF message layer shall 2516 determine the security association (which determines the algorithm) for 2517 the message target, insert the length of the authentication header, 2518 insert the next header in the authentication header, shall insert the 2519 security association identity (Key Generator Identity and SPI) before 2520 the resulting ciphertext, and perform the cryptographic transform over 2521 the resulting message. 2523 The next header in the CIDF message layer is then set to 51. 2525 4.2.5.1.1 Integrity Check Value Calculation 2527 The transmitter computes the Integrity Check Value (ICV) over the entire 2528 message using the ICV key, hashing algorithm, and algorithm mode 2529 indicated by the security association. Since the Authentication Data is 2530 not protected by encryption, a keyed authentication algorithm must be 2531 employed to compute the ICV. 2533 If privacy is selected in conjunction with CIDF authentication, 2534 encryption is performed first, before the authentication. The 2535 encryption does not encompass the Authentication Data field. This order 2536 of processing facilitates rapid detection and rejection of replayed or 2537 bogus messages by the receiver, prior to decrypting the message, hence 2538 potentially reducing the impact of denial of service attacks. It also 2539 allows for the possibility of parallel processing of messages at the 2540 receiver (i.e., decryption can take place in parallel) with 2541 authentication. 2543 4.2.5.1.2 Padding 2545 No padding is required if the default 96-bit truncated Hashed Message 2546 Authentication Codes (HMAC) algorithm is used. However, if another 2547 authentication algorithm is used, padding MAY be required. 2549 If an authentication algorithm creates an ICV with length less than an 2550 integral multiple of 32 bits, padding may be appended to the 2551 Authentication Data field to ensure a 32-bit multiple AH. Alternatively, 2552 the ICV may be truncated to a 32-bit multiple length. 2554 In addition, if the authentication algorithm requires a multiple of a 2555 block size and the CIDF message with CIDF authentication header does not 2556 meet the block size requirements, zero-valued padding MUST be appended 2557 to the end of the CIDF message prior to ICV computation. This padding 2558 is not transmitted with the CIDF message. 2560 4.2.5.1.3 Authentication Algorithms 2562 The security association specifies the authentication algorithm used for 2563 the ICV computation. At the time of writing, one mandatory-to-implement 2564 algorithm and mode has been defined for CIDF authentication header. It 2565 is based on the Hashed Message Authentication Codes using a SHA-1 hash 2566 value. The output of the HMAC computation is truncated to the leftmost 2567 96 bits. 2569 4.2.5.2 Inbound Message Processing 2571 Upon receipt of an CIDF message containing an CIDF authentication 2572 header, the CIDF message layer looks up the Security Association and 2573 verifies the Integrity Check Value. 2575 4.2.5.2.1 Security Association Lookup 2577 The Security Association information is included in the CIDF 2578 authentication header. The CIDF message layer looks up the appropriate 2579 algorithm and key for ICV computation, based on the SPI and Key 2580 Generator's identity from the CIDF authentication header. 2582 If no valid algorithm and key exists for this message, the receiver MUST 2583 discard the message. 2585 4.2.5.2.2 Integrity Check Value Verification 2587 The receiver computes the ICV of the entire CIDF message using the 2588 specified authentication algorithm and the security association ICV key 2589 that has been established for this security association. If the 2590 computed ICV matches the ICV included in the Authentication Data field 2591 of the message, the CIDF message is valid and accepted. If the values 2592 do not match, the CIDF message layer MUST discard the CIDF message as 2593 invalid. 2595 To validate the CIDF message, the CIDF message layer saves the ICV value 2596 in the CIDF authentication header and replaces it with zeros. Then the 2597 CIDF message layer performs the ICV computation over the entire message 2598 and compares the saved ICV value with the computed ICV value. 2600 ======================================================================== 2601 ======================================================================== 2602 = 2603 = APPENDIX A: Minimum CIDF Primitive Types Definition 2604 = 2605 ======================================================================== 2606 ======================================================================== 2608 The primitive types list enumerates the ways in which various data 2609 fields shall be encoded. The intent is to keep the primitive type list 2610 relatively small. Complex record structures should be defined within 2611 the payload S-expression, while the definition of enumerated field 2612 arrays are left to SIDs. 2614 ##################################################################### 2615 # Editor's Comment: Please forgive the reliance on C terminology. 2616 # These types should be applicable across programming languages. 2617 ##################################################################### 2619 INTEGRAL TYPES: These are the core type primitives. These are the 2620 preferred data types for SIDs with associated fields that are processed 2621 or character encoding. 2623 char: (7-bit ISO Invariant Code Set) 2624 char8: (8-bit ascii, no idea what standard to suggest) 2625 byte: (pure undefined octet, no sign relation) 2626 short: (16-bit, signed) 2627 ushort: (16-bit, unsigned 2628 long: (32-bit, signed) 2629 ulong: (32-bit, unsigned) 2630 float: (floating point 32-bit, point to IEEE standard) 2631 double: (floating point 64-bit, point to IEEE standard) 2633 AGGREGATE TYPES: These are for SIDs that require arrays or structures. 2635 An array is a collection of elements described by the same semantic 2636 identifier or type. An array can be of any length. 2638 Example: (array byte) An array of bytes. 2639 (array record) An array of records. 2641 An arrayn is similar to array, but has a fixed number of elements. 2643 Example: (arrayn 4 byte) An array consisting of 4 bytes. 2644 (arrayn 256 char8) An array of 256 characters. 2646 A structure is a sequence of possibly named elements of the specified 2647 types. 2649 Example: (structure 2650 ((arrayn 256 char8) name) 2651 (ulong ref-count) 2652 (time create-time)) 2653 A sequence consisting of a name, an array of 256 characters, 2654 a ref-count, an integer, and a create-time, a time. 2656 Following are some predefined aggregate types: 2658 string: (array char) 2659 string8: (array char8) 2660 ip4_address: (arrayn 4 byte) 2661 ip6_address: (array 8 ushort) 2662 header: (structure 2663 (byte version_id) 2664 (ulong msg_length) 2665 (timestamp msg_timestamp) 2666 (ulong sequence_num) 2667 (byte priority) 2668 (module_id source_ID) 2669 (module_id consumer_ID)) 2671 message: (structure 2672 (header msg_header) 2673 (payload msg_payload)) 2675 revision: (structure 2676 (byte major) 2677 (byte minor)) 2679 [ Note: A generic time-stamp structure: NTP/UTC timestamp: 2680 integral part: time in seconds since 00:00:00 GMT, 2681 January 1, 1900 (proposed: if the high-bit is off, 2682 that it be relative to 06:28:16, February 7, 2036). 2683 fractional part: 32 bits (i.e., MSB = 1/2 sec, etc.) 2684 resolution of about 233 picoseconds (1 picosecond = 2685 10e-12 seconds). TBD: Accuracy estimation info. 2686 two components: accuracy of clock, estimate of drift. ] 2688 timestamp: (structure 2689 (ulong seconds) 2690 (ulong fracsec)) 2692 SCALAR TYPES: There are no enumerated types in this specification, as 2693 there are in C, Ada, and Pascal. Rather, enumerated types shall be 2694 simple bitfield type structures, where SIDs build their own 2695 interpretation of the available bit patterns. This could save some 2696 tremendous headaches. Note, however, for portability it may be better 2697 for SIDs to simply utilize numeric values rather than bit manipulation 2698 when defining enumerated structures. 2700 ======================================================================== 2701 = Appendix B 2702 ======================================================================== 2704 B.1. Introduction 2706 In the following sections, the SIDs defined for use in CIDF are 2707 described. GIDO producers SHOULD use these SIDs whenever an appropriate 2708 one is defined. If a SID has any applicable extensions, these are given 2709 below the extended SID, indented. Extensions of extensions are further 2710 indented. 2712 B.2. Verb SID Descriptions 2714 Following each verb SID is a list of recommended role SIDs. This means 2715 that the sentence SHOULD contain role SIDs giving the described 2716 information (or must refer to an earlier instance which contains this 2717 information). 2719 B.2.1. Motion Verb SIDs 2721 Copy 2722 Description: An object (or set of objects) was copied from one 2723 place to another. To be distinguished from Store by the fact 2724 that the Operand of Copy represents the *identifier* of the 2725 object being copied, and the Operand of Store represents the 2726 *value* being stored. Hence, if one wishes to express a string 2727 that is stored in a file, then that string is being Stored, and 2728 not Copied (and the appropriate verb SID should be used). 2729 Recommended role SIDs: 2730 Initiator: The entity responsible for initiating the copy. 2731 Operand: The object being copied. 2732 From: The original location of the object. 2733 To: The new location of the copied object. 2735 Move 2736 Description: An object (or set of objects) was *moved* from 2737 one place to another. This is used when the object is 2738 persistent. 2739 Compare Transmit. 2740 Recommended role SIDs: 2741 Initiator: The entity responsible for initiating the move. 2742 Operand: The object being moved. 2743 From: The original location of the object. 2744 To: The new location of the moved object. 2746 Store 2747 Description: An object (or set of objects) was stored. To 2748 be distinguished from Copy by the fact that the Operand of 2749 Store represents the *value* being stored (and values do not 2750 have a source), and the operand of Copy represents the 2751 *identifier* of the object being copied. 2752 Recommended role SIDs: 2753 Initiator: The entity responsible for initiating the store. 2754 Operand: The object being stored. 2755 To: The new location of the stored object. 2757 Remove 2758 Description: An object (or set of objects) was removed. 2759 Recommended role SIDs: 2760 Initiator: The entity responsible for initiating the remove. 2761 Operand: The object being removed. 2762 From: The original location of the object. 2764 B.2.2. Process Verb SIDs 2766 Execute 2767 Description: A program or command was executed. 2768 Recommended role SIDs: 2769 Initiator: The entity responsible for executing the program. 2770 Operand: The program being executed. 2772 Interrupt 2773 Description: A program in execution was interrupted. 2774 Recommended role SIDs: 2775 Initiator: The entity responsible for interrupting the 2776 program. 2777 Operand: The program in execution that was interrupted. 2779 Resume 2780 Description: An interrupted program was resumed. 2781 Recommended role SIDs: 2782 Initiator: The entity responsible for resuming the program. 2783 Operand: The interrupted program that was resumed. 2785 Terminate 2786 Description: A program (either in execution or interrupted) was 2787 terminated. 2788 Recommended role SIDs: 2789 Initiator: The entity responsible for terminating the 2790 program. 2791 Operand: The program that was terminated. 2793 B.2.3. Privilege Verb SIDs 2795 AcquirePrivilege 2796 Description: An entity acquired a privilege. 2797 Recommended role SIDs: 2798 Initiator: The entity acquiring the privilege. 2799 Operand: The privilege in question. 2801 LosePrivilege 2802 Description: An entity lost a privilege. 2803 Recommended role SIDs: 2804 Initiator: The entity losing the privilege. 2805 Operand: The privilege in question. 2807 ChangeAttribute 2808 Description: An entity acquired a privilege. 2809 Recommended role SIDs: 2810 Initiator: The entity changing the attribute. 2811 Operand: The attribute in question. 2813 HasAuthorizations 2814 Description: An entity has permission to do certain things 2815 to an object. 2816 Recommended role SIDs: 2817 Initiator: The entity operating on the object. 2818 Operand: The object being operated on. 2819 Authorizations: The permissions associated with this 2820 Initiator and Operand. Currently, this should use the 2821 Permissions SID (see Section B.5.7). 2823 B.2.4. Transaction Verb SIDs 2825 Request 2826 Description: An entity requested a second entity to perform an 2827 action. 2828 Recommended role SIDs: 2829 Initiator: The entity making the request. 2830 To: The entity receiving the request. 2831 Operand: A second-level sentence that contains the requested 2832 action. The Initiator of this second-level sentence MAY be 2833 the To of the request. (It may be the case that 2834 delegation is required.) 2836 Login 2837 Description: An entity logs in (or attempts to do so) to a 2838 host. 2839 Recommended role SIDs: 2840 Initiator: The entity logging into the host. 2841 To: The host being logged into (ulch). 2843 B.2.5. Communication Verb SIDs 2845 BeginSession 2846 Description: A communication session is established between 2847 two entities. 2848 Recommended role SIDs: 2849 Initiator: The entity initiating the connection (the 2850 "active" mode side). 2851 To: The entity accepting the connection (the 2852 "passive" mode side). 2853 Operand: The connection and its associated attributes. 2854 (This might include a ReferAs clause, for instance.) 2856 EndSession 2857 Description: A communication session between two entities is 2858 ended. 2859 Recommended role SIDs: 2860 Initiator: The entity who had originally initiated the 2861 connection. 2862 To: The entity who had originally accepted the 2863 connection. 2864 Operand: The connection being closed. (Typically, this 2865 would consist only of a ReferTo clause.) 2867 Transmit 2868 Description: An entity sent an object to a second entity. This 2869 is used when the object is transient, as with a packet. Compare 2870 Move. 2871 Recommended role SIDs: 2872 Initiator: The entity responsible for starting the 2873 transmission. Typically the same entity as (and hence 2874 a possible referent of) the From. 2875 From: The entity sending the object. 2876 To: The entity receiving the object. 2877 Operand: The object being sent. 2878 Connection: Information identifying the connection, if 2879 applicable. 2881 Block 2882 Description: A transmission was blocked. 2883 Recommended role SIDs: 2884 Initiator: The entity blocking the transmission. 2885 From: The entity sending the object. 2886 To: The entity receiving the object. 2887 Operand: The object being sent. 2888 Connection: Information identifying the connection, if 2889 applicable. 2891 B.2.6. Monitoring Verb SIDs 2893 Snapshot 2894 Description: A one-time observation of conditions. 2895 Recommended role SIDs: 2896 Observer: The entity observing the system. 2897 PresentState: The conditions observed by the Observer. 2899 ChangeState 2900 Description: Conditions changed. 2901 Recommended role SIDs: 2902 Observer: The entity observing the system. 2903 OldState: The old state of the system. 2904 NewState: The new state of the system. 2906 Filter 2907 Description: A filter was matched by summarized occurences. 2908 Recommended role SIDs: 2909 Observer: The entity filtering the observations. 2910 Filter: The filter against which to match the observations. 2911 FilterStats: The statistics of observations matching the 2912 Filter. 2914 B.2.7. Policy Verb SIDs 2916 Require 2917 Description: An entity required a second entity to perform an 2918 action. 2919 Recommended role SIDs: 2920 Initiator: The entity making the requirement. 2921 To: The entity imposed by the requirement. 2922 Operand: A second-level sentence describing the required 2923 action. See Request. 2925 Recommend 2926 Description: An entity recommended a second entity to perform an 2927 action. 2928 Recommended role SIDs: 2929 Initiator: The entity making the recommendation 2930 To: The entity receiving the recommendation 2931 Operand: A second-level sentence describing the recommended 2932 action. See Request. 2934 Allow 2935 Description: An entity allowed a second entity to perform an 2936 action. 2937 Recommended role SIDs: 2938 Initiator: The entity making the allowance. 2939 To: The entity permitted to perform the action. 2940 Operand: A second-level sentence describing the allowed 2941 action. See Request. 2943 Forbid 2944 Description: An entity forbade a second entity from performing 2945 an action. 2946 Recommended role SIDs: 2947 Initiator: The entity making the proscription. 2948 To: The entity forbidden to perform the action. 2949 Operand: A second-level sentence describing the forbidden 2950 action. See Request. 2952 B.2.8. Subjunctive Verb SIDs 2953 Do 2954 Description: This is a request for action. 2955 Recommended role SIDs: 2956 Operand: A second-level sentence describing what is to 2957 be done. This sentence may lack an explicitly named 2958 Initiator, indicating that the recipient of the request 2959 is to ensure that the action is carried out. 2960 Recommender: The entity recommending the action. 2962 Diagnose 2963 Description: This is a diagnosis. 2964 Recommended role SIDs: 2965 Operand: A second-level sentence indicating what the 2966 diagnosis is. 2967 Analyzer: The entity making the diagnosis. 2969 Predict 2970 Description: This is a prognosis. 2971 Recommended role SIDs: 2972 Operand: A second-level sentence indicating what is 2973 predicted. 2974 Analyzer: The entity making the prediction. 2976 B.3. Role SID Descriptions 2978 The below are SIDs that denote a *role*. That is, they are used to tag a 2979 group of attributes that together describe something that plays a role 2980 in a sentence. They are intended to be used somewhat generically, so 2981 that the same SID (e.g., Initiator) can be used with many different 2982 actions. Thus, their definitions here are generic as well. When used 2983 with specific verbs, they have specific interpretations; these are given 2984 with the definition of the verbs. 2986 B.3.1. Operation Role SIDs 2988 Initiator 2989 Description: The entity responsible for causing something to 2990 happen. 2992 Operand 2993 Description: The object which is operated on. Often used in 2994 conjunction with Initiator, in which case it is the object 2995 that things happen *to*. 2997 Authorizations 2998 Description: The authorized activities permitted to an 2999 entity on an object. 3001 Using 3002 Description: The means used by the Initiator to perform some 3003 action. This is ordinarily a *program* or script which is 3004 executed by Initiator, which distinguishes it from the 3005 ByMeansOf construct (see Section B.4), which indicates that 3006 a *sentence* occurred as a way of having a second sentence 3007 occur. Therefore, a user might login "Using" a telnet program, 3008 but that same user would overload a system "ByMeansOf" causing 3009 that system to fail. 3011 B.3.2. Time and Location Role SIDs 3013 Before 3014 Description: A time before which the conditions 3015 described by the sentence are observed. 3017 After 3018 Description: A time after which the conditions 3019 described by the sentence are observed. 3021 While 3022 Description: The time during which the conditions 3023 described by the sentence are observed. 3025 AtTime 3026 Description: The time at which the conditions 3027 described by the sentence are observed. 3029 AtLocation 3030 Description: The location at which the conditions described 3031 by the sentence are observed to have happened. 3033 B.3.3. Motion Role SIDs 3035 From 3036 Description: The place from which movement occurs. This may 3037 also be used to identify an entity (i.e., active agent) 3038 sending an object. 3040 To 3041 Description: The place to which movement occurs. This may 3042 also be used to identify an entity receiving an object. 3044 Through 3045 Description: A place through which movement passes. This may 3046 also be used to identify an entity relaying an object. There 3047 may be more than one Through for a given verb. If there is an 3048 order to the Throughs, the GIDO producer SHOULD put them in 3049 chronological order. (To make this explicit, the producer 3050 MAY include an Epoch SID (see Section B.5.1) in this role.) 3052 Connection 3053 Description: A connection between two entities. 3055 B.3.4. Filter Role SIDs 3057 Filter 3058 Description: The template against which a component is 3059 matching observations, typically for statistics. 3061 FilterStats 3062 Description: The statistics on which observations match 3063 the associated Filter. 3065 B.3.5. Object Attribute Role SIDs 3067 Owner 3068 Description: The entity with ownership rights to the object. 3069 If specific assignment of ownership is lacking, then this 3070 indicates that the entity has the right to control access to 3071 the object. 3073 Host 3074 Description: The host on which the object resides. 3076 Certifier 3077 Description: The entity which vouches for the identity of 3078 the object. When applied to a certificate, it represents 3079 the CA for that certificate; when applied to a Kerberos 3080 principal, it represents the KDC; when applied to a hostname, 3081 it represents a (possibly secure) DNS server. 3083 Parent 3084 Description: The entity which created the object. When 3085 applied to a Unix process, it represents the parent of the 3086 process. 3088 B.3.6. Status Role SIDs 3090 Outcome 3091 Description: The outcome of an action which was *attempted*. 3093 Context 3094 Description: Additional information regarding an event. This 3095 is where the duration of an event, for instance, would go. 3097 B.3.7. Meta-Role SIDs 3099 Observer 3100 Description: The entity observing the conditions described 3101 by the sentence. 3103 Analyzer 3104 Description: The entity performing the analysis described 3105 by the sentence. 3107 Recommender 3108 Description: The entity prescribing the action described by 3109 the sentence. 3111 B.4. Conjunction SIDs 3113 CausallyRelated 3114 Format: (CausallyRelated ) 3115 Description: Sentence1 and Sentence2 both occurred, and are 3116 causally related. That is, either one helped cause the 3117 other, or a third sentence helped cause both. 3119 HelpedCause 3120 Format: (HelpedCause ) 3121 Description: Sentence1 and Sentence2 both occured, and 3122 Sentence1 was a contributing factor to Sentence2. Sentence2 3123 must denote an event. 3125 IntentionallyHelpedCause 3126 Format: (IntentionallyHelpedCause ) 3127 Description: Sentence1 and Sentence2 both occured, and 3128 Sentence1 was, and was intended to be, a contributing factor 3129 to Sentence2. Sentence2 must denote an event. 3131 CommonCause 3132 Format: (CommonCause ... ) 3133 Description: Sentence1 through SentenceN all occurred, 3134 and all have a common cause. 3136 ByMeansOf 3137 Format: (ByMeansOf ... ) 3138 Description: Sentence1 through SentenceN all denote events 3139 that happened. Some intentional agent (person or program) 3140 accomplished event 1 by means of accomplishing event 2, 3141 accomplished event 2 by means of accomplishing event 3, 3142 and so on. 3144 InOrder 3145 Format: (InOrder ... ) 3146 Description: Sentence1 through SentenceN all denote events 3147 that occurred. The events occurred in the order given. 3148 ending(event 1) <= beginning(event 2), 3149 ending(event 2) <= beginning(event 3), ... 3151 B.5. Atom SIDs 3153 B.5.1. Base SIDs 3155 Epoch 3156 Type: timestamp 3157 Description: The moment at which something occurred. 3159 Duration 3160 Type: float 3161 Description: The duration of an occurrence, in seconds. 3163 Size 3164 Type: ulong 3165 Description: The length of an object, in bytes. 3167 Certainty 3168 Type: float 3169 Description: The certainty of an observation, expressed as 3170 the observer's estimate of the probability that the entire 3171 observation is true. 3173 Severity 3174 Type: byte 3175 Description: The severity of an event, as estimated by the 3176 observer, with more severe events being given a higher 3177 number. Zero (0) represents the minimum severity, and 255 3178 represents the maximum severity. [Editor's Note: We solicit 3179 discussion on guidelines for determining intermediate levels 3180 of severity.] 3182 ReturnCode 3183 Type: byte 3184 Description: This is an enumerated value. The constraints 3185 on this are that zero (0) MUST mean success; failure is any 3186 non-zero value. 3188 ReturnCode (ExtendedBy CIDFReturnCode) 3189 Type: byte 3190 Description: This is an enumerated value with greater 3191 semantics than a generic return code: 3192 0 = success 3193 1 = failed 3194 2 = pending 3195 3-255 = reserved 3197 OSName 3198 Type: string 3199 Description: The name of an operating system. (For instance, 3200 "SunOS"). 3202 ObservationSourceType 3203 Type: string 3204 Description: A name describing the source of data used to 3205 generate an observation. 3207 ObjectType 3208 Type: byte 3209 Description: This is an enumerated value. 3210 0 = reserved 3211 1 = file 3212 2 = file_system 3213 3 = memory 3214 4 = CPU_time 3215 5 = peripheral 3216 6 = URL 3217 7 = network_packet 3218 8 = program 3219 9-255 = reserved 3221 ObjectName 3222 Type: string 3223 Description: The name of an object. 3225 (ExtendedBy FileSystemName) 3226 Type: string 3227 Description: A file system name, given in 3228 "hostname:directory-pathname" format, if object type 3229 is file system. 3231 (ExtendedBy DeviceName) 3232 Type: string 3233 Description: A name for the device, if object type is 3234 peripheral. 3236 (ExtendedBy URL) 3237 Type: string 3238 Description: A URL to find the object, given in 3239 "scheme:locator" format, if object type is URL. 3241 ObjectCreated 3242 Time: timestamp 3243 Description: Depending on applicability, the time at which 3244 the object was (last) created. 3246 ObjectModified 3247 Time: timestamp 3248 Description: Depending on applicability, the time at which 3249 the object was last modified. 3251 ObjectAccessed 3252 Time: timestamp 3253 Description: Depending on applicability, the time at which 3254 the object was last accessed. 3256 ProgramName 3257 Type: string 3258 Description: The name of a program, as distinguished from its 3259 filename. If a program is moved from one place in a directory 3260 to another, its filename may change, but its program name 3261 stays the same. An example of a program name is "PowerPoint". 3263 DeveloperName 3264 Type: string 3265 Description: The name of the entity responsible for developing 3266 a program. An example is "Microsoft". 3268 VersionNumber 3269 Type: string 3270 Description: The version number of an application. An example 3271 is "5.0". 3273 Comment 3274 Type: string 3275 Description: An annotation. 3277 B.5.2. Connector 3279 ReferAs 3280 Type: string 3281 Description: An identifier to be used later as a referent. 3282 (See Section 2.4.) 3284 ReferTo 3285 Type: string 3286 Description: An identifier referring to an earlier referent. 3287 (See Section 2.4.) 3289 B.5.3. Process SIDs 3291 Priority 3292 Type: short 3293 Description: The priority of a process, with high-priority 3294 processes being given a lower number. 3296 RevPriority 3297 Type: short 3298 Description: The priority of a process, with high-priority 3299 processes being given a larger number. 3301 ProcessName 3302 Type: short 3303 Description: The process's name (typically used for daemon or 3304 service name). 3306 ProcessID 3307 Type: ushort 3308 Description: The process's ID. 3310 ProcessID (ExtendedBy SessionID) 3311 Type: ushort 3312 Description: Denotes an ID relating to a process that carries 3313 a session. 3315 ProcessStatus 3316 Type: byte 3317 Description: This is an enumerated value. 3318 0 = active /* running */ 3319 1 = suspended /* awaiting an OS action */ 3320 2 = killed /* terminated by external signal */ 3321 3 = finished /* terminated internally */ 3322 4 = unknown (no such process?) 3323 5-255 = reserved 3325 SystemTime 3326 Type: float 3327 Description: Time spent (by a process) in the system/kernel, 3328 in seconds. 3330 UserTime 3331 Type: float 3332 Description: Time spent (by a process) in user space, in 3333 seconds. 3335 B.5.4. User SIDs 3337 EMailAddress 3338 Type: string 3339 Description: The e-mail address of an entity. 3341 RealName 3342 Type: string 3343 Description: The given name, as known, of an entity. 3345 PrincipalName 3346 Type: string 3347 Description: A persistent name associated with a user. 3349 UserName 3350 Type: string 3351 Description: The name associated with a user account. 3353 UserID 3354 Type: ushort 3355 Description: The user ID number for a user. 3357 PersistentUserName 3358 Type: string 3359 Description: A user name associated with a login session. 3361 PersistentUserID 3362 Type: ushort 3363 Description: The user account ID. 3365 CurrentUserName 3366 Type: string 3367 Description: A user name associated with the current interactive 3368 session. 3370 CurrentUserID 3371 Type: ushort 3372 Description: The current user ID. 3374 EffectiveUserName 3375 Type: string 3376 Description: A user name associated with a process. 3378 EffectiveUserID 3379 Type: ushort 3380 Description: The effective user ID. 3382 GroupName 3383 Type: string 3384 Description: The name associated with a user group. This can 3385 be associated with either a user or an object such as a file. 3387 EffectiveGroupName 3388 Type: string 3389 Description: The name associated with the group of an effective 3390 user. 3392 GroupID 3393 Type: ushort 3394 Description: A user group ID. This can be associated with 3395 either a user or an object such as a file. 3397 GroupUUID 3398 Type: 16-byte array 3399 Description: A UUID associated with a group. This has stronger 3400 guarantees of non-duplication than GroupID. 3402 B.5.5. Distributed/Networking SIDs 3404 HostName 3405 Type: string 3406 Description: The hostname associated with a host. 3408 (ExtendedBy FQHostName) 3409 Type: string 3410 Description: The fully qualified hostname. 3412 ServerDNSName 3413 Type: string 3414 Description: The name of a server associated with a user 3415 or an object. This is always a fully qualified DNS name. 3417 DomainName 3418 Type: string 3419 Description: An administrative domain name. 3421 (ExtendedBy FQDomainName) 3422 Type: string 3423 Description: The fully qualified domain name. 3425 DomainID 3426 Type: ulong 3427 Description: An administrative domain's ID. 3429 DomainUUID 3430 Type: 16-byte array 3431 Description: A UUID associated with an administrative domain. 3433 DataLinkProtocol 3434 Type: byte 3435 Description: Enumerated value. 3436 0 = reserved 3437 1 = Ethernet 3438 2 = Token ring 3439 3 = ARC net 3440 4 = IEEE 802.5, SNAP header 3441 5 = IEEE 802.2, FDDI 3442 6 = IEEE 802.3, MAN 3443 7 = SLIP 3444 8 = PPP 3445 9-255 = reserved 3447 NetworkProtocol 3448 Type: byte 3449 Description: Enumerated value. 3450 0 = reserved 3451 1 = IPv4 3452 2 = IPv6 3453 3 = ICMP 3454 4 = ARP 3455 5 = RARP 3456 6-255 = reserved 3458 TransportProtocol 3459 Type: byte 3460 Description: Enumerated value. 3461 0 = reserved 3462 1 = TCP 3463 2 = UDP 3464 3-255 = reserved 3466 B.5.5.1. Data Link Layer Attribute SIDs 3468 EthernetAddress 3469 Type: 6-byte array 3470 Description: The ethernet address associated with a host. 3472 EtherPreamble 3473 Type: 8-byte array 3474 Description: The ethernet preamble. 3476 EtherType 3477 Type: ushort 3478 Description: The ethernet type. 3480 EtherFrameCheckSeq 3481 Type: ulong 3482 Description: The ethernet frame check sequence number. 3484 B.5.5.2. Network Layer Attribute SIDs 3486 IPV4Address 3487 Type: ulong 3488 Description: The IPv4 address associated with a host. 3490 IPV4Mask 3491 Type: ulong 3492 Description: An IPv4 network mask. 3494 IPV4Port 3495 Type: ushort 3496 Description: An IPv4 port. 3498 IPV4verIHL 3499 Type: byte 3500 Description: 8 bit representation of IP header version ID 3501 (bits 0-3) and header length (bits 4-7). 3503 IPV4servicetype 3504 Type: byte 3505 Description: The IPv4 Type of Service (TOS). Only bits 3-6 3506 are significant. They are, in order, Minimize Delay, Maximize 3507 Throughput, Maximize Reliability, and Minimize Monetary Cost. 3509 IPV4totallength 3510 Type: ushort 3511 Description: The IPv4 total packet length. This is the length 3512 of the entire packet, header included. Subtracting the header 3513 length (determined from IPV4verIHL) gives the length of the 3514 data portion. 3516 IPV4identifier 3517 Type: ushort 3518 Description: The IPv4 packet identifier. Typically sequential. 3520 IPV4flags 3521 Type: byte 3522 Description: The IPv4 flags field. Only bits 1 and 2 are 3523 significant. They are, in order, Don't Fragment and More 3524 Fragments. 3526 IPV4fragoffset 3527 Type: ushort 3528 Description: The IPv4 offset of a datagram fragment. 3530 IPV4ttl 3531 Type: byte 3532 Description: The IPv4 packet time-to-live (maximum number 3533 of routers to relay the packet). 3535 IPV4protocol 3536 Type: byte 3537 Description: The IPv4 protocol number. This is an enumerated 3538 value. A full table of the enumeration can be found in RFC 3539 1700. [There has to be something more recent than that.] 3541 IPV4checksum 3542 Type: ushort 3543 Description: The IPv4 header checksum. It does not cover 3544 any of the data portion. 3546 B.5.5.3. Transport Layer SIDs 3548 TCPPort 3549 Type: ushort 3550 Description: A TCP port number. 3552 TCPsequencenumber 3553 Type: ulong 3554 Description: The TCP sequence number. Identifies the first 3555 byte of the stream in this packet. The first byte of the 3556 stream as a whole is indexed number zero. 3558 TCPacknumber 3559 Type: ulong 3560 Description: The TCP ack number. Identifies the first byte 3561 of the stream in the next (expected) packet. 3563 TCPwindow 3564 Type: ushort 3565 Description: The TCP window size, in bytes. 3567 TCPchecksum 3568 Type: ushort 3569 Description: The TCP packet checksum. This covers both the 3570 header *and* the data portions of the packet. 3572 TCPurgentpointer 3573 Type: ushort 3574 Description: The TCP urgent pointer. Presence of this SID 3575 presumes that the URGent bit was set. Number of bytes to 3576 get to the last byte of urgent data, starting from the 3577 first byte of this packet, inclusive. 3579 TCPMSS 3580 Type: ushort 3581 Description: The TCP maximum segment size. 3583 TCPflags 3584 Type: byte 3585 Description: Bit 0 = URG, Bit 1 = ACK, Bit 2 = PSH, Bit 3 = RST, 3586 Bit 4 = SYN, Bit 5 = FIN, Bits 6-7 = undefined. 3588 TCPflagsmask 3589 Type: byte 3590 Description: A bitmask over the TCPflags field. 3592 UDPPort 3593 Type: ushort 3594 Description: A UDP port number. 3596 UDPlength 3597 Type: ushort 3598 Description: The UDP packet length. Covers both the header and 3599 the data. 3601 UDPchecksum 3602 Type: ushort 3603 Description: The UDP packet checksum. This covers both the 3604 header *and* the data. 3606 B.5.6. Statistics SIDs 3608 SampleCount 3609 Type: ulong 3610 Description: The number of samples that were analyzed. 3612 MatchCount 3613 Type: ulong 3614 Description: The number of samples that matched the filter. 3616 DistinctMatchCount 3617 Type: ulong 3618 Description: The number of non-duplicated samples that matched 3619 the filter. 3621 MismatchCount 3622 Type: ulong 3623 Description: The number of samples that did not match the 3624 filter. 3626 DistinctMismatchCount 3627 Type: ulong 3628 Description: The number of non-duplicated samples that did not 3629 match the filter. 3631 Anomalousness 3632 Type: float 3633 Description: This represents the degree to which the statistics 3634 are unexpected, represented as a probability that a random 3635 sample set of the given size would exhibit the given behavior 3636 *or more extreme*. This can only be used with filter match 3637 or mismatch counts. With match counts, this represents the 3638 estimated probability of finding at least that many matches; 3639 with mismatch counts, the estimated probability of finding at 3640 least that many mismatches. 3642 Deviation 3643 Type: float 3644 Description: The distance of the statistics from the mean 3645 value, expressed as multiples of the standard deviation. 3646 If the value is lower than expected, then the value of this 3647 field is negative; if the value is higher than expected, 3648 then the value of this field is positive. 3650 B.5.7. Access Control SIDs 3652 AccessControlList 3653 Type: string 3654 Description: An access control list, in some format. This 3655 ought to be standardized, but isn't. 3657 MACLabel 3658 Type: string 3659 Description: The security label of the user. 3661 MACEffectiveLabel 3662 Type: string 3663 Description: The security label of the effective user 3664 identifier. 3666 MACClearances 3667 Type: string 3668 Description: The clearances of the user. 3670 MACObjectLabel 3671 Type: string 3672 Description: The security label of an object. 3674 Permissions 3675 Type: byte 3676 Description: This is a bitfield. 3677 0 = read (MSB) 3678 1 = append 3679 2 = modify 3680 3 = execute 3681 4-7 = reserved 3683 B.5.8. Uninterpreted SIDs 3685 CharSID 3686 Type: char 3687 Description: A char type with no defined semantics. 3689 ByteSID 3690 Type: byte 3691 Description: A byte type with no defined semantics. 3693 ShortSID 3694 Type: short 3695 Description: A short type with no defined semantics. 3697 UShortSID 3698 Type: ushort 3699 Description: A ushort type with no defined semantics. 3701 LongSID 3702 Type: long 3703 Description: A long type with no defined semantics. 3705 ULongSID 3706 Type: ulong 3707 Description: A ulong type with no defined semantics. 3709 FloatSID 3710 Type: float 3711 Description: A float type with no defined semantics. 3713 DoubleSID 3714 Type: double 3715 Description: A double type with no defined semantics. 3717 StringSID 3718 Type: string 3719 Description: A string type with no defined semantics. 3721 B.5.9. Packaged SIDs 3723 The following SIDs are grouped into packages. Each package, generally 3724 speaking, covers a domain of interest. The intent is to group SIDs 3725 together that would be useul to any component interested in a specific 3726 area. This organization confers the following benefits. 3728 * Components will be able to concisely specify which SIDs they 3729 do and do not understand, without being required to support a 3730 mandated set of SIDs. 3731 * Components will not be required to support SIDs for which they 3732 have no use. 3733 * Newly developed SIDs can be dropped into place with minimal 3734 fuss. 3736 Some SIDs within packages extend earlier defined SIDs. As noted in the 3737 main text, this means that the interpretation of such SIDs builds upon 3738 the meaning of the extended SIDs. 3740 B.5.9.1. Kerberos SIDs 3742 This package contains SIDs related to Kerberos activity: Kerberos 3743 extensions (as enumerated by preauthentication field types), Kerberos 3744 logging, Kerberos error types, and identities. 3746 KerberosV5PreauthType 3747 Type: ushort 3748 Description: The Kerberos V5 preauthentication field type. 3750 KerberosV5EncType 3751 Type: ushort 3752 0 = NULL (no encryption) 3753 1 = ENCTYPE_DES_CBC_CRC (DES in CBC mode with CRC32 checksum) 3754 2 = ENCTYPE_DES_CBC_MD4 (DES in CBC mode with MD4 checksum) 3755 3 = ENCTYPE_DES_CBC_MD5 (DES in CBC mode with MD5 checksum) 3756 4 = ENCTYPE_DES_CBC_RAW (DES in CBC mode raw (no checksum)) 3757 5 = ENCTYPE_DES3_CBC_SHA (DES in CBC mode with SHA1 checksum) 3758 6 = ENCTYPE_DES3_CBC_RAW (DES in CBC mode raw (no checksum)) 3759 7-510 = reserved 3760 511 = unknown encryption type 3761 Description: The Kerberos V5 encryption type used. 3763 KerberosLogUserNumber 3764 Type: string 3765 Description: The user number associated with this audit log entr 3766 be well-formed, it should be a six-digit number, although other 3767 information may be inserted here, if that six-digit number is no 3768 present. 3770 KerberosLogEventType 3771 Type: byte 3772 1 = A ticket was requested by this user. 3773 2 = A service (application) was requested by this user. 3774 3 = The allowed threshold for initial ticket requests has been e 3775 4 = User has been blacklisted by the KNSC (Kerberos system). 3776 5 = User blacklist has been cleared by the KNSC. 3777 6 = Denied request. 3778 Description: An enumerated type indicating the type of event bei 3779 logged. 3781 KerberosLogEventStatus 3782 Type: byte 3783 For KerberosLogEventType = 1, 3784 1 = Successful activity. 3785 2 = Failed ticket request: Invalid computing level. 3786 3 = Failed ticket request: Expired password. 3787 4 = Failed ticket request: Access failure. 3788 5 = Failed ticket request: Unknown user. 3789 6 = Failed ticket request: Invalid level for source. 3790 For KerberosLogEventType = 2, 3791 1 = Successful activity. 3792 2 = Failed service request: Invalid computing level. 3793 3 = Failed service request: Unknown service. 3794 4 = Failed service request: Expired ticket. 3795 5 = Failed service request: Invalid level for destination. 3796 Description: An enumerated type indicating, for various event ty 3797 the current status of the event at the time of log entry. 3799 KerberosLogEventLevel 3800 Type: char 3801 u = Unclassified. 3802 p = PARD. 3803 c = Confidential. 3804 s = Secret. 3805 Description: The user's requested computing level during 3806 authentication. 3808 KerberosLogEventService 3809 Type: string 3810 Description: Thirty-character name associated with the service 3811 requested by the user. This may be an application (such as 3812 telnet) or a node such as the CFS. A single '?' indicates that 3813 the event service name was unknown. 3815 ReturnCode (ExtendedBy KerberosV5Error) 3816 Type: byte 3817 Description: Indicates a Kerberos V5 error code. As 3818 before, zero indicates success. The complete 3819 enumeration may be found in RFC 1510. 3821 PrincipalName (ExtendedBy KerberosName) 3822 Type: string 3823 Description: A Kerberos principal name, unparsed. 3824 An example is "joe@WORK.COM". Its two extensions 3825 ought to be self-explanatory. 3827 (ExtendedBy KerberosV4Name) 3829 (ExtendedBy KerberosV5Name) 3831 ServerDNSName (ExtendedBy KerberosKDCName) 3832 Type: string 3833 Description: Indicates the host name of the Kerberos 3834 server. 3836 DomainName (ExtendedBy KerberosRealmName) 3837 Type: string 3838 Description: A Kerberos realm name. 3840 B.5.9.2. DCE SIDs 3842 This package contains SIDs related to DCE. It currently contains only 3843 identity-related SIDs, but it may also contain SIDs relating to logging, 3844 errors, and privileges. 3846 GroupName (ExtendedBy DCEGroupName) 3847 Type: string 3848 Description: A DCE group name. 3850 GroupUUID (ExtendedBy DCEGroupUUID) 3851 Type: 16-byte array 3852 Description: A DCE group UUID. 3854 DomainName (ExtendedBy DCECellName) 3855 Type: string 3856 Description: A DCE cell name. 3858 DomainUUID (ExtendedBy DCECellUUID) 3859 Type: 16-byte array 3860 Description: A DCE cell UUID. 3862 B.5.9.3. AFS SIDs (For instance, 3863 "SunOS"). (For instance, 3864 "SunOS"). (For instance, 3865 "SunOS"). (For instance, 3866 "SunOS"). (For instance, 3867 "SunOS"). 3869 This package contains SIDs related to DCE. It currently contains 3870 identity-related SIDs and ACL-related SIDs, but it may also contain SIDs 3871 relating to logging and errors. 3873 AFSProtectionGroupName 3874 Type: string 3875 Description: The protection group associated with a given ACL. 3876 This is a combination of the form ::. 3878 AFSACL 3879 Type: char 3880 r = Read. 3881 l = Lookup. 3882 i = Insert. 3883 d = Delete. 3884 w = Write. 3885 k = locK. 3886 a = Administer. 3887 Description: The access permission granted on the directory, to 3888 a given AFSProtectionGroup. 3890 GroupName (ExtendedBy AFSGroupName) 3891 Type: string 3892 Description: A AFS group name. 3894 GroupUUID (ExtendedBy AFSGroupUUID) 3895 Type: 16-byte array 3896 Description: A AFS group UUID. 3898 ServerDNSName (ExtendedBy AFSServerName) 3899 Type: string 3900 Description: Indicates the name of the host serving 3901 the AFS file within the cell. 3903 DomainName (ExtendedBy AFSCellName) 3904 Type: string 3905 Description: An AFS cell name. 3907 DomainUUID (ExtendedBy AFSCellUUID) 3908 Type: 16-byte array 3909 Description: An AFS cell UUID. 3911 B.5.9.4. CIDF Box Reporting SIDs 3913 This package contains SIDs that convey information about the status and 3914 configuration of CIDF-compliant components (referred to as "boxes"). 3916 BoxRecsPerSec 3917 Type: ulong 3918 Description: The number of records per second received since upt 3920 BoxBytesPerSec 3921 Type: ulong 3922 Description: The number of bytes per second received since uptim 3924 BoxSentRecsCnt 3925 Type: ulong 3926 Description: The total number of records received since uptime. 3928 BoxSentByteCnt 3929 Type: ulong 3930 Description: The total number of bytes received since uptime. 3932 BoxErrorCnt 3933 Type: ulong 3934 Description: The total number of errors received since uptime. 3936 BoxWarnDesc 3937 Type: string 3938 Description: A narrative description of the warning. 3940 BoxEventStreamID 3941 Type: byte 3942 0 = OS-audit 3943 1 = packet-data 3944 : 3945 : 3946 15 = reserved 3947 16 = available 3948 : 3949 255 = available 3950 Description: A byte value identifying the message stream type 3952 B.5.9.5. Enumerated Action SIDs 3954 This package contains enumerated lists of actions. 3956 FTPCommand 3957 Type: string 3958 Description: The name of an FTP command used during a session. 3960 ResourceAction 3961 Type: byte 3962 Description: An enumeration of all the actions that may be 3963 taken on a resource object. 3964 0 = access 3965 1 = chdir 3966 2 = chmod 3967 3 = chown 3968 4 = chroot 3969 5 = close 3970 6 = create 3971 7 = link 3972 8 = mount 3973 9 = open 3974 10 = read 3975 11 = umount 3976 12 = unlink 3977 13 = write 3978 14+ = reserved 3980 OSAction 3981 Type: short 3982 Description: This SID enumerates the possible OS audit/syslog ev 3983 that may be seen in an audit trail. 3984 0 = void 3985 1 = discon 3986 2 = access 3987 3 = open 3988 4 = write 3989 5 = read 3990 6 = delete 3991 7 = create 3992 8 = rmdir 3993 9 = chmod 3994 10 = exec 3995 11 = chown 3996 12 = link 3997 13 = chdir 3998 14 = su 3999 15 = bad_su 4000 16 = exit 4001 17 = logout 4002 18 = uncat 4003 19 = rsh 4004 20 = passwd 4005 21 = rmount 4006 22 = passwd_auth 4007 23 = kill 4008 24 = core 4009 25 = ptrace 4010 26 = truncate 4011 27 = utimes 4012 28 = fork 4013 29 = chroot 4014 30 = mknod 4015 31 = halt 4016 32 = reboot 4017 33 = shutdown 4018 34 = boot 4019 35 = set_time 4020 36 = setuid 4021 37 = setgid 4022 38 = audit_config 4023 39 = is_promiscuous 4024 40 = connect 4025 41 = accept 4026 42 = bind 4027 43 = socketoption 4028 44+ = reserved 4030 B.5.9.6. Unix SIDs 4032 This package contains Unix-related SIDs: error codes and identities. It 4033 may also contain other Unix-specific SIDs. 4035 ReturnCode (ExtendedBy UnixErrno) 4036 Type: byte 4037 Description: Indicates a Unix errno value. Thus, 4038 1 is EPERM, 2 is ENOENT, 3 is ESRCH, and so forth. 4039 This should be standard through 32 (EPIPE). After 4040 that, the values are not standardized, so we may see 4041 this extension further ExtendedBy LinuxErrno, for 4042 example. To be explicit about UnixErrno, we reproduce 4043 the enumeration below. (Depending on the context, 4044 this may not need to be generated by an actual Unix 4045 process, but may also be used by (for example) A-boxes 4046 explaining why an action failed.) 4047 0 = SUCCESS /* Inherited from ReturnCode */ 4048 1 = EPERM /* Operation not permitted */ 4049 2 = ENOENT /* No such file or directory */ 4050 3 = ESRCH /* No such process */ 4051 4 = EINTR /* Interrupted system call */ 4052 5 = EIO /* I/O error */ 4053 6 = ENXIO /* No such device or address */ 4054 7 = E2BIG /* Arg list too long */ 4055 8 = ENOEXEC /* Exec format error */ 4056 9 = EBADF /* Bad file number */ 4057 10 = ECHILD /* No child processes */ 4058 11 = EAGAIN /* Try again */ 4059 12 = ENOMEM /* Out of memory */ 4060 13 = EACCES /* Permission denied */ 4061 14 = EFAULT /* Bad address */ 4062 15 = ENOTBLK /* Block device required */ 4063 16 = EBUSY /* Device or resource busy */ 4064 17 = EEXIST /* File exists */ 4065 18 = EXDEV /* Cross-device link */ 4066 19 = ENODEV /* No such device */ 4067 20 = ENOTDIR /* Not a directory */ 4068 21 = EISDIR /* Is a directory */ 4069 22 = EINVAL /* Invalid argument */ 4070 23 = ENFILE /* File table overflow */ 4071 24 = EMFILE /* Too many open files */ 4072 25 = ENOTTY /* Not a typewriter */ 4073 26 = ETXTBSY /* Text file busy */ 4074 27 = EFBIG /* File too large */ 4075 28 = ENOSPC /* No space left on device */ 4076 29 = ESPIPE /* Illegal seek */ 4077 30 = EROFS /* Read-only file system */ 4078 31 = EMLINK /* Too many links */ 4079 32 = EPIPE /* Broken pipe */ 4080 33-255 = undefined 4082 ObjectName (ExtendedBy UnixPathName) 4083 Type: string 4084 Description: A fully expanded Unix pathname, if object 4085 type is file. 4087 Priority (ExtendedBy UnixNiceness) 4088 Type: short 4089 Description: The process's Unix nice value. User processes 4090 are restricted to positive (lower-priority) niceness values. 4092 ObjectName (ExtendedBy DeviceName) (ExtendedBy UnixFullDeviceName) 4093 Type: string 4094 Description: Indicates a full Unix device name, such 4095 as "/dev/ttyp0". A simple "ttyp0" is not a valid 4096 value if this extension is present. 4098 UserName (ExtendedBy UnixUserName) 4099 Type: string 4100 Description: A Unix account name. 4102 UserID (ExtendedBy UnixUID) 4103 Type: ushort 4104 Description: A Unix UID. 4106 PersistentUserName (ExtendedBy UnixAUserName) 4107 Type: string 4108 Description: A Unix audit (real) user name. 4110 PersistentUserID (ExtendedBy UnixAUID) 4111 Type: ushort 4112 Description: A Unix audit (real) user ID. 4114 CurrentUserName (ExtendedBy UnixCUserName) 4115 Type: string 4116 Description: A Unix current user name. 4118 CurrentUserID (ExtendedBy UnixEUID) 4119 Type: ushort 4120 Description: A Unix current user ID. 4122 EffectiveUserName (ExtendedBy UnixEUserName) 4123 Type: string 4124 Description: A Unix effective user name. 4126 EffectiveUserID (ExtendedBy UnixEUID) 4127 Type: ushort 4128 Description: A Unix effective user ID. 4130 GroupName (ExtendedBy UnixGroupName) 4131 Type: string 4132 Description: The name of a Unix group. 4134 EffectiveGroupName (ExtendedBy UnixEGroupName) 4135 Type: string 4136 Description: The name of a Unix effective group. 4138 UnixPermissions 4139 Type: string 4140 Description: The permissions associated with a Unix file, 4141 expressed in "04777" format. For example, "00544" means 4142 readable and executable by the owner, readable only by anyone 4143 else. 4145 B.5.9.7. DOS SIDs 4147 This package contains DOS-specific SIDs. 4149 ObjectName (ExtendedBy DOSPathName) 4150 Type: string 4151 Description: A fully expanded DOS pathname, if object 4152 type is file. 4154 B.5.9.8. X.500 SIDs 4156 This package contains X.500 SIDs. It currently contains only identity- 4157 related SIDs, but it may also contain SIDs conveying information about 4158 certificates, directory servers, and algorithms. 4160 RealName (ExtendedBy X500CommonName) 4161 Type: string 4162 Description: An X.500 Common Name. 4164 PrincipalName (ExtendedBy X500DistName) 4165 Type: string 4166 Description: An X.500 Distinguished Name, encoded as 4167 in RFC 1779. 4169 Expiration Date 4171 This draft expires September 18th, 1998. 4173 Authors 4175 Stuart Staniford-Chen 4176 Department of Computer Science, 4177 UC Davis, 4178 Davis, CA 95616 4179 Phone: 4180 (707) 825-0836 4181 Fax: 4182 (707) 826-7571 4183 E-mail: stanifor@cs.ucdavis.edu 4185 Brian Tung 4186 USC Information Sciences Institute 4187 4676 Admiralty Way Suite 1001 4188 Marina del Rey CA 90292 4189 Phone: (310) 822-1511 x135 4190 Fax: (310) 823-6714 4191 E-mail: brian@isi.edu 4192 Phil Porras 4193 SRI 4194 Phone: (650) 859-3232 4195 Fax: (650) 859-2844 4196 E-mail: porras@csl.sri.com 4198 Cliff Kahn 4199 The Open Group Research Institute 4200 11 Cambridge Center 4201 Cambridge MA 02142 4202 Phone: (617) 621-7221 4203 Fax: (617) 621-8696 4204 E-mail: c.kahn@opengroup.org 4206 Dan Schnackenberg 4207 Boeing Information, Space and Defense Systems 4208 P.O. Box 3999 4209 MS 88-12 4210 Seattle WA 98124 4211 Phone: (253) 773-8231 4212 Fax: (253) 773-1015 4213 E-mail: dan@baker.ds.boeing.com 4215 Rich Feiertag 4216 Trusted Information Systems 4217 444 Castro Street, Suite 800 4218 Phone: (415) 962-8885 x3012 4219 Fax: (415) 962-9330 4220 E-mail: feiertag@tis.com 4222 Maureen Stillman 4223 Odyssey Research Associates 4224 33 Thornwood Drive, Suite 500 4225 Phone: (607) 266-7123 4226 Fax: 4227 (607) 257-1972 4228 E-mail: maureen@oracorp.com