Internet Engineering Task Force                                     IDWG
Internet Draft                                                     Gupta
draft-ietf-idwg-iap-03.txt                               Hewlett-Packard
11 December 2000
Expires: 11 June, 2001


                     IAP: Intrusion Alert Protocol

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Abstract

Intrusion Alert Protocol (IAP) is an application--level protocol for
exchanging intrusion alert data between intrusion detection elements,
notably sensor/analyzers and managers across IP networks.  The proto-
col's design is compatible with the goals for the HyperText Transfer
Protocol (HTTP). The specification of alerts carried using this protocol
is described in a companion document of the intrusion detection working
group of the IETF.


1 Introduction

1.1 Purpose

The Intrusion Alert Protocol (IAP) is an application--level protocol for
exchanging intrusion alert data. The protocol is designed to provide the
necessary transport and security properties to allow sensitive alert



Gupta                                                         [Page 1]






Internet Draft                     IAP                  11 December 2000


data to be sent across IP networks. In addition, the protocol is
designed so that future extensions may use the application layer for
configuring intrusion detection sensor/analyzers or sending responses
(the current charter of the working group does not include configura-
tion).

1.2 Transport layer protocol

IAP uses the transmission control protocol (TCP) [1] as its underlying
transport layer mechanism. This protocol is used for a wide variety of
IP services. It has a number of features such as congestion avoidance,
slow start, etc. that enable it to work over large networks with a wide
variety of latency, bandwidth and congestion characteristics. TCP pro-
vides reliable and sequenced delivery of data between IP peers.

1.3 Terminology

Terminology is borrowed from [2].

1.4 Overall operation

IAP is primarily oriented towards supporting the transmission of alert
data from an intrusion detection sensor/analyser, which detects a poten-
tial intrusion, to a manager that displays it to a human, logs it to a
database or takes appropriate action.

In the simplest case, a sensor/analyser (SA) sends alerts to a man-
ager(M).



   SA  ------------------->  M



In a more complex situation, there are more than one intermediaries in
the communication path. Two common forms of intermediary are:

     Proxy: A proxy is a forwarding agent which MAY do some rewriting of
          the content, and forward the message. A proxy MAY be used to
          relay two connections when the communication needs to pass



Gupta                                                         [Page 2]





Internet Draft                     IAP                  11 December 2000


          through an intermediary such as a firewall.


     Gateway: A gateway is used to translate messages from/to some
          native format (such as SNMPv3 UDP wire protocol).

A proxy may be used to relay two connections when the communication
needs to pass through an intermediary such as a firewall.

An example of a connection with intermediaries is shown below:


  SA ----> P  -----> G ----> M


Here, IDMEF data is generated by SA and passed to a proxy P. P connects
to a gateway G, which translates alerts into a native format to be con-
sumed by the manager M. In this exchange, the connections between SA and
P, and P and G use IAP. The connection between G and M uses the native
protocol supported by M.

IAP communication takes place over an IP network using the transport
control protocol (TCP). To connect with other networks, gateways should
be used to transform protocol data into the native representation. It is
expected that the IANA will allocate a designated TCP port for IAP com-
munications.

1.5 Augmented BNF

We use the augmented BNF definitions of [3].

1.6 Protocol parameters

IAP uses a <major>.<minor> numbering scheme to indicate versions of the
protocol. The minor number is changed when updates to the protocol add
features that do not change the parsing algorithm. The major number is
changed when the parsing algorithm is modified.





Gupta                                                         [Page 3]





Internet Draft                     IAP                  11 December 2000


This document describes version 0.4 of IAP. The version string for this
is IAP/0.4, and is denoted by iap-version.

1.7 Media Types

IAP uses Internet Media Types [4] to denote the type of alert data.
Media types are used to define the encapsulation of data, in a manner
that can be extended without requiring changes to the application proto-
col. It is expected that the event data will be sent using the XML data
type definition in a companion document of the working group.

The only media type used by IAP/0.4 is application/xml. IAP entities
MUST accept data sent in this format.

2 IAP Communication Model

