idnits 2.17.1 draft-ietf-idwg-beep-idxp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1097 has weird spacing: '... code mea...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2002) is 7828 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-2396' on line 985 -- Looks like a reference, but probably isn't: 'RFC-1034' on line 988 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '1') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intrusion Detection Exchange B. Feinstein 3 Format CipherTrust, Inc. 4 Internet-Draft G. Matthews 5 Expires: April 22, 2003 CSC/NASA Ames Research Center 6 J. White 7 MITRE Corporation 8 October 22, 2002 10 The Intrusion Detection Exchange Protocol (IDXP) 11 draft-ietf-idwg-beep-idxp-07 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 22, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 40 Abstract 42 This memo describes the Intrusion Detection Exchange Protocol (IDXP), 43 an application-level protocol for exchanging data between intrusion 44 detection entities. IDXP supports mutual-authentication, integrity, 45 and confidentiality over a connection-oriented protocol. The 46 protocol provides for the exchange of IDMEF messages, unstructured 47 text, and binary data. The IDMEF message elements are described in 48 the Intrusion Detection Message Exchange Format (IDMEF) [6], a 49 companion document of the Intrusion Detection Exchange Format (IDWG) 50 working group of the IETF. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1 Connection Provisioning . . . . . . . . . . . . . . . . . . 6 60 2.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.3 Connection Teardown . . . . . . . . . . . . . . . . . . . . 9 62 2.4 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3. The IDXP Profile . . . . . . . . . . . . . . . . . . . . . . 11 64 3.1 IDXP Profile Overview . . . . . . . . . . . . . . . . . . . 11 65 3.2 IDXP Profile Identification and Initialization . . . . . . . 11 66 3.3 IDXP Profile Message Syntax . . . . . . . . . . . . . . . . 12 67 3.4 IDXP Profile Semantics . . . . . . . . . . . . . . . . . . . 12 68 3.4.1 The IDXP-GREETING Element . . . . . . . . . . . . . . . . . 12 69 3.4.2 The OPTION Element . . . . . . . . . . . . . . . . . . . . . 14 70 3.4.3 The IDMEF-MESSAGE Element . . . . . . . . . . . . . . . . . 14 71 4. IDXP Options . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.1 The channelPriority Option . . . . . . . . . . . . . . . . . 16 73 4.2 The streamType Option . . . . . . . . . . . . . . . . . . . 17 74 5. Fulfillment of IDWG Communications Protocol Requirements . . 20 75 5.1 Reliable Message Transmission . . . . . . . . . . . . . . . 20 76 5.2 Interaction with Firewalls . . . . . . . . . . . . . . . . . 20 77 5.3 Mutual Authentication . . . . . . . . . . . . . . . . . . . 20 78 5.4 Message Confidentiality . . . . . . . . . . . . . . . . . . 21 79 5.5 Message Integrity . . . . . . . . . . . . . . . . . . . . . 21 80 5.6 Per-source Authentication . . . . . . . . . . . . . . . . . 21 81 5.7 Denial of Service . . . . . . . . . . . . . . . . . . . . . 22 82 5.8 Message Duplication . . . . . . . . . . . . . . . . . . . . 22 83 6. Extending IDXP . . . . . . . . . . . . . . . . . . . . . . . 23 84 7. IDXP Option Registration Template . . . . . . . . . . . . . 24 85 8. Initial Registrations . . . . . . . . . . . . . . . . . . . 25 86 8.1 Registration: The IDXP Profile . . . . . . . . . . . . . . . 25 87 8.2 Registration: The System (Well-Known) TCP port number 88 for IDXP . . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 8.3 Registration: The channelPriority Option . . . . . . . . . . 25 90 8.4 Registration: The streamType Option . . . . . . . . . . . . 26 91 9. The DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 9.1 The IDXP DTD . . . . . . . . . . . . . . . . . . . . . . . . 27 93 9.2 The channelPriority Option DTD . . . . . . . . . . . . . . . 28 94 9.3 The streamType DTD . . . . . . . . . . . . . . . . . . . . . 29 95 10. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . 31 96 11. Security Considerations . . . . . . . . . . . . . . . . . . 32 97 11.1 Use of the TUNNEL Profile . . . . . . . . . . . . . . . . . 32 98 11.2 Use of Underlying Security Profiles . . . . . . . . . . . . 32 99 Informational References . . . . . . . . . . . . . . . . . . 33 100 Normative References . . . . . . . . . . . . . . . . . . . . 34 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 102 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 103 B. History of Significant Changes . . . . . . . . . . . . . . . 36 104 B.1 Significant Changes Since beep-idxp-06 . . . . . . . . . . . 36 105 B.2 Significant Changes Since beep-idxp-05 . . . . . . . . . . . 36 106 B.3 Significant Changes Since beep-idxp-04 . . . . . . . . . . . 36 107 B.4 Significant Changes Since beep-idxp-03 . . . . . . . . . . . 36 108 B.5 Significant Changes Since beep-idxp-02 . . . . . . . . . . . 37 109 B.6 Significant Changes Since beep-idxp-01 . . . . . . . . . . . 38 110 B.7 Significant Changes Since beep-idxp-00 . . . . . . . . . . . 38 111 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 112 Full Copyright Statement . . . . . . . . . . . . . . . . . . 40 114 1. Introduction 116 IDXP is specified, in part, as a Blocks Extensible Exchange Protocol 117 (BEEP) [8] "profile". BEEP is a generic application protocol 118 framework for connection-oriented, asynchronous interactions. 119 Features such as authentication and confidentiality are provided 120 through the use of other BEEP profiles. Accordingly, many aspects of 121 IDXP (e.g., confidentiality) are provided within the BEEP framework. 123 1.1 Purpose 125 IDXP provides for the exchange of IDMEF [6] messages, unstructured 126 text, and binary data between intrusion detection entities. 127 Addressing the security-sensitive nature of exchanges between 128 intrusion detection entities, underlying BEEP security profiles 129 should be used to offer IDXP the required set of security properties. 130 See Section 5 for a discussion of how IDXP fulfills the IDWG 131 communication protocol requirements. See Section 11 for a discussion 132 of security considerations. 134 IDXP is primarily intended for the exchange of data created by 135 intrusion detection entities. IDMEF [6] messages should be used for 136 the structured representation of this intrusion detection data, 137 although IDXP may be used to exchange unstructured text and binary 138 data. 140 1.2 Profiles 142 There are several BEEP profiles discussed, the first of which we 143 define in this memo: 145 The IDXP Profile 147 The TUNNEL Profile [7] 149 The Simple Authentication and Security Layer (SASL) Family of 150 Profiles (c.f., Section 4.1 of [8]) 152 The TLS Profile (c.f., Section 3.1 of [8]) 154 1.3 Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [2]. 160 Throughout this memo, the terms "analyzer" and "manager" are used in 161 the context of the Intrusion Detection Message Exchange Requirements 162 [9]. In particular, Section 3.2 of [9] defines the meaning of a 163 collection of intrusion detection terms. 165 The terms "peer", "initiator", "listener", "client", and "server", 166 and the characters "I", "L", "C", and "S" are used in the context of 167 BEEP [8]. In particular, Section 2.1 of BEEP discusses the roles 168 that a BEEP peer may perform. 170 The term "Document Type Declaration" is abbreviated as "DTD" and is 171 defined in Section 2.8 of the Extensible Markup Language (XML) [3]. 173 Note that the term "proxy" is specific to IDXP, and does not exist in 174 the context of BEEP. The term "intrusion detection" is abbreviated 175 as "ID". 177 2. The Model 179 2.1 Connection Provisioning 181 Intrusion detection entities using IDXP to transfer data are termed 182 IDXP peers. Peers can exist only in pairs, and these pairs 183 communicate over a single BEEP session with one or more BEEP channels 184 opened for transferring data. Peers are either managers or 185 analyzers, as defined in Section 3.2 of [9]. 187 The relationship between analyzers and managers is potentially many- 188 to-many. I.e., an analyzer MAY communicate with many managers; 189 similarly, a manager MAY communicate with many analyzers. Likewise, 190 the relationship between different managers is potentially many-to- 191 many, so that a manager MAY receive the alerts sent by a large number 192 of analyzers by receiving them through intermediate managers. 193 Analyzers MUST NOT establish IDXP exchanges with other analyzers. 195 An IDXP peer wishing to establish IDXP communications with another 196 IDXP peer does so by opening a BEEP channel, which may entail 197 initiating a BEEP session. A BEEP security profile offering the 198 required security properties SHOULD initially be negotiated (see 199 Section 11 for a discussion of security considerations). Following 200 the successful negotiation of the BEEP security profile, IDXP 201 greetings are exchanged and connection provisioning proceeds. 203 In the following sequence a peer 'Alice' initiates an IDXP exchange 204 with the peer 'Bob'. 206 Alice Bob 207 ---------------- xport connect[1] ------------------> 208 <-------------------- greeting ----------------------> 209 <-------------start security profile[2] -------------> 210 <-------------------- greeting ----------------------> 211 <------------------ start IDXP[3] -------------------> 213 Notes: 215 [1] 'Alice' initiates a transport connection to 'Bob', triggering the 216 exchange of BEEP greeting messages. 218 [2] both entities negotiate the use of a BEEP security profile. 220 [3] both entities negotiate the use of the IDXP profile. 222 In between a pair of IDXP peers may be an arbitrary number of 223 proxies. A proxy may be necessary for administrative reasons, such 224 as running on a firewall to allow restricted access. Another use 225 might be one proxy per company department, which forwards data from 226 the analyzer peers in the department onto a company-wide manager 227 peer. 229 A BEEP tuning profile MAY be used to create an application-layer 230 tunnel that transparently forwards data over a chain of proxies. The 231 TUNNEL profile [7] SHOULD be used for this purpose; see [7] for more 232 detail concerning the options available to setup an application-layer 233 tunnel using TUNNEL, and see Section 11.1 for a discussion of TUNNEL 234 related security considerations. TUNNEL MUST be offered as a tuning 235 profile for the creation of application-layer tunnels. The TUNNEL 236 profile MUST offer the use of some form of SASL authentication (c.f., 237 Section 4.1 of [8]). Once a tunnel has been created a BEEP security 238 profile offering the required security properties SHOULD be 239 negotiated, followed by negotiation of the IDXP profile. 241 The following sequence shows how TUNNEL might be used to create an 242 application-layer tunnel through which IDXP would operate. A peer 243 'Alice' initiates the creation of a BEEP session using the IDXP 244 profile with the entity 'Bob' by first contacting 'proxy1'. In the 245 greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile is 246 selected, and subsequently the use of the TUNNEL profile is extended 247 to reach through 'proxy2' to 'Bob'. 249 Alice proxy1 proxy2 Bob 250 -- xport connect --> 251 <---- greeting -----> 252 -- start TUNNEL ---> 253 - xport connect[1] -> 254 <----- greeting -----> 255 --- start TUNNEL ---> 256 --- xport connect --> 257 <----- greeting -----> 258 --- start TUNNEL ---> 259 <----- [2] ------ 260 <------- ------- 261 <------ ------- 262 <------------------------- greeting --------------------------> 263 <------------------ start security profile -------------------> 264 <------------------------- greeting --------------------------> 265 <------------------------ start IDXP -------------------------> 267 Notes: 269 [1] Instead of immediately acknowledging the request from 'Alice' to 270 start TUNNEL, 'proxy1' attempts to establish use of TUNNEL with 271 'proxy2'. 'proxy2' also delays its acknowledgment to 'proxy1'. 273 [2] 'Bob' acknowledges the request from 'proxy2' to start TUNNEL, and 274 this acknowledgment propagates back to 'Alice' so that a TUNNEL 275 application-layer tunnel is established from 'Alice' to 'Bob'. 277 2.2 Data Transfer 279 Between a pair of ID entities communicating over a BEEP session, one 280 or more BEEP channels MAY be opened using the IDXP profile. If 281 desired, additional BEEP sessions MAY be established to offer 282 additional channels using the IDXP profile. However, in most 283 situations additional channels using the IDXP profile SHOULD be 284 opened within an existing BEEP session, as opposed to provisioning a 285 new BEEP session containing the additional channels using the IDXP 286 profile. 288 Peers assume the role of client or server on a per-channel basis, 289 with one acting as the client and the other as the server. A peer's 290 role of client or server is determined independent of whether the 291 peer assumed the role of initiator or listener during the BEEP 292 session establishment. Clients and servers act as sources and sinks, 293 respectively, for exchanging data. 295 In a simple case, an analyzer peer sends data to a manager peer. 296 E.g., 298 +----------+ +----------+ 299 | | | | 300 | |****** BEEP session ******| | 301 | | | | 302 | Analyzer | ----- IDXP profile ----> | Manager | 303 | (Client) | | (Server) | 304 | | | | 305 | |**************************| | 306 | | | | 307 +----------+ +----------+ 309 Use of multiple BEEP channels in a BEEP session facilitates 310 categorization and prioritization of data sent between IDXP peers. 311 For example, a manager 'M1', sending alert data to another manager, 312 'M2', may choose to open a separate channel to exchange different 313 categories of alerts. 'M1' would act as the client on each of these 314 channels, and manager 'M2' can then process and act on the incoming 315 alerts based on their respective channel categorizations. See 316 Section 4 for more detail on how to incorporate categorization and/or 317 prioritization into channel creation. 319 +----------+ +----------+ 320 | | | | 321 | |*************** BEEP session ***************| | 322 | | | | 323 | | -- IDXP profile, network-based alerts ---> | | 324 | Manager | | Manager | 325 | M1 | ---- IDXP profile, host-based alerts ----> | M2 | 326 | (Client) | | (Server) | 327 | | ------ IDXP profile, other alerts -------> | | 328 | | | | 329 | |********************************************| | 330 | | | | 331 +----------+ +----------+ 333 2.3 Connection Teardown 335 An IDXP peer may choose to close an IDXP channel under many different 336 circumstances (e.g., an error in processing has occurred). To close 337 a channel, the peer sends a "close" element (c.f., Section 2.3.1.3 of 338 [8]) on channel zero indicating which channel is being closed. An 339 IDXP peer may also choose to close an entire BEEP session by sending 340 a "close" element indicating that channel zero is to be closed. 341 Section 2.3.1.3 of [8] offers a more complete discussion of the 342 circumstances under which a BEEP peer is permitted to close a channel 343 and the mechanisms for doing so. 345 It is anticipated that due to the overhead of provisioning an 346 application-layer tunnel and/or a BEEP security profile, BEEP 347 sessions containing IDXP channels will be long-lived. Additionally, 348 the repeated overhead of IDXP channel provisioning (i.e., the 349 exchange of IDXP greetings) may be avoided by keeping IDXP channels 350 open even while data is not actively being exchanged on them. These 351 are recommendations and, as such, IDXP peers may choose to close and 352 re-provision BEEP sessions and/or IDXP channels as they see fit. 354 2.4 Trust Model 356 In our model, trust is placed exclusively in the IDXP peers. Proxies 357 are always assumed to be untrustworthy. A BEEP security profile is 358 used to establish end-to-end security between pairs of IDXP peers, 359 doing away with the need to place trust in any intervening proxies. 360 Only after successful negotiation of the underlying security profile 361 are IDXP peers to be trusted. Only BEEP security profiles offering 362 at least the protections required by Section 5 of [9] should be used 363 to secure a BEEP session containing channels using the IDXP profile. 364 See Section 3 of [8] for the registration of the TLS profile, an 365 example of a BEEP security profile meeting the requirements of 366 Section 5 of [9]. See Section 5 for a discussion of how IDXP 367 fulfills the IDWG communications protocol requirements. 369 3. The IDXP Profile 371 3.1 IDXP Profile Overview 373 The IDXP profile provides a mechanism for exchanging information 374 between intrusion detection entities. A BEEP tuning profile MAY be 375 used to create an application-layer tunnel that transparently 376 forwards data over a chain of proxies. The TUNNEL profile [7] SHOULD 377 be used for this purpose; see [7] for more detail concerning the 378 options available to setup an application-layer tunnel using TUNNEL, 379 and see Section 11.1 for a discussion of TUNNEL related security 380 considerations. TUNNEL MUST be offered as a tuning profile for the 381 creation of application-layer tunnels. The TUNNEL profile MUST offer 382 the use of some form of SASL authentication (c.f., Section 4.1 of 383 [8]). The TLS profile SHOULD be used to provide the required 384 combination of mutual-authentication, integrity, and confidentiality 385 for the IDXP profile. For further discussion of application-layer 386 tunnel and security issues see Section 2.1 and Section 11. 388 The IDXP profile supports several elements of interest: 390 o The "IDXP-Greeting" element identifies an analyzer or manager at 391 one end of a BEEP channel to the analyzer or manager at the other 392 end of the channel. 394 o The "Option" element is used to convey optional channel parameters 395 between peers during the exchange of "IDXP-Greeting" elements. 396 This element is OPTIONAL. 398 o The "IDMEF-Message" element carries the structured information to 399 be exchanged between the peers. 401 3.2 IDXP Profile Identification and Initialization 403 The IDXP profile is identified as 405 http://iana.org/beep/transient/idwg/idxp 407 in the BEEP "profile" element during channel creation. 409 During channel creation, "IDXP-Greeting" elements MUST be mutually 410 exchanged between the peers. An "IDXP-Greeting" element MAY be 411 contained within the corresponding "profile" element in the BEEP 412 "start" element. Including an "IDXP-Greeting" element in the initial 413 "start" element has exactly the same semantics as passing it as the 414 first "MSG" message on the channel. If channel creation is 415 successful, then before sending the corresponding reply, the BEEP 416 peer processes the "IDXP-Greeting" element and includes the resulting 417 response in the reply. This response will be an "ok" element or an 418 "error" element. The choice of which element is returned is 419 dependent on local provisioning of the peer. 421 3.3 IDXP Profile Message Syntax 423 BEEP messages in the profile MUST have a MIME Content-Type [4] of 424 "text/xml", "text/plain", or "application/octet-stream". The syntax 425 of the individual elements is specified in Section 9.1 and Section 5 426 of [6]. 428 3.4 IDXP Profile Semantics 430 Each BEEP peer issues the "IDXP-Greeting" element using "MSG" 431 messages. The "IDXP-Greeting" element MAY contain one or more 432 "Option" sub-elements, conveying optional channel parameters. Each 433 BEEP peer then issues "ok" in "RPY" messages or "error" in "ERR" 434 messages. (See Section 2.3.1 of [8] for the definitions of the 435 "error" and "ok" elements.) An "error" element MAY be issued within a 436 "RPY" message when piggy-backed within a BEEP "profile" element. See 437 Section 3.4.1 for an example of an "error" element being issued 438 within a "RPY" message. Based on the respective client/server roles 439 negotiated during the exchange of "IDXP-Greeting" elements, the 440 client sends data using "MSG" messages. Depending on the MIME 441 Content-Type, this data may be an "IDMEF-Message" element, plain 442 text, or binary. The server then issues "ok" in "RPY" messages or 443 "error" in "ERR" messages. 445 3.4.1 The IDXP-GREETING Element 447 The "IDXP-Greeting" element serves to identify the analyzer or 448 manager at one end of the BEEP channel to the analyzer or manager at 449 the other end of the channel. The "IDXP-Greeting" element MUST 450 include the role of the peer on the channel (client or server) and 451 the Uniform Resource Identifier (URI) [1] of the peer. Additionally, 452 the "IDXP-Greeting" element MAY include the fully qualified domain 453 name (c.f., [5]) of the peer. One or more "Option" sub-elements MAY 454 be present. 456 An "IDXP-Greeting" element MAY be sent by either peer at any time. 457 The peer receiving the "IDXP-Greeting" MUST respond with an "ok" 458 (indicating acceptance), or an "error" (indicating rejection). A 459 peer's identity and role on a channel and any optional channel 460 parameters are, in effect, specified by the most recent "IDXP- 461 Greeting" it sent that was answered with an "ok". 463 An "IDXP-Greeting" may be rejected (with an "error" element) under 464 many circumstances. These include, but are not limited to, 465 authentication failure, lack of authorization to connect under the 466 specified role, the negotiation of an inadequate ciphersuite, or the 467 presence of a channel option that must be understood but was 468 unrecognized. 470 For example, a successful creation with an embedded "IDXP-Greeting" 471 might look like this: 473 I: MSG 0 10 . 1592 187 474 I: Content-Type: text/xml 475 I: 476 I: 477 I: 478 I: ]]> 480 I: 481 I: 482 I: END 483 L: RPY 0 10 . 1865 91 484 L: Content-Type: text/xml 485 L: 486 L: 487 L: ]]> 488 L: 489 L: END 490 L: MSG 0 11 . 1956 61 491 L: Content-Type: text/xml 492 L: 493 L: 494 L: END 495 I: RPY 0 11 . 1779 7 496 I: Content-Type: text/xml 497 I: 498 I: 499 I: END 500 A creation with an embedded "IDXP-Greeting" that fails might look 501 like this: 503 I: MSG 0 10 . 1776 185 504 I: Content-Type: text/xml 505 I: 506 I: 507 I: 508 I: ]]> 510 I: 511 I: 512 I: END 513 L: RPY 0 10 . 1592 182 514 L: Content-Type: text/xml 515 L: 516 L: 517 L: 'http://example.com/eve' must first 519 L: negotiate the TLS profile ]]> 520 L: 521 L: END 523 3.4.2 The OPTION Element 525 If present, the "Option" element MUST be contained within an "IDXP- 526 Greeting" element. An individual "IDXP-Greeting" element MAY contain 527 one or more "Option" sub-elements. Each "Option" element within an 528 "IDXP-Greeting" element represents a request to enable an IDXP option 529 on the channel being negotiated. See Section 4 for a complete 530 description of IDXP options and the "Option" element. 532 3.4.3 The IDMEF-MESSAGE Element 534 The "IDMEF-Message" element carries the information to be exchanged 535 between the peers. See Section 5 of [6] for the definition of this 536 element. 538 4. IDXP Options 540 IDXP provides a service for the reliable exchange of data between 541 intrusion detection entities. Options are used to alter the 542 semantics of the service. 544 The specification of an IDXP option MUST define: 546 o the identity of the option; 548 o what content, if any, is contained within the option; and, 550 o the processing rules for the option. 552 An option registration template (c.f. Section 7) organizes this 553 information. 555 An "Option" element is contained within an "IDXP-Greeting" element. 556 The "IDXP-Greeting" element itself MAY contain one or more "Option" 557 elements. The "Option" element has several attributes and contains 558 arbitrary content: 560 o the "internal" and the "external" attributes, exactly one of which 561 MUST be present, uniquely identify the option; 563 o the "mustUnderstand" attribute, whose presence is OPTIONAL and 564 whose default value is "false", specifies whether the option, if 565 unrecognized, MUST cause an error in processing to occur; and, 567 o the "localize" attribute, whose presence is OPTIONAL, specifies 568 one or more language tokens, each identifying a desirable language 569 tag to be used if textual diagnostics are returned to the 570 originator. 572 The value of the "internal" attribute is the IANA-registered name for 573 the option. If the "internal" attribute is not present, then the 574 value of the "external" attribute is a URI or URI with a fragment- 575 identifier. Note that a relative-URI value is not allowed. 577 The "mustUnderstand" attribute specifies whether the peer may ignore 578 the option if it is unrecognized. If the value of the 579 "mustUnderstand" attribute is "true", and if the peer does not 580 recognize the option, then an error in processing has occurred. When 581 absent, the value of the "mustUnderstand" attribute is defined to be 582 "false". 584 4.1 The channelPriority Option 586 Section 8.3 contains the IDXP option registration for the 587 "channelPriority" option. This option contains a "channelPriority" 588 element (c.f., Section 9.2). 590 By default, IDXP does not place any requirements on how peers should 591 manage multiple IDXP channels. The "channelPriority" option provides 592 a way for peers using multiple IDXP channels to request relative 593 priorities for each channel. When sending an "IDXP-Greeting" element 594 during the provisioning of an IDXP channel, the originating peer MAY 595 request that the remote peer assign a priority to the channel by 596 including an "Option" element containing a "channelPriority" element. 598 The "channelPriority" element has one attribute named "priority", of 599 range 0..2147483647. This attribute is REQUIRED. Not 600 coincidentally, this is the maximum range of possible BEEP channel 601 numbers. 0 is defined to represent the highest priority, with 602 relative priority decreasing as the "priority" value ascends. 604 For example, during the exchange of "IDXP-Greeting" elements during 605 channel provisioning, an analyzer successfully requests that a 606 manager assign a priority to the channel: 608 analyzer manager 609 --------------- greeting w/ option -----------------> 610 <---------------------- ------------------------ 612 C: MSG 1 17 . 1984 165 613 C: Content-Type: text/xml 614 C: 615 C: 616 C: 619 C: 620 C: END 621 S: RPY 1 17 . 2001 7 622 S: Content-Type: text/xml 623 S: 624 S: 625 S: END 626 For example, during the exchange of "IDXP-Greeting" elements during 627 channel provisioning, a manager unsuccessfully requests that an 628 analyzer assign a priority to the channel: 630 analyzer manager 631 <---------------- greeting w/ option ---------------- 632 --------------------- ----------------------> 634 S: MSG 1 17 . 1312 194 635 S: Content-Type: text/xml 636 S: 637 S: 638 S: 641 S: 642 S: END 643 C: ERR 1 17 . 451 68 644 C: Content-Type: text/xml 645 C: 646 C: 'channelPriority' option was unrecognized 647 C: END 649 4.2 The streamType Option 651 Section 8.4 contains the IDXP option registration for the 652 "streamType" option. This option contains a "streamType" element 653 (c.f., Section 9.3). 655 By default, IDXP provides no explicit method for categorizing 656 channels. The "streamType" option provides a way for peers to 657 request that a channel be categorized as a particular stream type. 658 When sending an "IDXP-Greeting" element during the provisioning of an 659 IDXP channel, the originating peer MAY request that the remote peer 660 assign a stream type to the channel by including an "Option" element 661 containing a "streamType" element. 663 The "streamType" element has one attribute named "type", with the 664 possible values of "alert", "heartbeat", or "config". This attribute 665 is REQUIRED. A value of "alert" indicates that the channel should be 666 categorized as being used for the exchange of ID alerts. A value of 667 "heartbeat" indicates that the channel should be categorized as being 668 used for the exchange of heartbeat messages such as the "Heartbeat" 669 element (c.f., Section 5 of [6]). A value of "config" indicates that 670 the channel should be categorized as being used for the exchange of 671 configuration messages. 673 For example, during the exchange of "IDXP-Greeting" elements during 674 channel provisioning, an analyzer successfully requests that a 675 manager assign a stream type to the channel: 677 analyzer manager 678 --------------- greeting w/ option -----------------> 679 <---------------------- ------------------------ 681 C: MSG 1 21 . 1963 155 682 C: Content-Type: text/xml 683 C: 684 C: 685 C: 688 C: 689 C: END 690 S: RPY 1 21 . 1117 7 691 S: Content-Type: text/xml 692 S: 693 S: 694 S: END 695 For example, during the exchange of "IDXP-Greeting" elements during 696 channel provisioning, a manager unsuccessfully requests that an 697 analyzer assign a stream type to the channel: 699 analyzer manager 700 <---------------- greeting w/ option ---------------- 701 --------------------- ----------------------> 703 S: MSG 1 21 . 1969 176 704 S: Content-Type: text/xml 705 S: 706 S: 707 S: 710 S: 711 S: END 712 C: ERR 1 21 . 1292 63 713 C: Content-Type: text/xml 714 C: 715 C: 'streamType' option was unrecognized 716 C: END 718 5. Fulfillment of IDWG Communications Protocol Requirements 720 The following lists each of the communications protocol requirements 721 established in Section 5 of [9] and, for each requirement, describes 722 the manner in which it is fulfilled. IDXP itself does not fulfill 723 each of the communications protocol requirements, but instead relies 724 on the underlying BEEP protocol and a variety of BEEP profiles. 726 5.1 Reliable Message Transmission 728 The [protocol] MUST support reliable transmission of messages. See 729 Section 5.1 of [9]. 731 IDXP operates over BEEP, which operates only over reliable 732 connection-oriented transport protocols (e.g., TCP). In addition, 733 BEEP peers communicate using a simple request-response protocol, 734 which provides end-to-end reliability between peers. 736 5.2 Interaction with Firewalls 738 The [protocol] MUST support transmission of messages between ID 739 components across firewall boundaries without compromising security. 740 See Section 5.2 of [9]. 742 The TUNNEL profile [7] MUST be offered as an option for creation 743 of application-layer tunnels to allow operation across firewalls. 744 The TUNNEL profile SHOULD be used to provide an application-layer 745 tunnel. The ability to authenticate hosts during the creation of 746 an application-layer tunnel MUST be provided by the mechanism 747 chosen to create such tunnels. A firewall may therefore be 748 configured to authenticate all hosts attempting to tunnel into the 749 protected network. If the TUNNEL profile is used, SASL (c.f., 750 Section 4.1 of [8]) MUST be offered as a mechanism by which hosts 751 can be authenticated. 753 5.3 Mutual Authentication 755 The [protocol] MUST support mutual authentication of the analyzer and 756 the manager to each other. See Section 5.3 of [9]. 758 IDXP supports mutual authentication of the peers through the use 759 of an appropriate underlying BEEP security profile. The TLS 760 profile and members of the SASL family of profiles (c.f., Section 761 4.1 of [8]) are examples of security profiles that may be used to 762 authenticate the identity of communicating ID components. TLS 763 MUST be offered as a mechanism to provide mutual authentication, 764 and TLS SHOULD be used to provide mutual authentication. 766 5.4 Message Confidentiality 768 The [protocol] MUST support confidentiality of the message content 769 during message exchange. The selected design MUST be capable of 770 supporting a variety of encryption algorithms and MUST be adaptable 771 to a wide variety of environments. See Section 5.4 of [9]. 773 IDXP supports confidentiality through the use of an appropriate 774 underlying BEEP security profile. The TLS profile is an example a 775 security profile that offers confidentiality. The TLS profile 776 with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be 777 offered as a mechanism to provide confidentiality, and TLS with 778 this cipher suite SHOULD be used to provide confidentiality. The 779 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses ephemeral 780 Diffie-Hellman (DHE) with DSS signatures for key exchange and 781 triple DES (3DES) and cipher-block chaining (CBC) for encryption. 782 Stronger cipher suites are optional. 784 5.5 Message Integrity 786 The [protocol] MUST ensure the integrity of the message content. The 787 selected design MUST be capable of supporting a variety of integrity 788 mechanisms and MUST be adaptable to a wide variety of environments. 789 See Section 5.5 of [9]. 791 IDXP supports message integrity through the use of an appropriate 792 underlying BEEP security profile. The TLS profile and members of 793 the SASL family of profiles (c.f., Section 4.1 of [8]) are 794 examples of security profiles that offer message integrity. The 795 TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher 796 suite MUST be offered as a mechanism to provide integrity, and TLS 797 with this cipher suite SHOULD be used to provide integrity. The 798 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses the Secure 799 Hash Algorithm (SHA) for integrity protection using a keyed 800 message authentication code. Stronger cipher suites are optional. 802 5.6 Per-source Authentication 804 The [protocol] MUST support separate authentication keys for each 805 sender. See Section 5.6 of [9]. 807 IDXP supports separate authentication keys for each sender (i.e., 808 per-source authentication) through the use of an appropriate 809 underlying BEEP security profile. The TLS profile is an example 810 of a security profile that supports per-source authentication 811 through the mutual authentication of public-key certificates. TLS 812 MUST be offered as a mechanism to provide per-source 813 authentication, and TLS SHOULD be used to provide per-source 814 authentication. 816 5.7 Denial of Service 818 The [protocol] SHOULD resist protocol denial of service attacks. See 819 Section 5.7 of [9]. 821 IDXP supports resistance to denial of service (DoS) attacks 822 through the use of an appropriate underlying BEEP security 823 profile. BEEP peers offering the IDXP profile MUST offer the use 824 of TLS with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite, 825 and SHOULD use TLS with that cipher suite. To resist DoS attacks 826 it is helpful to discard traffic arising from a non-authenticated 827 source. BEEP peers MUST support the use of authentication in 828 conjunction with any mechanism used to create application-layer 829 tunnels. In particular, the use of some form of SASL 830 authentication (c.f., Section 4.1 of [8]) MUST be offered to 831 provide authentication in the use of the TUNNEL profile. See 832 Section 7 of [7] for a discussion of security considerations in 833 the use of the TUNNEL profile. 835 5.8 Message Duplication 837 The [protocol] SHOULD resist malicious duplication of messages. See 838 Section 5.8 of [9]. 840 IDXP supports resistance to malicious duplication of messages 841 (i.e., replay attacks) through the use of an appropriate 842 underlying BEEP security profile. The TLS profile is an example 843 of a security profile offering resistance to replay attacks. The 844 TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher 845 suite MUST be offered as a mechanism to provide resistance against 846 replay attacks, and TLS with this cipher suite SHOULD be used to 847 provide resistance against replay attacks. The 848 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses cipher-block 849 chaining (CBC) to ensure that even if a message is duplicated the 850 cipher-text duplicate will produce a very different plain-text 851 result. Stronger cipher suites are optional. 853 6. Extending IDXP 855 The specification of IDXP options (c.f., Section 4) is the preferred 856 method of extending IDXP. In order to extend IDXP, an IDXP option 857 SHOULD be documented in a Standards Track RFC and MUST be registered 858 with the IANA (c.f., Section 7). IDXP extensions that cannot be 859 expressed as IDXP options MUST be documented in a Standards Track 860 RFC. 862 7. IDXP Option Registration Template 864 When an IDXP option is registered, the following information is 865 supplied: 867 Option Identification: specify the NMTOKEN or the URI that 868 authoritatively identifies this option. 870 Contains: specify the XML content that is contained within the 871 "Option" element. 873 Processing Rules: specify the processing rules associated with the 874 option. 876 Contact Information: specify the postal and electronic contact 877 information for the author(s) of the option. 879 8. Initial Registrations 881 8.1 Registration: The IDXP Profile 883 Profile identification: http://iana.org/beep/transient/idwg/idxp 885 Messages exchanged during channel creation: "IDXP-Greeting" 887 Messages starting one-to-one exchanges: "IDXP-Greeting", "IDMEF- 888 Message" 890 Messages in positive replies: "ok" 892 Messages in negative replies: "error" 894 Messages in one-to-many exchanges: none 896 Message syntax: c.f., Section 3.3 898 Message semantics: c.f., Section 3.4 900 Contact information: c.f., the "Authors' Addresses" section of this 901 memo 903 8.2 Registration: The System (Well-Known) TCP port number for IDXP 905 Protocol Number: TCP 907 Message Formats, Types, Opcodes, and Sequences: c.f., Section 3.3 909 Functions: c.f., Section 3.4 911 Use of Broadcast/Multicast: none 913 Proposed Name: Intrusion Detection Exchange Protocol 915 Short name: idxp 917 Contact Information: c.f., the "Authors' Addresses" section of this 918 memo 920 8.3 Registration: The channelPriority Option 922 Option Identification: channelPriority 924 Contains: channelPriority (c.f., Section 9.2) 926 Processing Rules: c.f., Section 4.1 927 Contact Information: c.f., the "Authors' Addresses" section of this 928 memo 930 8.4 Registration: The streamType Option 932 Option Identification: streamType 934 Contains: streamType (c.f., Section 9.3) 936 Processing Rules: c.f., Section 4.2 938 Contact Information: c.f., the "Authors' Addresses" section of this 939 memo 941 9. The DTDs 943 9.1 The IDXP DTD 945 The following is the DTD defining the valid elements for the IDXP 946 profile 948 958 960 962 %BEEP; 964 966 %IDMEF; 968 979 991 992 994 1001 1002 1007 1013 1014 1020 1026 1028 9.2 The channelPriority Option DTD 1030 The following is the DTD defining the valid elements for the 1031 channelPriority option 1032 1043 1052 1054 1055 1058 1060 9.3 The streamType DTD 1062 The following is the DTD defining the valid elements for the 1063 streamType option 1064 1075 1084 1086 1087 1090 1092 10. Reply Codes 1094 This section lists the three-digit error codes the IDXP profile may 1095 generate. 1097 code meaning 1098 ==== ======= 1099 421 Service not available 1100 (E.g., the peer does not have sufficient resources.) 1102 450 Requested action not taken 1103 (E.g., DNS lookup failed or connection could not 1104 be established. See also 550.) 1106 454 Temporary authentication failure 1108 500 General syntax error 1109 (E.g., poorly-formed XML) 1111 501 Syntax error in parameters 1112 (E.g., non-valid XML) 1114 504 Parameter not implemented 1116 530 Authentication required 1118 534 Authentication mechanism insufficient 1119 (E.g., cipher suite too weak, sequence exhausted, etc.) 1121 535 Authentication failure 1123 537 Action not authorized for user 1125 550 Requested action not taken 1126 (E.g., peer could be contacted, but 1127 malformed greeting or no IDXP profile advertised.) 1129 553 Parameter invalid 1131 554 Transaction failed 1132 (E.g., policy violation) 1134 11. Security Considerations 1136 The IDXP profile is a profile of BEEP. In BEEP, transport security, 1137 user authentication, and data exchange are orthogonal. Refer to 1138 Section 8 of [8] for a discussion of this. It is strongly 1139 recommended that those wanting to use the IDXP profile initially 1140 negotiate a BEEP security profile between the peers that offers the 1141 required security properties. The TLS profile SHOULD be used to 1142 provide for transport security. See Section 5 for a discussion of 1143 how IDXP fulfills the IDWG communications protocol requirements. 1145 See Section 2.4 for a discussion of the trust model. 1147 11.1 Use of the TUNNEL Profile 1149 See Section 5 for IDXP's requirements on application-layer tunneling 1150 and the TUNNEL profile specifically. See Section 7 of [7] for a 1151 discussion of the security considerations inherent in the use of the 1152 TUNNEL profile. 1154 11.2 Use of Underlying Security Profiles 1156 At present, the TLS profile is the only BEEP security profile known 1157 to meet all of the requirements set forth in Section 5 of [9]. When 1158 securing a BEEP session with the TLS profile, the 1159 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite offers an acceptable 1160 level of security. See Section 5 for a discussion of how IDXP 1161 fulfills the IDWG communications requirements through the use of an 1162 underlying security profile. 1164 Informational References 1166 [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 1167 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1169 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1170 Levels", BCP 14, RFC 2119, March 1997. 1172 [3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1173 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 1174 October 2000, . 1176 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1177 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1178 1996. 1180 [5] Mockapetris, P., "Domain names - concepts and facilities", STD 1181 13, RFC 1034, November 1987. 1183 Normative References 1185 [6] Curry, D. and H. Debar, "Intrusion Detection Message Exchange 1186 Format Data Model and Extensible Markup Language (XML) Document 1187 Type Definition", RFC XXXX, Month YYYY. 1189 [7] New, D., "The TUNNEL Profile Registration", RFC XXXX, Month 1190 YYYY. 1192 [8] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 1193 3080, March 2001. 1195 [9] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange 1196 Requirements", RFC XXXX, Month YYYY. 1198 Authors' Addresses 1200 Benjamin S. Feinstein 1201 CipherTrust, Inc. 1203 EMail: Ben.Feinstein@ciphertrust.com 1204 URI: http://www.ciphertrust.com/ 1206 Gregory A. Matthews 1207 CSC/NASA Ames Research Center 1209 EMail: gmatthew@nas.nasa.gov 1210 URI: http://www.nas.nasa.gov/ 1212 John C. C. White 1213 MITRE Corporation 1215 EMail: jccw@mitre.org 1216 URI: http://www.mitre.org/ 1218 Appendix A. IANA Considerations 1220 The IANA registers "IDXP" as a standards-track BEEP profile, as 1221 specified in Section 8.1. The IANA changes the IDXP profile 1222 identification to "http://iana.org/beep/IDXP". 1224 The IANA registers "idxp" as a TCP port number, as specified in 1225 Section 8.2 1227 The IANA maintains a list of: 1229 IDXP options, c.f., Section 7. 1231 For this list, the IESG is responsible for assigning a designated 1232 expert to review the specification prior to the IANA making the 1233 assignment. As a courtesy to developers of non-standards track IDXP 1234 options, the mailing list idxp-java-users@lists.sourceforge.net may 1235 be used to solicit commentary. 1237 The IANA makes the registrations specified in Section 8.3 and Section 1238 8.4. 1240 Appendix B. History of Significant Changes 1242 The RFC Editor should remove this section and its corresponding TOC 1243 references prior to publication. 1245 B.1 Significant Changes Since beep-idxp-06 1247 Modified Section 5 to make explicit that each of the IDWG 1248 communications protocol requirements is listed and that IDXP relies 1249 on BEEP and several BEEP profiles to meet this set of requirements. 1251 Added Section 6 describing the ways to extend IDXP. 1253 Separated the references into normative and informational sections. 1255 Updated document author information. 1257 B.2 Significant Changes Since beep-idxp-05 1259 Modified the part of Section 5 regarding non-repudiation to instead 1260 refer to per-source authentication, per draft-ietf-idwg-requirements- 1261 09. 1263 B.3 Significant Changes Since beep-idxp-04 1265 Added sentence to Section 3.4 explaining the situation in which an 1266 "error" element may be issued within an "RPY" message. 1268 Modified examples in Section 4.1 and Section 4.2, changing the 1269 message types from "RPY" to "ERR" for the negative response sent by 1270 the client. 1272 Fixed two locations where we were referencing the wrong section of 1273 the requirements document. 1275 Removed references to IP and the %IP attribute. 1277 Modified part of Section 5 dealing with non-repudiation of message 1278 origin. 1280 Modified Section 1.3 to further refine terminology. 1282 Replaced all remaining references to "entities" with references to 1283 "peers". 1285 B.4 Significant Changes Since beep-idxp-03 1287 Modified references to Internet-Drafts to contain placeholders for 1288 their forthcoming RFC numbers. 1290 Modified IDMEF formal public identifier (FPI) in the IDXP DTD to 1291 reflect the changes in draft-ietf-idwg-idmef-xml-06. 1293 Modified IDXP FPI for the IDXP DTD to be more in line with the IDMEF 1294 FPI. 1296 B.5 Significant Changes Since beep-idxp-02 1298 Added IDXP option registration template and registered two initial 1299 options. 1301 Indicated that the IANA should change the profile identification to 1302 "http://iana.org/beep/IDXP" upon adoption of IDXP as a standards- 1303 track BEEP profile. 1305 Renamed the "Options" element to "Option" and allowed multiple 1306 "Option" sub-elements within an "IDXP-Greeting" element. Also added 1307 attributes to "Option" element. 1309 Modified IANA profile registration and added TCP port number IANA 1310 registration. 1312 Reordered some sections to improve the flow of the document. 1314 Changed IDXP DTD identifier to be more IETF-like and removed URLs 1315 from ENTITY declarations. 1317 Changed IDXP profile URI to fall under the "http://iana.org/beep/ 1318 transient" namespace. 1320 Modified Section 1.3 to reference the requirements language specified 1321 by [2]. 1323 Eliminated the use of the "endpoint" terminology, in favor of "peer". 1325 Modified figures to make them more understandable. 1327 Modified Section 2, Section 3, and Section 4 to use the requirements 1328 language specified by [2]. 1330 Indicated that the RFC Editor should remove Appendix B and its 1331 corresponding TOC reference prior to publication. 1333 Fixed several typos. 1335 B.6 Significant Changes Since beep-idxp-01 1337 Added new MUST and SHOULD language for use of TLS and TUNNEL 1338 profiles. 1340 Modified the "IDXP-Greeting" element to include an "Options" sub- 1341 element. 1343 Changed IDXP profile URI. 1345 B.7 Significant Changes Since beep-idxp-00 1347 Added Section 5, describing how IDXP fulfills the communication 1348 protocol requirements of the IDWG. 1350 Moved IDXP profile registration to Appendix A. 1352 Clarified the role that underlying BEEP security profiles must play. 1354 Clarified how IDMEF messages fit into IDXP. 1356 Clarified how the IDXP profile channels and BEEP sessions interact. 1358 Made terminology clarifications and changes for overall consistency. 1360 Appendix C. Acknowledgements 1362 The authors gratefully acknowledge the contributions of Darren New, 1363 Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, and Paul 1364 Osterwald. 1366 Full Copyright Statement 1368 Copyright (C) The Internet Society (2002). All Rights Reserved. 1370 This document and translations of it may be copied and furnished to 1371 others, and derivative works that comment on or otherwise explain it 1372 or assist in its implementation may be prepared, copied, published 1373 and distributed, in whole or in part, without restriction of any 1374 kind, provided that the above copyright notice and this paragraph are 1375 included on all such copies and derivative works. However, this 1376 document itself may not be modified in any way, such as by removing 1377 the copyright notice or references to the Internet Society or other 1378 Internet organizations, except as needed for the purpose of 1379 developing Internet standards in which case the procedures for 1380 copyrights defined in the Internet Standards process must be 1381 followed, or as required to translate it into languages other than 1382 English. 1384 The limited permissions granted above are perpetual and will not be 1385 revoked by the Internet Society or its successors or assigns. 1387 This document and the information contained herein is provided on an 1388 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1389 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1390 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1391 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1392 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1394 Acknowledgement 1396 Funding for the RFC Editor function is currently provided by the 1397 Internet Society.