RFC 4767

The Intrusion Detection Exchange Protocol (IDXP)

📅 published March 2007, from ietf

The Intrusion Detection Exchange Protocol (IDXP) 💖

Okay bestie, here's the title block so you know who made this and what it's about 🎀

  • Network Working Group 🌸
  • RFC number: 4767
  • Authors: B. Feinstein (SecureWorks, Inc.) and G. Matthews (CSC/NASA Ames Research Center) 💅
  • Category: Experimental 🧪
  • Date: March 2007 📅
  • Obsoletes / Updates: the title block doesn't list any RFCs that this one obsoletes or updates ✨

Status of This Memo ✨

So this memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind, and it's lowkey giving "try it out and tell us what you think" energy. Discussion and suggestions for improvement are requested 🫶. Distribution of this memo is unlimited 🌈.

Copyright (C) The IETF Trust (2007).

Abstract 🦋

Okay so this memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities 🔥. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol 🔒. It's giving full security glow-up ✨. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data 💜. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF 🧚.

Table of Contents 🍓

   1. Introduction ....................................................3
      1.1. Purpose ....................................................3
      1.2. Profiles ...................................................3
      1.3. Terminology ................................................3
   2. The Model .......................................................4
      2.1. Connection Provisioning ....................................4
      2.2. Data Transfer ..............................................6
      2.3. Connection Teardown ........................................7
      2.4. Trust Model ................................................8
   3. The IDXP Profile ................................................8
      3.1. IDXP Profile Overview ......................................8
      3.2. IDXP Profile Identification and Initialization .............9
      3.3. IDXP Profile Message Syntax ................................9
      3.4. IDXP Profile Semantics .....................................9

           3.4.1. The IDXP-Greeting Element ..........................10
           3.4.2. The Option Element .................................11
           3.4.3. The IDMEF-Message Element ..........................12
   4. IDXP Options ...................................................12
      4.1. The channelPriority Option ................................13
      4.2. The streamType Option .....................................14
   5. Fulfillment of IDWG Communications Protocol Requirements .......16
      5.1. Reliable Message Transmission .............................16
      5.2. Interaction with Firewalls ................................16
      5.3. Mutual Authentication .....................................16
      5.4. Message Confidentiality ...................................17
      5.5. Message Integrity .........................................17
      5.6. Per-Source Authentication .................................17
      5.7. Denial of Service .........................................18
      5.8. Message Duplication .......................................18
   6. Extending IDXP .................................................18
   7. IDXP Option Registration Template ..............................19
   8. Initial Registrations ..........................................19
      8.1. Registration: The IDXP Profile ............................19
      8.2. Registration: The System (Well-Known) TCP Port
           Number for IDXP ...........................................19
      8.3. Registration: The channelPriority Option ..................20
      8.4. Registration: The streamType Option .......................20
   9. The DTDs .......................................................20
      9.1. The IDXP DTD ..............................................20
      9.2. The channelPriority Option DTD ............................22
      9.3. The streamType DTD ........................................23
   10. Reply Codes ...................................................24
   11. Security Considerations .......................................25
      11.1. Use of the TUNNEL Profile ................................25
      11.2. Use of Underlying Security Profiles ......................25
   12. IANA Considerations ...........................................25
   13. References ....................................................26
      13.1. Normative References .....................................26
      13.2. Informative References ...................................26
   14. Acknowledgements ..............................................26

1. Introduction 🌷

Okay so IDXP is specified, in part, as a Blocks Extensible Exchange Protocol (BEEP) [4] "profile" 💅. BEEP is a generic application protocol framework for connection-oriented, asynchronous interactions 🦋. Features such as authentication and confidentiality are provided through the use of other BEEP profiles 🔐. Accordingly, many aspects of IDXP (e.g., confidentiality) are provided within the BEEP framework ✨.

1.1. Purpose 🎯

IDXP provides for the exchange of IDMEF [2] messages, unstructured text, and binary data between intrusion detection entities 💜. Because these exchanges are so security-sensitive, underlying BEEP security profiles should be used to offer IDXP the required set of security properties 🔒. See Section 5 for a discussion of how IDXP fulfills the IDWG communications protocol requirements 📋. See Section 11 for a discussion of security considerations 🛡️.

IDXP is primarily intended for the exchange of data created by intrusion detection entities 🧚. IDMEF [2] messages should be used for the structured representation of this intrusion detection data 🍓, although IDXP may be used to exchange unstructured text and binary data 🎀.

1.2. Profiles 🌈

There are several BEEP profiles discussed, and we define the first of them in this memo 💖:

  • The IDXP Profile 🦋
  • The TUNNEL Profile [3] 🎀
  • The Simple Authentication and Security Layer (SASL) Family of Profiles (see Section 4.1 of [4]) 🫶
  • The TLS Profile (see Section 3.1 of [4]) 🔐

1.3. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. These are the serious-business words, so read them carefully 🧐.

Throughout this memo, the terms "analyzer" and "manager" are used in the context of the Intrusion Detection Message Exchange Requirements [5] 🔍. In particular, Section 2.2 of [5] defines a collection of intrusion detection terms 📚.