IAP communications occur on top of the transport control protocol (TCP).
The TCP connection carries request-response pairs much like the payload
of the HyperText Transfer Protocol (HTTP) [3].  The TCP connection MAY
be initiated by the analyzer SA or the manager M. This is to accommodate
security perimeter configurations that proscribe certain kinds of con-
nections - for instance, if the manager resides in an outsourcer's envi-
ronment whereas the analyzer is inside a protected network, perimeter
security needs of the protected network may be better served if the ana-
lyzer initiates the connection.

In order to accommodate this variation, the roles of IAP entities are
not determined by who initiates the TCP connection. This is in contrast
to HTTP where the client (user agent) always initiates the TCP connec-
tion.

Response codes are borrowed from the specification of version 1.1 of the
hypertext transfer protocol [3].

2.1 Why not HTTP?

HTTP/1.1 satisfies a number of needs of the application, but has a few
assumptions that make it difficult to use in-toto as the application
layer. The first is the assumption that the TCP connection initiator is
the HTTP client or requester in the request-response scheme - this pre-
cludes running the protocol "in reverse". A second issue is the inabil-
ity to give the proxy enough hints about the connection if the protocol
is being run over a TLS session, although there is ongoing work in that
direction. This draft uses the recommendations of that work, in particu-
lar the Upgrade: keyword and the CONNECT method as outlined in [5].

The protocol specifies the use of the CONNECT method to establish a
transparent tunnel between IAP peers. Intermediate proxies enable



Gupta                                                         [Page 4]





Internet Draft                     IAP                  11 December 2000


connectivity across security perimeters and issues with DNS resolution
limitations inside security perimeters. The use of HTTP protocol ele-
ments allows an IAP entity to provide virtual hosting thus allowing pub-
lic IPv4 addresses to be conserved while allowing security properties to
be established about the peers.

2.2 Request-Response

A configured IAP sensor/analyzer - manager pair MAY have two simultane-
ous active connections, one for analyzer-initiated flow and another for
manager-initiated flow. These active flows MUST be carried over
separate TCP connections.

An IAP entity MAY close a connection if it finds unexpected data from
its peer.

An analyzer MUST implement connections in which it sends the requests
once the channel setup is complete. It MAY choose to implement connec-
tions in which it responds to requests from a manager.

2.3 Phases

The protocol is divided into two major phases. The first (setup) phase
is a request-response protocol where requests are sent by the peer that
initiated the TCP connection. This establishes roles for the peers. The
two parties agree whether the connection will be used for request-
response pairs where the analyzer acts as the sender, or vice versa.

The second (data) phase is also a request-response session in which the
sender of requests may be reversed, based on the negotiations in the
first phase. If the connection is used for carrying payload initiated by
the analyzer, such as alerts, the requests will be from the analyzer.
Otherwise, they will be from the manager.

2.3.1 Proxies

An IDMEF entity in a proxy role does not have an IAP identity. It acts as
a relay of messages without understanding their content. It MAY do some
rewriting of the content, but in a manner that does not impact the secu-
rity properties of alerts.

3 IAP Setup Phase

This is the first phase after a TCP connection is in the established
state. In this phase, the two parties set up the transport parameters of
the protocol. An IAP entity in a proxy role MAY rewrite content to set
up the protocol in this phase. This phase uses a request--response form,
with the TCP connection initiator as requestor. The phase is divided



Gupta                                                         [Page 5]





Internet Draft                     IAP                  11 December 2000


into three subphases, where the TCP connection, security and channel
parameters are agreed upon by the peers.

3.1 TCP Setup

The TCP connection initiator issues an iap-connect-request command.

A corresponding peer MAY choose to accept this connection, and respond
using an iap-response command, with the status code set to 200 to denote
success. The pair can then proceed to the security setup section.

Alternatively, the entity MAY reject the connection request by setting
the status code to 4xx to denote failure. In particular, the 403 Forbid-
den command MAY be used by the responder.

An intermediate entity in a proxy role MAY, upon receiving the request,
rewrite the iap-connect-request command. A proxy MAY append a iap-proxy-
via line to the connection request before passing it on to the receiving
entity.

