INTERNET-DRAFT Yixian Yang Expires: December 2003 Jie Chang Yonggang Chu Beijing University of Posts and Telecom. June 2003 The Security Components Exchange Protocol(SCXP) draft-yang-scxp-00.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 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." 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 December, 2003 [Page 1] INTERNET-DRAFT The SCXP June, 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 December, 2003 [Page 2] INTERNET-DRAFT The SCXP June, 2003 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 structured messages, unstructured text, and binary data: Although SCXP is mainly intended for exchanging structured 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 December, 2003 [Page 3] INTERNET-DRAFT The SCXP June, 2003 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, security console and some response components. 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 may 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Yixian Yang, et al. Expires December, 2003 [Page 4] INTERNET-DRAFT The SCXP June, 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 December, 2003 [Page 5] INTERNET-DRAFT The SCXP June, 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 MAY 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 may 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 may 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 may 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 December, 2003 [Page 6] INTERNET-DRAFT The SCXP June, 2003 SCXP peer may 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 structured message) which doesní¯t require the receiver to return a corresponding structured message . For example, one SCXP peer can send alert messages to the other SCXP peer using this pattern. Yixian Yang, et al. Expires December, 2003 [Page 7] INTERNET-DRAFT The SCXP June, 2003 3.2.2 request-response exchange In this pattern, the client sends a command message (which is usually structured by using XML) 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 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 December, 2003 [Page 8] INTERNET-DRAFT The SCXP June, 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 structured 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 MAY 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 December, 2003 [Page 9] INTERNET-DRAFT The SCXP June, 2003 4.4 SCXP Profile Message Semantics Each SCXP peer issues the "hello" element using "MSG" messages. The "hello" element MAY 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 MAY 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 may 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 MAY 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 December, 2003 [Page 10] INTERNET-DRAFT The SCXP June, 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: I: I: ]]> I: I: I: END L: RPY 0 10 . 1865 90 L: Content-Type: text/xml L: L: L: ]]> L: L: END L: MSG 1 11 . 1955 53 L: Content-Type: text/xml L: L: L: END I: RPY 1 11 . 1770 7 I: Content-Type: text/xml I: I: 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 December, 2003 [Page 11] INTERNET-DRAFT The SCXP June, 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: I: I: ]]> I: I: I: END L: RPY 0 10 . 1592 181 L: Content-Type: text/xml L: L: L: 'http://example.com/cat' must first L: negotiate the TLS profile ]]> L: 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 information to be exchanged between the peers, which both of the peers can understand. These information should be structured message. Security components can define the data formats that satisfy their requirements, using XML. Those formatted data using XML is termed structured message, which can be contained in the "content" element. The specification of structured messages MUST define: - the semantics of the message; and, - the syntax of the message. Yixian Yang, et al. Expires December, 2003 [Page 12] INTERNET-DRAFT The SCXP June, 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 December, 2003 [Page 13] INTERNET-DRAFT The SCXP June, 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 MAY 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 IDMEF[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 IDMEF[8]; - The value of "interaction" indicates that the channel should be categorized as being used for the exchange of interaction messages, which usually are a pair of "command" and "reply" message; 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 December, 2003 [Page 14] INTERNET-DRAFT The SCXP June, 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 ------------->| |<---------------------- ------------------| C: MSG 1 21 . 1963 145 C: Content-Type: text/xml C: C: C: C: C: END S: RPY 1 21 . 1117 7 S: Content-Type: text/xml S: S: S: END In the case, the type of the channel is "interaction", therefore, the channel can be used to transfer the "command" and "reply" messages. Similarly, an unsuccessful example might look like this: client server |<--------------- hello w/option -----------| |------------------- -------------->| S: MSG 1 21 . 1969 151 S: Content-Type: text/xml S: S: S: S: S: END C: ERR 1 21 . 1292 64 C: Content-Type: text/xml C: C: ' channelType ' option was unrecognized 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 December, 2003 [Page 15] INTERNET-DRAFT The SCXP June, 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 MAY 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 ---------------->| |<------------------- -----------------------| C: MSG 1 17 . 1984 141 C: Content-Type: text/xml C: C: C: C: C: END S: RPY 1 17 . 2001 7 S: Content-Type: text/xml S: S: S: END Yixian Yang, et al. Expires December, 2003 [Page 16] INTERNET-DRAFT The SCXP June, 2003 Similarly, an unsuccessful example might look like this: client server |<---------------- hello w/Option -------------| |------------------- ------------------->| S: MSG 1 17 . 1312 161 S: Content-Type: text/xml S: S: S: S: S: END C: ERR 1 17 . 451 66 C: Content-Type: text/xml C: C: 'channelPRI' Option was unrecognized 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 December, 2003 [Page 17] INTERNET-DRAFT The SCXP June, 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 December, 2003 [Page 18] INTERNET-DRAFT The SCXP June, 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 December, 2003 [Page 19] INTERNET-DRAFT The SCXP June, 2003 7. SCXP DTDs 7.1 The SCXP DTD The following is the DTD defining the valid elements for the SCXP profile: %BEEP; Yixian Yang, et al. Expires December, 2003 [Page 20] INTERNET-DRAFT The SCXP June, 2003 7.2 the channelType option DTD The following is the DTD defining the valid elements for the channelType option: Yixian Yang, et al. Expires December, 2003 [Page 21] INTERNET-DRAFT The SCXP June, 2003 7.3 the channelPRI DTD The following is the DTD defining the valid elements for the channelPRI option: Yixian Yang, et al. Expires December, 2003 [Page 22] INTERNET-DRAFT The SCXP June, 2003 8. Reply Codes The following error codes may 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 December, 2003 [Page 23] INTERNET-DRAFT The SCXP June, 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 may 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 may replay these message to confuse the receiver. Therefore, SCXP must resist such message replay. Yixian Yang, et al. Expires December, 2003 [Page 24] INTERNET-DRAFT The SCXP June, 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 December, 2003 [Page 25] INTERNET-DRAFT The SCXP June, 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, . [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] Curry, D. and H. Debar, "Intrusion Detection Message Exchange 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 December, 2003 [Page 26] INTERNET-DRAFT The SCXP June, 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 and Zhansong Wei. 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 may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may 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 may 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 December, 2003 [Page 27]