The terms "peer", "initiator", "listener", "client", and "server", and the characters "I", "L", "C", and "S" are used in the context of BEEP [4] 🧚. In particular, Section 2.1 of BEEP discusses the roles that a BEEP peer may perform 👑.

The term "Document Type Definition" is abbreviated as "DTD" and is defined in Section 2.8 of the Extensible Markup Language (XML) [7] 💜.

Note that the term "proxy" is specific to IDXP and does not exist in the context of BEEP ⚠️. The term "intrusion detection" is abbreviated as "ID" 🌸.

2. The Model ✨

(Part 2 picks up right here, with The Model 🧚💖)

2.1. Connection Provisioning ✨

okay so, IDXP peers are the intrusion detection entities that use IDXP to transfer data 🦋 and they only ever come in pairs, bestie! 💖 Those pairs talk over one single BEEP session that holds one or more BEEP channels for moving data around. Each peer is either a manager or an analyzer, as defined in Section 2.2 of [5]. 🎀

The analyzer and manager relationship is potentially many-to-many, so one analyzer MAY talk to many managers, and a manager MAY talk to many analyzers 🌸 Same deal for managers talking to other managers, so a manager MAY receive alerts from a huge number of analyzers by getting them through intermediate managers. ✨ But analyzers MUST NOT set up IDXP exchanges with other analyzers. 🙈 No analyzer-to-analyzer drama, periodt! 💅

When an IDXP peer wants to chat with another IDXP peer, it opens a BEEP channel, and that might mean starting a BEEP session first 🧚 A BEEP security profile that gives the required security properties SHOULD be negotiated first (see Section 11 for the security considerations tea ☕). Once that security profile is successfully negotiated, the IDXP greetings get exchanged and connection provisioning carries on 💜

Here's the sequence where the peer 'Alice' starts an IDXP exchange with the peer 'Bob' 👑

   Alice                                               Bob
     ---------------- xport connect(1) ------------------>
    <-------------------- greeting ---------------------->
    <-------------start security profile(2) ------------->
    <-------------------- greeting ---------------------->
    <------------------ start IDXP(3) ------------------->

Notes:

(1) 'Alice' opens a transport connection to 'Bob', which kicks off the BEEP greeting messages 🌈

(2) Both entities negotiate a BEEP security profile 🔥

(3) Both entities negotiate the IDXP profile ⭐

Between a pair of IDXP peers there can be an arbitrary number of proxies 🦋 A proxy might be needed for admin reasons, like sitting on a firewall to allow restricted access 🔒 Another use is one proxy per company department, which forwards data from the analyzer peers in that department onto a company-wide manager peer. 🏢💅

A BEEP tuning profile MAY be used to create an application-layer tunnel that transparently forwards data over a chain of proxies. 🌸 The TUNNEL profile [3] SHOULD be used for this purpose, see [3] for more detail on the options for setting up an application-layer tunnel using TUNNEL, and see Section 11.1 for the TUNNEL-related security considerations 🫶 TUNNEL MUST be offered as a tuning profile for creating application-layer tunnels. The TUNNEL profile MUST offer some form of SASL authentication (see Section 4.1 of [4]). Once the tunnel exists, a BEEP security profile offering the required security properties SHOULD be negotiated, followed by negotiation of the IDXP profile ✨

Here's how TUNNEL might be used to build an application-layer tunnel for IDXP to run through. A peer 'Alice' starts a BEEP session with the IDXP profile toward 'Bob' by first reaching out to 'proxy1' 🎀 In the greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile gets selected, and then the TUNNEL profile is extended to reach through 'proxy2' to 'Bob' 🧚

   Alice              proxy1               proxy2               Bob
     -- xport connect -->
    <---- greeting ----->
     -- start TUNNEL --->
                         - xport connect(1) ->
                        <----- greeting ----->
                         --- start TUNNEL --->
                                              --- xport connect -->
                                             <----- greeting ----->
                                              --- start TUNNEL --->
                                             <----- <ok>(2) ------
                        <------- <ok> -------
    <------ <ok> -------
    <------------------------- greeting -------------------------->
    <------------------ start security profile ------------------->
    <------------------------- greeting -------------------------->
    <------------------------ start IDXP ------------------------->

Notes:

(1) Rather than acknowledging 'Alice's start TUNNEL request right away, 'proxy1' tries to set up TUNNEL with 'proxy2'. 'proxy2' also holds off on its acknowledgment to 'proxy1' 🫠

(2) 'Bob' acknowledges the start TUNNEL request from 'proxy2', and that ack travels back to 'Alice', so a TUNNEL application-layer tunnel now exists from 'Alice' to 'Bob' 🥹✨

2.2. Data Transfer ✨

Between a pair of ID entities talking over a BEEP session, one or more BEEP channels MAY be opened using the IDXP profile 💖 If that's what you want, additional BEEP sessions MAY be set up to offer more channels using the IDXP profile too. 🌷 But in most situations, extra IDXP-profile channels SHOULD be opened inside an existing BEEP session, rather than provisioning a brand new BEEP session just to hold them 🎀