A proxy SHOULD relay the server's response back to the client after
appending a iap-proxy-via line. A proxy MUST verify that existing proxy-
via headers in the request don't match its own identity in order to
limit the damage from misconfigured proxies.  Otherwise, it MUST send a
bad gateway (502) response to the peer that requested the connection.

Any entities in a proxy role MUST forward data transparently once the
upgrade phase is reached. End entities detect any attempts to manipulate
or inject messages into the communications channel.

3.2 Security Setup

A single request--response pair is used to upgrade the security of a
connected transport. The initiator of the TCP connection upon receiving
an iap-response command without any errors, issues a iap-upgrade-request
command.

A server should expect the iap-upgrade-request command after sending an
iap-response reply indicating acceptance of the connection. The server
SHOULD terminate if the request is not received, or some other request
is received. Upon receiving the request, it SHOULD send an iap-response
reply with the status code set to 101 to indicate acceptance of the
upgrade.

It MAY also send a 500 to denote server configuration error, if for
instance, it is not yet configured and does not have a certificate.





Gupta                                                         [Page 6]





Internet Draft                     IAP                  11 December 2000


Once the TCP connection initiator receives an iap-response message indi-
cating success of its request to upgrade the security of the connection,
the parties initiate the TLS 1.0 handshake protocol [6]. This step nego-
tiates the protocol version, cryptographic algorithms, mutual authenti-
cation and generates shared secrets for the next phase. The TLS hand-
shake is initiated by the originator of the TCP connection (client)
which assumes the TLS client role. The connection initiator sends a TLS
client-hello message to initiate the handshake.

If the parties complete the TLS handshake protocol successfully, they
exchange final setup request--response pairs, using the TLS record pro-
tocol. These pairs are exchanged after a successful handshake and are
used by the parties to verify connection parameters. Once the TLS hand-
shake is completed successfully, the TCP connection initiator sends the
channel setup request.

3.3 Channel Setup

Data in the channel setup phase is send using the TLS record layer, and
is thus impervious to passive and active attacks. The purpose of this
phase is to verify the IAP version information and decide on the roles
each entity will take.

The TCP connection initiator sends the iap-channel-setup-request mes-
sage. The recipient then:

     + Verifies the version information against what it received during
       the protocol setup phase;

     + Checks that it is able to either accept requests from, or send
       requests to the peer

It then issues a iap-response reply to indicate its agreement with the
parameters specified by the TCP connection initiator.

The protocol, security and channel setup phases are now complete, and
the channel is ready to communicate data. The directionality of this
phase is dependent on the parameters agreed upon during channel setup.
Note that the channel, once set up, can be used for sending multiple
alerts. The parties can also implement some pooling method that tears
down connections after some period of no traffic, or some other pooling
strategy.

3.4 Secured data transport

This is the main phase of the protocol. In this phase, encoded IDMEF
alerts are sent by the sender (sensor/analyzer) to the receiver
(manager) over the TLS record layer.



Gupta                                                         [Page 7]





Internet Draft                     IAP                  11 December 2000


In addition to data in the form application/xml, compatible clients and
servers MAY send other data using this transport. A peer, upon receipt
of data that it is unable to decode (unknown IAP content type), SHOULD
reject the data. It MAY choose not to terminate the connection. This
allows clients (analyzers) supporting richer content types to communi-
cate with legacy servers (managers).

3.5 Termination

Termination can be initiated by either peer by sending a TLS close-
notify alert (section 7.2.1). The recipient, on receipt of this alert,
should in turn respond with a close-notify alert and the parties can
close the connection gracefully.

3.6 Example

In this example, an analyzer A is configured to connect to proxy P. P
connects to a manager M to deliver the alerts. The following diagram
depicts the abstract message flow for the case where there are no
errors, and a connection is set up to deliver alerts from A to M.


          A                        P                   M
[Setup Phase]

  --------------->
  iap-connect-request


                             --------------->
                             iap-connect-request

                                                <---------------
                                                iap-response

                     <---------------
                     iap-response

[proxy is now a transparent forwarding agent]

  --------------->
  iap-upgrade-request

                                                <---------------
                                                iap-response



Gupta                                                         [Page 8]






Internet Draft                     IAP                  11 December 2000


           (TLS handshake negotiation initiated by A)

