One document matched: draft-yang-scxp-01.txt
Differences from draft-yang-scxp-00.txt
INTERNET-DRAFT Yixian Yang
Expires: June 2004 Jie Chang
Yonggang Chu
Beijing University of
Posts and Telecom.
December 2003
The Security Components Exchange Protocol(SCXP)
draft-yang-scxp-01.txt
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 June also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and June 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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
At present, various security components have appeared. All the
security components should work together to establish a stronger
defense architecture in the future, so it is necessary for these
components to communicate with each other. This document describes
the Security Components Exchange Protocol (SCXP), an
application-level protocol for exchanging data between security
components. SCXP supports mutual-authentication, integrity,
confidentiality and replay protection over a connection-oriented
protocol.
Yixian Yang, et al. Expires June, 2004 [Page 1]
INTERNET-DRAFT The SCXP December, 2003
Table of contents
Status of This Memo ......................................... 1
Abstract .................................................... 1
1. Introduction .......................................... 3
2. Document Terminology .................................. 4
3. Basic Model ........................................... 5
3.1 Communication ......................................... 5
3.2 Data Exchange Patterns ................................ 7
3.2.1 One-way exchange ...................................... 7
3.2.2 response-request exchange ............................. 8
4. The SCXP Profile ...................................... 9
4.1 SCXP Profile Overview ................................. 9
4.2 SCXP Profile Identification and Initialization ........ 9
4.3 SCXP Profile Message Syntax ........................... 9
4.4 SCXP Profile Message Semantics ........................ 10
4.4.1 The Hello Element ..................................... 10
4.4.2 The content Element ................................... 12
5. SCXP Options .......................................... 13
5.1 The channelContent Option ............................. 14
5.2 The channelPRI Option ................................. 16
5.3 The extension of SCXP option .......................... 17
5.4 SCXP Option Registration Template ..................... 17
6 IANA Considerations ................................... 18
6.1 Registration: the SCXP Profile ........................ 18
6.2 Registration: The System (Well-Known) TCP port number
for SCXP .............................................. 18
6.3 Registration: the channelContent Option ............... 18
6.4 Registration: the channelPRI Option ................... 19
7. The SCXP DTDs ......................................... 20
7.1 The SCXP DTD .......................................... 20
7.2 The channelType Option DTD ............................ 21
7.3 The channelPRI Option DTD ............................. 22
8. Reply Codes ........................................... 23
9. Security Considerations ............................... 24
9.1 Mutual-authentication of the identity ................. 24
9.2 Message confidentiality ............................... 24
9.3 Message integrity ..................................... 24
9.4 Replay protection ..................................... 24
9.5 Minimizing protocol denial of service threat .......... 25
9.6 Summary of Recommended Security Implementation ........ 25
10. References ............................................ 26
11. Authors' Addresses .................................... 27
12. Acknowledgements ...................................... 27
Full Copyright Statement .................................... 27
Yixian Yang, et al. Expires June, 2004 [Page 2]
INTERNET-DRAFT The SCXP December, 2004
1. Introduction
This document describes an application-level protocol for supporting
the interaction between security components. SCXP is designed on
Blocks Extensible Exchange Protocol (BEEP)[1], and it can be looked
upon a profile of BEEP in a way. BEEP is a generic application
protocol framework for connection-oriented, asynchronous
interactions. Within BEEP, features such as authentication, privacy,
and reliability through retransmission are provided.
A chief objective of this protocol is to exchange data between
security components. In details, the main characteristics of SCXP
include:
- Reliable: SCXP runs over BEEP, which runs only over reliable
connection-oriented transport protocols (e.g., TCP). Therefore,
no additional mechanisms are necessary for reliable exchange of
data between security components.
- Able to carry SCIMF[8] messages, unstructured text, and binary
data: Although SCXP is mainly intended for exchanging SCIMF[8]
messages created by security components, it also can be used to
delivery unstructured text and binary data.
- Support two message exchange patterns: SCXP specifies two types
of message exchange pattern: one-way and request-response
exchange.
- Able to provide a set of security properties: Considering the
sensitivity of exchanges between security components, SCXP uses
underlying BEEP security profiles to offer the required security
properties, such as mutual authentication, confidentiality, replay
protection, and message integrity and so on. Further, SCXP also
can minimize the denial of service threats. See section 9 for
more discussion of security considerations.
SCXP inherits the design idea of IDXP[9]. SCXP has improved IDXP
and extends its application.
Yixian Yang, et al. Expires June, 2004 [Page 3]
INTERNET-DRAFT The SCXP December, 2004
2. Document Terminology
The term "security components" means a set of components which serve
for the security of a network or a system, such as intrusion
detection system, firewall, anti-virus software, scanner, router,
Honeypot, Log audit, netmanager and so on.
The term "intrusion detection system" is abbreviated as "IDS".
The terms "peer", "initiator", "listener", "client", and "server",
and the characters "I", "L", "C", and "S" are used in the context of
BEEP [1]. In particular, Section 2.1 of BEEP discusses the roles
that a BEEP peer June perform.
The term "Document Type Declaration" is abbreviated as "DTD" and is
defined in Section 2.8 of the Extensible Markup Language (XML) [3].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "June", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
Yixian Yang, et al. Expires June, 2004 [Page 4]
INTERNET-DRAFT The SCXP December, 2003
3. Basic model
Security Components using SCXP to exchange data are termed SCXP
peers. A pair of SCXP peers respectively play a client or server role
during the data exchange. The client means the SCXP peer that starts
an exchange, similarly, the other SCXP peer is termed the server.
It should be noted that the role a SCXP peer acting as is just
relevant to a specific BEEP channel on which it is communicating with
the other SCXP peer. A security component can serve as a client and
a server, all at once, if so configured. For example, one IDS can
serve as a client to send interactive command to the firewall on one
BEEP channel, meanwhile, it also can serve as a server to receive
alert messages from antivirus software on other BEEP channel, it even
can serve as a server to receive alert messages from that firewall on
another BEEP channel.
3.1 Communication
When a pair of SCXP peers need to exchange data, they SHOULD
establish a BEEP session at first. A BEEP session can map onto an
underlying transport service. [4] has specified how a single BEEP
session maps onto a TCP connection. When a BEEP session is
established, the listener MUST listen a well-known TCP port number,
and the initiator is responsible for initiating a connection to the
listener. Then a BEEP security profile which can provide the required
security properties (i.e. authentication and confidentiality) SHOULD
be negotiated. Once the BEEP security profile is successful, the pair
of SCXP peers can open a SCXP channel. When a SCXP channel is
created, SCXP profile MUST be negotiated while the initiating
messages (the "hello" element defined in section 4.1.1) are
exchanged. Following the successful creation of SCXP channel, the
SCXP peer in the client role can initiate the exchange of data on
the channel.
Figure 3-1 illustrates the process that a SCXP peer establishes
communication with the other SCXP peer:
Ellen Tom
| -------------- xport connect -------------->|
|<----------------- greeting ---------------->|
|<----------- negotiate security profile ---->|
|<----------------- greeting ---------------->|
|<----------- negotiate SCXP profile -------->|
| ------------------ data ------------------->|
figure 3-1 the establishment of the communication between SCXP peers
Here Ellen initiates a transport connection to Tom, triggering the
exchange of BEEP greeting message, then a BEEP session is established,
followed by the negotiation of the use of the BEEP security profile.
Upon completion of the negotiation process, the two peers exchange
Yixian Yang, et al. Expires June, 2004 [Page 5]
INTERNET-DRAFT The SCXP December, 2003
BEEP greeting message again. At last, the two peers negotiate the use
of SCXP profile, followed by the start of data transfer.
BEEP allows multiple data exchange channels to be simultaneously in
use over a single BEEP session, so multiple SCXP channels June be
reated to facilitate categorizing and rating the data transferring
between SCXP peers. Figure 3-2 illustrates a case in which a pair of
SCXP peers open three BEEP channels using SCXP profile and the client
sends different type messages to the server on each channel.
Therefore, the server can deal with the messages from different
channel respectively, depending on the messages type transferred on
the channel. Furthermore, each channel also can be rate in the form of
priority and security level.
+------+ +-------+
| | | |
| |*************** BEEP session *************** | |
| | | |
| |- channel 1 (SCXP profile), alert message ->| |
| Client |- channel 2 (SCXP profile), status message ->| Server |
| |- channel 3 (SCXP profile), other messages ->| |
| | | |
| |*********************************************| |
| | | |
+------+ +-------+
figure 3-2 multi-channel illustration
In addition, multiple BEEP sessions can be established between a pair
of SCXP peers. If desired, additional BEEP sessions can be created to
provide more channels using the SCXP profile. However, in most
situations, we suggest that additional channels be created on an
existing BEEP session, instead of establishing a new BEEP session to
create the additional channels using the SCXP profile.
Either SCXP peer which is communicating June request to close a SCXP
channel. When a SCXP peer wants to close a channel, it sends a
"close" element on channel zero (which is used to channel management)
indicating which channel it wants to close. If the other SCXP peer
accepts the request to close the channel, it will send an "ok"
message. Similarly, A SCXP peer also June request to release a whole
BEEP session by sending a "close" element indicating that it wants to
close channel zero. See section 2.3.1.3 of [1] for more details on
how to close a BEEP channel and session.
In general, a BEEP session containing SCXP channels is relatively
persistent so that the overhead of negotiating a BEEP security
profile can be avoided. The idle SCXP channel without data exchange
can also hold to avoid the repeated overhead of SCXP channel
provisioning (i.e. the exchange of initiating message of the
channel). However, SCXP peers still June request to close and recreate
a BEEP session or/and a SCXP channel as they need. For example, if a
BEEP session is always idle, and a SCXP peer hasní¯t received the
required state message from the other SCXP peer for a long time, the
Yixian Yang, et al. Expires June, 2004 [Page 6]
INTERNET-DRAFT The SCXP December, 2003
SCXP peer June consider to close the whole BEEP session.
3.2 Message exchange pattern
All exchanges occur in the context of a channel in BEEP. When a SCXP
channel is created between a pair of SCXP peers, the two peers can
deliver data on the channel as respective role (server or client).
SCXP supports two types of message exchange pattern:
3.2.1 one-way exchange
In this pattern, the client sends data to the server, using "MSG"
messages. When the server receives the data, it immediately processes
the data. If the server accepts the data, it issues "ok" in "RPY"
messages (see figure 3-3); if the server refuses the data, it issues
"error" in "ERR" messages.
+--------+ +--------+
| | +++++++ BEEP session +++++++++ | |
| | *** channel (SCXP profile) *** | |
| | --------- MSG(data) ---------> | |
| Client | | Server |
| | <-------- RPY(ok) ------------ | |
| | ****************************** | |
| | ++++++++++++++++++++++++++++++ | |
+----------+ +--------+
figure 3-3 one-way exchange
One-way exchange can be used to send a message (usually a SCIMF[8]
message) which doesní¯t require the receiver to return a
corresponding SCIMF message . For example, one SCXP peer can send
alert messages to the other SCXP peer using this pattern.
Yixian Yang, et al. Expires June, 2004 [Page 7]
INTERNET-DRAFT The SCXP December, 2003
3.2.2 request-response exchange
In this pattern, the client sends a command message (usually a SCIMF
message) to the server, using "MSG" messages. When the server
receives the data, it immediately processes the data. If the server
accepts the command, it will perform the corresponding operation as
the command requires and send back a reply message (usually a SCIMF
message) that contains the result of operation, using "RPY" messages
(see figure 3-4); if the server refuses the command, it issues
"error" in "ERR" messages.
+--------+ +--------+
| | ++++++++ BEEP session ++++++++ | |
| | *** channel (SCXP profile) *** | |
| | -------- MSG(command) -------> | |
| Client | | Server |
| | <------- RPYú¿replyú¨--------- | |
| | ****************************** | |
| | ++++++++++++++++++++++++++++++ | |
+--------+ +--------+
figure 3-4 request-response exchange
Request-response exchange can be used to send a command message which
requires the receiver to return a corresponding structured message
containing the process result . For example, a IDS commands a
firewall to perform a response action, such as blocking and refusing,
and requires the firewall to return the result of the action.
Yixian Yang, et al. Expires June, 2004 [Page 8]
INTERNET-DRAFT The SCXP December, 2003
4. The SCXP Profile
4.1 SCXP Profile Overview
The SCXP profile is designed for the reliable message exchange
between security components. Additionally, BEEP security profile
SHOULD be used to offer the required assurance of mutual
authentication, integrity, confidentiality and replay protection and
so on.
The SCXP profile supports the following three elements of interest:
- the "hello" element : identifying the SCXP peer at the end of a
BEEP channel to the other SCXP peer at the other end of the
channel, and indicating the function type of the security
component.
- the "option" element : delivering one or more optional channel
options and included in the "hello" element.
- the "content" element : carrying the SCIMF[8] messages exchanged
between the two peers.
4.2 SCXP Profile Identification and Initialization
The SCXP profile is identified as
http://iana.org/beep/transient/isc/SCXP
in the BEEP "profile" element during channel creation.
During channel creation, the "hello" element MUST be exchanged
between the two SCXP peers. The corresponding "profile" element in
the BEEP "start" element June contain an "hello" element. If channel
creation is successful, then before sending the corresponding reply,
the BEEP peer processes the "hello" 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 recipient.
Including an "hello" in the initial "start" element has exactly the
same semantics as passing it as the first MSG message on the channel.
4.3 SCXP Profile Message Syntax
All BEEP messages in this profile have a MIME Content-Type [5] of
"text/xml", "text/plain", or "application/octet-stream". The syntax
of the individual elements is specified in Section 7.
Yixian Yang, et al. Expires June, 2004 [Page 9]
INTERNET-DRAFT The SCXP December, 2003
4.4 SCXP Profile Message Semantics
Each SCXP peer issues the "hello" element using "MSG" messages. The
"hello" element June contain one or more "option" sub-elements,
delivering optional channel options. The SCXP peer that receives the
"hello" element then issues "ok" in "RPY" messages or "error" in
"ERR" messages. (See Section 2.3.1 of [1] for the definitions of the
"error" and "ok" elements.) An "error" element June be issued within a
"RPY" message when piggy-backed within a BEEP "profile" element. If
the SCXP channel is created successfully, based on the respective
client/server roles negotiated during the exchange of "hello"
elements, the client sends data using "MSG" messages. Depending on
the MIME Content-Type, this data June be an "content" element, plain
text, or binary. The server then completes the message exchange
pattern either by:
- sending back "ok" in "RPY" messages or "error" in "ERR" messages;
or,
- sending back a "content" element in "RPY" messages or "error" in
"ERR" messages.
4.4.1 The hello Element
The "hello" element serves to identify the SCXP peer at the end of a
BEEP channel to the other SCXP peer at the other end of the channel,
and indicate the type of the security component. The "hello" element
has a "uri" attribute, a "role" attribute, a optional "fqdn"
attribute and one or more optional "option" elements:
- the "uri" attribute is the Uniform Resource Identifier (URI) [6]
of the peer, identifying the SCXP peer sending the element;
- the "role" attribute indicates the role (client or server) that
the peer will play on the channel;
- the "fqdn" attribute is the fully qualified domain name (c.f.,
[7]) of the peer; and,
- each "option" element contained within the "hello" element
indicates a request to enable an SCXP option on the channel being
negotiated. The "option" element will be specified in section 5
as well as SCXP options.
An "hello" element June be sent by a SCXP peer at any time. The other
peer receiving the "hello" element MUST respond to an "hello"
element with an "ok" (indicating acceptance), or an "error"
(indicating rejection), after processing the received "hello"
element. The identity, role and any channel option in effect are
specified by the most recent "hello" it has sent that was answered
with an "ok".
Yixian Yang, et al. Expires June, 2004 [Page 10]
INTERNET-DRAFT The SCXP December, 2003
For example, a successful creation with an embedded "hello" element
exchanged might look like this:
I: MSG 0 10 . 1592 178
I: Content-Type: text/xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/transient/isc/SCXP'>
I: <![CDATA[ <Hello uri='http://example.com/ellen'
I: role='client' /> ]]>
I: </profile>
I: </start>
I: END
L: RPY 0 10 . 1865 90
L: Content-Type: text/xml
L:
L: <profile uri='http://iana.org/beep/transient/isc/SCXP'>
L: <![CDATA[ <ok /> ]]>
L: </profile>
L: END
L: MSG 1 11 . 1955 53
L: Content-Type: text/xml
L:
L: <Hello uri='http://example.com/Tom' role='server' />
L: END
I: RPY 1 11 . 1770 7
I: Content-Type: text/xml
I:
I: <ok />
I: END
In the case, the initiator sends a "start" element on channel zero at
first, requesting to create a channel, and the "uri" attribute of
"profile" element indicates the URI of the SCXP profile. Notes that
the "hello" element as the initiating message of the SCXP channel is
included in the "profile" element to send, whose "uri" attribute
indicates the identity of the initiator and "role" attribute
indicates the role of initiator on the channel; Then the listener
sends back a "ok" element, indicating that it supports the SCXP
profile, and the SCXP channel is created successfully. Subsequently,
the listener sends a "hello" element on the channel and the initiator
answers with "ok". Thus, the mutual exchange of "hello" element is
completed.
Yixian Yang, et al. Expires June, 2004 [Page 11]
INTERNET-DRAFT The SCXP December, 2003
A creation with an embedded "hello" element exchanged that fails
might look like this:
I: MSG 0 10 . 1776 176
I: Content-Type: text/xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/transient/isc/SCXP'>
I: <![CDATA[ <Hello uri='http://example.com/cat'
I: role='client' /> ]]>
I: </profile>
I: </start>
I: END
L: RPY 0 10 . 1592 181
L: Content-Type: text/xml
L:
L: <profile uri='http://iana.org/beep/transient/isc/SCXP'>
L: <![CDATA[
L: <error code='530'>'http://example.com/cat' must first
L: negotiate the TLS profile</error> ]]>
L: </profile>
L: END
In this case, the listener receives the "hello" element sent by the
initiator and answers it with the "error" element in RPY message, for
the initiator has not negotiated the TLS profile with the listener,
which is indicated by the error code.
4.4.2 The content element
The "content" element carries the SCIMF messages to be exchanged
between the peers.
The semantics and the syntax of SCIMF messages are defined by [8].
Yixian Yang, et al. Expires June, 2004 [Page 12]
INTERNET-DRAFT The SCXP December, 2003
5. SCXP Options
SCXP provides a service for the reliable exchange of data between
security components. Options provide a mechanism for modifying the
semantics of the service. Accordingly, the specification of an SCXP
option MUST define:
- the identification of the option;
- the content, if any, contained within the option; and,
- the processing rules for the option.
An option registration template(section 5.3) organizes this
information.
The "option" element has the following attributes and contains
arbitrary content:
- the "name" and the "uri" attributes, exactly either of which MUST
be present, identify the option; the value of the "name" attribute
is the IANA-registered name for the option. If the "name"
attribute is not present, the value of the "uri" attribute MUST be
a URI or URI with a fragment- identifier. Note that a
relative-URI value is not allowed;
- the "mustUnderstand" attribute, which is optional, can be used to
indicate whether the option, if unrecognized, MUST induce an error
in processing. The value of the "mustUnderstand" attribute is
either "1" or "0". If the value of the attribute is "1", then if
the peer receiving the option can not recognize the option, an
error in processing will occur; If the value of the attribute is
"0", then if the peer can not recognize the option, the option can
be ignored, without error in processing to occur. The absence of
the "mustUnderstand" attribute is semantically equivalent to its
presence with the value "0"; and
- the "localize" attribute, if present, contains one or more
language tokens(defined in [1]), each identifying a desirable
language tag to be used by the remote SCXP peer when textual
diagnostics are returned to the originator.
To improve the service performance of SCXP, two options are
provided: the channelType option and the channelPRI option.
Yixian Yang, et al. Expires June, 2004 [Page 13]
INTERNET-DRAFT The SCXP December, 2003
5.1 The channelType Option
The registration for "channelType" option is presented in section
6.3. The "channelType" option provides a way for a SCXP peer to
request that a channel should be categorized as a particular type.
The categorization is mainly based on the data type to be exchanged
on the channel. Thus, when the remote SCXP peer receives the data on
the channel, it can delivery these data to the corresponding process
module directly depending on the channel type.
This option contains a "channelType" element. When sending an "hello"
element during the creation of an SCXP channel, the originating peer
June request that the remote peer assign a particular type to the
channel by including an "option" element containing a "channelType"
element.
The "channelType" element only has a mandatory "type" attribute,
whose possible value is "alert", "state", "interaction" or "config":
- The value of "alert" indicates that the channel should be
categorized as being used for the exchange of alert messages, such
as the "alert" class in SCIMF[8];
- The value of "state" indicates that the channel should be
categorized as being used for the exchange of state messages, such
as the "heartbeat" class in SCIMF[8];
- The value of "interaction" indicates that the channel should be
categorized as being used for the exchange of interaction
messages, such as the "command" class in SCIMF[8]; and
- The value of "config" indicates that the channel should be
categorized as being used for the exchange of configuration
messages, which could be self-identifying data that can support
diverse peer specific information without requiring modifications
to the SCXP itself.
Yixian Yang, et al. Expires June, 2004 [Page 14]
INTERNET-DRAFT The SCXP December, 2003
For example, during the creation of a channel, the client
successfully requests that the server assign a type to the channel
with the exchange of "hello" elements:
client server
| --------------- hello w/ Option ------------->|
|<---------------------- <ok> ------------------|
C: MSG 1 21 . 1963 145
C: Content-Type: text/xml
C:
C: <hello uri='http://example.com/ellen' role='client'>
C: <option name='channelType'>
C: < channelType type='interaction' />
C: </option>
C: </hello>
C: END
S: RPY 1 21 . 1117 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
In the case, the type of the channel is "interaction", therefore, the
channel can be used to transfer the "command" messages.
Similarly, an unsuccessful example might look like this:
client server
|<--------------- hello w/option -----------|
|------------------- <error> -------------->|
S: MSG 1 21 . 1969 151
S: Content-Type: text/xml
S:
S: <hello uri='http://example.com/Tom' role='server'>
S: <Option name='channelType' mustUnderstand='1'>
S: < channelType type='config' />
S: </Option>
S: </hello>
S: END
C: ERR 1 21 . 1292 64
C: Content-Type: text/xml
C:
C: <error code='504'>' channelType ' option was unrecognized</error>
C: END
In this case, the server requests the client to assign a type to a
channel during the creation of the channel, however, the client can
not recognize this option, and the "mustUnderstand" attribute is "1",
so the client sends back "error" message.
Yixian Yang, et al. Expires June, 2004 [Page 15]
INTERNET-DRAFT The SCXP December, 2003
5.2 The channelPRI Option
The registration for "channelPRI" option is presented in section 6.3.
By default, each SCXP channel is equal, and SCXP has no restrain on
how peers should manage multiple SCXP channels. The "channelPRI"
option provides a way for a SCXP peer using multiple SCXP channels to
request a relative priority for each channel. The channel with
higher priority will be given more bandwidth.
This option contains a "channelPRI" element. When sending an "hello"
element during the creation of an SCXP channel, the originating peer
June request that the remote peer assign a priority to the channel by
including an "option" element containing a "channelPRI" element.
The "channelPRI" element only has a mandatory "priority" attribute,
whose range of value is 0..2147483647, which is the maximum range of
possible BEEP channel numbers. 0 is specified to represent the
highest priority, with the relative priority decreasing as the
"priority" value ascends.
For example, during the creation of a channel, the client
successfully requests that the server assign a priority to the
channel with the exchange of "hello" elements:
client server
| -------------- hello w/ Option ---------------->|
|<------------------- <ok> -----------------------|
C: MSG 1 17 . 1984 141
C: Content-Type: text/xml
C:
C: <hello uri='http://example.com/ellen' role='client'>
C: <option name='channelPRI'>
C: <channelPRI priority='0' />
C: </option>
C: </hello>
C: END
S: RPY 1 17 . 2001 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
Yixian Yang, et al. Expires June, 2004 [Page 16]
INTERNET-DRAFT The SCXP December, 2003
Similarly, an unsuccessful example might look like this:
client server
|<---------------- hello w/Option -------------|
|------------------- <error> ------------------->|
S: MSG 1 17 . 1312 161
S: Content-Type: text/xml
S:
S: <hello uri='http://example.com/Tom' role='server'>
S: <option name='channelPRI' mustUnderstand='1'>
S: <channelPRI priority='2147483647' />
S: </option>
S: </hello>
S: END
C: ERR 1 17 . 451 66
C: Content-Type: text/xml
C:
C: <error code='504'>'channelPRI' Option was unrecognized</error>
C: END
In this case, the server requests the client to assign a priority to
a channel during the creation of the channel, however, the client can
not recognize this option, and the "mustUnderstand" attribute is "1",
so the client sends back "error" message.
5.3 The extension of SCXP option
SCXP options are extensible by specifying a new option. An SCXP
option SHOULD be documented in a Standards Track RFC and MUST be
registered with the IANA(c.f., section 5.4).
5.4 SCXP option Registration Template
When an SCXP option is registered, the following information is
supplied:
Option Identification: specify the NMTOKEN or the URI that
authoritatively identifies this option. Note that the URI MUST not be
a relative-URI.
Option Content: specify the XML content contained within the "option"
element.
Processing Rules: specify the processing rules for the option.
Contact Information: specify the postal and electronic contact
information for the author(s) of the option.
Yixian Yang, et al. Expires June, 2004 [Page 17]
INTERNET-DRAFT The SCXP December, 2003
6. IANA Registrations
6.1 Registration: The SCXP Profile
Profile identification: http://iana.org/beep/transient/isc/SCXP
Messages exchanged during channel creation: "hello"
Messages starting one-to-one exchanges: "hello", "content"
Messages in positive replies: "ok", "content"
Messages in negative replies: "error"
Messages in one-to-many exchanges: none
Message syntax: c.f., Section 4.3
Message semantics: c.f., Section 4.4
Contact information: c.f., the "Authors' Addresses" section of this
memo
6.2 Registration: The System (Well-Known) TCP port number for SCXP
Protocol Number: TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 4.3
Functions: c.f., Section 4.4
Use of Broadcast/Multicast: none
Proposed Name: Intrusion Detection Interactive Protocol
Short name: SCXP
Contact Information: c.f., the "Authors' Addresses" section of this
memo
6.3 Registration: The channelType Option
Option Identification: channelType
Option Content: channelType (c.f., Section 7.2)
Processing Rules: c.f., Section 5.1
Contact Information: c.f., the "Authors' Addresses" section of this
memo
Yixian Yang, et al. Expires June, 2004 [Page 18]
INTERNET-DRAFT The SCXP December, 2003
6.4 Registration: The channelPRI Option
Option Identification: channelPRI
Option Content: channelPRI (c.f., Section 7.3)
Processing Rules: c.f., Section 5.2
Contact Information: c.f., the "Authors' Addresses" section of this
memo
Yixian Yang, et al. Expires June, 2004 [Page 19]
INTERNET-DRAFT The SCXP December, 2003
7. SCXP DTDs
7.1 The SCXP DTD
The following is the DTD defining the valid elements for the SCXP
profile:
<!--
DTD for the SCXP Profile, as of 2003-05-28
Refer to this DTD as:
<!COMPONENT % SCXP PUBLIC "-//IETF//DTD RFC XXXX SCXP v1.0//EN">
%SCXP;
-->
<!-- Includes -->
<!COMPONENT % BEEP PUBLIC "-//IETF//DTD BEEP//EN">
%BEEP;
<!--
Profile Summary
BEEP profile http://iana.org/beep/transient/isc/SCXP
role MSG RPY ERR
==== === === ===
I or L hello ok error
C content ok or content error
-->
<!--
Component Definitions
component syntax/reference example
====== ================ =======
an authoritative identification
URI c.f., [RFC-2396] http://example.com
a fully qualified domain name
FQDN c.f., [RFC-1034] www.example.com
-->
<!COMPONENT % URI "CDATA">
<!COMPONENT % FQDN "CDATA">
Yixian Yang, et al. Expires June, 2004 [Page 20]
INTERNET-DRAFT The SCXP December, 2003
<!--
The "hello" element declares the identification and role of
the peer issuing it, on a per channel basis. The "hello"
element June contain one or more option sub-elements.
-->
<!ELEMENT hello (option*)>
<!ATTLIST hello
uri %URI; #REQUIRED
role (client|server) #REQUIRED
fqdn %FQDN; #IMPLIED>
<!--
The Option element conveys an SCXP option.
Note that the %LOCS component is imported from the BEEP Channel
Management DTD.
-->
<!ELEMENT Option (ANY)>
<!ATTLIST Option
name NMTOKEN ""
uri %URI; ""
mustUnderstand (1|0) "0"
localize %LOCS; "i-default">
<!--
The content element conveys the XML content that is exchanged.
Other DTD(s) can be used to define this element.
-->
<!-- End of DTD -->
7.2 the channelType option DTD
The following is the DTD defining the valid elements for the
channelType option:
<!--
DTD for the channelType SCXP Option, as of 2003-05-28
Refer to this DTD as:
<!COMPONENT % SCXP-channelType PUBLIC
"-//IETF//DTD RFC XXXX SCXP-channelType v1.0//EN">
%SCXP-channelType;
-->
Yixian Yang, et al. Expires June, 2004 [Page 21]
INTERNET-DRAFT The SCXP December, 2003
<!--
Component Definitions
component syntax/reference example
====== ================ =======
a stream type
STYPE (alert|state|config|interaction) "alert"
-->
<!COMPONENT % STYPE (alert|state|config|interaction)>
<!ELEMENT channelType EMPTY>
<!ATTLIST channelType
type %STYPE #REQUIRED>
<!-- End of DTD -->
7.3 the channelPRI DTD
The following is the DTD defining the valid elements for the
channelPRI option:
<!--
DTD for the channelPRI SCXP Option, as of 2003-05-28
Refer to this DTD as:
<!COMPONENT % SCXP-channelPRI PUBLIC
"-//IETF//DTD RFC XXXX SCXP-channelPRI v1.0//EN">
%SCXP-channelPRI;
-->
<!--
Component Definitions
component syntax/reference example
====== ================ =======
a priority number
PRIORITY 0..2147483647 1
-->
<!COMPONENT % PRIORITY "CDATA">
<!ELEMENT channelPRI EMPTY>
<!ATTLIST channelPRI
priority %PRIORITY #REQUIRED>
<!-- End of DTD -->
Yixian Yang, et al. Expires June, 2004 [Page 22]
INTERNET-DRAFT The SCXP December, 2003
8. Reply Codes
The following error codes June be used in SCXP profile:
code meaning
==== =======
200 success
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.)
451 requested action aborted
(e.g., local error in processing)
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
538 authentication mechanism requires encryption
550 Requested action not taken
(E.g., no SCXP profiles are acceptable.)
553 Parameter invalid
554 Transaction failed
(E.g., policy violation)
Yixian Yang, et al. Expires June, 2004 [Page 23]
INTERNET-DRAFT The SCXP December, 2003
9. Security consideration
Since the SCXP profile is defined using the BEEP framework, consult
[1]'s Section 8 for a discussion of BEEP-specific security issues.
In addition, since SCXP is designed for the data exchange between
security components, the protocol MUST support mutual-authentication,
confidentiality, integrity, replay protection and MUST minimize the
denial of service threat. An appropriate underlying BEEP security
profile can provide above security features:
9.1 Mutual-authentication of the identity
Since most of the data exchanged by SCXP is concerned with the
security of a system or a network, it is important that the sender
and the receiver have confidence in the identity of each other.
Therefore, SCXP peers require the mutual-authentication to the
identity of each other before using the SCXP profile.
The TLS profile SHOULD be used to provision the mutual-authentication
of SCXP peers which will communicate with each other. And the cipher
suite SHOULD contain a client-side certificate.
9.2 Message confidentiality
The messages transferring on a SCXP channel, which generally are
generated by a security component in human readable form (such as
using XML) with the assumption that the receive should be able to
read and understand the meaning, sometimes are extremely
security-sensitive, and the attacker would be interest in observing
or gaining these messages. However, these messages June be
transmitted in many kinds of network environments some of whose
underlying transferring mechanism provides no protection to the data.
So SCXP must support confidentiality of the message content in the
transaction.
9.3 Message integrity
In general, the messages generated by security components and
transferring on a SCXP channel, relate to the security of a system or
a network. So the receiver must assure that the content of the
message received has not been changed or modified in transit, which
requires that SCXP MUST support the message integrity.
The TLS profile SHOULD be used to provide the message integrity. The
cipher algorithm used SHOULD be TLS_ DHE_DSS _WITH_3DES_EDE_CBC_SHA.
9.4 Replay protection
In some case, even though the attacker might be unable to understand
the message transferring by some secure communication mechanism, it
June replay these message to confuse the receiver. Therefore, SCXP
must resist such message replay.
Yixian Yang, et al. Expires June, 2004 [Page 24]
INTERNET-DRAFT The SCXP December, 2003
The TLS profile SHOULD be used to provide replay protection. The
cipher algorithm used SHOULD be TLS_ DHE_DSS _WITH_3DES_EDE_CBC_SHA.
9.5 Minimizing protocol denial of service threat
SCXP peers are generally security components, which take on the
security of the protected system or network, therefore, once the
attacker makes the resource of SCXP peers unavailable, the SCXP peers
will lose the function of protection. It is important for SCXP itself
to minimize protocol denial of service threat.
To minimize protocol denial of service threat, the message from an
unauthenticated source SHOULD be refused, so SCXP peers SHOULD offer
the use of the TLS profile. The cipher suite used SHOULD be
TLS_ DHE_DSS_WITH_3DES_EDE_CBC_SHA.
9.6 Summary of Recommended Security Implementation
Based on above security consideration, the SCXP peers SHOULD provide
this BEEP tuning profile: http://iana.org/beep/TLS (using the
TLS_DHE_DSS _WITH_3DES_EDE_CBC_SHA cipher suite).
It is strongly recommended that the security components that want to
use the SCXP profile should negotiate a underlying BEEP security
profile to offer the required security properties. And the TLS
profile with the TLS_DHE_DSS _WITH_3DES_EDE_CBC_SHA cipher suite can
offer an appropriate level of security.
Yixian Yang, et al. Expires June, 2004 [Page 25]
INTERNET-DRAFT The SCXP December, 2003
10. References
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, <http://www.w3.org/TR/REC-xml>.
[4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[8] Yixian, Y. and Ming, T., "Security Components Interactive
Message Format Data Model and Extensible Markup Language (XML)
Document Type Definition", RFC XXXX, Month YYYY.
[9] Benjamin S. Feinstein and Gregory A. Matthews, "The Intrusion
Detection Exchange Protocol(IDXP) ", RFC XXXX, Month YYYY.
Yixian Yang, et al. Expires June, 2004 [Page 26]
INTERNET-DRAFT The SCXP December, 2003
11. Authors' Addresses
Yixian Yang
Information Security Center,
Beijing University of posts and telecom.(BUPT),
Beijing, China,100876
Phone:8610-62283366
Email:yxyang@bupt.edu.cn
12. Acknowledgements
The authors gratefully acknowledge the contributions of Huiqin Lv,
Ning An, Ming Tao, Yafei Yang,Zhansong Wei and Weimin Shi. And
special thanks to the National High Technology Research and
Development Program of China(863 Program) for the fund support.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it June be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation June be prepared, copied, published
and distributed, 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 June not be modified in any way, such as by removing
the copyright notice or references 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 FITNESS FOR A PARTICULAR PURPOSE.
Yixian Yang, et al. Expires June, 2004 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:49 |