Peers take on the role of client or server on a per-channel basis, with one acting as the client and the other as the server 🦋 Whether a peer is the client or server is decided separately from whether it was the initiator or listener during BEEP session setup. Clients and servers act as sources and sinks, respectively, for exchanging data. 💜

In a simple case, an analyzer peer sends data to a manager peer, like so 🍓

   +----------+                          +----------+
   |          |                          |          |
   |          |****** BEEP session ******|          |
   |          |                          |          |
   | Analyzer | ----- IDXP profile ----> | Manager  |
   | (Client) |                          | (Server) |
   |          |                          |          |
   |          |**************************|          |
   |          |                          |          |
   +----------+                          +----------+

Using multiple BEEP channels inside one BEEP session makes it easier to sort and prioritize the data flying between IDXP peers 💅 For example, a manager 'M1' sending alert data to another manager, 'M2', might open a separate channel for each category of alerts 🧚 'M1' acts as the client on every one of these channels, and 'M2' can then process and act on the incoming alerts based on how each channel is categorized 👑 Check out Section 4 for more on putting categorization and/or prioritization into channel creation 🌈

   +----------+                                            +----------+
   |          |                                            |          |
   |          |*************** BEEP session ***************|          |
   |          |                                            |          |
   |          | -- IDXP profile, network-based alerts ---> |          |
   | Manager  |                                            | Manager  |
   |   M1     | ---- IDXP profile, host-based alerts ----> |   M2     |
   | (Client) |                                            | (Server) |
   |          | ------ IDXP profile, other alerts -------> |          |
   |          |                                            |          |
   |          |********************************************|          |
   |          |                                            |          |
   +----------+                                            +----------+

2.3. Connection Teardown ✨