[TLS handshake completed: data sent using the TLS record layer]

  --------------->
  iap-channel-setup-request

                                                <---------------
                                                iap-response


[Data Phase]

  --------------->
  iap-content-request

                                                <---------------
                                                iap-response




4 IAP Wire Protocol

IAP uses a subset of the HTTP/1.1 syntax to send IDMEF alerts. The
request--response protocol is modeled on HTTP. If a request or response
body is present, the entity generating it MUST use the Content-Length
header to denote the size of the body.

All requests must be responded to using an iap-response message indicat-
ing whether the recipient was able to successfully interpret (and act
on) the request. Response codes are borrowed from HTTP/1.1 with the same
interpretation.

4.1 Alert content

Alert content payload must be preceded by a header specifying the con-
tent length.

4.2 Syntax

In the wire protocol, requests and responses are terminated by a pair of
CRLF sequences, following HTTP/1.1. The following definitions from [3]
are used.




Gupta                                                         [Page 9]





Internet Draft                     IAP                  11 December 2000


     + HTTP-message

     + host

     + DIGIT

     + Chunked-Body

     + SPC

     + CRLF

An IAP message is denoted by iap-message.

  iap-message       = ( iap-request | iap-response )



An IAP request has a request header and an optional request body.


  iap-request       = iap-request-line
                      +(iap-message-header CRLF)
                      CRLF
                      [ iap-message-body ]

  iap-response
                    = iap-status-line
                      *(iap-message-header CRLF)
                      CRLF
                      [ iap-message-body ]

  iap-message-header=
                     message-header

  iap-message-body  = entity-body

  iap-request-line =



Gupta                                                        [Page 10]






Internet Draft                     IAP                  11 December 2000


     ( iap-connect-request |
       iap-upgrade-request |
       iap-channel-setup-request |
       iap-content-request )




In case the iap-message-body item is present in an IAP message, the Con-
tent-Length header is mandatory. In case of IAP requests, the Host mes-
sage header is mandatory.

The version of the protocol is denoted by iap-version.

  iap-version      = "IAP/0.4"


The role of the TCP connection initiator is specified by sender-
receiver:

  sender-receiver   = "Sender" | "Receiver"


By choosing the appropriate string, it signals whether it wants to send
requests to the peer or receive them from the peer.

4.3 Protocol messages

4.3.1 Responses

An iap-response denotes the status code returned by an IAP entity in
response to a request.



Gupta                                                        [Page 11]






Internet Draft                     IAP                  11 December 2000


  iap-status-line      = iap-version SP 3DIGIT CRLF



4.3.2 Connection Request

A iap-connect-request denotes a request message sent by an IAP client to
establish an IAP protocol connection.

  iap-connect-request
                    = iap-t-connect-request
                      ( iap-t-via )*

  iap-t-connect-request
                    = "CONNECT" SP host ":" port SP iap-version CRLF

  iap-t-via         = "Via:" SP host CRLF



4.3.3 Upgrade Request

An iap-upgrade-request contains a notification from the client that it
wishes to upgrade the security of the connection.


  iap-config-url = "/idmef/config/"

  iap-upgrade-request
                    = "PUT" SP iap-config-url SP iap-version CRLF
                      "Upgrade: TLS/1.0" CRLF



Gupta                                                        [Page 12]





Internet Draft                     IAP                  11 December 2000


4.3.4 Channel Setup

An iap-channel-setup request contains a notification requesting that the
peer verify the version of IAP being used.


  iap-channel-setup-request
                    = "PUT" SP iap-config-url SP iap-version CRLF
                      "IAP-Version: 0.4" CRLF
                      "IAP-Role: " sender-receiver CRLF


4.3.5 Alert Content

The iap-content-request message is an encoded alert sent using IAP.


  iap-content-request
                    = iap-t-content-headers

  iap-content-url   = "/iap/alert/"

  iap-t-content-headers
                    = "PUT" SP iap-content-url SP iap-version CRLF
                      iap-content-type
                      iap-transfer-encoding

  iap-content-type  = "Content-Type:" SP
                      "application/xml"
                      CRLF

  iap-transfer-encoding
                    = "Content-Length: " SP +DIGIT CRLF





