[xml2rfc] IDXP xml problems
Benjamin.Feinstein@guardent.com (Benjamin.Feinstein@guardent.com) Thu, 13 June 2002 01:06 UTC
From: Benjamin.Feinstein@guardent.com
Date: Wed, 12 Jun 2002 21:06:50 -0400
Subject: [xml2rfc] IDXP xml problems
Message-ID: <397E0659AA2DD411843500508B64F1CE04310241@USBOSMX01>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C21276.996E2A90
Content-Type: text/plain;
charset="iso-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Marshall,
Has something changed with the references on xml.resource.org?
IDXP-04 will no longer go through the submit page. I have IDXP-05
nearly ready, but it suffers the same problem. Please help. Attached
is the XML source for IDXP-04 and IDXP-05. Many thanks!
The error page is:
Unable to convert:
can't read "xref(RFC3080)": no such element in array
Context:
<rfc ipr="full2026" docName="draft-ietf-idwg-beep-idxp-05">
<middle>
<section anchor="intro" title="Introduction">
<t>
Ben Feinstein
Software Development Engineer, R & D
W: 678.585.7865 x6726 F: 770.645.8311 M: 678.772.4126
8302 Dunwoody Pl., Suite 320, Atlanta, GA 30350 www.guardent.com
_____________________________________________________
G U A R D E N T
Enterprise Security and Privacy Programs
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPQfxFPt7bOk+HH2bEQJrQACglh+LrdH0h5lH+KHGVnMWoT3w9MIAoJ5j
eYaKz6thUnwUBDN0/nfOpn92
=c0nv
-----END PGP SIGNATURE-----
------_=_NextPart_000_01C21276.996E2A90
Content-Type: application/octet-stream;
name="draft-ietf-idwg-beep-idxp-04.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-idwg-beep-idxp-04.xml"
<?xml version=3D"1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc=3D"yes"?>
<!--
$Header: /cvsroot/idxp-java/idxp-doc/draft-ietf-idwg-beep-idxp.xml,v =
1.3 2002/01/08 19:51:22 bfeinste Exp $
-->
<!-- Remember to increment the document number for each release -->
<rfc ipr=3D"full2026" docName=3D"draft-ietf-idwg-beep-idxp-04">
<front>
<title abbrev=3D"The IDXP">The Intrusion Detection Exchange Protocol =
(IDXP)</title>
<author initials=3D"B.S." surname=3D"Feinstein" fullname=3D"Benjamin S. =
Feinstein">
<organization>Guardent, Inc.</organization>
<address>
<email>Ben.Feinstein@guardent.com</email>
<uri>http://www.guardent.com/</uri>
</address>
</author>
<author initials=3D"G.A." surname=3D"Matthews" fullname=3D"Gregory A. =
Matthews">
<organization>CSC/NASA Ames Research Center</organization>
<address>
<email>gmatthew@nas.nasa.gov</email>
<uri>http://www.nas.nasa.gov/</uri>
</address>
</author>
<author initials=3D"J.C.C." surname=3D"White" fullname=3D"John C. C. =
White">
<organization>MITRE Corporation</organization>
<address>
<email>jccw@mitre.org</email>
<uri>http://www.mitre.org/</uri>
</address>
</author>
<!-- Remember to update the date for each release -->
<date day=3D"8" month=3D"January" year=3D"2002" />
<area>Security</area>
<workgroup>Intrusion Detection Exchange Format</workgroup>
<keyword>intrusion detection</keyword>
<keyword>security</keyword>
<keyword>secure</keyword>
<keyword>secure protocol</keyword>
<keyword>exchange</keyword>
<keyword>intrusion</keyword>
<keyword>IDS</keyword>
<keyword>BEEP</keyword>
<keyword>intrusion detection protocol</keyword>
<abstract>
<t>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. The =
protocol provides for the exchange of IDMEF messages, unstructured =
text, and binary data. The IDMEF message elements are described in the =
<xref target=3D"refs.IDMEF">Intrusion Detection Message Exchange Format =
(IDMEF)</xref>, a companion document of the Intrusion Detection =
Exchange Format (IDWG) working group of the IETF.</t>
</abstract>
</front>
<middle>
<section anchor=3D"intro" title=3D"Introduction">
<t>IDXP is specified, in part, as a <xref target=3D"RFC3080">Blocks =
Extensible Exchange Protocol (BEEP)</xref> "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.</t>
<section anchor=3D"purpose" title=3D"Purpose">
<t>IDXP provides for the exchange of <xref =
target=3D"refs.IDMEF">IDMEF</xref> messages, unstructured text, and =
binary data between intrusion detection entities. Addressing the =
security-sensitive nature of exchanges between intrusion detection =
entities, underlying BEEP security profiles should be used to offer =
IDXP the required set of security properties. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communication protocol requirements. See <xref target=3D"security" /> =
for a discussion of security considerations.</t>
<t>IDXP is primarily intended for the exchange of data created by =
intrusion detection entities. <xref target=3D"refs.IDMEF">IDMEF</xref> =
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.</t>
</section>
<section title=3D"Profiles">
<t>There are several BEEP profiles discussed, the first of which we =
define in this memo:</t>
<t><list style=3D"empty">
<t>The IDXP Profile</t>
<t><xref target=3D"refs.tunnel">The TUNNEL Profile</xref></t>
<t>The Simple Authentication and Security Layer (SASL) Family of =
Profiles (c.f., Section 4.1 of <xref target=3D"RFC3080" />)</t>
<t>The TLS Profile (c.f., Section 3.1 of <xref target=3D"RFC3080" =
/>)</t>
</list></t>
</section>
<section anchor=3D"terminology" title=3D"Terminology">
<t>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 <xref =
target=3D"RFC2119">RFC 2119</xref>.</t>
<t>Throughout this memo, the terms "analyzer" and "manager" are used in =
the context of the <xref target=3D"refs.IDWG-reqs">Intrusion Detection =
Message Exchange Requirements</xref>. In particular, Section 3.2 of =
<xref target=3D"refs.IDWG-reqs" /> defines the meaning of a collection =
of intrusion detection terms.</t>
<t>The terms "peer", "initiator", "listener", "client", and "server" =
are used in the context of <xref target=3D"RFC3080">BEEP</xref>. In =
particular, Section 2.1 of the BEEP framework memo discusses the roles =
that a BEEP peer may perform.</t>
<t>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".</t>
</section>
</section>
<section anchor=3D"model" title=3D"The Model">
<section anchor=3D"connect" title=3D"Connection Provisioning">
<t>Intrusion detection entities using IDXP to transfer data are termed =
IDXP peers. Peers can exist only in pairs, and these pairs communicate =
over a single BEEP session with one or more BEEP channels opened for =
transferring data. Peers are either managers or analyzers, as defined =
in Section 3.2 of <xref target=3D"refs.IDWG-reqs" />.</t>
<t> The relationship between analyzers and managers is potentially =
many-to-many. I.e., an analyzer MAY communicate with many managers; =
similarly, a manager MAY communicate with many analyzers. Likewise, the =
relationship between different managers is potentially many-to-many, so =
that a manager MAY receive the alerts sent by a large number of =
analyzers by receiving them through intermediate managers. Analyzers =
MUST NOT establish IDXP exchanges with other analyzers.</t>
<!--
<t>[Rationale: Analyzers may send alert data and receive configuration =
data, and managers may send or receive both alert and configuration =
data.]</t>
-->
<t>An ID entity wishing to establish IDXP communications with another =
ID entity does so by opening a BEEP channel, which may entail =
initiating a BEEP session. A BEEP security profile offering the =
required security properties SHOULD initially be negotiated (see <xref =
target=3D"security" /> for a discussion of security considerations). =
Following the successful negotiation of the BEEP security profile, IDXP =
greetings are exchanged and connection provisioning proceeds.</t>
<figure>
<preamble>In the following sequence an ID entity 'Alice' initiates an =
IDXP exchange with the entity 'Bob'.</preamble>
<artwork><![CDATA[
Alice Bob
---------------- xport connect[1] ------------------>
<-------------------- greeting ---------------------->
<-------------start security profile[2] ------------->
<-------------------- greeting ---------------------->
<------------------ start IDXP[3] ------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">'Alice' initiates a transport connection to 'Bob', =
triggering the exchange of BEEP greeting messages.</t>
<t hangText=3D"[2]">both entities negotiate the use of a BEEP security =
profile.</t>
<t hangText=3D"[3]">both entities negotiate the use of the IDXP =
profile.</t>
</list></t>
<t>In between a pair of IDXP peers may be an arbitrary number of =
proxies. A proxy may be necessary for administrative reasons, such as =
running on a firewall to allow restricted access. Another use might be =
one proxy per company department, which forwards data from the analyzer =
peers in the department onto a company-wide manager peer.</t>
<!--
<t>To create an application-layer tunnel that transparently forwards =
data over a chain of proxies, the <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> should be used. See <xref target=3D"refs.tunnel" /> for =
more detail concerning the options available to setup an =
application-layer tunnel, and see . Once a tunnel is established =
between two peers, a new BEEP greeting must be exchanged. At this =
point, a BEEP security profile offering the required security =
properties would be negotiated, followed by negotiation of the IDXP =
profile.</t>
-->
<t>A BEEP tuning profile MAY be used to create an application-layer =
tunnel that transparently forwards data over a chain of proxies. The =
<xref target=3D"refs.tunnel">TUNNEL profile</xref> SHOULD be used for =
this purpose; see <xref target=3D"refs.tunnel" /> for more detail =
concerning the options available to setup an application-layer tunnel =
using TUNNEL, and see <xref target=3D"security.tunnel" /> for a =
discussion of TUNNEL related security considerations. TUNNEL MUST be =
offered as a tuning profile for the creation of application-layer =
tunnels. The TUNNEL profile MUST offer the use of some form of SASL =
authentication (c.f., Section 4.1 of <xref target=3D"RFC3080" />). Once =
a tunnel has been created a BEEP security profile offering the required =
security properties SHOULD be negotiated, followed by negotiation of =
the IDXP profile.</t>
<figure>
<preamble>The following sequence shows how TUNNEL might be used to =
create an application-layer tunnel through which IDXP would operate. An =
ID entity 'Alice' initiates the creation of a BEEP session using the =
IDXP profile with the entity 'Bob' by first contacting 'proxy1'. In the =
greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile is =
selected, and subsequently the use of the TUNNEL profile is extended to =
reach through 'proxy2' to 'Bob'.</preamble>
<artwork><![CDATA[
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 ------------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">Instead of immediately acknowledging the request =
from 'Alice' to start TUNNEL, 'proxy1' attempts to establish use of =
TUNNEL with 'proxy2'. 'proxy2' also delays its acknowledgment to =
'proxy1'.</t>
<t hangText=3D"[2]">'Bob' acknowledges the request from 'proxy2' to =
start TUNNEL, and this acknowledgment propagates back to 'Alice' so =
that a TUNNEL application-layer tunnel is established from 'Alice' to =
'Bob'.</t>
</list></t>
</section>
<section anchor=3D"transfer" title=3D"Data Transfer">
<t>Between a pair of ID entities communicating over a BEEP session, one =
or more BEEP channels MAY be opened using the IDXP profile. If desired, =
additional BEEP sessions MAY be established to offer additional =
channels using the IDXP profile. However, in most situations additional =
channels using the IDXP profile SHOULD be opened within an existing =
BEEP session, as opposed to provisioning a new BEEP session containing =
the additional channels using the IDXP profile.</t>
<t>Peers assume the role of client or server on a per-channel basis, =
with one acting as the client and the other as the server. A peer's =
role of client or server is determined independent of whether the peer =
assumed the role of initiator or listener during the BEEP session =
establishment. Clients and servers act as sources and sinks, =
respectively, for exchanging data.</t>
<figure>
<preamble>In a simple case, an analyzer peer sends data to a manager =
peer. E.g.,</preamble>
<artwork>
+----------+ +----------+
| | | |
| |****** BEEP session ******| |
| | | |
| Analyzer | ----- IDXP profile ----> | Manager |
| (Client) | | (Server) |
| | | |
| |**************************| |
| | | |
+----------+ +----------+
</artwork>
<!--<postamble>Note that the arrowhead for the BEEP channel using the =
IDXP profile points from client to server.</postamble>-->
</figure>
<t>Use of multiple BEEP channels in a BEEP session facilitates =
categorization and prioritization of data sent between IDXP peers. For =
example, a manager 'M1', sending alert data to another manager, 'M2', =
may choose to open a separate channel to exchange different categories =
of alerts. 'M1' would act as the client on each of these channels, and =
manager 'M2' can then process and act on the incoming alerts based on =
their respective channel categorizations. See <xref =
target=3D"idxp_options" /> for more detail on how to incorporate =
categorization and/or prioritization into channel creation.</t>
<figure>
<artwork>
+----------+ +----------+
| | | |
| |*************** BEEP session ***************| |
| | | |
| | -- IDXP profile, network-based alerts ---> | |
| Manager | | Manager |
| M1 | ---- IDXP profile, host-based alerts ----> | M2 |
| (Client) | | (Server) |
| | ------ IDXP profile, other alerts -------> | |
| | | |
| |********************************************| |
| | | |
+----------+ +----------+
</artwork>
</figure>
</section>
<section title=3D"Connection Teardown">
<t>An IDXP peer may choose to close an IDXP channel under many =
different circumstances (e.g., an error in processing has occurred). To =
close a channel, the peer sends a "close" element (c.f., Section =
2.3.1.3 of <xref target=3D"RFC3080" />) on channel zero indicating =
which channel is being closed. An IDXP peer may also choose to close an =
entire BEEP session by sending a "close" element indicating that =
channel zero is to be closed. Section 2.3.1.3 of <xref =
target=3D"RFC3080" /> offers a more complete discussion of the =
circumstances under which a BEEP peer is permitted to close a channel =
and the mechanisms for doing so.</t>
<t>It is anticipated that due to the overhead of provisioning an =
application-layer tunnel and/or a BEEP security profile, BEEP sessions =
containing IDXP channels will be long-lived. Additionally, the repeated =
overhead of IDXP channel provisioning (i.e., the exchange of IDXP =
greetings) may be avoided by keeping IDXP channels open even while data =
is not actively being exchanged on them. These are recommendations and, =
as such, IDXP peers may choose to close and re-provision BEEP sessions =
and/or IDXP channels as they see fit.</t>
</section>
<section anchor=3D"trust" title=3D"Trust Model">
<t>In our model, trust is placed exclusively in the IDXP peers. =
Proxies are always assumed to be untrustworthy. A BEEP security profile =
is used to establish end-to-end security between pairs of IDXP peers, =
doing away with the need to place trust in any intervening proxies. =
Only after successful negotiation of the underlying security profile =
are IDXP peers to be trusted. Only BEEP security profiles offering at =
least the protections required by Section 6 of <xref =
target=3D"refs.IDWG-reqs" /> should be used to secure a BEEP session =
containing channels using the IDXP profile. See Section 3 of <xref =
target=3D"RFC3080" /> for the registration of the TLS profile, an =
example of a BEEP security profile meeting the requirements of Section =
6 of <xref target=3D"refs.IDWG-reqs" />. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communications protocol requirements.</t>
</section>
</section>
<section anchor=3D"IDXP-profile" title=3D"The IDXP Profile">
<section title=3D"IDXP Profile Overview">
<t>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 <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> SHOULD be used for this purpose; see <xref =
target=3D"refs.tunnel" /> for more detail concerning the options =
available to setup an application-layer tunnel using TUNNEL, and see =
<xref target=3D"security.tunnel" /> for a discussion of TUNNEL related =
security considerations. TUNNEL MUST be offered as a tuning profile for =
the creation of application-layer tunnels. The TUNNEL profile MUST =
offer the use of some form of SASL authentication (c.f., Section 4.1 of =
<xref target=3D"RFC3080" />). 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 <xref =
target=3D"connect" /> and <xref target=3D"security" />.</t>
<t>The IDXP profile supports several elements of interest:</t>
<t><list style=3D"symbols">
<t>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.</t>
<t>The "Option" element is used to convey optional channel =
parameters between peers during the exchange of "IDXP-Greeting" =
elements. This element is OPTIONAL.</t>
<t>The "IDMEF-Message" element carries the structured information =
to be exchanged between the peers.</t>
</list></t>
</section>
<section title=3D"IDXP Profile Identification and Initialization">
<t>The IDXP profile is identified as</t>
<t><list style=3D"empty">
<t>http://iana.org/beep/transient/idwg/idxp</t>
</list></t>
<t>in the BEEP "profile" element during channel creation.</t>
<t>During channel creation, "IDXP-Greeting" elements MUST be mutually =
exchanged between the peers. An "IDXP-Greeting" element MAY be =
contained within the corresponding "profile" element in the BEEP =
"start" element. Including an "IDXP-Greeting" element in the initial =
"start" element has exactly the same semantics as passing it as the =
first "MSG" message on the channel. If channel creation is successful, =
then before sending the corresponding reply, the BEEP peer processes =
the "IDXP-Greeting" element and includes the resulting response in the =
reply. This response will be an "ok" element or an "error" element. The =
choice of which element is returned is dependent on local provisioning =
of the peer.</t>
</section>
<section anchor=3D"IDXP-syntax" title=3D"IDXP Profile Message =
Syntax">
<t>BEEP messages in the profile MUST have a <xref =
target=3D"RFC2046">MIME Content-Type</xref> of "text/xml", =
"text/plain", or "application/octet-stream". The syntax of the =
individual elements is specified in <xref target=3D"idxp_dtd" /> and =
Section 5 of <xref target=3D"refs.IDMEF" />.</t>
</section>
<section anchor=3D"IDXP-semantics" title=3D"IDXP Profile Semantics">
<t>Each BEEP peer issues the "IDXP-Greeting" element using "MSG" =
messages. The "IDXP-Greeting" element MAY contain one or more "Option" =
sub-elements, conveying optional channel parameters. Each BEEP peer =
then issues "ok" in "RPY" messages or "error" in "ERR" messages. (See =
Section 2.3.1 of <xref target=3D"RFC3080" /> for the definitions of the =
"error" and "ok" elements.) Based on the respective client/server roles =
negotiated during the exchange of "IDXP-Greeting" elements, the client =
sends data using "MSG" messages. Depending on the MIME Content-Type, =
this data may be an "IDMEF-Message" element, plain text, or binary. The =
server then issues "ok" in "RPY" messages or "error" in "ERR" =
messages.</t>
<section title=3D"The IDXP-GREETING Element">
<t>The "IDXP-Greeting" element serves to identify the analyzer or =
manager at one end of the BEEP channel to the analyzer or manager at =
the other end of the channel. The "IDXP-Greeting" element MUST include =
the role of the peer on the channel (client or server) and the <xref =
target=3D"RFC2396">Uniform Resource Identifier (URI)</xref> of the =
peer. Additionally, the "IDXP-Greeting" element MAY include a =
combination of the fully qualified domain name (c.f., <xref =
target=3D"RFC1034" />) and IP address of the peer. The IP address =
chosen SHOULD correspond to the IP address associated with the =
underlying transport protocol carrying the channel. One or more =
"Option" sub-elements MAY be present.</t>
<t>An "IDXP-Greeting" element MAY be sent by either peer at any =
time. The peer receiving the "IDXP-Greeting" MUST respond with an "ok" =
(indicating acceptance), or an "error" (indicating rejection). A peer's =
identity and role on a channel and any optional channel parameters are, =
in effect, specified by the most recent "IDXP-Greeting" it sent that =
was answered with an "ok".</t>
<t>An "IDXP-Greeting" may be rejected (with an "error" element) =
under many circumstances. These include, but are not limited to, =
authentication failure, lack of authorization to connect under the =
specified role, the negotiation of an inadequate ciphersuite, or the =
presence of a channel option that must be understood but was =
unrecognized.</t>
<figure>
<preamble>For example, a successful creation with an embedded =
"IDXP-Greeting" might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1592 187
I: Content-Type: text/xml
I:
I: <start number=3D'1'>
I: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
I: <![CDATA[ <IDXP-Greeting uri=3D'http://example.com/alice'
I: role=3D'client' /> ]]>
I: </profile>
I: </start>
I: END
L: RPY 0 10 . 1865 91
L: Content-Type: text/xml
L:
L: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
L: <![CDATA[ <ok /> ]]>
L: </profile>
L: END
L: MSG 0 11 . 1956 61
L: Content-Type: text/xml
L:
L: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server' =
/>
L: END
I: RPY 0 11 . 1779 7
I: Content-Type: text/xml
I:
I: <ok />
I: END
</artwork>
</figure>
<figure>
<preamble>A creation with an embedded "IDXP-Greeting" that fails =
might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1776 185
I: Content-Type: text/xml
I:
I: <start number=3D'1'>
I: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
I: <![CDATA[ <IDXP-Greeting uri=3D'http://example.com/eve'
I: role=3D'client' /> ]]>
I: </profile>
I: </start>
I: END
L: RPY 0 10 . 1592 182
L: Content-Type: text/xml
L:
L: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
L: <![CDATA[
L: <error code=3D'530'>'http://example.com/eve' must first
L: negotiate the TLS profile</error> ]]>
L: </profile>
L: END
</artwork>
</figure>
</section>
<section title=3D"The OPTION Element">
<t>If 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 within =
an "IDXP-Greeting" element represents a request to enable an IDXP =
option on the channel being negotiated. See <xref =
target=3D"idxp_options" /> for a complete description of IDXP options =
and the "Option" element.</t>
</section>
<section title=3D"The IDMEF-MESSAGE Element">
<t>The "IDMEF-Message" element carries the information to be =
exchanged between the peers. See Section 5 of <xref =
target=3D"refs.IDMEF" /> for the definition of this element.</t>
</section>
</section>
</section>
<section anchor=3D"idxp_options" title=3D"IDXP Options">
<t>IDXP provides a service for the reliable exchange of data between =
intrusion detection entities. Options are used to alter the semantics =
of the service.</t>
<t>The specification of an IDXP option MUST define:</t>
<t><list style=3D"symbols">
<t>the identity of the option;</t>
<t>what content, if any, is contained within the option; and,</t>
<t>the processing rules for the option.</t>
</list></t>
<t>An option registration template (c.f. <xref target=3D"option_reg" =
/>) organizes this information.</t>
<t>An "Option" element is contained within an "IDXP-Greeting" element. =
The "IDXP-Greeting" element itself MAY contain one or more "Option" =
elements. The "Option" element has several attributes and contains =
arbitrary content:</t>
<t><list style=3D"symbols">
<t>the "internal" and the "external" attributes, exactly one of which =
MUST be present, uniquely identify the option;</t>
<t>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,</t>
<t>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.</t>
</list></t>
<t>The value of the "internal" attribute is the IANA-registered name =
for the option. If the "internal" attribute is not present, then the =
value of the "external" attribute is a URI or URI with a =
fragment-identifier. Note that a relative-URI value is not allowed.</t>
<t>The "mustUnderstand" attribute specifies whether the peer may ignore =
the option if it is unrecognized. If the value of the "mustUnderstand" =
attribute is "true", and if the peer does not recognize the option, =
then an error in processing has occurred. When absent, the value of the =
"mustUnderstand" attribute is defined to be "false".</t>
<section anchor=3D"priority_option" title=3D"The channelPriority =
Option">
<t><xref target=3D"priority_opt_reg" /> contains the IDXP option =
registration for the "channelPriority" option. This option contains a =
"channelPriority" element (c.f., <xref target=3D"priority_dtd" />).</t>
<t>By default, IDXP does not place any requirements on how peers =
should manage multiple IDXP channels. The "channelPriority" option =
provides a way for peers using multiple IDXP channels to request =
relative priorities for each channel. When sending an "IDXP-Greeting" =
element during the provisioning of an IDXP channel, the originating =
peer MAY request that the remote peer assign a priority to the channel =
by including an "Option" element containing a "channelPriority" =
element.</t>
<t>The "channelPriority" element has one attribute named =
"priority", of range 0..2147483647. This attribute is REQUIRED. Not =
coincidentally, this is the maximum range of possible BEEP channel =
numbers. 0 is defined to represent the highest priority, with relative =
priority decreasing as the "priority" value ascends.</t>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
C: MSG 1 17 . 1984 165
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C: <Option internal=3D'channelPriority'>
C: <channelPriority priority=3D'0' />
C: </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 17 . 2001 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
</figure>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
S: MSG 1 17 . 1312 194
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S: <Option internal=3D'channelPriority' mustUnderstand=3D'true'>
S: <channelPriority priority=3D'2147483647' />
S: </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 17 . 451 68
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'channelPriority' option was =
unrecognized</error>
C: END
]]></artwork>
</figure>
</section>
<section anchor=3D"type_option" title=3D"The streamType Option">
<t><xref target=3D"type_opt_reg" /> contains the IDXP option =
registration for the "streamType" option. This option contains a =
"streamType" element (c.f., <xref target=3D"st_dtd" />).</t>
<t>By default, IDXP provides no explicit method for categorizing =
channels. The "streamType" option provides a way for peers to request =
that a channel be categorized as a particular stream type. When sending =
an "IDXP-Greeting" element during the provisioning of an IDXP channel, =
the originating peer MAY request that the remote peer assign a stream =
type to the channel by including an "Option" element containing a =
"streamType" element.</t>
<t>The "streamType" element has one attribute named "type", with =
the possible values of "alert", "heartbeat", or "config". This =
attribute is REQUIRED. A value of "alert" indicates that the channel =
should be categorized as being used for the exchange of ID alerts. A =
value of "heartbeat" indicates that the channel should be categorized =
as being used for the exchange of heartbeat messages such as the =
"Heartbeat" element (c.f., Section 5 of <xref target=3D"refs.IDMEF" =
/>). A value of "config" indicates that the channel should be =
categorized as being used for the exchange of configuration =
messages.</t>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
C: MSG 1 21 . 1963 155
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C: <Option internal=3D'streamType'>
C: <streamType type=3D'alert' />
C: </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 21 . 1117 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
</figure>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
S: MSG 1 21 . 1969 176
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S: <Option internal=3D'streamType' mustUnderstand=3D'true'>
S: <streamType type=3D'config' />
S: </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 21 . 1292 63
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'streamType' option was unrecognized</error>
C: END
]]></artwork>
</figure>
</section>
</section>
<section anchor=3D"proto-reqs" title=3D"Fulfillment of IDWG =
Communications Protocol Requirements">
<t>The following lists the communications protocol requirements =
established in Section 6 of <xref target=3D"refs.IDWG-reqs" /> and, for =
each requirement, describes the manner in which it is fulfilled by =
IDXP.</t>
<t>The [protocol] MUST support reliable transmission of messages.</t>
<t><list style=3D"empty">
<t>IDXP operates over BEEP, which operates only over reliable =
connection-oriented transport protocols (e.g., TCP). In addition, BEEP =
peers communicate using a simple request-response protocol, which =
provides end-to-end reliability between peers.</t>
</list></t>
<t>The [protocol] MUST support transmission of messages between ID =
components across firewall boundaries without compromising =
security.</t>
<t><list style=3D"empty">
<t>The TUNNEL profile <xref target=3D"refs.tunnel" /> MUST be =
offered as an option for creation of application-layer tunnels to allow =
operation across firewalls. The TUNNEL profile SHOULD be used to =
provide an application-layer tunnel. The ability to authenticate hosts =
during the creation of an application-layer tunnel MUST be provided by =
the mechanism chosen to create such tunnels. A firewall may therefore =
be configured to authenticate all hosts attempting to tunnel into the =
protected network. If the TUNNEL profile is used, SASL (c.f., Section =
4.1 of <xref target=3D"RFC3080" />) MUST be offered as a mechanism by =
which hosts can be authenticated.</t>
</list></t>
<t>The [protocol] MUST support mutual authentication of the analyzer =
and the manager to each other.</t>
<t><list style=3D"empty">
<t>IDXP supports mutual authentication of the peers through the use =
of an appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security profiles that may 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.</t>
</list></t>
<t>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.</t>
<t><list style=3D"empty">
<t>IDXP supports confidentiality through the use of an appropriate =
underlying BEEP security profile. The TLS profile is an example a =
security profile 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. The =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses ephemeral =
Diffie-Hellman (DHE) with DSS signatures for key exchange and triple =
DES (3DES) and cipher-block chaining (CBC) for encryption. Stronger =
cipher suites are optional.</t>
</list></t>
<t>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.</t>
<t><list style=3D"empty">
<t>IDXP supports message integrity through the use of an =
appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security 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. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA =
cipher suite uses the Secure Hash Algorithm (SHA) for integrity =
protection using a keyed message authentication code. Stronger cipher =
suites are optional.</t>
</list></t>
<t>The [protocol] SHOULD be able to ensure non-repudiation of the =
origin of IDMEF messages.</t>
<t><list style=3D"empty">
<t>IDXP supports non-repudiation of message origin through the use =
of an appropriate underlying BEEP security profile. The TLS profile is =
an example of a security profile that offers non-repudiation of message =
origin through the authentication of public-key certificates. TLS MUST =
be offered as a mechanism to provide non-repudiation of message origin, =
and TLS SHOULD be used to provide non-repudiation of message =
origin.</t>
</list></t>
<t>The [protocol] SHOULD resist protocol denial of service =
attacks.</t>
<t><list style=3D"empty">
<t>IDXP supports resistance to denial of service (DoS) attacks =
through the use of 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 is helpful to discard =
traffic arising from a non-authenticated source. BEEP peers MUST =
support the use of authentication in conjunction with any mechanism =
used to create application-layer tunnels. In particular, the use of =
some form of SASL authentication (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) MUST be offered to provide authentication in the =
use of the TUNNEL profile. See Section 7 of <xref =
target=3D"refs.tunnel" /> for a discussion of security considerations =
in the use of the TUNNEL profile.</t>
</list></t>
<t>The [protocol] SHOULD resist malicious duplication of =
messages.</t>
<t><list style=3D"empty">
<t>IDXP supports resistance to malicious duplication of messages =
(i.e., replay attacks) through the use of an appropriate underlying =
BEEP security profile. The TLS profile is an example of a security =
profile offering 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. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses =
cipher-block chaining (CBC) to ensure that even if a message is =
duplicated the cipher-text duplicate will produce a very different =
plain-text result. Stronger cipher suites are optional.</t>
</list></t>
</section>
<section title=3D"IDXP Option Registration Template" =
anchor=3D"option_reg">
<t>When an IDXP option is registered, the following information is =
supplied:</t>
<t>Option Identification: specify the NMTOKEN or the URI that =
authoritatively identifies this option.</t>
<t>Contains: specify the XML content that is contained within the =
"Option" element.</t>
<t>Processing Rules: specify the processing rules associated with the =
option.</t>
<t>Contact Information: specify the postal and electronic contact =
information for the author(s) of the option.</t>
</section>
<section title=3D"Initial Registrations">
<section anchor=3D"idxp-registration" title=3D"Registration: The IDXP =
Profile">
<t>Profile identification: http://iana.org/beep/transient/idwg/idxp</t>
<t>Messages exchanged during channel creation: "IDXP-Greeting"</t>
<t>Messages starting one-to-one exchanges: "IDXP-Greeting", =
"IDMEF-Message"</t>
<t>Messages in positive replies: "ok"</t>
<t>Messages in negative replies: "error"</t>
<t>Messages in one-to-many exchanges: none</t>
<t>Message syntax: c.f., <xref target=3D"IDXP-syntax" /></t>
<t>Message semantics: c.f., <xref target=3D"IDXP-semantics" /></t>
<t>Contact information: c.f., the "Authors' Addresses" section of this =
memo</t>
</section>
<section anchor=3D"port-registration" title=3D"Registration: The =
System (Well-Known) TCP port number for IDXP">
<t>Protocol Number: TCP</t>
<t>Message Formats, Types, Opcodes, and Sequences: c.f., <xref =
target=3D"IDXP-syntax" /></t>
<t>Functions: c.f., <xref target=3D"IDXP-semantics" /></t>
<t>Use of Broadcast/Multicast: none</t>
<t>Proposed Name: Intrusion Detection Exchange Protocol</t>
<t>Short name: idxp</t>
<t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
</section>
<section anchor=3D"priority_opt_reg" title=3D"Registration: The =
channelPriority Option">
<t>Option Identification: channelPriority</t>
<t>Contains: channelPriority (c.f., <xref target=3D"priority_dtd" =
/>)</t>
<t>Processing Rules: c.f., <xref target=3D"priority_option" /></t>
<t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
</section>
<section anchor=3D"type_opt_reg" title=3D"Registration: The =
streamType Option">
<t>Option Identification: streamType</t>
<t>Contains: streamType (c.f., <xref target=3D"st_dtd" />)</t>
<t>Processing Rules: c.f., <xref target=3D"type_option" /></t>
<t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
</section>
</section>
<section title=3D"The DTDs">
<section anchor=3D"idxp_dtd" title=3D"The IDXP DTD">
<t>The following is the DTD defining the valid elements for the IDXP =
profile</t>
<figure>
<artwork><![CDATA[
<!--
DTD for the IDXP Profile, as of 2002-01-08
Refer to this DTD as:
<!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC XXXX IDXP v1.0//EN">
%IDXP;
-->
<!-- Includes -->
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">
%BEEP;
<!ENTITY % IDMEF-Message PUBLIC "-//IETF//DTD RFC XXXX IDMEF =
v1.0//EN">
%IDMEF;
<!--
Profile Summary
BEEP profile http://iana.org/beep/transient/idwg/idxp
role MSG RPY ERR
=3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =
=3D=3D=3D
I or L IDXP-Greeting ok error
C IDMEF-Message ok error
-->
<!--
Entity Definitions
entity syntax/reference example
=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D
an authoritative identification
URI c.f., [RFC-2396] http://example.com
a fully qualified domain name
FQDN c.f., [RFC-1034] www.example.com
a dotted-quad IP address
IP 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT "." 1*3DIGIT
10.0.0.27
-->
<!ENTITY % URI "CDATA">
<!ENTITY % FQDN "CDATA">
<!ENTITY % IP "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
ip %IP; #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"> =20
<!--
The IDMEF-Message element conveys the intrusion detection
information that is exchanged. This element is defined in the
idmef-message.dtd
-->
<!-- End of DTD -->
]]></artwork>
</figure>
</section>
<section anchor=3D"priority_dtd" title=3D"The channelPriority Option =
DTD">
<t>The following is the DTD defining the valid elements for the =
channelPriority option</t>
<figure>
<artwork><![CDATA[
<!--
DTD for the channelPriority IDXP option, as of 2002-01-08
Refer to this DTD as:
<!ENTITY % IDXP-channelPriority PUBLIC
"-//IETF//DTD RFC XXXX IDXP-channelPriority v1.0//EN">
%IDXP-channelPriority;
-->
<!--
Entity Definitions
entity syntax/reference example
=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D
a priority number
PRIORITY 0..2147483647 1
-->
<!ENTITY % PRIORITY "CDATA">
<!ELEMENT channelPriority EMPTY>
<!ATTLIST channelPriority
priority %PRIORITY #REQUIRED>
<!-- End of DTD -->=20
]]></artwork>
</figure>
</section>
<section anchor=3D"st_dtd" title=3D"The streamType DTD">
<t>The following is the DTD defining the valid elements for the =
streamType option</t>
<figure>
<artwork><![CDATA[
<!--
DTD for the streamType IDXP option, as of 2002-01-08
Refer to this DTD as:
<!ENTITY % IDXP-streamType PUBLIC
"-//IETF//DTD RFC XXXX IDXP-streamType v1.0//EN">
%IDXP-streamType;
-->
<!--
Entity Definitions
entity syntax/reference example
=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D
a stream type
STYPE (alert | heartbeat | config) "alert"
-->
<!ENTITY % STYPE (alert|heartbeat|config)>
<!ELEMENT streamType EMPTY>
<!ATTLIST streamType
type %STYPE #REQUIRED>
<!-- End of DTD -->
]]></artwork>
</figure>
</section>
</section>
<section title=3D"Reply Codes">
<figure>
<preamble>This section lists the three-digit error codes the IDXP =
profile may generate.</preamble>
<artwork>
code meaning
=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D
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, etc.)
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)
</artwork>
</figure>
</section>
<section anchor=3D"security" title=3D"Security Considerations">
<t>The IDXP profile is a profile of BEEP. In BEEP, transport security,
user authentication, and data exchange are orthogonal. Refer to Section =
8
of <xref target=3D"RFC3080" /> for a discussion of this. It is strongly =
recommended that those wanting to use the IDXP profile initially =
negotiate a BEEP security profile between the peers that offers the =
required security properties. The TLS profile SHOULD be used to provide =
for transport security. See <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications protocol =
requirements.</t>
<t>See <xref target=3D"trust" /> for a discussion of the trust =
model.</t>
<section anchor=3D"security.tunnel" title=3D"Use of the TUNNEL =
Profile">
<t>See <xref target=3D"proto-reqs" /> for IDXP's requirements on =
application-layer tunneling and the TUNNEL profile specifically. See =
Section 7 of <xref target=3D"refs.tunnel" /> for a discussion of the =
security considerations inherent in the use of the TUNNEL profile.</t>
</section>
<section title=3D"Use of Underlying Security Profiles">
<t>At present, the TLS profile is the only BEEP security profile =
known to meet all of the requirements set forth in Section 6 of <xref =
target=3D"refs.IDWG-reqs" />. When securing 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 <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications requirements =
through the use of an underlying security profile.</t>
</section>
</section>
</middle>
<back>
<references>
%include.reference.RFC.2396;
%include.reference.RFC.2119;
<reference anchor=3D"refs.IDMEF">
<front>
<title>Intrusion Detection Message Exchange Format Data Model and =
Extensible Markup Language (XML) Document Type Definition</title>
<author initials=3D"D." surname=3D"Curry" fullname=3D"David Curry">
<organization>Merrill Lynch & Co.</organization>
</author>
<author initials=3D"H." surname=3D"Debar" fullname=3D"Herve Debar">
<organization>France Telecom R & D</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>
<!--
<reference anchor=3D"refs.IDMEF" target=3D"draft-ietf-idwg-idmef-xml-03 =
(work in progress)">
<front>
<title>Intrusion Detection Message Exchange Format Data Model and =
Extensible Markup Language (XML) Document Type Definition</title>
<author initials=3D"D." surname=3D"Curry" fullname=3D"David Curry">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"H." surname=3D"Debar" fullname=3D"Herve Debar">
<organization>France Telecom</organization>
</author>
<date day=3D"14" month=3D"February" year=3D"2001" />
</front>
</reference>
-->
<!--
%include.reference.RFC.2246;
-->
%include.reference.RFC.2046;
<!--
<reference anchor=3D"refs.IAP" target=3D"draft-ietf-idwg-iap-03 (work =
in progress)">
<front>
<title>IAP: Intrusion Alert Protocol</title>
<author initials=3D"D." surname=3D"Gupta" fullname=3D"Dipankar Gupta">
<organization abbrev=3D"HP">Hewlett-Packard</organization>
</author>
<date month=3D"December" year=3D"2000" />
</front>
</reference>
-->
%include.reference.RFC.1034;
<!--
%include.reference.RFC.2222;
-->
<!--
<reference anchor=3D"refs.syslog" =
target=3D"draft-ietf-syslog-reliable-03 (work in progress)">
<front>
<title>Reliable Delivery for syslog</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<author initials=3D"M.T." surname=3D"Rose" fullname=3D"Marshall T. =
Rose">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date month=3D"January" year=3D"2001" />
</front>
</reference>
-->
<reference anchor=3D"refs.tunnel">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>
<!--
<reference anchor=3D"refs.tunnel" =
target=3D"draft-ietf-idwg-beep-tunnel-02 (work in progress)">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"23" month=3D"August" year=3D"2001" />
</front>
</reference>
-->
<!--
<reference anchor=3D"refs.APEX" target=3D"draft-mrose-apex-core-00 =
(work in progress)">
<front>
<title>The Application Exchange Framework</title>
<author initials=3D"M.T." surname=3D"Rose" fullname=3D"Marshall T. =
Rose">
<organization>Invisible Worlds, Inc.</organization>
</author>
<author initials=3D"G." surname=3D"Klyne" fullname=3D"Graham Klyne">
<organization>Content Technologies Limited</organization>
</author>
<author initials=3D"D.H." surname=3D"Crocker" fullname=3D"David H. =
Crocker">
<organization>Brandenburg Consulting</organization>
</author>
<date month=3D"December" year=3D"2000" />
</front>
</reference>
-->
%include.reference.RFC.3080;
<!--
%include.reference.RFC.2629;
-->
<reference anchor=3D"refs.IDWG-reqs">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>
<!--
<reference anchor=3D"refs.IDWG-reqs" =
target=3D"draft-ietf-idwg-requirements-05 (work in progress)">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"20" month=3D"February" year=3D"2001" />
</front>
</reference>
-->
</references>
<section anchor=3D"IANA" title=3D"IANA Considerations">
<t>The IANA registers "IDXP" as a standards-track BEEP profile, as =
specified in <xref target=3D"idxp-registration" />. The IANA changes =
the IDXP profile identification to "http://iana.org/beep/IDXP".</t>
<t>The IANA registers "idxp" as a TCP port number, as specified in =
<xref target=3D"port-registration" /></t>
<t>The IANA maintains a list of:</t>
<t><list style=3D"empty">
<t>IDXP options, c.f., <xref target=3D"option_reg"/>.</t>
</list></t>
<t>For this list, the IESG is responsible for assigning a designated =
expert to review the specification prior to the IANA making the =
assignment. As a courtesy to developers of non-standards track IDXP =
options, the mailing list idxp-java-users@lists.sourceforge.net may be =
used to solicit commentary.</t>
<t>The IANA makes the registrations specified in <xref =
target=3D"priority_opt_reg" /> and <xref target=3D"type_opt_reg" =
/>.</t>
</section>
<section title=3D"History of Significant Changes" anchor=3D"changes">
<t>The RFC Editor should remove this section and its corresponding =
TOC references prior to publication.</t>
<section title=3D"Significant Changes Since beep-idxp-03">
<t>Modified references to Internet-Drafts to contain placeholders =
for their forthcoming RFC numbers.</t>
<t>Modified IDMEF formal public identifier (FPI) in the IDXP DTD to =
reflect the changes in draft-ietf-idwg-idmef-xml-06.</t>
<t>Modified IDXP FPI for the IDXP DTD to be more in line with the =
IDMEF FPI.</t>
</section>
<section title=3D"Significant Changes Since beep-idxp-02">
<t>Added IDXP option registration template and registered two =
initial options.</t>
<t>Indicated that the IANA should change the profile identification =
to "http://iana.org/beep/IDXP" upon adoption of IDXP as a =
standards-track BEEP profile.</t>
<t>Renamed the "Options" element to "Option" and allowed multiple =
"Option" sub-elements within an "IDXP-Greeting" element. Also added =
attributes to "Option" element.</t>
<t>Modified IANA profile registration and added TCP port number =
IANA registration.</t>
<t>Reordered some sections to improve the flow of the document.</t>
<t>Changed IDXP DTD identifier to be more IETF-like and removed =
URLs from ENTITY declarations.</t>
<t>Changed IDXP profile URI to fall under the =
"http://iana.org/beep/transient" namespace.</t>
<t>Modified <xref target=3D"terminology" /> to reference the =
requirements language specified by <xref target=3D"RFC2119" />.</t>
<t>Eliminated the use of the "endpoint" terminology, in favor of =
"peer".</t>
<t>Modified figures to make them more understandable.</t>
<t>Modified Sections 2, 3, and 4 to use the requirements language =
specified by <xref target=3D"RFC2119"/>.</t>
<t>Indicated that the RFC Editor should remove <xref =
target=3D"changes" /> and its corresponding TOC reference prior to =
publication.</t>
<t>Fixed several typos.</t>
</section>
<section title=3D"Significant Changes Since beep-idxp-01">
<t>Added new MUST and SHOULD language for use of TLS and TUNNEL =
profiles.</t>
<t>Modified the "IDXP-Greeting" element to include an "Options" =
sub-element.</t>
<t>Changed IDXP profile URI.</t>
</section>
<section title=3D"Significant Changes Since beep-idxp-00">
<t>Added <xref target=3D"proto-reqs" />, describing how IDXP =
fulfills the communication protocol requirements of the IDWG.</t>
<t>Moved IDXP profile registration to <xref target=3D"IANA" />.</t>
<t>Clarified the role that underlying BEEP security profiles must =
play.</t>
<t>Clarified how IDMEF messages fit into IDXP.</t>
<t>Clarified how the IDXP profile channels and BEEP sessions =
interact.</t>
<t>Made terminology clarifications and changes for overall =
consistency.</t>
</section>
</section>
<section title=3D"Acknowledgements">
<t>The authors gratefully acknowledge the contributions of Darren New, =
Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, and Paul =
Osterwald.</t>
</section>
</back>
</rfc>
------_=_NextPart_000_01C21276.996E2A90
Content-Type: application/octet-stream;
name="draft-ietf-idwg-beep-idxp-05.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-idwg-beep-idxp-05.xml"
<?xml version=3D"1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc=3D"yes"?>
<!--
$Header: /cvsroot/idxp-java/idxp-doc/draft-ietf-idwg-beep-idxp.xml,v =
1.3 2002/01/08 19:51:22 bfeinste Exp $
-->
<!-- Remember to increment the document number for each release -->
<rfc ipr=3D"full2026" docName=3D"draft-ietf-idwg-beep-idxp-05">
<front>
<title abbrev=3D"The IDXP">The Intrusion Detection Exchange Protocol =
(IDXP)</title>
<author initials=3D"B.S." surname=3D"Feinstein" fullname=3D"Benjamin S. =
Feinstein">
<organization>Guardent, Inc.</organization>
<address>
<email>Ben.Feinstein@guardent.com</email>
<uri>http://www.guardent.com/</uri>
</address>
</author>
<author initials=3D"G.A." surname=3D"Matthews" fullname=3D"Gregory A. =
Matthews">
<organization>CSC/NASA Ames Research Center</organization>
<address>
<email>gmatthew@nas.nasa.gov</email>
<uri>http://www.nas.nasa.gov/</uri>
</address>
</author>
<author initials=3D"J.C.C." surname=3D"White" fullname=3D"John C. C. =
White">
<organization>MITRE Corporation</organization>
<address>
<email>jccw@mitre.org</email>
<uri>http://www.mitre.org/</uri>
</address>
</author>
<!-- Remember to update the date for each release -->
<date day=3D"12" month=3D"June" year=3D"2002" />
<area>Security</area>
<workgroup>Intrusion Detection Exchange Format</workgroup>
<keyword>intrusion detection</keyword>
<keyword>security</keyword>
<keyword>secure</keyword>
<keyword>secure protocol</keyword>
<keyword>exchange</keyword>
<keyword>intrusion</keyword>
<keyword>IDS</keyword>
<keyword>BEEP</keyword>
<keyword>intrusion detection protocol</keyword>
<abstract>
<t>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. The =
protocol provides for the exchange of IDMEF messages, unstructured =
text, and binary data. The IDMEF message elements are described in the =
<xref target=3D"refs.IDMEF">Intrusion Detection Message Exchange Format =
(IDMEF)</xref>, a companion document of the Intrusion Detection =
Exchange Format (IDWG) working group of the IETF.</t>
</abstract>
</front>
<middle>
<section anchor=3D"intro" title=3D"Introduction">
<t>IDXP is specified, in part, as a <xref target=3D"RFC3080">Blocks =
Extensible Exchange Protocol (BEEP)</xref> "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.</t>
<section anchor=3D"purpose" title=3D"Purpose">
<t>IDXP provides for the exchange of <xref =
target=3D"refs.IDMEF">IDMEF</xref> messages, unstructured text, and =
binary data between intrusion detection entities. Addressing the =
security-sensitive nature of exchanges between intrusion detection =
entities, underlying BEEP security profiles should be used to offer =
IDXP the required set of security properties. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communication protocol requirements. See <xref target=3D"security" /> =
for a discussion of security considerations.</t>
<t>IDXP is primarily intended for the exchange of data created by =
intrusion detection entities. <xref target=3D"refs.IDMEF">IDMEF</xref> =
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.</t>
</section>
<section title=3D"Profiles">
<t>There are several BEEP profiles discussed, the first of which we =
define in this memo:</t>
<t><list style=3D"empty">
<t>The IDXP Profile</t>
<t><xref target=3D"refs.tunnel">The TUNNEL Profile</xref></t>
<t>The Simple Authentication and Security Layer (SASL) Family of =
Profiles (c.f., Section 4.1 of <xref target=3D"RFC3080" />)</t>
<t>The TLS Profile (c.f., Section 3.1 of <xref target=3D"RFC3080" =
/>)</t>
</list></t>
</section>
<section anchor=3D"terminology" title=3D"Terminology">
<t>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 <xref =
target=3D"RFC2119">RFC 2119</xref>.</t>
<t>Throughout this memo, the terms "analyzer" and "manager" are used in =
the context of the <xref target=3D"refs.IDWG-reqs">Intrusion Detection =
Message Exchange Requirements</xref>. In particular, Section 3.2 of =
<xref target=3D"refs.IDWG-reqs" /> defines the meaning of a collection =
of intrusion detection terms.</t>
<t>The terms "peer", "initiator", "listener", "client", and "server", =
and the
characters "I", "L", "C", and "S" are used in the context of <xref =
target=3D"RFC3080">BEEP</xref>.
In particular, Section 2.1 of BEEP discusses the roles that a BEEP =
peer may perform.</t>
<t>The term "Document Type Declaration" is abbreviated as "DTD" and is =
defined in Section 2.8 of the
<xref target=3D"W3C.REC-xml">Extensible Markup Language =
(XML)</xref>.</t>
<t>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".</t>
</section>
</section>
<section anchor=3D"model" title=3D"The Model">
<section anchor=3D"connect" title=3D"Connection Provisioning">
<t>Intrusion detection entities using IDXP to transfer data are termed =
IDXP peers. Peers can exist only in pairs, and these pairs communicate =
over a single BEEP session with one or more BEEP channels opened for =
transferring data. Peers are either managers or analyzers, as defined =
in Section 3.2 of <xref target=3D"refs.IDWG-reqs" />.</t>
<t> The relationship between analyzers and managers is potentially =
many-to-many. I.e., an analyzer MAY communicate with many managers; =
similarly, a manager MAY communicate with many analyzers. Likewise, the =
relationship between different managers is potentially many-to-many, so =
that a manager MAY receive the alerts sent by a large number of =
analyzers by receiving them through intermediate managers. Analyzers =
MUST NOT establish IDXP exchanges with other analyzers.</t>
<!--
<t>[Rationale: Analyzers may send alert data and receive configuration =
data, and managers may send or receive both alert and configuration =
data.]</t>
-->
<t>An IDXP peer wishing to establish IDXP communications with another =
IDXP peer does so by opening a BEEP channel, which may entail =
initiating a BEEP session. A BEEP security profile offering the =
required security properties SHOULD initially be negotiated (see <xref =
target=3D"security" /> for a discussion of security considerations). =
Following the successful negotiation of the BEEP security profile, IDXP =
greetings are exchanged and connection provisioning proceeds.</t>
<figure>
<preamble>In the following sequence a peer 'Alice' initiates an IDXP =
exchange with the peer 'Bob'.</preamble>
<artwork><![CDATA[
Alice Bob
---------------- xport connect[1] ------------------>
<-------------------- greeting ---------------------->
<-------------start security profile[2] ------------->
<-------------------- greeting ---------------------->
<------------------ start IDXP[3] ------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">'Alice' initiates a transport connection to 'Bob', =
triggering the exchange of BEEP greeting messages.</t>
<t hangText=3D"[2]">both entities negotiate the use of a BEEP security =
profile.</t>
<t hangText=3D"[3]">both entities negotiate the use of the IDXP =
profile.</t>
</list></t>
<t>In between a pair of IDXP peers may be an arbitrary number of =
proxies. A proxy may be necessary for administrative reasons, such as =
running on a firewall to allow restricted access. Another use might be =
one proxy per company department, which forwards data from the analyzer =
peers in the department onto a company-wide manager peer.</t>
<!--
<t>To create an application-layer tunnel that transparently forwards =
data over a chain of proxies, the <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> should be used. See <xref target=3D"refs.tunnel" /> for =
more detail concerning the options available to setup an =
application-layer tunnel, and see . Once a tunnel is established =
between two peers, a new BEEP greeting must be exchanged. At this =
point, a BEEP security profile offering the required security =
properties would be negotiated, followed by negotiation of the IDXP =
profile.</t>
-->
<t>A BEEP tuning profile MAY be used to create an application-layer =
tunnel that transparently forwards data over a chain of proxies. The =
<xref target=3D"refs.tunnel">TUNNEL profile</xref> SHOULD be used for =
this purpose; see <xref target=3D"refs.tunnel" /> for more detail =
concerning the options available to setup an application-layer tunnel =
using TUNNEL, and see <xref target=3D"security.tunnel" /> for a =
discussion of TUNNEL related security considerations. TUNNEL MUST be =
offered as a tuning profile for the creation of application-layer =
tunnels. The TUNNEL profile MUST offer the use of some form of SASL =
authentication (c.f., Section 4.1 of <xref target=3D"RFC3080" />). Once =
a tunnel has been created a BEEP security profile offering the required =
security properties SHOULD be negotiated, followed by negotiation of =
the IDXP profile.</t>
<figure>
<preamble>The following sequence shows how TUNNEL might be used to =
create an application-layer tunnel through which IDXP would operate. A =
peer 'Alice' initiates the creation of a BEEP session using the IDXP =
profile with the entity 'Bob' by first contacting 'proxy1'. In the =
greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile is =
selected, and subsequently the use of the TUNNEL profile is extended to =
reach through 'proxy2' to 'Bob'.</preamble>
<artwork><![CDATA[
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 ------------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">Instead of immediately acknowledging the request =
from 'Alice' to start TUNNEL, 'proxy1' attempts to establish use of =
TUNNEL with 'proxy2'. 'proxy2' also delays its acknowledgment to =
'proxy1'.</t>
<t hangText=3D"[2]">'Bob' acknowledges the request from 'proxy2' to =
start TUNNEL, and this acknowledgment propagates back to 'Alice' so =
that a TUNNEL application-layer tunnel is established from 'Alice' to =
'Bob'.</t>
</list></t>
</section>
<section anchor=3D"transfer" title=3D"Data Transfer">
<t>Between a pair of ID entities communicating over a BEEP session, one =
or more BEEP channels MAY be opened using the IDXP profile. If desired, =
additional BEEP sessions MAY be established to offer additional =
channels using the IDXP profile. However, in most situations additional =
channels using the IDXP profile SHOULD be opened within an existing =
BEEP session, as opposed to provisioning a new BEEP session containing =
the additional channels using the IDXP profile.</t>
<t>Peers assume the role of client or server on a per-channel basis, =
with one acting as the client and the other as the server. A peer's =
role of client or server is determined independent of whether the peer =
assumed the role of initiator or listener during the BEEP session =
establishment. Clients and servers act as sources and sinks, =
respectively, for exchanging data.</t>
<figure>
<preamble>In a simple case, an analyzer peer sends data to a manager =
peer. E.g.,</preamble>
<artwork>
+----------+ +----------+
| | | |
| |****** BEEP session ******| |
| | | |
| Analyzer | ----- IDXP profile ----> | Manager |
| (Client) | | (Server) |
| | | |
| |**************************| |
| | | |
+----------+ +----------+
</artwork>
<!--<postamble>Note that the arrowhead for the BEEP channel using the =
IDXP profile points from client to server.</postamble>-->
</figure>
<t>Use of multiple BEEP channels in a BEEP session facilitates =
categorization and prioritization of data sent between IDXP peers. For =
example, a manager 'M1', sending alert data to another manager, 'M2', =
may choose to open a separate channel to exchange different categories =
of alerts. 'M1' would act as the client on each of these channels, and =
manager 'M2' can then process and act on the incoming alerts based on =
their respective channel categorizations. See <xref =
target=3D"idxp_options" /> for more detail on how to incorporate =
categorization and/or prioritization into channel creation.</t>
<figure>
<artwork>
+----------+ +----------+
| | | |
| |*************** BEEP session ***************| |
| | | |
| | -- IDXP profile, network-based alerts ---> | |
| Manager | | Manager |
| M1 | ---- IDXP profile, host-based alerts ----> | M2 |
| (Client) | | (Server) |
| | ------ IDXP profile, other alerts -------> | |
| | | |
| |********************************************| |
| | | |
+----------+ +----------+
</artwork>
</figure>
</section>
<section title=3D"Connection Teardown">
<t>An IDXP peer may choose to close an IDXP channel under many =
different circumstances (e.g., an error in processing has occurred). To =
close a channel, the peer sends a "close" element (c.f., Section =
2.3.1.3 of <xref target=3D"RFC3080" />) on channel zero indicating =
which channel is being closed. An IDXP peer may also choose to close an =
entire BEEP session by sending a "close" element indicating that =
channel zero is to be closed. Section 2.3.1.3 of <xref =
target=3D"RFC3080" /> offers a more complete discussion of the =
circumstances under which a BEEP peer is permitted to close a channel =
and the mechanisms for doing so.</t>
<t>It is anticipated that due to the overhead of provisioning an =
application-layer tunnel and/or a BEEP security profile, BEEP sessions =
containing IDXP channels will be long-lived. Additionally, the repeated =
overhead of IDXP channel provisioning (i.e., the exchange of IDXP =
greetings) may be avoided by keeping IDXP channels open even while data =
is not actively being exchanged on them. These are recommendations and, =
as such, IDXP peers may choose to close and re-provision BEEP sessions =
and/or IDXP channels as they see fit.</t>
</section>
<section anchor=3D"trust" title=3D"Trust Model">
<t>In our model, trust is placed exclusively in the IDXP peers. =
Proxies are always assumed to be untrustworthy. A BEEP security profile =
is used to establish end-to-end security between pairs of IDXP peers, =
doing away with the need to place trust in any intervening proxies. =
Only after successful negotiation of the underlying security profile =
are IDXP peers to be trusted. Only BEEP security profiles offering at =
least the protections required by Section 5 of <xref =
target=3D"refs.IDWG-reqs" /> should be used to secure a BEEP session =
containing channels using the IDXP profile. See Section 3 of <xref =
target=3D"RFC3080" /> for the registration of the TLS profile, an =
example of a BEEP security profile meeting the requirements of Section =
5 of <xref target=3D"refs.IDWG-reqs" />. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communications protocol requirements.</t>
</section>
</section>
<section anchor=3D"IDXP-profile" title=3D"The IDXP Profile">
<section title=3D"IDXP Profile Overview">
<t>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 <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> SHOULD be used for this purpose; see <xref =
target=3D"refs.tunnel" /> for more detail concerning the options =
available to setup an application-layer tunnel using TUNNEL, and see =
<xref target=3D"security.tunnel" /> for a discussion of TUNNEL related =
security considerations. TUNNEL MUST be offered as a tuning profile for =
the creation of application-layer tunnels. The TUNNEL profile MUST =
offer the use of some form of SASL authentication (c.f., Section 4.1 of =
<xref target=3D"RFC3080" />). 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 <xref =
target=3D"connect" /> and <xref target=3D"security" />.</t>
<t>The IDXP profile supports several elements of interest:</t>
<t><list style=3D"symbols">
<t>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.</t>
<t>The "Option" element is used to convey optional channel =
parameters between peers during the exchange of "IDXP-Greeting" =
elements. This element is OPTIONAL.</t>
<t>The "IDMEF-Message" element carries the structured information =
to be exchanged between the peers.</t>
</list></t>
</section>
<section title=3D"IDXP Profile Identification and Initialization">
<t>The IDXP profile is identified as</t>
<t><list style=3D"empty">
<t>http://iana.org/beep/transient/idwg/idxp</t>
</list></t>
<t>in the BEEP "profile" element during channel creation.</t>
<t>During channel creation, "IDXP-Greeting" elements MUST be mutually =
exchanged between the peers. An "IDXP-Greeting" element MAY be =
contained within the corresponding "profile" element in the BEEP =
"start" element. Including an "IDXP-Greeting" element in the initial =
"start" element has exactly the same semantics as passing it as the =
first "MSG" message on the channel. If channel creation is successful, =
then before sending the corresponding reply, the BEEP peer processes =
the "IDXP-Greeting" element and includes the resulting response in the =
reply. This response will be an "ok" element or an "error" element. The =
choice of which element is returned is dependent on local provisioning =
of the peer.</t>
</section>
<section anchor=3D"IDXP-syntax" title=3D"IDXP Profile Message =
Syntax">
<t>BEEP messages in the profile MUST have a <xref =
target=3D"RFC2046">MIME Content-Type</xref> of "text/xml", =
"text/plain", or "application/octet-stream". The syntax of the =
individual elements is specified in <xref target=3D"idxp_dtd" /> and =
Section 5 of <xref target=3D"refs.IDMEF" />.</t>
</section>
<section anchor=3D"IDXP-semantics" title=3D"IDXP Profile Semantics">
<t>Each BEEP peer issues the "IDXP-Greeting" element using "MSG" =
messages. The "IDXP-Greeting" element MAY contain one or more "Option" s=
ub-elements, conveying optional channel parameters. Each BEEP peer then =
issues "ok" in "RPY" messages or "error" in "ERR" messages. (See =
Section 2.3.1 of <xref target=3D"RFC3080" /> for the definitions of the =
"error" and "ok" elements.) Based on the respective client/server roles =
negotiated during the exchange of "IDXP-Greeting" elements, the client =
sends data using "MSG" messages. Depending on the MIME Content-Type, =
this data may be an "IDMEF-Message" element, plain text, or binary. The =
server then issues "ok" in "RPY" messages or "error" in "ERR" =
messages.</t>
<section title=3D"The IDXP-GREETING Element">
<t>The "IDXP-Greeting" element serves to identify the analyzer or =
manager at one end of the BEEP channel to the analyzer or manager at =
the other end of the channel. The "IDXP-Greeting" element MUST include =
the role of the peer on the channel (client or server) and the <xref =
target=3D"RFC2396">Uniform Resource Identifier (URI)</xref> of the =
peer. Additionally, the "IDXP-Greeting" element MAY include the fully =
qualified domain name (c.f., <xref target=3D"RFC1034" />) of the peer. =
One or more "Option" sub-elements MAY be present.</t>
<t>An "IDXP-Greeting" element MAY be sent by either peer at any =
time. The peer receiving the "IDXP-Greeting" MUST respond with an "ok" =
(indicating acceptance), or an "error" (indicating rejection). A peer's =
identity and role on a channel and any optional channel parameters are, =
in effect, specified by the most recent "IDXP-Greeting" it sent that =
was answered with an "ok".</t>
<t>An "IDXP-Greeting" may be rejected (with an "error" element) =
under many circumstances. These include, but are not limited to, =
authentication failure, lack of authorization to connect under the =
specified role, the negotiation of an inadequate ciphersuite, or the =
presence of a channel option that must be understood but was =
unrecognized.</t>
<figure>
<preamble>For example, a successful creation with an embedded =
"IDXP-Greeting" might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1592 187
I: Content-Type: text/xml
I:
I: <start number=3D'1'>
I: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
I: <![CDATA[ <IDXP-Greeting uri=3D'http://example.com/alice'
I: role=3D'client' /> ]]>
I: </profile>
I: </start>
I: END
L: RPY 0 10 . 1865 91
L: Content-Type: text/xml
L:
L: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
L: <![CDATA[ <ok /> ]]>
L: </profile>
L: END
L: MSG 0 11 . 1956 61
L: Content-Type: text/xml
L:
L: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server' =
/>
L: END
I: RPY 0 11 . 1779 7
I: Content-Type: text/xml
I:
I: <ok />
I: END
</artwork>
</figure>
<figure>
<preamble>A creation with an embedded "IDXP-Greeting" that fails =
might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1776 185
I: Content-Type: text/xml
I:
I: <start number=3D'1'>
I: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
I: <![CDATA[ <IDXP-Greeting uri=3D'http://example.com/eve'
I: role=3D'client' /> ]]>
I: </profile>
I: </start>
I: END
L: RPY 0 10 . 1592 182
L: Content-Type: text/xml
L:
L: <profile uri=3D'http://iana.org/beep/transient/idwg/idxp'>
L: <![CDATA[
L: <error code=3D'530'>'http://example.com/eve' must first
L: negotiate the TLS profile</error> ]]>
L: </profile>
L: END
</artwork>
</figure>
</section>
<section title=3D"The OPTION Element">
<t>If 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 within =
an "IDXP-Greeting" element represents a request to enable an IDXP =
option on the channel being negotiated. See <xref =
target=3D"idxp_options" /> for a complete description of IDXP options =
and the "Option" element.</t>
</section>
<section title=3D"The IDMEF-MESSAGE Element">
<t>The "IDMEF-Message" element carries the information to be =
exchanged between the peers. See Section 5 of <xref =
target=3D"refs.IDMEF" /> for the definition of this element.</t>
</section>
</section>
</section>
<section anchor=3D"idxp_options" title=3D"IDXP Options">
<t>IDXP provides a service for the reliable exchange of data between =
intrusion detection entities. Options are used to alter the semantics =
of the service.</t>
<t>The specification of an IDXP option MUST define:</t>
<t><list style=3D"symbols">
<t>the identity of the option;</t>
<t>what content, if any, is contained within the option; and,</t>
<t>the processing rules for the option.</t>
</list></t>
<t>An option registration template (c.f. <xref target=3D"option_reg" =
/>) organizes this information.</t>
<t>An "Option" element is contained within an "IDXP-Greeting" element. =
The "IDXP-Greeting" element itself MAY contain one or more "Option" =
elements. The "Option" element has several attributes and contains =
arbitrary content:</t>
<t><list style=3D"symbols">
<t>the "internal" and the "external" attributes, exactly one of which =
MUST be present, uniquely identify the option;</t>
<t>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,</t>
<t>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.</t>
</list></t>
<t>The value of the "internal" attribute is the IANA-registered name =
for the option. If the "internal" attribute is not present, then the =
value of the "external" attribute is a URI or URI with a =
fragment-identifier. Note that a relative-URI value is not allowed.</t>
<t>The "mustUnderstand" attribute specifies whether the peer may ignore =
the option if it is unrecognized. If the value of the "mustUnderstand" =
attribute is "true", and if the peer does not recognize the option, =
then an error in processing has occurred. When absent, the value of the =
"mustUnderstand" attribute is defined to be "false".</t>
<section anchor=3D"priority_option" title=3D"The channelPriority =
Option">
<t><xref target=3D"priority_opt_reg" /> contains the IDXP option =
registration for the "channelPriority" option. This option contains a =
"channelPriority" element (c.f., <xref target=3D"priority_dtd" />).</t>
<t>By default, IDXP does not place any requirements on how peers =
should manage multiple IDXP channels. The "channelPriority" option =
provides a way for peers using multiple IDXP channels to request =
relative priorities for each channel. When sending an "IDXP-Greeting" =
element during the provisioning of an IDXP channel, the originating =
peer MAY request that the remote peer assign a priority to the channel =
by including an "Option" element containing a "channelPriority" =
element.</t>
<t>The "channelPriority" element has one attribute named =
"priority", of range 0..2147483647. This attribute is REQUIRED. Not =
coincidentally, this is the maximum range of possible BEEP channel =
numbers. 0 is defined to represent the highest priority, with relative =
priority decreasing as the "priority" value ascends.</t>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
C: MSG 1 17 . 1984 165
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C: <Option internal=3D'channelPriority'>
C: <channelPriority priority=3D'0' />
C: </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 17 . 2001 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
</figure>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
S: MSG 1 17 . 1312 194
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S: <Option internal=3D'channelPriority' mustUnderstand=3D'true'>
S: <channelPriority priority=3D'2147483647' />
S: </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 17 . 451 68
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'channelPriority' option was =
unrecognized</error>
C: END
]]></artwork>
</figure>
</section>
<section anchor=3D"type_option" title=3D"The streamType Option">
<t><xref target=3D"type_opt_reg" /> contains the IDXP option =
registration for the "streamType" option. This option contains a =
"streamType" element (c.f., <xref target=3D"st_dtd" />).</t>
<t>By default, IDXP provides no explicit method for categorizing =
channels. The "streamType" option provides a way for peers to request =
that a channel be categorized as a particular stream type. When sending =
an "IDXP-Greeting" element during the provisioning of an IDXP channel, =
the originating peer MAY request that the remote peer assign a stream =
type to the channel by including an "Option" element containing a =
"streamType" element.</t>
<t>The "streamType" element has one attribute named "type", with =
the possible values of "alert", "heartbeat", or "config". This =
attribute is REQUIRED. A value of "alert" indicates that the channel =
should be categorized as being used for the exchange of ID alerts. A =
value of "heartbeat" indicates that the channel should be categorized =
as being used for the exchange of heartbeat messages such as the =
"Heartbeat" element (c.f., Section 5 of <xref target=3D"refs.IDMEF" =
/>). A value of "config" indicates that the channel should be =
categorized as being used for the exchange of configuration =
messages.</t>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
C: MSG 1 21 . 1963 155
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C: <Option internal=3D'streamType'>
C: <streamType type=3D'alert' />
C: </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 21 . 1117 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
</figure>
<figure>
<preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
S: MSG 1 21 . 1969 176
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S: <Option internal=3D'streamType' mustUnderstand=3D'true'>
S: <streamType type=3D'config' />
S: </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 21 . 1292 63
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'streamType' option was unrecognized</error>
C: END
]]></artwork>
</figure>
</section>
</section>
<section anchor=3D"proto-reqs" title=3D"Fulfillment of IDWG =
Communications Protocol Requirements">
<t>The following lists the communications protocol requirements =
established in Section 5 of <xref target=3D"refs.IDWG-reqs" /> and, for =
each requirement, describes the manner in which it is fulfilled by =
IDXP.</t>
<t>The [protocol] MUST support reliable transmission of messages.</t>
<t><list style=3D"empty">
<t>IDXP operates over BEEP, which operates only over reliable =
connection-oriented transport protocols (e.g., TCP). In addition, BEEP =
peers communicate using a simple request-response protocol, which =
provides end-to-end reliability between peers.</t>
</list></t>
<t>The [protocol] MUST support transmission of messages between ID =
components across firewall boundaries without compromising =
security.</t>
<t><list style=3D"empty">
<t>The TUNNEL profile <xref target=3D"refs.tunnel" /> MUST be =
offered as an option for creation of application-layer tunnels to allow =
operation across firewalls. The TUNNEL profile SHOULD be used to =
provide an application-layer tunnel. The ability to authenticate hosts =
during the creation of an application-layer tunnel MUST be provided by =
the mechanism chosen to create such tunnels. A firewall may therefore =
be configured to authenticate all hosts attempting to tunnel into the =
protected network. If the TUNNEL profile is used, SASL (c.f., Section =
4.1 of <xref target=3D"RFC3080" />) MUST be offered as a mechanism by =
which hosts can be authenticated.</t>
</list></t>
<t>The [protocol] MUST support mutual authentication of the analyzer =
and the manager to each other.</t>
<t><list style=3D"empty">
<t>IDXP supports mutual authentication of the peers through the use =
of an appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security profiles that may 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.</t>
</list></t>
<t>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.</t>
<t><list style=3D"empty">
<t>IDXP supports confidentiality through the use of an appropriate =
underlying BEEP security profile. The TLS profile is an example a =
security profile 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. The =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses ephemeral =
Diffie-Hellman (DHE) with DSS signatures for key exchange and triple =
DES (3DES) and cipher-block chaining (CBC) for encryption. Stronger =
cipher suites are optional.</t>
</list></t>
<t>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.</t>
<t><list style=3D"empty">
<t>IDXP supports message integrity through the use of an =
appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security 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. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA =
cipher suite uses the Secure Hash Algorithm (SHA) for integrity =
protection using a keyed message authentication code. Stronger cipher =
suites are optional.</t>
</list></t>
<t>The [protocol] SHOULD be able to ensure non-repudiation of the =
origin of IDMEF messages.</t>
<t><list style=3D"empty">
<t>IDXP supports non-repudiation of session origin through the use =
of an
appropriate underlying BEEP security profile. An IDXP peer application =
MAY use
IDMEF content and/or BEEP session credentials to provide for =
non-repudiation of
message origin. The TLS profile is an example of a security profile =
that offers
non-repudiation of session origin through the
authentication of public-key certificates. TLS MUST be offered as a =
mechanism to
provide non-repudiation of session origin, and TLS SHOULD be used to =
provide
non-repudiation of session origin.</t>
</list></t>
<t>The [protocol] SHOULD resist protocol denial of service =
attacks.</t>
<t><list style=3D"empty">
<t>IDXP supports resistance to denial of service (DoS) attacks =
through the use of 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 is helpful to discard =
traffic arising from a non-authenticated source. BEEP peers MUST =
support the use of authentication in conjunction with any mechanism =
used to create application-layer tunnels. In particular, the use of =
some form of SASL authentication (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) MUST be offered to provide authentication in the =
use of the TUNNEL profile. See Section 7 of <xref =
target=3D"refs.tunnel" /> for a discussion of security considerations =
in the use of the TUNNEL profile.</t>
</list></t>
<t>The [protocol] SHOULD resist malicious duplication of =
messages.</t>
<t><list style=3D"empty">
<t>IDXP supports resistance to malicious duplication of messages =
(i.e., replay attacks) through the use of an appropriate underlying =
BEEP security profile. The TLS profile is an example of a security =
profile offering 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. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses =
cipher-block chaining (CBC) to ensure that even if a message is =
duplicated the cipher-text duplicate will produce a very different =
plain-text result. Stronger cipher suites are optional.</t>
</list></t>
</section>
<section title=3D"IDXP Option Registration Template" =
anchor=3D"option_reg">
<t>When an IDXP option is registered, the following information is =
supplied:</t>
<t>Option Identification: specify the NMTOKEN or the URI that =
authoritatively identifies this option.</t>
<t>Contains: specify the XML content that is contained within the =
"Option" element.</t>
<t>Processing Rules: specify the processing rules associated with the =
option.</t>
<t>Contact Information: specify the postal and electronic contact =
information for the author(s) of the option.</t>
</section>
<section title=3D"Initial Registrations">
<section anchor=3D"idxp-registration" title=3D"Registration: The IDXP =
Profile">
<t>Profile identification: http://iana.org/beep/transient/idwg/idxp</t>
<t>Messages exchanged during channel creation: "IDXP-Greeting"</t>
<t>Messages starting one-to-one exchanges: "IDXP-Greeting", =
"IDMEF-Message"</t>
<t>Messages in positive replies: "ok"</t>
<t>Messages in negative replies: "error"</t>
<t>Messages in one-to-many exchanges: none</t>
<t>Message syntax: c.f., <xref target=3D"IDXP-syntax" /></t>
<t>Message semantics: c.f., <xref target=3D"IDXP-semantics" /></t>
<t>Contact information: c.f., the "Authors' Addresses" section of this =
memo</t>
</section>
<section anchor=3D"port-registration" title=3D"Registration: The =
System (Well-Known) TCP port number for IDXP">
<t>Protocol Number: TCP</t>
<t>Message Formats, Types, Opcodes, and Sequences: c.f., <xref =
target=3D"IDXP-syntax" /></t>
<t>Functions: c.f., <xref target=3D"IDXP-semantics" /></t>
<t>Use of Broadcast/Multicast: none</t>
<t>Proposed Name: Intrusion Detection Exchange Protocol</t>
<t>Short name: idxp</t>
<t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
</section>
<section anchor=3D"priority_opt_reg" title=3D"Registration: The =
channelPriority Option">
<t>Option Identification: channelPriority</t>
<t>Contains: channelPriority (c.f., <xref target=3D"priority_dtd" =
/>)</t>
<t>Processing Rules: c.f., <xref target=3D"priority_option" /></t>
<t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
</section>
<section anchor=3D"type_opt_reg" title=3D"Registration: The =
streamType Option">
<t>Option Identification: streamType</t>
<t>Contains: streamType (c.f., <xref target=3D"st_dtd" />)</t>
<t>Processing Rules: c.f., <xref target=3D"type_option" /></t>
<t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
</section>
</section>
<section title=3D"The DTDs">
<section anchor=3D"idxp_dtd" title=3D"The IDXP DTD">
<t>The following is the DTD defining the valid elements for the IDXP =
profile</t>
<figure>
<artwork><![CDATA[
<!--
DTD for the IDXP Profile, as of 2002-01-08
Refer to this DTD as:
<!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC XXXX IDXP v1.0//EN">
%IDXP;
-->
<!-- Includes -->
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">
%BEEP;
<!ENTITY % IDMEF-Message PUBLIC "-//IETF//DTD RFC XXXX IDMEF =
v1.0//EN">
%IDMEF;
<!--
Profile Summary
BEEP profile http://iana.org/beep/transient/idwg/idxp
role MSG RPY ERR
=3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =
=3D=3D=3D
I or L IDXP-Greeting ok error
C IDMEF-Message ok error
-->
<!--
Entity Definitions
entity syntax/reference example
=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D
an authoritative identification
URI c.f., [RFC-2396] http://example.com
a fully qualified domain name
FQDN c.f., [RFC-1034] 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"> =20
<!--
The IDMEF-Message element conveys the intrusion detection
information that is exchanged. This element is defined in the
idmef-message.dtd
-->
<!-- End of DTD -->
]]></artwork>
</figure>
</section>
<section anchor=3D"priority_dtd" title=3D"The channelPriority Option =
DTD">
<t>The following is the DTD defining the valid elements for the =
channelPriority option</t>
<figure>
<artwork><![CDATA[
<!--
DTD for the channelPriority IDXP option, as of 2002-01-08
Refer to this DTD as:
<!ENTITY % IDXP-channelPriority PUBLIC
"-//IETF//DTD RFC XXXX IDXP-channelPriority v1.0//EN">
%IDXP-channelPriority;
-->
<!--
Entity Definitions
entity syntax/reference example
=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D
a priority number
PRIORITY 0..2147483647 1
-->
<!ENTITY % PRIORITY "CDATA">
<!ELEMENT channelPriority EMPTY>
<!ATTLIST channelPriority
priority %PRIORITY #REQUIRED>
<!-- End of DTD -->=20
]]></artwork>
</figure>
</section>
<section anchor=3D"st_dtd" title=3D"The streamType DTD">
<t>The following is the DTD defining the valid elements for the =
streamType option</t>
<figure>
<artwork><![CDATA[
<!--
DTD for the streamType IDXP option, as of 2002-01-08
Refer to this DTD as:
<!ENTITY % IDXP-streamType PUBLIC
"-//IETF//DTD RFC XXXX IDXP-streamType v1.0//EN">
%IDXP-streamType;
-->
<!--
Entity Definitions
entity syntax/reference example
=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
=3D=3D=3D=3D=3D=3D=3D
a stream type
STYPE (alert | heartbeat | config) "alert"
-->
<!ENTITY % STYPE (alert|heartbeat|config)>
<!ELEMENT streamType EMPTY>
<!ATTLIST streamType
type %STYPE #REQUIRED>
<!-- End of DTD -->
]]></artwork>
</figure>
</section>
</section>
<section title=3D"Reply Codes">
<figure>
<preamble>This section lists the three-digit error codes the IDXP =
profile may generate.</preamble>
<artwork>
code meaning
=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D
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, etc.)
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)
</artwork>
</figure>
</section>
<section anchor=3D"security" title=3D"Security Considerations">
<t>The IDXP profile is a profile of BEEP. In BEEP, transport security,
user authentication, and data exchange are orthogonal. Refer to Section =
8
of <xref target=3D"RFC3080" /> for a discussion of this. It is strongly =
recommended that those wanting to use the IDXP profile initially =
negotiate a BEEP security profile between the peers that offers the =
required security properties. The TLS profile SHOULD be used to provide =
for transport security. See <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications protocol =
requirements.</t>
<t>See <xref target=3D"trust" /> for a discussion of the trust =
model.</t>
<section anchor=3D"security.tunnel" title=3D"Use of the TUNNEL =
Profile">
<t>See <xref target=3D"proto-reqs" /> for IDXP's requirements on =
application-layer tunneling and the TUNNEL profile specifically. See =
Section 7 of <xref target=3D"refs.tunnel" /> for a discussion of the =
security considerations inherent in the use of the TUNNEL profile.</t>
</section>
<section title=3D"Use of Underlying Security Profiles">
<t>At present, the TLS profile is the only BEEP security profile =
known to meet all of the requirements set forth in Section 5 of <xref =
target=3D"refs.IDWG-reqs" />. When securing 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 <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications requirements =
through the use of an underlying security profile.</t>
</section>
</section>
</middle>
<back>
<references>
%include.reference.RFC.2396;
%include.reference.RFC.2119;
%include.reference.W3C.REC-xml;
<!-- %include.reference.I-D.ietf-idwg-idmef-xml; -->
<reference anchor=3D"refs.IDMEF">
<front>
<title>Intrusion Detection Message Exchange Format Data Model and =
Extensible Markup Language (XML) Document Type Definition</title>
<author initials=3D"D." surname=3D"Curry" fullname=3D"David Curry">
<organization>Merrill Lynch & Co.</organization>
</author>
<author initials=3D"H." surname=3D"Debar" fullname=3D"Herve Debar">
<organization>France Telecom R & D</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>
<!--
%include.reference.RFC.2246;
-->
%include.reference.RFC.2046;
<!--
<reference anchor=3D"refs.IAP" target=3D"draft-ietf-idwg-iap-03 (work =
in progress)">
<front>
<title>IAP: Intrusion Alert Protocol</title>
<author initials=3D"D." surname=3D"Gupta" fullname=3D"Dipankar Gupta">
<organization abbrev=3D"HP">Hewlett-Packard</organization>
</author>
<date month=3D"December" year=3D"2000" />
</front>
</reference>
-->
%include.reference.RFC.1034;
<!--
%include.reference.RFC.2222;
-->
<!--
<reference anchor=3D"refs.syslog" =
target=3D"draft-ietf-syslog-reliable-03 (work in progress)">
<front>
<title>Reliable Delivery for syslog</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<author initials=3D"M.T." surname=3D"Rose" fullname=3D"Marshall T. =
Rose">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date month=3D"January" year=3D"2001" />
</front>
</reference>
-->
<reference anchor=3D"refs.tunnel">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>
<!--
<reference anchor=3D"refs.tunnel" =
target=3D"draft-ietf-idwg-beep-tunnel-02 (work in progress)">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"23" month=3D"August" year=3D"2001" />
</front>
</reference>
-->
%include.reference.RFC.3080;
<!--
%include.reference.RFC.2629;
-->
<!-- %include.reference.I-D.ietf-idwg-requirements; -->
<reference anchor=3D"refs.IDWG-reqs">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>
<!--
<reference anchor=3D"refs.IDWG-reqs" =
target=3D"draft-ietf-idwg-requirements-05 (work in progress)">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"20" month=3D"February" year=3D"2001" />
</front>
</reference>
-->
</references>
<section anchor=3D"IANA" title=3D"IANA Considerations">
<t>The IANA registers "IDXP" as a standards-track BEEP profile, as =
specified in <xref target=3D"idxp-registration" />. The IANA changes =
the IDXP profile identification to "http://iana.org/beep/IDXP".</t>
<t>The IANA registers "idxp" as a TCP port number, as specified in =
<xref target=3D"port-registration" /></t>
<t>The IANA maintains a list of:</t>
<t><list style=3D"empty">
<t>IDXP options, c.f., <xref target=3D"option_reg"/>.</t>
</list></t>
<t>For this list, the IESG is responsible for assigning a designated =
expert to review the specification prior to the IANA making the =
assignment. As a courtesy to developers of non-standards track IDXP =
options, the mailing list idxp-java-users@lists.sourceforge.net may be =
used to solicit commentary.</t>
<t>The IANA makes the registrations specified in <xref =
target=3D"priority_opt_reg" /> and <xref target=3D"type_opt_reg" =
/>.</t>
</section>
<section title=3D"History of Significant Changes" anchor=3D"changes">
<t>The RFC Editor should remove this section and its corresponding =
TOC references prior to publication.</t>
<section title=3D"Significant Changes Since beep-idxp-04">
<t>Fixed two locations where we were referencing the wrong section =
of the requirements document.</t>
<t>Removed references to IP and the %IP attribute.</t>
<t>Modified part of Section 5 dealing with non-repudiation of =
message origin.</t>
<t>Modified Section 1.3 to further refine terminology.</t>
<t>Replaced all remaining references to "entities" with references =
to "peers".</t>
</section>
<section title=3D"Significant Changes Since beep-idxp-03">
<t>Modified references to Internet-Drafts to contain placeholders =
for their forthcoming RFC numbers.</t>
<t>Modified IDMEF formal public identifier (FPI) in the IDXP DTD to =
reflect the changes in draft-ietf-idwg-idmef-xml-06.</t>
<t>Modified IDXP FPI for the IDXP DTD to be more in line with the =
IDMEF FPI.</t>
</section>
<section title=3D"Significant Changes Since beep-idxp-02">
<t>Added IDXP option registration template and registered two =
initial options.</t>
<t>Indicated that the IANA should change the profile identification =
to "http://iana.org/beep/IDXP" upon adoption of IDXP as a =
standards-track BEEP profile.</t>
<t>Renamed the "Options" element to "Option" and allowed multiple =
"Option" sub-elements within an "IDXP-Greeting" element. Also added =
attributes to "Option" element.</t>
<t>Modified IANA profile registration and added TCP port number =
IANA registration.</t>
<t>Reordered some sections to improve the flow of the document.</t>
<t>Changed IDXP DTD identifier to be more IETF-like and removed =
URLs from ENTITY declarations.</t>
<t>Changed IDXP profile URI to fall under the =
"http://iana.org/beep/transient" namespace.</t>
<t>Modified <xref target=3D"terminology" /> to reference the =
requirements language specified by <xref target=3D"RFC2119" />.</t>
<t>Eliminated the use of the "endpoint" terminology, in favor of =
"peer".</t>
<t>Modified figures to make them more understandable.</t>
<t>Modified Sections 2, 3, and 4 to use the requirements language =
specified by <xref target=3D"RFC2119"/>.</t>
<t>Indicated that the RFC Editor should remove <xref =
target=3D"changes" /> and its corresponding TOC reference prior to =
publication.</t>
<t>Fixed several typos.</t>
</section>
<section title=3D"Significant Changes Since beep-idxp-01">
<t>Added new MUST and SHOULD language for use of TLS and TUNNEL =
profiles.</t>
<t>Modified the "IDXP-Greeting" element to include an "Options" =
sub-element.</t>
<t>Changed IDXP profile URI.</t>
</section>
<section title=3D"Significant Changes Since beep-idxp-00">
<t>Added <xref target=3D"proto-reqs" />, describing how IDXP =
fulfills the communication protocol requirements of the IDWG.</t>
<t>Moved IDXP profile registration to <xref target=3D"IANA" />.</t>
<t>Clarified the role that underlying BEEP security profiles must =
play.</t>
<t>Clarified how IDMEF messages fit into IDXP.</t>
<t>Clarified how the IDXP profile channels and BEEP sessions =
interact.</t>
<t>Made terminology clarifications and changes for overall =
consistency.</t>
</section>
</section>
<section title=3D"Acknowledgements">
<t>The authors gratefully acknowledge the contributions of Darren New, =
Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, and Paul =
Osterwald.</t>
</section>
</back>
</rfc>
------_=_NextPart_000_01C21276.996E2A90
Content-Type: application/octet-stream;
name="PGPexch.rtf.asc"
Content-Disposition: attachment;
filename="PGPexch.rtf.asc"
-----BEGIN PGP MESSAGE-----
Version: PGP 7.0.4
owGdVL+P3EQUXpJAJEQQQZQUjy1IIvassX37Q5vcRUv2LndSLpxyF0hhKczaz/Yk
szNmPF7v6nShSAP/ABJCCCRAVDTQUFBS0YaWHkpqGp7tzWqvoGGKkcfzfd9775s3
82nr5vkXX9i6+Pcb/5zIv7bfPP3i8rnRk9aXr783+PjPp9//9OznP5598tJre+/8
+uNnra+//fDCK9fufHXu1c8vHn/zy2+Xv3v45OkPF363rWqcBMbGbsBVLuopzBLX
63pBhHHMqllylbjM90+CWCtrJ5I+WBDnpcjzIA5TbnK0DEZGcHn9lDbd1WZmPvLW
IO+jibjiNcj7L9BS5/TSy8FMYPlYqGgzKEI3yLiJmsgegz1cwAExUi5lp9oieD3v
8RxyPUWbCpUAqaoEIyiFTcGmCAZjNKhCzEErmE+lYzDXhQnR0Sa5CfvjB4cbbJMI
UoLSIDXxDSSa2EYXSaOSF5OpsJDxBB3Yh5TPcMnsgkJu5IIC8WjRgUlhgZB5EVPc
vCHzKUJm9ETi1IFDiTxHSFFmDoys5WFK+YoG+uDgDjTZQazNKjmuoufhHHJBLQjM
1eP8rcaCY2KiMUSoEiSt4bpB9xWnyGA1hFrN0NgzuyFXV2ydPLTnZNbVe7u3fDZg
19rDyo68CFNAShwV1aWAG8MX6/xb1CI4t0NolkDjholDEJnZaseFlB7zem2IdHiX
bNhqR4bHdkOgjTdEVCYbE8SMvuYZ1dbeXhOZiiiSuP4nx9AKOkSuwlSTulDW6DZY
YSUJ71erqKghZ4Ts9nq+gZ484tZmaXDFY2cXK1QUSOH3WDAJ6NQsRaUWh3dRwS4K
lVuaggmrOloKhYSqL4DbpWBHOrYlNwhjnKHUWW3bjkoIh6YD9+BtGC9ZjOAfDKHX
HzjdQdfpD3pdmPf6Xg92h9DvM6e32XUGvuvCQYPq9z1n0/V6NZ/IA595MC5UqXW0
oLZyOnBUCIvge6xDnUXX2PIO3B6Bz/wug7IsnaSg6ignJ9TTpt6H/2dUNdOlbDK5
DfdhRKWNYQfuwnFT3tI41ti5srFxaYdaxmRG0DU4wrAwwi7qFj80YsZDqsXoxPBp
Xrm8Elo+BOtnSU9G618=
=RowR
-----END PGP MESSAGE-----
------_=_NextPart_000_01C21276.996E2A90--
- [xml2rfc] Re: IDXP xml problems Marshall Rose
- [xml2rfc] IDXP xml problems Benjamin.Feinstein@guardent.com