An IDXP peer may close an IDXP channel for lots of reasons (like if there's an error in processing, ugh 💀). To close a channel, the peer sends a "close" element (see Section 2.3.1.3 of [4]) on channel zero, saying which channel is getting closed. An IDXP peer may also close an entire BEEP session by sending a "close" element that says channel zero is to be closed. 🫶

Section 2.3.1.3 of [4] has a more complete rundown of when a BEEP peer is allowed to close a channel and how to do it 📖

Since setting up an application-layer tunnel and/or a BEEP security profile takes a lot of overhead, BEEP sessions with IDXP channels are expected to be long-lived 🌸 Also, the repeated overhead of IDXP channel provisioning (that's the exchange of IDXP greetings) can be skipped by keeping IDXP channels open even when no data is actively moving over them 💖 These are recommendations, though, so IDXP peers may close and re-provision BEEP sessions and/or IDXP channels however they see fit ✨

2.4. Trust Model ✨

In our model, trust goes exclusively to the IDXP peers. Proxies are always assumed to be untrustworthy 🙈 A BEEP security profile is used to set up end-to-end security between pairs of IDXP peers, so we don't have to trust any proxies in the middle 🔐 Only after the underlying security profile is successfully negotiated are IDXP peers to be trusted. Only BEEP security profiles offering at least the protections required by Section 5 of [5] SHOULD be used to secure a BEEP session containing channels using the IDXP profile. See Section 3 of [4] for the registration of the TLS profile, an example of a BEEP security profile that meets the requirements of Section 5 of [5] 🎀 See Section 5 for how IDXP fulfills the IDWG communications protocol requirements 💜

3. The IDXP Profile 🌈

3.1. IDXP Profile Overview ✨

The IDXP profile provides a mechanism for exchanging information between intrusion detection entities 🦋 A BEEP tuning profile MAY be used to create an application-layer tunnel that transparently forwards data over a chain of proxies. The TUNNEL profile [3] SHOULD be used for this purpose, see [3] for more detail on the options for setting up an application-layer tunnel using TUNNEL, and see Section 11.1 for the TUNNEL-related security considerations 🎀 TUNNEL MUST be offered as a tuning profile for creating application-layer tunnels. The TUNNEL profile MUST offer some form of SASL authentication (see Section 4.1 of [4]). The TLS profile SHOULD be used to provide the required combination of mutual-authentication, integrity, and confidentiality for the IDXP profile 🔥 For further discussion of application-layer tunnel and security issues, see Sections 2.1 and 11. 💅

The IDXP profile supports several elements of interest 👑

  • The "IDXP-Greeting" element identifies an analyzer or manager at one end of a BEEP channel to the analyzer or manager at the other end of the channel. 🧚
  • The "Option" element is used to convey optional channel parameters between peers during the exchange of "IDXP-Greeting" elements. This element is OPTIONAL. 🌸
  • The "IDMEF-Message" element carries the structured information to be exchanged between the peers. 🫶

3.2. IDXP Profile Identification and Initialization

Okay so the IDXP profile is identified by this URI, and it goes in the BEEP profile element when you create a channel 💖

http://idxp.org/beep/profile

During channel creation, both peers MUST mutually exchange IDXP-Greeting elements 🫶. An IDXP-Greeting element MAY be tucked inside the matching profile element in the BEEP start element. Putting it in that initial start element means exactly the same thing as sending it as the first MSG message on the channel 🧚. If channel creation works, the BEEP peer processes the IDXP-Greeting before it sends the reply, and it includes the result in that reply. The result is either an ok element or an error element, and which one you get depends on the peer's local provisioning 🎀.

3.3. IDXP Profile Message Syntax

BEEP messages in the profile MUST have a MIME Content-Type [8] of text/xml, text/plain, or application/octet-stream 📄. The syntax of the individual elements is specified in Section 9.1 of this document and Section 4 of [2] ✨.

3.4. IDXP Profile Semantics

Each BEEP peer sends its IDXP-Greeting element inside MSG messages 💌. The IDXP-Greeting element MAY contain one or more Option sub-elements, which carry optional channel parameters 🌸. Then each peer answers with ok in RPY messages or error in ERR messages. (See Section 2.3.1 of [4] for the definitions of the error and ok elements.) An error element MAY be sent within a RPY message when it's piggy-backed inside a BEEP profile element 🙈. Check out Section 3.4.1 for an example of an error element showing up in a RPY message.

Once the IDXP-Greeting elements have been swapped, the client sends data in MSG messages, based on the client and server roles that were negotiated during that exchange 🦋. Depending on the MIME Content-Type, that data might be an IDMEF-Message element, plain text, or binary 💜. The server then answers with ok in RPY messages or error in ERR messages 💅.

3.4.1. The IDXP-Greeting Element

The IDXP-Greeting element is how the analyzer or manager at one end of the BEEP channel introduces itself to the analyzer or manager at the other end 👑. It MUST include the role of the peer on the channel (client or server) and the Uniform Resource Identifier (URI) [6] of the peer 🪪. It MAY also include the fully qualified domain name (see [9]) of the peer ✨. One or more Option sub-elements MAY be present too 🎀.

An IDXP-Greeting element MAY be sent by either peer at any time ⏰. The peer that receives the IDXP-Greeting MUST respond with an ok (accepting it) or an error (rejecting it) 🙌. A peer's identity and role on a channel, along with any optional channel parameters, are effectively set by the most recent IDXP-Greeting it sent that got answered with an ok 💖.

An IDXP-Greeting can get rejected with an error element for lots of reasons. These include, but aren't limited to, authentication failure, not being authorized to connect under the specified role, negotiating an inadequate cipher suite, or a channel option that must be understood but wasn't recognized 😭.

Here's a successful creation with an embedded IDXP-Greeting:

I: MSG 0 10 . 1592 187
I: Content-Type: text/xml
I:
I: <start number='1'>
I:   <profile uri='http://idxp.org/beep/profile'>
I:     <![CDATA[ <IDXP-Greeting uri='http://example.com/alice'
I:       role='client' /> ]]>
I:   </profile>
I: </start>
I: END
L: RPY 0 10 . 1865 91
L: Content-Type: text/xml
L:
L: <profile uri='http://idxp.org/beep/profile'>
L:   <![CDATA[ <ok /> ]]>
L: </profile>
L: END
L: MSG 0 11 . 1956 61
L: Content-Type: text/xml
L:
L: <IDXP-Greeting uri='http://example.com/bob' role='server' />
L: END
I: RPY 0 11 . 1779 7
I: Content-Type: text/xml
I:
I: <ok />
I: END

And here's a creation with an embedded IDXP-Greeting that fails 😬:

I: MSG 0 10 . 1776 185
I: Content-Type: text/xml
I:
I: <start number='1'>
I:   <profile uri='http://idxp.org/beep/profile'>
I:     <![CDATA[ <IDXP-Greeting uri='http://example.com/eve'
I:       role='client' /> ]]>
I:   </profile>
I: </start>
I: END
L: RPY 0 10 . 1592 182
L: Content-Type: text/xml
L:
L: <profile uri='http://idxp.org/beep/profile'>
L:   <![CDATA[
L:     <error code='530'>'http://example.com/eve' must first
L:       negotiate the TLS profile</error> ]]>
L: </profile>
L: END

3.4.2. The Option Element

If it's present, the Option element MUST be contained within an IDXP-Greeting element 🧩. An individual IDXP-Greeting element MAY contain one or more Option sub-elements 🍓. Each Option element inside an IDXP-Greeting element is a request to turn on an IDXP option for the channel being negotiated 🌈. See Section 4 for the full scoop on IDXP options and the Option element 📚.

3.4.3. The IDMEF-Message Element

The IDMEF-Message element carries the information the peers want to exchange 💬. See Section 4 of [2] for the definition of this element 🔎.

4. IDXP Options ✨

IDXP gives you a service for reliably exchanging data between intrusion detection entities 🛡️. Options are how you tweak the semantics of that service 🎛️.

The specification of an IDXP option MUST define:

  • the identity of the option;
  • what content, if any, is contained within the option; and
  • the processing rules for the option.

An option registration template (see Section 7) keeps all of this info organized 🗂️.

An Option element lives inside an IDXP-Greeting element. The IDXP-Greeting element itself MAY contain one or more Option elements 🌷. The Option element has a few attributes and can hold arbitrary content:

  • the "internal" and the "external" attributes, exactly one of which MUST be present, uniquely identify the option 🆔;
  • the "mustUnderstand" attribute, whose presence is OPTIONAL and whose default value is "false", specifies whether the option, if unrecognized, MUST cause an error in processing to occur 🚨; and
  • the "localize" attribute, whose presence is OPTIONAL, specifies one or more language tokens, each identifying a desirable language tag to be used if textual diagnostics are returned to the originator 🌍.

The value of the "internal" attribute is the IANA-registered name for the option 🏷️. If the "internal" attribute isn't present, then the value of the "external" attribute is a URI or a URI with a fragment identifier 🔗. Note that a relative-URI value is not allowed 🙅.

The "mustUnderstand" attribute says whether the peer may ignore the option when it doesn't recognize it 🤔. If the value of "mustUnderstand" is "true" and the peer doesn't recognize the option, then an error in processing has occurred 💀. When it's absent, the value of "mustUnderstand" is defined to be "false" 💜.

4.1. The channelPriority Option

Section 8.3 contains the IDXP option registration for the "channelPriority" option 📝. This option contains a channelPriority element (see Section 9.2) 🎀.

By default, IDXP doesn't put any requirements on how peers manage multiple IDXP channels 🤷‍♀️. The "channelPriority" option gives peers that use multiple IDXP channels a way to ask for relative priorities for each channel 🏆. When an originating peer sends an IDXP-Greeting element while provisioning an IDXP channel, it MAY ask the remote peer to assign a priority to the channel by including an Option element that contains a channelPriority element 💅.

The channelPriority element has one attribute, priority, with a range of 0..2147483647. This attribute is REQUIRED 📏. Not coincidentally, that's the maximum range of possible BEEP channel numbers 🤯. 0 is the highest priority, and the relative priority goes down as the priority value goes up 📉.

Here's an example: during the exchange of IDXP-Greeting elements while the channel is being provisioned, an analyzer successfully asks a manager to assign a priority to the channel 🙌:

   analyzer                                           manager
      --------------- greeting w/ option ----------------->
      <---------------------- <ok> ------------------------
C: MSG 1 17 . 1984 165
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri='http://example.com/alice' role='client'>
C:   <Option internal='channelPriority'>
C:     <channelPriority priority='0' />
C:   </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 17 . 2001 7
S: Content-Type: text/xml
S:
S: <ok />
S: END

And here's one where it doesn't work out 😤. During the exchange of IDXP-Greeting elements while the channel is being provisioned, a manager unsuccessfully asks an analyzer to assign a priority to the channel:

     analyzer                                           manager
       <---------------- greeting w/ option ----------------
        --------------------- <error> ---------------------->
  S: MSG 1 17 . 1312 194
  S: Content-Type: text/xml
  S:
  S: <IDXP-Greeting uri='http://example.com/bob' role='server'>
  S:   <Option internal='channelPriority' mustUnderstand='true'>
  S:     <channelPriority priority='2147483647' />
  S:   </Option>
  S: </IDXP-Greeting>
  S: END
  C: ERR 1 17 . 451 68
  C: Content-Type: text/xml
  C:
  C: <error code='504'>'channelPriority' option was unrecognized</error>
  C: END

4.2. The streamType Option 🎀

okay so Section 8.4 is where the IDXP option registration for the "streamType" option lives 📋 and this option carries a "streamType" element (see Section 9.3) ✨

by default, IDXP gives you no explicit way to categorize channels 🙈 that's where the "streamType" option slides in 💅 it lets peers ask for a channel to be categorized as a particular stream type. when the originating peer sends an IDXP-Greeting element while provisioning an IDXP channel, it MAY ask the remote peer to assign a stream type to the channel by including an Option element that contains a streamType element 🦋

the streamType element has one attribute, type, and it can be "alert", "heartbeat", or "config". this attribute is REQUIRED 🔒 a value of "alert" means the channel gets categorized for exchanging ID alerts 🚨 a value of "heartbeat" means it gets categorized for exchanging heartbeat messages, like the Heartbeat element (see Section 4 of [2]) 💓 and a value of "config" means it gets categorized for exchanging configuration messages ⚙️

here's an example of an analyzer successfully asking a manager to assign a stream type to the channel during the IDXP-Greeting exchange 🥰

analyzer                                           manager
   --------------- greeting w/ option ----------------->
  <---------------------- <ok> ------------------------

C: MSG 1 21 . 1963 155
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri='http://example.com/alice' role='client'>
C:   <Option internal='streamType'>
C:     <streamType type='alert' />
C:   </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 21 . 1117 7
S: Content-Type: text/xml
S:
S: <ok />
S: END

and now the not-so-slay version 😭 here, a manager tries to get an analyzer to assign a stream type during channel provisioning, but it doesn't work out 💀

analyzer                                           manager
  <---------------- greeting w/ option ----------------
   --------------------- <error> ---------------------->

S: MSG 1 21 . 1969 176
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri='http://example.com/bob' role='server'>
S:   <Option internal='streamType' mustUnderstand='true'>
S:     <streamType type='config' />
S:   </Option>
</IDXP-Greeting>
S: END
C: ERR 1 21 . 1292 63
C: Content-Type: text/xml
C:
C: <error code='504'>'streamType' option was unrecognized</error>
C: END

5. Fulfillment of IDWG Communications Protocol Requirements ✨

okay this section is the checklist 📝 it goes through each of the communications protocol requirements set out in Section 5 of [5] and explains how each one gets fulfilled. ngl, IDXP doesn't fulfill every single one by itself 🙈 it leans on the underlying BEEP protocol and a bunch of BEEP profiles to do the heavy lifting 🫶

5.1. Reliable Message Transmission 💌

"The [protocol] MUST support reliable transmission of messages." See Section 5.1 of [5].

IDXP runs over BEEP, and BEEP only runs over reliable connection-oriented transport protocols (e.g., TCP) 🧵 on top of that, BEEP peers talk using a simple request-response protocol, which gives you end-to-end reliability between peers 💖

5.2. Interaction with Firewalls 🧱

"The [protocol] MUST support transmission of messages between ID components across firewall boundaries without compromising security." See Section 5.2 of [5].

the TUNNEL profile [3] MUST be offered as an option for creating application-layer tunnels, so things can operate across firewalls 🌈 the TUNNEL profile SHOULD be used to provide that application-layer tunnel 🎀 whatever mechanism you pick to create these tunnels MUST provide a way to authenticate hosts while the tunnel is being created 🔐 which means a firewall can be set up to authenticate every host trying to tunnel into the protected network, iykyk 👑 and if the TUNNEL profile is used, SASL (see Section 4.1 of [4]) MUST be offered as a way for hosts to get authenticated 🦋

5.3. Mutual Authentication 🤝

"The [protocol] MUST support mutual authentication of the analyzer and the manager to each other." See Section 5.3 of [5].

IDXP supports mutual authentication between peers through an appropriate underlying BEEP security profile ✨ the TLS profile and members of the SASL family of profiles (see Section 4.1 of [4]) are examples of security profiles that can be used to authenticate the identity of communicating ID components 🫶 TLS MUST be offered as a mechanism to provide mutual authentication, and TLS SHOULD be used to provide mutual authentication 💅

5.4. Message Confidentiality 🤫

"The [protocol] MUST support confidentiality of the message content during message exchange. The selected design MUST be capable of supporting a variety of encryption algorithms and MUST be adaptable to a wide variety of environments." See Section 5.4 of [5].

IDXP supports confidentiality through an appropriate underlying BEEP security profile 🔒 the TLS profile is an example of one that offers confidentiality 💜 the TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a mechanism to provide confidentiality, and TLS with this cipher suite SHOULD be used to provide confidentiality 🌸 quick breakdown of that cipher suite: it uses ephemeral Diffie-Hellman (DHE) with DSS signatures for key exchange, and triple DES (Data Encryption Standard) (3DES) and cipher-block chaining (CBC) for encryption 🧁 stronger cipher suites are optional ✨

5.5. Message Integrity 🛡️

"The [protocol] MUST ensure the integrity of the message content. The selected design MUST be capable of supporting a variety of integrity mechanisms and MUST be adaptable to a wide variety of environments." See Section 5.5 of [5].

IDXP supports message integrity through an appropriate underlying BEEP security profile 🌷 the TLS profile and members of the SASL family of profiles (see Section 4.1 of [4]) are examples of profiles that offer message integrity 🧚 the TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a mechanism to provide integrity, and TLS with this cipher suite SHOULD be used to provide integrity 💖 that suite uses the Secure Hash Algorithm (SHA) for integrity protection with a keyed message authentication code 🔑 stronger cipher suites are optional, bestie 🫶

5.6. Per-Source Authentication 🪪

"The [protocol] MUST support separate authentication keys for each sender." See Section 5.6 of [5].

IDXP supports separate authentication keys for each sender (aka per-source authentication) through an appropriate underlying BEEP security profile 🦋 the TLS profile is an example of one that supports per-source authentication through mutual authentication of public-key certificates 📜 TLS MUST be offered as a mechanism to provide per-source authentication, and TLS SHOULD be used to provide per-source authentication 👑

5.7. Denial of Service 🚫

"The [protocol] SHOULD resist protocol denial-of-service attacks." See Section 5.7 of [5].

IDXP resists denial of service (DoS) attacks through an appropriate underlying BEEP security profile 🛡️ BEEP peers offering the IDXP profile MUST offer the use of TLS with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite, and SHOULD use TLS with that cipher suite 🌈 to resist DoS attacks, it helps to discard traffic coming from a non-authenticated source 🙅‍♀️ BEEP peers MUST support the use of authentication alongside any mechanism used to create application-layer tunnels 🔐 in particular, some form of SASL authentication (see Section 4.1 of [4]) MUST be offered to provide authentication when using the TUNNEL profile 💅 for the security considerations of the TUNNEL profile, see Section 7 of [3] 📖

5.8. Message Duplication 🔁

"The [protocol] SHOULD resist malicious duplication of messages." See Section 5.8 of [5].

IDXP resists malicious duplication of messages (aka replay attacks) through an appropriate underlying BEEP security profile 🧠 the TLS profile is an example of a security profile that offers resistance to replay attacks 🌸 the TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a mechanism to provide resistance against replay attacks, and TLS with this cipher suite SHOULD be used to provide resistance against replay attacks 💜 that suite uses cipher-block chaining (CBC) so that even if a message gets duplicated, the duplicate cipher-text produces a very different plain-text result 🙈 stronger cipher suites are optional 🫶

6. Extending IDXP 🧩

the preferred way to extend IDXP is to specify IDXP options (see Section 4) 🍓 to extend IDXP, an IDXP option SHOULD be documented in an RFC and MUST be registered with the IANA (see Section 7) 📋 and IDXP extensions that can't be expressed as IDXP options MUST be documented in an RFC 📄

7. IDXP Option Registration Template 📝

when an IDXP option gets registered, the following information is supplied:

Option Identification: specify the NMTOKEN or the URI that authoritatively identifies this option.

Contains: specify the XML content that is contained within the "Option" element.

Processing Rules: specify the processing rules associated with the option.

Contact Information: specify the postal and electronic contact information for the author(s) of the option.

8. Initial Registrations 🌟

8.1. Registration: The IDXP Profile 👑

Profile identification: http://idxp.org/beep/profile

Messages exchanged during channel creation: "IDXP-Greeting"

Messages starting one-to-one exchanges: "IDXP-Greeting", "IDMEF-Message"

Messages in positive replies: "ok"

Messages in negative replies: "error"

Messages in one-to-many exchanges: none

Message syntax: see Section 3.3

Message semantics: see Section 3.4

Contact information: see the "Authors' Addresses" section of this memo

8.2. Registration: The System (Well-Known) TCP Port Number for IDXP 🔌

Protocol Number: 603

Message Formats, Types, Opcodes, and Sequences: see Section 3.3

Functions: see Section 3.4

Use of Broadcast/Multicast: none

Proposed Name: Intrusion Detection Exchange Protocol

Short name: idxp

Contact Information: see the "Authors' Addresses" section of this memo

8.3. Registration: The channelPriority Option 🎀

Option Identification: channelPriority

Contains: channelPriority (see Section 9.2)

Processing Rules: see Section 4.1

Contact Information: see the "Authors' Addresses" section of this memo

8.4. Registration: The streamType Option 🦋

Option Identification: streamType

Contains: streamType (see Section 9.3)

Processing Rules: see Section 4.2

Contact Information: see the "Authors' Addresses" section of this memo

9. The DTDs 🌈

9.1. The IDXP DTD 🎀

Okay so, this is the DTD that spells out exactly which elements are valid for the IDXP profile 💅

<!--
DTD for the IDXP Profile

Refer to this DTD as:

  <!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC 4767 IDXP v1.0//EN">

  %IDXP;
-->
<!-- Includes -->

  <!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">

  %BEEP;


  <!ENTITY % IDMEF-Message PUBLIC
                            "-//IETF//DTD RFC 4765 IDMEF v1.0//EN">

  %IDMEF;

<!--
  Profile Summary

    BEEP profile http://idxp.org/beep/profile

    role       MSG               RPY      ERR
    ====       ===               ===      ===
    I or L     IDXP-Greeting     ok       error
    C          IDMEF-Message     ok       error
-->

<!--
  Entity Definitions

        entity        syntax/reference     example
        ======        ================     =======
    an authoritative identification
        URI           see RFC 3986 [6]     http://example.com

    a fully qualified domain name
        FQDN          see RFC 1034 [9]     www.example.com
-->

<!ENTITY % URI      "CDATA">
<!ENTITY % FQDN     "CDATA">

<!--
  The IDXP-Greeting element declares the role and identity of
  the peer issuing it, on a per-channel basis. The
  IDXP-Greeting element may contain one or more Option
  sub-elements.
-->

<!ELEMENT IDXP-Greeting  (Option*)>
<!ATTLIST IDXP-Greeting
          uri            %URI;                #REQUIRED
          role           (client|server)      #REQUIRED
          fqdn           %FQDN;               #IMPLIED>

<!--
  The Option element conveys an IDXP channel option.
  Note that the %LOCS entity is imported from the BEEP Channel
  Management DTD.
-->

<!ELEMENT Option (ANY)>
<!ATTLIST Option
          internal       NMTOKEN              ""
          external       %URI;                ""
          mustUnderstand (true|false)         "false"
          localize       %LOCS;               "i-default">

<!--
  The IDMEF-Message element conveys the intrusion detection
  information that is exchanged.  This element is defined in the
  idmef-message.dtd
-->

<!-- End of DTD -->

9.2. The channelPriority Option DTD 🦋

Next up is the DTD for the channelPriority option, which tells you what the valid elements are for that one ✨

<!--
DTD for the channelPriority IDXP option, as of 2002-01-08

Refer to this DTD as:

  <!ENTITY % IDXP-channelPriority PUBLIC
    "-//IETF//DTD RFC 4767 IDXP-channelPriority v1.0//EN">

  %IDXP-channelPriority;
-->

<!--
  Entity Definitions

        entity        syntax/reference     example
        ======        ================     =======

  a priority number
        PRIORITY      0..2147483647        1
-->

<!ENTITY % PRIORITY          "CDATA">

<!ELEMENT channelPriority    EMPTY>
<!ATTLIST channelPriority
          priority           %PRIORITY    #REQUIRED>

<!-- End of DTD -->

9.3. The streamType DTD 🌸

And here's the DTD for the streamType option, which defines its valid elements 🍓

<!--
DTD for the streamType IDXP option, as of 2002-01-08

Refer to this DTD as:

  <!ENTITY % IDXP-streamType PUBLIC
    "-//IETF//DTD RFC 4767 IDXP-streamType v1.0//EN">

  %IDXP-streamType;
-->

<!--
  Entity Definitions

        entity        syntax/reference                example
        ======        ================                =======
   a stream type
        STYPE         (alert | heartbeat | config)    "alert"
-->

<!ENTITY % STYPE        (alert|heartbeat|config)>

<!ELEMENT streamType    EMPTY>
<!ATTLIST streamType
          type          %STYPE    #REQUIRED>

<!-- End of DTD -->

10. Reply Codes 🚨

This section is the list of three-digit error codes that the IDXP profile may generate. Here they are, all in one place 💀

code    meaning
====    =======
421     Service not available
        (e.g., the peer does not have sufficient resources)

450     Requested action not taken
        (e.g., DNS lookup failed or connection could not
         be established.  See also 550.)

454     Temporary authentication failure

500     General syntax error
        (e.g., poorly-formed XML)

501     Syntax error in parameters
        (e.g., non-valid XML)

504     Parameter not implemented

530     Authentication required

534     Authentication mechanism insufficient
        (e.g., cipher suite too weak, sequence exhausted)

535     Authentication failure

537     Action not authorized for user

550     Requested action not taken
        (e.g., peer could be contacted, but
         malformed greeting or no IDXP profile advertised)

553     Parameter invalid

554     Transaction failed
        (e.g., policy violation)

11. Security Considerations 🔐😭

Okay, this part is seriously important, so pay attention bestie 🫶

The IDXP profile is a profile of BEEP. In BEEP, transport security, user authentication, and data exchange are orthogonal, meaning they're separate things that don't depend on each other. Check out Section 9 of [4] for the full discussion of this. It is strongly recommended that anyone wanting to use the IDXP profile first negotiate a BEEP security profile between the peers that offers the required security properties. The TLS profile SHOULD be used to provide transport security. See Section 5 for how IDXP fulfills the IDWG communications protocol requirements.

See Section 2.4 for a discussion of the trust model. 👑

11.1. Use of the TUNNEL Profile 🧚

Go to Section 5 for IDXP's requirements on application-layer tunneling and the TUNNEL profile specifically. Then see Section 7 of [3] for the security considerations that come with using the TUNNEL profile 🙈

11.2. Use of Underlying Security Profiles 🌈

At present, the TLS profile is the only BEEP security profile known to meet all of the requirements in Section 5 of [5]. When you secure a BEEP session with the TLS profile, the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite offers an acceptable level of security. See Section 5 for how IDXP fulfills the IDWG communications requirements through the use of an underlying security profile ✨

12. IANA Considerations 🦋

The IANA registered "idxp" as a TCP port number, as specified in Section 8.2.

The IANA maintains a list of:

  • IDXP options, see Section 7.

For this list, the IESG is responsible for assigning a designated expert to review the specification before the IANA makes the assignment. As a courtesy to developers of non-standards track IDXP options, the mailing list idxp-discuss@lists.idxp.org may be used to solicit commentary. 💌

IANA made the registrations specified in Sections 8.3 and 8.4. 💖

13. References 📚

13.1. Normative References 💜

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765, March 2007.
  • [3] New, D., "The TUNNEL Profile", RFC 3620, October 2003.
  • [4] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
  • [5] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange Requirements", RFC 4766, March 2007.

13.2. Informative References 🌸

  • [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [7] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
  • [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [9] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

14. Acknowledgements 🫶

The authors gratefully acknowledge the contributions of Darren New, Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, John C. C. White, and Paul Osterwald. Thank you all, you're literally the reason this exists 🥹💖

Authors' Addresses 🧚‍♀️

Benjamin S. Feinstein
SecureWorks, Inc.
PO Box 95007
Atlanta, GA 30347
US

Phone: +1 404 327-6339
Email: bfeinstein@acm.org
URI:   http://www.secureworks.com/


Gregory A. Matthews
CSC/NASA Ames Research Center

EMail: gmatthew@nas.nasa.gov
URI:   http://www.nas.nasa.gov/

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💕

Funding for the RFC Editor function is currently provided by the Internet Society. 🌷

📦 where this page comes from