Gupta                                                        [Page 13]





Internet Draft                     IAP                  11 December 2000


4.4 Example

Here is a transcript of a scenario in which an IDMEF sensor/analyzer A
wishes to send alerts to manager M. The proxy P mediates this connec-
tion. After the connection has been set up, A sends an IDMEF alert 3632
octets in length in an XML dialect.


          A                        P                   M
iap-connect-request
--------------->
CONNECT M.DOM.ORG:1443 IAP/0.4 CRLF
Host: M.DOM.ORG CRLF
CRLF
                     iap-connect-request
                     --------------->
                     CONNECT M.DOM.ORG:1443 IAP/0.4 CRLF
                     Host: M.DOM.ORG CRLF
                     Via: P.DOM.ORG CRLF
                     CRLF
                                                iap-response
                                                <---------------
                                                IAP/0.4 200 OK CRLF
                                                CRLF
                     iap-response
                     <---------------
                     IAP/0.4 200 OK CRLF
                     Via: P.DOM.ORG CRLF
                     CRLF

[proxy is now a transparent forwarding agent]
iap-upgrade-request
--------------->
PUT /iap/config/ IAP/0.4 CRLF
Upgrade: TLS/1.0 CRLF
Host: M.DOM.ORG CRLF
CRLF
                                                iap-response
                                                <---------------
                                                IAP/0.4 101 CRLF
                                                CRLF




Gupta                                                        [Page 14]





Internet Draft                     IAP                  11 December 2000


                     (TLS handshake negotiation)

[TLS handshake completed: data sent using the TLS record layer]
iap-version-verify
--------------->
PUT /iap/config/ IAP/0.4 CRLF
IAP-Version: 0.4 CRLF
IAP-Role: Sender CRLF
Host: M.DOM.ORG CRLF
CRLF
                                                iap-response
                                                <---------------
                                                IAP/0.4 200 CRLF
                                                CRLF


iap-content
--------------->
PUT /iap/event IAP/0.4 CRLF
Content-Type: application/xml CRLF
Content-Length: 3632 CRLF
Host: M.DOM.ORG CRLF
CRLF
<?xml version="1.0" encoding="UTF-8"?>

   <!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.1//EN"
     "idmef-message.dtd">

   <IDMEF-Message version="0.1">
     <Alert alertid="1234567890" impact="attempted-user">
       <Time offset="-0500">
         <ntpstamp>0x12345.0x67890</ntpstamp>
         <date>2000/03/09</date>
         <time>22:18:07</time>
       </Time>
       <Analyzer ident="999888777.1">
         <Node category="dns">
           <name>dialserver.bigcompany.com</name>
         </Node>
       </Analyzer>
       <Classification origin="vendor-specific">
         <name>out-of-hours activity</name>
         <url>http://my.company.com/policies</url>
       </Classification>
       <Source>
         <Node>
           <Address category="ipv4-addr">
             <address>127.0.0.1</address>



Gupta                                                        [Page 15]





Internet Draft                     IAP                  11 December 2000


           </Address>
         </Node>
       </Source>
       <Target>
         <Node category="dns">
           <name>mainframe.bigcompany.com</name>
         </Node>
         <User category="os-device">
           <name>louis</name>
           <uid>501</uid>
         </User>
         <Service>
           <name>login</name>
           <dport>23</dport>
           <sport>4235</sport>
         </Service>
       </Target>
       <AdditionalData type="time" meaning="start-time">
         07:00:00
       </AdditionalData>
       <AdditionalData type="time" meaning="stop-time">
         19:30:00
       </AdditionalData>
     </Alert>
   </IDMEF-Message>

                                                iap-response
                                                <---------------
                                                IAP/0.4 200 CRLF
                                                CRLF



5 Scenarios

5.1 Simple analyzer

A simple analyzer can only initiate connections, and only be able to
connect with a single manager at a time. In this case, the analyzer's
configuration is expected to include the manager's IP address and a
specification of the manager's certificate (such as the signer's public
key and patterns in the common name or organizational unit).

The analyzer would initiate the TCP session. As a result, any firewalls
in the path MUST be configured to let through traffic initiated by the



Gupta                                                        [Page 16]





Internet Draft                     IAP                  11 December 2000


analyzer(s) with the manager's IP address and IAP destination port as
the other endpoint of the session.

5.2 Simple analyzer with proxy

If perimeter security demands that a proxy be deployed, the analyzer
should be configured with the proxy's IP address. The proxy would then
establish a connection to the manager, and forward traffic between the
two connections. The proxy's configuration would include the manager's
address. Note that the proxy does not participate in the TLS handshake
and does not need TLS related configuration parameters.

5.3 Manager design considerations

The protocol is oriented to allow lightweight implementation of sen-
sor/analyzers. A manager MUST accept TCP connections from multiple sen-
sor/analyzers by listening on the IAP port.

6 Implementation Considerations

6.1 TCP connection initiation

The entity that initiates a TCP connection will be variable, and depen-
dent on the exact deployment model. One scenario is that of sensor/ana-
lyzers outside a security perimeter, with the manager inside. In such
configurations, the manager MAY initiate the connection in line with
perimeter security requirements.

Another scenario is that of remote sensor/analyzers being managed by a
service provider. In this case, the sensor/analyzer MAY contact a proxy
on the perimeter, which in turn connects to the remote manager in a ser-
vice provider's network.

The communications protocol should allow chained proxies to carry IAP
data across multiple security perimeters.

6.2 Urgent data

Urgent data at the TCP layer MUST NOT be used by an entity using IAP.
Endpoints MUST ignore urgent data and MAY choose to terminate a connec-
tion upon receipt of urgent data, because this data is not protected by
TLS and could be forged.

6.3 TLS/1.0 protocol

The TLS 1.0 protocol MUST be used. An IDMEF entity MUST not allow older
protocol HELLO messages, and reject attempts to negotiate an older ver-
sion of the protocol. The following TLS ciphersuite MUST be supported in



Gupta                                                        [Page 17]





Internet Draft                     IAP                  11 December 2000


line with recommendations from the tls working group:

     + TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA

The recommendations in sections 2.1 and 2.2 of [7] must be followed by
IAP client and server implementations.

6.4 Mandatory certificates

In line with the requirement for strong mutual authentication, certifi-
cates for sensor/analyzers acting in an IAP client role and for managers
acting in an IAP server role are mandatory. Each entity should verify
the peer's certificate during the TLS handshake in accordance with the
administrative domain's certificate verification policies.

6.5 Certificate conventions

One or more of the following extended key usage extensions MUST be spec-
ified in X.509v3 certificates issued to an IAP client or server entity:

     + IAP_ALERT_GENERATOR

     + IAP_ALERT_CONSUMER

     + IAP_IDMEF_CONFIGURATOR

The object identifiers (OIDs) for these extensions will be specified in
a companion document. The presence of the extension means that the
signer believes that the holder of the certificate is allowed to func-
tion in the corresponding IAP role.

An entity in a IAP server role MUST have the IAP_ALERT_CONSUMER exten-
sion in its certificate. Similarly, an entity in a IAP client role MUST
have the IAP_ALERT_GENERATOR extension in its certificate.

6.6 Verification of peer identity

As the peer identity is initially sent in the clear, it is essential
that the IAP client and server entities verify the identity of their
peer using criteria based on their public key certificates.  Implemen-
tors SHOULD adopt prudent security practice and reject certificates that
are not in accordance with the installation's configuration. For
instance, they may wish to verify subfields of the peer's identity, such
as the Organizational Unit, in addition to verifying the correctness of
the signature and the signer's identity.

The version of the protocol MUST be verified during the channel setup
phase to stop protocol downgrade attacks. The mechanism specified in



Gupta                                                        [Page 18]





Internet Draft                     IAP                  11 December 2000


section 2.4 of [7] for verifying peer certificates must be followed.

6.7 TLS session resumption

The entities MUST be configured to support TLS session resumption.
Because of the possibility of external entities maliciously terminating
IAP sessions, clients and servers MAY attempt to resume a session if the
TLS close-notify alert was not received before the transport closed.

7 Security Considerations

As IAP is intended to be used for carrying security--sensitive data, we
will list a number of security considerations.

7.1 Reliable and sequenced delivery

Although reliable and sequenced delivery can be built on top of UDP,
this usually reimplements some of the protocol features of TCP.  Certain
deployment scenarios may prefer fast unreliable delivery with the man-
ager doing a "best effort" attempt to keep up with the flow of alerts.
This proposal does not address such a scenario. One potential alterna-
tive for this scenario is to use the SNMP trap as a means to represent
the alert. We remark that the above scenario is at odds with a number of
items in section 6 of the requirements document of the working group. In
addition, the use of UDP-based protocols is likely to result in unre-
sponsive or aggressive flows which further exacerbate the congestion
problem in the internet.

7.2 TCP handshake

TCP uses a three--message handshake mechanism to set up connections.
This opens the protocol up to certain well-known denial of service
attacks. This protocol does not address this vulnerability. The effect
of such attacks can be mitigated by a number of techniques, including:

     + restricting the set of peer IP addresses allowed to connect to
       the node.

     + restricting the number of open connections permitted to each
       known peer.

     + restricting the number of open connections permitted to subsets
       of known peers.

7.3 Key Management

For a public--key based communications model to be useful, good key man-
agement principles must be used for the lifecycle of public key



Gupta                                                        [Page 19]





Internet Draft                     IAP                  11 December 2000


certificates. The pkix working group of the IETF is defining mechanisms
that can be used for this purpose [8].

7.4 Message length

Traffic analysis may allow an observer to induce the type of alert from
the size of the message. If this is a threat, IDMEF entities SHOULD pad
their data so that it observes some known distribution over time.

7.5 Proxy considerations

As the proxy transparently forwards encrypted traffic after connections
are established, it is prudent to deploy the proxy in a manner that it
will not be used to violate the perimeter security policy. For instance,
a proxy may only accept requests from connections on its inside inter-
face to known locations outside the security perimeter.

8 Acknowledgements

This document makes heavy use of prior work in the IETF on HTTP, MIME
and TLS. Their effort is gratefully acknowledged. Members of the IETF's
intrusion detection working group (idwg) have made extensive comments
that are reflected in the draft.

9 Bibliography

[1] J. Postel, "Transmission control protocol," Request for Comments
(Standard) 793, Internet Engineering Task Force, Sept. 1981.

[2] M. Wood, "Intrusion detection exchange format requirements," inter-
net draft (work in progress), Internet Engineering Task Force, Oct.
1999.

[3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,
and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," Request
for Comments (Draft Standard) 2616, Internet Engineering Task Force,
June 1999.

[4] N. Borenstein and N. Freed, "MIME (multipurpose internet mail exten-
sions): Mechanisms for specifying and describing the format of internet
message bodies," Request for Comments (Proposed Standard) 1341, Internet
Engineering Task Force, June 1992.

[5] M. Khare and S. Lawrence, "Upgrading to TLS within HTTP/1.1,"
Request for Comments (Standards Track) 2595, Internet Engineering Task
Force, May 2000.





Gupta                                                        [Page 20]





Internet Draft                     IAP                  11 December 2000


[6] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request for
Comments (Proposed Standard) 2246, Internet Engineering Task Force, Jan.
1999.

[7] C. Newman, "Using TLS with IMAP, POP3 and ACAP," Request for Com-
ments (Proposed Standard) 2595, Internet Engineering Task Force, June
1999.

[8] C. Adams and S. Farrell, "Internet X.509 public key infrastructure
certificate management protocols," Request for Comments (Standards
Track) 2510, Internet Engineering Task Force, Mar. 1999.

A Author's Address

Dipankar Gupta
Hewlett-Packard
3404 E Harmony Road, MS A2
Fort Collins, C0 80525, USA
Fax: +1(970)898-3077
Email: dg@fc.hp.com

B Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or ref-
erences to the Internet Society or other Internet organizations, except
as needed for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages other
than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE.




Gupta                                                        [Page 21]





Internet Draft                     IAP                  11 December 2000


                           Table of Contents


1          Introduction  . . . . . . . . . . . . . . . . . . . . . .   1
1.1        Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   1
1.2        Transport layer protocol  . . . . . . . . . . . . . . . .   2
1.3        Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
1.4        Overall operation . . . . . . . . . . . . . . . . . . . .   2
1.5        Augmented BNF . . . . . . . . . . . . . . . . . . . . . .   3
1.6        Protocol parameters . . . . . . . . . . . . . . . . . . .   3
1.7        Media Types . . . . . . . . . . . . . . . . . . . . . . .   4
2          IAP Communication Model . . . . . . . . . . . . . . . . .   4
2.1        Why not HTTP?   . . . . . . . . . . . . . . . . . . . . .   4
2.2        Request-Response  . . . . . . . . . . . . . . . . . . . .   5
2.3        Phases  . . . . . . . . . . . . . . . . . . . . . . . . .   5
2.3.1      Proxies . . . . . . . . . . . . . . . . . . . . . . . . .   5
3          IAP Setup Phase . . . . . . . . . . . . . . . . . . . . .   5
3.1        TCP Setup . . . . . . . . . . . . . . . . . . . . . . . .   6
3.2        Security Setup  . . . . . . . . . . . . . . . . . . . . .   6
3.3        Channel Setup . . . . . . . . . . . . . . . . . . . . . .   7
3.4        Secured data transport  . . . . . . . . . . . . . . . . .   7
3.5        Termination . . . . . . . . . . . . . . . . . . . . . . .   8
3.6        Example . . . . . . . . . . . . . . . . . . . . . . . . .   8
4          IAP Wire Protocol . . . . . . . . . . . . . . . . . . . .   9
4.1        Alert content . . . . . . . . . . . . . . . . . . . . . .   9
4.2        Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   9
4.3        Protocol messages . . . . . . . . . . . . . . . . . . . .  11
4.3.1      Responses . . . . . . . . . . . . . . . . . . . . . . . .  11
4.3.2      Connection Request  . . . . . . . . . . . . . . . . . . .  12
4.3.3      Upgrade Request . . . . . . . . . . . . . . . . . . . . .  12
4.3.4      Channel Setup . . . . . . . . . . . . . . . . . . . . . .  13
4.3.5      Alert Content . . . . . . . . . . . . . . . . . . . . . .  13
4.4        Example . . . . . . . . . . . . . . . . . . . . . . . . .  14
5          Scenarios . . . . . . . . . . . . . . . . . . . . . . . .  16
5.1        Simple analyzer . . . . . . . . . . . . . . . . . . . . .  16
5.2        Simple analyzer with proxy  . . . . . . . . . . . . . . .  17
5.3        Manager design considerations . . . . . . . . . . . . . .  17
6          Implementation Considerations . . . . . . . . . . . . . .  17
6.1        TCP connection initiation . . . . . . . . . . . . . . . .  17
6.2        Urgent data . . . . . . . . . . . . . . . . . . . . . . .  17
6.3        TLS/1.0 protocol  . . . . . . . . . . . . . . . . . . . .  17
6.4        Mandatory certificates  . . . . . . . . . . . . . . . . .  18
6.5        Certificate conventions . . . . . . . . . . . . . . . . .  18
6.6        Verification of peer identity . . . . . . . . . . . . . .  18
6.7        TLS session resumption  . . . . . . . . . . . . . . . . .  19
7          Security Considerations . . . . . . . . . . . . . . . . .  19
7.1        Reliable and sequenced delivery . . . . . . . . . . . . .  19
7.2        TCP handshake . . . . . . . . . . . . . . . . . . . . . .  19



Gupta                                                        [Page 22]





Internet Draft                     IAP                  11 December 2000


7.3        Key Management  . . . . . . . . . . . . . . . . . . . . .  19
7.4        Message length  . . . . . . . . . . . . . . . . . . . . .  20
7.5        Proxy considerations  . . . . . . . . . . . . . . . . . .  20
8          Acknowledgements  . . . . . . . . . . . . . . . . . . . .  20
9          Bibliography  . . . . . . . . . . . . . . . . . . . . . .  20
A          Author's Address  . . . . . . . . . . . . . . . . . . . .  21
B          Full Copyright Statement  . . . . . . . . . . . . . . . .  21












































Gupta                                                        [Page 23]