Internet Draft L.A. Sanchez, Megisto draft-ietf-ipsp-spp-01.txt M.N. Condell, BBN Expires July, 2002 January 29, 2002 Security Policy 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." 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. Abstract This document describes a protocol for discovering, accessing and processing security policy information of hosts, subnets or networks of a security domain. The Security Policy Protocol defines how the policy information is exchanged, processed, and protected by clients and servers. The protocol is extensible and flexible. It allows the exchange of complex policy objects between clients and servers. Sanchez, Condell [page 1] Internet Draft Security Policy Protocol January 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions. . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Policies . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. SPP Message. . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 SPP Message Format . . . . . . . . . . . . . . . . . . . . 7 3.2 SPP Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Query Payload. . . . . . . . . . . . . . . . . . . . . 11 3.2.2 Record Payload . . . . . . . . . . . . . . . . . . . . 12 3.2.3 Signature Payload. . . . . . . . . . . . . . . . . . . 13 3.3 SPP Messages . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1 Query Messages . . . . . . . . . . . . . . . . . . . . 14 3.3.2 Reply Messages . . . . . . . . . . . . . . . . . . . . 14 3.3.3 Policy Messages. . . . . . . . . . . . . . . . . . . . 15 3.3.4 Policy Acknowledgment Messages . . . . . . . . . . . . 15 3.3.5 Transfer Messages. . . . . . . . . . . . . . . . . . . 15 3.3.6 KeepAlive Messages . . . . . . . . . . . . . . . . . . 16 4. Policy Queries . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1 Security Gateway Query . . . . . . . . . . . . . . . . . . 16 4.2 COMSEC Query . . . . . . . . . . . . . . . . . . . . . . . 17 4.3 Certificate Query. . . . . . . . . . . . . . . . . . . . . 18 5. Policy Records . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 Security Gateway Record. . . . . . . . . . . . . . . . . . 19 5.2 COMSEC Record. . . . . . . . . . . . . . . . . . . . . . . 21 5.3 Security Association Record. . . . . . . . . . . . . . . . 22 5.4 Policy Server Record . . . . . . . . . . . . . . . . . . . 23 5.5 Certificate Record . . . . . . . . . . . . . . . . . . . . 25 6. Transfer Records . . . . . . . . . . . . . . . . . . . . . . . 25 7. Policy Attribute Encoding. . . . . . . . . . . . . . . . . . . 26 8. SPP Message Processing . . . . . . . . . . . . . . . . . . . . 28 8.1 General Message Processing . . . . . . . . . . . . . . . . 28 8.2 Query Message Processing . . . . . . . . . . . . . . . . . 29 8.3 Reply Message Processing . . . . . . . . . . . . . . . . . 32 8.4 Policy Message Processing. . . . . . . . . . . . . . . . . 35 8.5 Policy Acknowledgment Message Processing . . . . . . . . . 37 8.6 Transfer Message Processing. . . . . . . . . . . . . . . . 38 8.7 KeepAlive Message Processing . . . . . . . . . . . . . . . 40 9. Policy Resolution . . . . . . . . . . . . . . . . . . . . . . . 41 9.1 Expansion of step 4. . . . . . . . . . . . . . . . . . . . 42 Sanchez, Condell [page 2] Internet Draft Security Policy Protocol January 2002 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46 10.1 Message Type. . . . . . . . . . . . . . . . . . . . . . . 46 10.2 Message Code. . . . . . . . . . . . . . . . . . . . . . . 46 10.3 Identity Type . . . . . . . . . . . . . . . . . . . . . . 46 10.4 Payload Class . . . . . . . . . . . . . . . . . . . . . . 47 10.5 Query Type. . . . . . . . . . . . . . . . . . . . . . . . 47 10.6 Record Type . . . . . . . . . . . . . . . . . . . . . . . 47 10.7 Signature Type. . . . . . . . . . . . . . . . . . . . . . 47 10.8 Certificate Type. . . . . . . . . . . . . . . . . . . . . 47 10.9 Certificate Identity Type . . . . . . . . . . . . . . . . 47 10.10 Attribute Data Type. . . . . . . . . . . . . . . . . . . 48 10.11 User Name Type . . . . . . . . . . . . . . . . . . . . . 48 10.12 System Name Type . . . . . . . . . . . . . . . . . . . . 48 10.13 IPsec Action Attribute . . . . . . . . . . . . . . . . . 48 10.14 IKE Action Attribute . . . . . . . . . . . . . . . . . . 48 11. Security Considerations. . . . . . . . . . . . . . . . . . . . 49 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix A. DATA_TYPE Definitions. . . . . . . . . . . . . . . . . 51 Appendix B. An SPP Example . . . . . . . . . . . . . . . . . . . . 78 Appendix C. Decorrelation. . . . . . . . . . . . . . . . . . . . . 83 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Author Information . . . . . . . . . . . . . . . . . . . . . . . . 92 1. Introduction The IPsec protocols [Kent98] provide a mechanism for securing communications at the IP layer and IKE [Harkins98] can be used to provide keys for IPsec. Currently practice with these protocols maintains an assumption that communicating hosts have some a-priori knowledge of which communications with particular newtwork entities must be secured. While this assumption is valid in some environments (e.g. some VPN environments), it does not support more general IPsec senarios in a scalable manner. In order to allow IPsec to scale in general cases, it is necessary to be able to identify which entities involved in a communication will require IPsec to protect the communication and what their policies are regarding it. The Security Policy Protocol (SPP) defines how the policy information is exchanged, processed, and protected by clients and servers. The protocol also defines what policy information is exchanged and the format used to encode the information. The protocol specifies six different message types used to exchange policy information. An SPP Sanchez, Condell [page 3] Internet Draft Security Policy Protocol January 2002 message contains a message header section followed by zero or more SPP payloads, depending on the message type. SPP is part of the Security Policy System architecture [SPS]. This document uses terms and references functionality described in [SPS]. The remainder of this section defines terms and concepts that will be used throughout this document. Section 2 provides and overview of the protocol. The remainder of the document describes the encoding of the protocol and how SPP messages are processed. 1.1 Definitions The following terms are used throughout this document, in addition to the terms defined in [SPS] and defined for general policy terminology [RGSC00]. Authoritative Host A is authoritative over host B if host A has the right to represent policy for host B. Host A may assert its relationship to host B using policy server records (section 5.4), but MUST be able to cryptographically prove the assertion. Transitively Authoritative A host is transitively authoritative over another host, A, if it is either authoritative over host A or authoritative over a host, B, which is trasitively athoritative over host A. For example, if host X is authoritative for host Y and host Y is authoritative for host Z, then host X is transitively authoritative for host Z. Chain of Trust A chain of trust is a set of cryptographically-proven authoritative assertions that prove that a policy server is transitively authoritative over the source or destination of a communication. The chain of trust is used to prove that a policy server has a right to be involved in an SPP exchange. See section 10 for more about the chain of trust. Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 1.2 Policies Defining and storing policies are beyond the scope if this document. However, this section describes SPP's policy requirements and a brief high-level look at its representation. Sanchez, Condell [page 4] Internet Draft Security Policy Protocol January 2002 Policy Representation SPP provides both the comsec record (section 5.2) and the Security Association (SA rec) record (section 5.3) to describe policies. The comsec record defines the selectors that describe a communication along with a permit or deny action. The SA rec defines the actions, specifically the IPsec and IKE security associations, necessary for the communication to proceed. A policy transferred by SPP, therefore, MUST consist of one comsec record to describe the selectors of the communication and zero or more SA recs which describe the security associations that are required to complete the communication. Decorrelation Policies exchanged using SPP MUST be decorrelated as described in Appendix C. Two policies are decorrelated if there exists at least one selector in both policies for which their values do not intersect. Decorrelation is necessary to permit policy servers to properly cache policies. 2. Overview This section provides an overview of the SPP operation. A more detailed and complex example of SPP operation is available in appendix B. This overview assumes the policy servers have been loaded with policies for their security domains and the policy has been appropriately decorrelated. Security Security Domain Foo Domain Foo +----------+ +----------+ | Policy | | Policy | | Server A | | Server B | +----------+ +----------+ ^ ^ ^ ^ +---------+ Q1 | | Q2 /\ /\ Q2 | | Q3 +----------+ | Host | R1 | | R2 / \ Q2/R2 / \ R2 | | R3 | Host | | A |<--- -----><------><--- ---->| B | +---------+ \ / \ / +----------+ \/ \/ Figure 1: Overview of SPP operation Host A, wanting to communicate with Host B, invokes its policy client. Host A's client sends a Query (Q1) to its configured local policy server, Policy Server A. Policy Server A looks in its cache for a policy record that matches the query. If it doesn't find one, it sends a Query (Q2) containing the same policy request information to Host B. Q2 is sent to Host B since Policy Server A may not know about the existence of SGB or Policy Server B. This message includes a signature that validates the authenticity and integrity of the query's content. Sanchez, Condell [page 5] Internet Draft Security Policy Protocol January 2002 (Q2) is intercepted by SGB. SGB forwards the message (Q2) to Policy Server B. Policy server B verifies that it can accept queries from Policy Server A and validates the signature in Q2. It searches its database for the appropriate policy information after verifying that it is authoritative over Policy Client B. Policy Server B merges its local policy with the policy information in (Q2) and it sends a Reply (R2) to Policy Server A. The reply includes the original query information and all policy information needed to allow Policy Client A to establish a secure communication with Host B. Policy Server B also attaches additional information to the reply asserting its authority over Host B. When Policy Server A receives the reply (R2) from Policy Server A, it validates the signature in R2 and cryptographically verifies that Policy Server B is authoritative over Host B. It then merges is local policy with the policy information in (R2) and sends a Reply (R1) to Host A. Policy Server A caches the merged policy to use when answering future queries. Host A may then use this information to establish necessary security associations with Host B. If, however, Policy Server B is not authoritative over Host B, it would query Host B for its policy with respect to this particular communication. Policy Server B would generate a third query (Q3). Host B would respond with its policy in (R3). Policy Server B merges its policy for this communication and the policy in (R3) before replying to Policy Server A. Policy Server A processes the reply as it did above. SPP accommodates topology changes, hence policy changes, rather easily without the scalability constraints imposed by static reconfiguration of each client. The protocol is extensible and flexible It allows the exchange of complex policy objects between clients and servers. 3. SPP Message The SPP header is present in every message. It contains fields identifying the message, the type of message, the status of the message, the number of queries and/or record payloads, and the host requesting policy information. The header also includes a timestamp field that provides anti-replay protection. Following the header there might be zero or more SPP payloads. Currently, there are three payload types defined in SPP: Query, Record, and Signature payloads. See section 3.2 for encoding details. SPP has six distinct message types. Query messages contain a specific request for policy information. Reply messages include policy records that answer specific policy queries. Policy messages include policy information and are utilized for up/downloading security policies to and from a policy server. Policy Acknowledgment messages are utilized to acknowledge corresponding Policy messages but do not themselves contain policy information. Transfer messages, which include policy Sanchez, Condell [page 6] Internet Draft Security Policy Protocol January 2002 information, are utilized by policy servers to exchange bulk policy information between servers. Finally, policy servers use keep alive messages to inform security gateways and/or other monitoring devices of the status of the server. SPP messages MUST be authenticated either using IPsec [Kent98] or another security mechanism. SPP provides a basic security mechanism that can be used to provide authentication and integrity to its messages when other security mechanisms are not in use. The SPP authentication is especially useful when traversing heterogenous domains and the identity of the policy server authoritative for the destination is unknown. These services are provided using digital signatures. SPP caries signatures in the signature payload. The signature is calculated over the entire SPP message. When this service is used, the entity (host, policy server, or security gateway) verifying the signature must have access to the public key that corresponds to the private key used to sign the SPP message. Certificate fetching is out of the scope of SPP. However, SPP provides a simple certificate fetching mechanism for entities that elect to use it as an alternative to other mechanisms. SPP suports several Public Key certificates formats. SPP is modular and extensible (see section 10 for IANA considerations). New policy queries and records can be defined and incorporated easily. This document defines a minimum set of queries and policy records required in a policy-based security management system. 3.1 SPP Message Format An SPP message follows the format depicted in figure 2. It is comprised of a header and zero or more SPP payloads. This section defines the encoding for the SPP header. Sections 3.2 and 3.3 cover the encoding for the SPP payload and message types, respectively. Sanchez, Condell [page 7] Internet Draft Security Policy Protocol January 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- | VERSION | MTYPE | MCODE | RESERVED | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MESSAGE ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | QCOUNT | RCOUNT | IDENTITY TYPE |R|D|C|I|T| RSVD| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SPP + TIMESTAMP + Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ SENDER IDENTITY ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- | | SPP ~ SPP PAYLOADS... ~ Pay- | | loads +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- Figure 2: Format of an SPP Message The SPP header includes the following fields: VERSION A 1-octect field containing the version of the Security Policy Protocol. This document describes version 1 of the protocol. MTYPE A 1-octet field indicating the SPP message type. The currently defined values are: Message Type Value Value Not Assigned 0 SPP-QUERY 1 SPP-REPLY 2 SPP-POL 3 SPP-POL_ACK 4 SPP-XFR 5 SPP-KEEP_ALIVE 6 values 7-250 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. MCODE A 1-octet field providing information about this message. All MTYPEs share a common MCODE space, although each message type may not use all the defined message codes. See section 3.3 for the codes applicable to each message type. Sanchez, Condell [page 8] Internet Draft Security Policy Protocol January 2002 Action Code Type Field Value Not Assigned 0 message accepted 1 denied, administratively prohibited 2 denied, timestamp failed 3 denied, failed signature 4 denied, insufficient resources 5 denied, malformed message 6 denied, unspecified 7 partially available 8 unavailable 9 communication prohibited 10 partially available, server unreachable 11 values 12-250 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. RESERVED A one octet field reserved for future use. Set value to all zeros (0). MESSAGE ID A 4 octet field used to match messages and their responses (e.g. queries to replies and policy to policy acknowledgement messages). This value starts at "zero" and MUST be incremented by (1) with every new message. QCOUNT A 1 octet field indicating the number of Query payloads included in the message. RCOUNT A 1 octet field indicating the number of Record payloads included in the message. IDENTITY TYPE This 1 octet field indicates the type of indentity found in the Sender Identity field. Valid values are: Identity Type Value Value Not Assigned 0 IPV4_ADDR 1 IPV6_ADDR 2 Host DNS Name 3 values 4-250 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. Sanchez, Condell [page 9] Internet Draft Security Policy Protocol January 2002 R Raw policy flag. When this flag is set, policy servers MUST NOT resolve the policies that they return. D Domain flag. Only resolve the policies as far as the last policy server that is transitively authoritative over the host requesting the policy resolution. C Dont cache flag. Don't cache the policies generated by the query. I Ignore cache flag. Ignore any cached policies when processing the query. T No chain-of-trust. A client indicates to its server that it does not need chain-of-trust information. Policy Servers MUST NOT set this flag. Only Policy Clients have the option to set it. RSVD A 4 bit field reserved for future use. Set value to all zeros (0). TIMESTAMP This 8-octet field contains a timestamp used to provide limited protection against replay attacks. The timestamp is formatted as specified by the Network Time Protocol [RFC1305]. SENDER IDENTITY A variable length field containing the identity of the sender (host, security gateway, or policy server) of the SPP message. The IDENTITY_TYPE field indicates the format of the content in this field: Identity Type Sender Identity IPV4_ADDR An IPv4 Address IPV6_ADDR An IPv6 Address Host DNS Name A DNS name encoded as described in [rfc1035] This field does not allow IP address ranges or wildcards. If this field is not aligned at the 4 octet boundary, the field MUST be padded on the right with (00)hex to align on the next 32-bit boundary. Sanchez, Condell [page 10] Internet Draft Security Policy Protocol January 2002 3.2 SPP Payloads 3.2.1 Query Payload The Query payload contains fields to express a particular request for policy information. Hosts, security gateways, or policy servers can generate and transmit Query payloads in SPP messages to policy servers. Figure 3 shows the format of the Query payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCL | PID | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUERY Data ... +-+-+-+-+-+-+-+- Figure 3: Format of Query Payload The Query Payload fields are defined as follows: PCL A 1 octet field indicating the payload class. Query payloads MUST contain (1) in the PCL field. PID A 1 octet field containing the ID number that identifies a particular Query payload within an SPP message. Since one SPP message can contain multiple Query payloads, each one MUST be uniquely identified. This number MUST be unique among the Query payloads within an SPP message. RESERVED A 2 octet field reserved for future use. Set value to all zeros (0). TYPE A 2 octet field that specifies the type of query contained in the QUERY Data fields. The currently defined queries are: Query Payload Type Value Value Not Assigned 0 Security Gateway Query 1 Communication Security Query 2 Certificate Query 3 values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. Sanchez, Condell [page 11] Internet Draft Security Policy Protocol January 2002 LENGTH A 2 octet field indicating the length in octets of the query data field. QUERY Data A variable length field containing a single policy query. See section 7 for encoding format. 3.2.2 Record Payload The Record payload contains fields that assert policy information. Hosts, security gateways, or policy servers can generate and transmit Record payloads in SPP messages. Figure 4 shows the format of the Record payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCL | PID | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RECORD Data ... +-+-+-+-+-+-+-+- Figure 4: Format of Record Payload The Record Payload fields are defined as follows: PCL A 1 octet field indicating the payload class. Record payloads MUST contain (2) in the PCL field. PID This field is used to match queries to Record payloads. If the record is a reply to a query, then the value for this field MUST match the correspondent Query payload PID. If it is not a reply to a query, the value SHOULD be set to zero. RESERVED A 2 octet field reserved for future use. Set value to all zeros (0). TYPE A 2 octet field that specifies the type of Record. The currently defined records are: Sanchez, Condell [page 12] Internet Draft Security Policy Protocol January 2002 Record Type Value Value Not Assigned 0 Security Gateway Record 1 Communication Security Record 2 Security Association Record 3 Certificate Record 4 Policy Server Record 5 Transfer Record 6 values 7-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. LENGTH A 2 octet field indicating the length in octets of the RECORD data field. RECORD Data A variable length field containing a single policy record. See section 8 for encoding format. 3.2.3 Signature Payload The Signature Payload contains data generated by the digital signature function (selected by the originator), over the entire SPP message, except for part of the Signature payload. This payload is used to verify the integrity of the data in the SPP message. Figure 5 shows the format of the Signature payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCL | TYPE | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIGNATURE Data ... +-+-+-+-+-+-+-+- Figure 5: Signature Payload Format The Signature payload fields are defined as follows: PCL A 1 octet field indicating the payload class. Signature payloads MUST contain (3) in the PCL field. TYPE A 1 octet field that specifies the signature algorithm employed. The currently defined signature types are: Sanchez, Condell [page 13] Internet Draft Security Policy Protocol January 2002 Algorithm Type Value Value Not Assigned 0 RSA 1 DSA 2 values 3-250 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. LENGTH A 2 octet field indicating the length in octets of the SIGNATURE Data field. SIGNATURE Data A variable length field that contains the results from applying the digital signature function to the entire SPP message (including the PCL, TYPE, and LENGTH fields of the Signature payload), except for the Signature Data field of the Signature payload. 3.3 SPP Messages 3.3.1 Query Message An SPP-QUERY message is comprised of an SPP header, one or more Query payloads, zero or more Record payloads, and a Signature payload, if one is required. Query messages MUST always contain a Query payload. Record payloads may optionally be included to pass policy information along with the query. If the Signature payload is employed it MUST be the last payload in the message. The Query message MTYPE value is (1). The MCODE field must be set to zero (0). 3.3.2 Reply Message An SPP-REPLY message is comprised of an SPP header, one or more Query payloads, zero or more Record payloads which answer the corresponding Query payload, and a Signature payload, if one is required. Reply messages MUST contain a Query payload. Reply messages MUST include a Record payload unless the reply contains an MCODE of values 2-8. If the Signature payload is employed it MUST be the last payload in the message. The MTYPE value for a Reply message is (2). The following MCODE values may be used for Reply messages: Sanchez, Condell [page 14] Internet Draft Security Policy Protocol January 2002 Action Code Type Field Value Not Assigned 0 message accepted 1 denied, administratively prohibited 2 denied, timestamp failed 3 denied, failed signature 4 denied, insufficient resources 5 denied, malformed message 6 denied, unspecified 7 partially available 8 unavailable 9 communication prohibited 10 partially available, server unreachable 11 3.3.3 Policy Message An SPP-POL message is comprised of an SPP header, one or more Record payloads, and a Signature payload, if one is required. Policy messages MUST NOT include Query payloads. If the Signature payload is employed it MUST be the last payload in the message. The MTYPE value for a Policy message is (3). The MCODE field must be set to zero (0). 3.3.4 Policy Acknowledgement Message An SPP-POL_ACK message is comprised of an SPP header and a Signature payload, if one is required. These messages MUST NOT contain Query or Record payloads. The status of the associated Policy message is expressed within the MCODE field. If the Signature payload is employed it MUST be the only payload in the message. The MTYPE value for a Policy Acknowledgement message is (4). The following MCODE values may be used for Policy Acknowledgement messages: Action Code Type Field Value Not Assigned 0 message accepted 1 denied, administratively prohibited 2 denied, timestamp failed 3 denied, failed signature 4 denied, insufficient resources 5 denied, malformed message 6 denied, unspecified 7 3.3.5 Transfer Message An SPP-XFR message is comprised of an SPP header, one or more Record payloads, and a Signature payload, if one is required. Transfer messages MUST NOT include Query payloads. If the Signature payload is employed it MUST be the last payload in the message. The MTYPE value for a Transfer message is (5). The MCODE field must be set to zero (0). Sanchez, Condell [page 15] Internet Draft Security Policy Protocol January 2002 3.3.6 KeepAlive Message An SPP-KEEP_ALIVE message is comprised of an SPP header and a Signature payload, if one is required. These messages MUST NOT contain Query or Record payloads. If the Signature payload is employed it MUST be the only payload in the message. The MTYPE value for a KeepAlive message is (6). The MCODE field must be set to zero (0). 4. Policy Queries 4.1 Security Gateway Query This basic query provides a dynamic mechanism to determine which relevant security gateways, both primary and backup, are in the path to a particular destination address. Since the answer to a request for information could depend on the identity of the requestor, the host address of the source of the intended communicaton is included in the query. Figure 6 shows the format of the Security Gateway Query. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SOURCE ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ DESTINATION ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Security Gateway Query Format The Security Gateway Query fields are defined as follows: SOURCE ADDRESS DATA This variable length field contains a single IP address (unicast) either in IPv4 or IPv6 format. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 3 and 9. DESTINATION ADDRESS DATA This variable length field contains a single IP address (unicast) either in IPv4 or IPv6 format. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 6 and 12. Sanchez, Condell [page 16] Internet Draft Security Policy Protocol January 2002 4.2 COMSEC Query The Communication Security Query (or COMSEC query) provides a dynamic mechanism for a host or security gateway to inquire if a communication having a particular set of characteristics is allowed. The communication is described in terms of source and destination addresses, protocols, source port, destination port, and other parameters as defined in section 7. These parameters are known as selectors in the IPsec context and are primarily the contents of the IP, TCP, and UDP headers. Figure 7 shows the format of the COMSEC Query. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SOURCE ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ DESTINATION ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SELECTOR DATA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: COMSEC Query Format The COMSEC Query fields are defined as follows: SOURCE ADDRESS DATA This variable length field contains a single IP address (unicast) either in IPv4 or IPv6 format. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 3 and 9. DESTINATION ADDRESS DATA This variable length field contains a single IP address (unicast) either in IPv4 or IPv6 format. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 6 and 12. SELECTOR DATA This includes one or more fields following the encoding format specified in section 7. The acceptable DATA_TYPE values are 15-29, inclusive. Sanchez, Condell [page 17] Internet Draft Security Policy Protocol January 2002 4.3 CERT Query Mechanisms to dispatch and fetch public-key certificates are not part of SPP. However, in the absence of external request/dispatch mechanisms, SPP provides for a certificate request query that allows a host, security gateway, or server to solicit a certificate. Figure 8 shows the format of the CERT Query. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT_TYPE | IDENTITY_TYPE | AUTHORITY_TYPE| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IDENTITY ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ CERTIFICATE AUTHORITY ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Certificate Query Format The Certificate query fields are defined as follows: CERT_TYPE A 1 octet field that contains an encoding of the type of certificate requested. Acceptable values are listed below: Certificate Type Value Value Not Assigned 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 SPKI Certificate 7 values 8-250 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. IDENTITY_TYPE This 1 octet field indicates the type of indentity found in the Identity field. Valid values are listed below: Sanchez, Condell [page 18] Internet Draft Security Policy Protocol January 2002 Value Identity Type 0 Value Not Assigned 1 IPV4_ADDR 2 IPV6_ADDR 3 DNS Name 4 X.500 Distinguished Name values 5-250 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. AUTHORITY_TYPE This 1 octet field indicates the type of authority found in the Certificate Authority field. Valid values are the same as IDENTITY_TYPE. IDENTITY This variable length field contains the identity of the principal by which the certificate should be located. The value MUST be of the type stated in IDENTITY_TYPE. CERTIFICATE AUTHORITY A variable length field containing an encoding of an acceptable certificate authority for the type of certificate requested. The value MUST be of the type stated in AUTHORITY_TYPE. 5. Policy Records 5.1 Security Gateway Record This record contains information that indicates the IP addresses of the interfaces for the the primary and secondary security gateways protecting a host or group of hosts. The record contains the primary and secondary gateways at one point in the communication path between the source and destination addresses listed in the Security Gateway query. If the IP datagram must traverse multiple gateways, a Security Gateway Record must be included for each gateway. The list of secondary security gateways is optional. Figure 9 shows the format of the Security Gateway Record. Sanchez, Condell [page 19] Internet Draft Security Policy Protocol January 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CACHE-EXPIRY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ PRIMARY SG ADDRESS ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SECONDARY SG ADDRESSES +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Security Gateway Record Format The Security Gateway Record fields are defined as follows: CACHE-EXPIRY A 4 octet field indicating the maximum amount of time, in seconds, this policy record MAY be cached. FLAGS A 2 octet field indicating different options to aid in interpreting the security gateway data. If not in use, set value to all zeros (00)hex. Currently, no flag values are defined so this field MUST be set to (00)hex. RESERVED A 2 octet field reserved for future use. Set value to all zeros (0). PRIMARY SG ADDRESS A variable length field containing the IP address of the primary security gateway for protecting a particular host. This variable length field contains a single unicast IP address. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 1 and 2. SECONDARY SG ADDRESSES This variable length field contains the IP addresses of one or more secondary security gateways protecting a particular host. This field may contain a list of single unicast IP addresses. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 1 and 2. Sanchez, Condell [page 20] Internet Draft Security Policy Protocol January 2002 5.2 COMSEC Record The COMSEC record indicates if a communication having a particular set of characteristics is allowed or not. The communication is described in terms of source and destination addresses, protocols, source ports, destination ports, and other attributes defined in section 7. Figure 10 shows the format of the COMSEC Record. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CACHE-EXPIRY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SOURCE ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ DESTINATION ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SELECTOR DATA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: COMSEC Record Format The COMSEC Record fields are defined as follows: CACHE-EXPIRY A 4 octet field indicating the maximum amount of time, in seconds, this policy record MAY be cached. FLAGS A 2 octet field indicating different options to aid in interpreting the selector data. If not in use, set value to all zeros (0). Currently, no flag values are defined so this field MUST be set to zero (0). RESERVED A 2 octet field reserved for future use. Set value to all zeros (0). Sanchez, Condell [page 21] Internet Draft Security Policy Protocol January 2002 SOURCE ADDRESS DATA This variable length field contains a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (low and high values, inclusive), address + mask, or a wildcard address. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 3-5 and 9-11, inclusive. DESTINATION ADDRESS DATA This variable length field contains a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (low and high values, inclusive), address + mask, or a wildcard address. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 6-8 and 12-14, inclusive. SELECTOR DATA This includes one or more fields following the encoding format specified in section 7. The acceptable DATA_TYPE values are 15-29, inclusive. 5.3 Security Association Record Security Association Records contain selectors and security association attributes (appliers) that characterize a particular Security Association between the source and destination addresses listed in the record. This record contains data types as defined in the section 7. Figure 11 shows the format of the SA Record. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CACHE-EXPIRY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SOURCE ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ DESTINATION ADDRESS DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SELECTOR DATA AND APPLIERS... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: SA Record Format The SA record fields are defined as follows: Sanchez, Condell [page 22] Internet Draft Security Policy Protocol January 2002 CACHE-EXPIRY A 4 octet field indicating the maximum amount of time, in seconds, this policy record MAY be cached. FLAGS A 2 octet field indicating different options to aid in interpreting the selector data. If not in use, set value to all zeros (0). Currently, no flag values are defined so this field MUST be set to zero(0). RESERVED A 2 octet field reserved for future use. Set value to all zeros (0). SOURCE ADDRESS DATA This variable length field contains a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (low and high values, inclusive), address + mask, or a wildcard address. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 3-5 and 9-11, inclusive. DESTINATION ADDRESS DATA This variable length field contains a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (low and high values, inclusive), address + mask, or a wildcard address. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 6-8 and 12-14, inclusive. SELECTOR DATA AND APPLIERS This includes one or more fields following the encoding format specified in section 7. The acceptable DATA_TYPE values are 15-29 and 50-51, inclusive. 5.4 Policy Server Record The Policy Server record indicates the host, security gateway, or policy server for which a particular policy server is authoritative. It represents an assertion, typically made by a policy server, with repect to a member of a security domain that the server represents. The record includes the Identity of the policy server and the identity of a node (host, security gateway, another server, etc.). Figure 12 shows the format of the Policy Server Record. Sanchez, Condell [page 23] Internet Draft Security Policy Protocol January 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CACHE-EXPIRY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ POLICY SERVER IDENTITY ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ NODE IDENTITY ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Policy Server record format The Policy Server Record fields are defined as follows: CACHE-EXPIRY A 4 octet field indicating the maximum amount of time, in seconds, this policy record MAY be cached. FLAGS A 2 octet field indicating different options to aid in interpreting the server and node data. If not in use, set value to all zeros (0). Currently, no flag values are defined so this field MUST be set to zero (0). RESERVED A 2 octet field reserved for future use. Set value to all zeros (0). POLICY SERVER IDENTITY This variable length field contains the identity of the policy server. It may contain an IP address (unicast) either in IPv4 or IPv6 format. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 1 and 2. NODE IDENTITY This variable length field contains the identity of a node for which the policy server is authoritative. It may contain an IP address (unicast) either in IPv4 or IPv6 format. The encoding format is specified in section 7. The acceptable DATA_TYPE values are 1 and 2. Sanchez, Condell [page 24] Internet Draft Security Policy Protocol January 2002 5.5 CERT Record The CERT record contains one public key certificate. This record is provided in SPP as an alternate mechanism for certificate dispatching. Figure 13 shows the format of the CERT Record. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CACHE-EXPIRY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT_TYPE | | +-+-+-+-+-+-+-+-+ | ~ CERT_DATA ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Certificate Record Format CACHE-EXPIRY A 4 octet field indicating the maximum amount of time, in seconds, this policy record MAY be cached. CERT_TYPE This 1 octet field indicates the type of certificate or certificate-related information contained in the Certificate Data field. The values for this field are described in Section 4.3. CERT_DATA This variable length field contains the actual encoding of certificate data. The type of certificate is indicated by the Certificate Type field. 6. Transfer Records This record contains the text of the master file that is used to configure the primary policy server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ MASTER FILE TEXT ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Security Gateway Record Format The Transfer Record field is defined as follows: Sanchez, Condell [page 25] Internet Draft Security Policy Protocol January 2002 MASTER FILE TEXT This variable length field contains the text of the master file that is used to configure the policy server. 7. Policy Attribute Encoding Query and Record payloads include several different selector types and SA attributes with their associated values. These data are encoded following a Type/Length/Value (TLV) format to provide flexibility for representing different kinds of data within a payload. Certain Data_Types with values of length equal to 2 octets follow the Type/Value (T/V) format. The first bit of the DATA_TYPE field is used to distinguished between the two formats. A value of (0) indicates a TLV format while a value of (1) indicates TV format. This generic encoding format is depicted in figure 15. X = 0: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| DATA_TYPE | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA_VALUE... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X = 1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| DATA_TYPE | DATA_VALUE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Generic Data Attribute Formats The generic data attribute fields are defined as follows: X This bit indicates if the DATA_TYPE follows the TLV(0) or the TV(1) format. DATA_TYPE A 2 octet field indicating the selector type. The currently defined values are: Sanchez, Condell [page 26] Internet Draft Security Policy Protocol January 2002 DATA DATA_TYPE X IPV4_ADDR 1 0 IPV6_ADDR 2 0 SRC_IPV4_ADDR 3 0 SRC_IPV4_ADDR_SUBNET 4 0 SRC_IPV4_ADDR_RANGE 5 0 DST_IPV4_ADDR 6 0 DST_IPV4_ADDR_SUBNET 7 0 DST_IPV4_ADDR_RANGE 8 0 SRC_IPV6_ADDR 9 0 SRC_IPV6_ADDR_SUBNET 10 0 SRC_IPV6_ADDR_RANGE 11 0 DST_IPV6_ADDR 12 0 DST_IPV6_ADDR_SUBNET 13 0 DST_IPV6_ADDR_RANGE 14 0 DIRECTION 15 1 USER_NAME 16 0 SYSTEM_NAME 17 0 XPORT_PROTOCOL 18 0 SRC_PORT 19 0 SRC_PORT_DYNAMIC 20 0 DST_PORT 21 0 DST_PORT_DYNAMIC 22 0 SEC_LABELS 23 0 V6CLASS 24 1 V6FLOW 25 0 V4TOS 26 1 ACTION 27 1 SRC_PORT_RANGE 28 0 DST_PORT_RANGE 29 0 IPSEC_ACTION 50 0 ISAKMP_ACTION 51 0 values 30-49 and 52-3200 are reserved to IANA. Values 3200-32767 are for private use among mutually consenting parties. LENGTH A 2 octet field indicating the length of the selector value in octets, not including any trailing padding added to the DATA_VALUE field. The padding length is implicit. DATA_VALUE A variable length field containing the value of the selector specified by DATA_TYPE. If the Selector value is not aligned at the 4 octet boundary the field MUST be padded on the right with (00)hex to align on the next 32-bit boundary. Sanchez, Condell [page 27] Internet Draft Security Policy Protocol January 2002 8. SPP Message Processing SPP messages use UDP or TCP as their transport protocol. Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Fragmentation is allowed for messages containing more than 512 bytes. The SPP-XFR message SHOULD use TCP to transfer the contents of the SPS Database from a primary to secondary policy server. A port number has not yet been assigned for use with SPP. For now SPP uses private UDP and TCP ports 55555. 8.1 General Message processing For an SPP-Query or SPP-Pol message, the transmitting entity MUST do the following: 1. Set a timer and initialize a retry counter. 2. If an SPP-Reply or SPP-Pol_Ack message corresponding to the appropriate SPP-Query or SPP-Pol message is received within the time interval, or before the retry counter reaches 0, the transmitting entity continues normal operation. 3. If an SPP-Reply or SPP-Pol_Ack message corresponding to the appropriate SPP-Query or SPP-Pol message is not received within the time interval and a secondary policy server, which has not been attempted on this value of the retry counter, is available, the message is sent to the secondary server. If all the secondary servers fail to respond within the time interval, decrement the retry counter and resend the message to the primary server. 4. If the retry counter reaches zero (0) the event MAY be logged in the appropriate system audit file. 5. Following step 4, processing is more specific: - For hosts and security gateways: o the transmitting entity will clear state for this peer and revert to using conventional security mechanisms. - For policy servers: o For SPP-Pol messages, clear state for this peer. o For SPP-Query messages, clear state for this peer, lookup policy in the server's SPS database and send an SPP-Reply message per section 8.3 with the policy and MCODE 11. Sanchez, Condell [page 28] Internet Draft Security Policy Protocol January 2002 8.2 Query Message (SPP-Query) Processing When creating a SPP-Query message, the entity (host, security gateway, or policy server) MUST do the following: 1. Generate the Message ID value. This value starts at zero (0) and MUST be incremented by (1) with every new message. 2. Set the value of the MTYPE field to 1 3. Set the MCODE value to zero (0). 4. Set the QCOUNT and RCOUNT fields. All fields MUST be set to zero (0) when their corresponding payloads do no exist. 5. Set the flag bits accordingly and set the RESERVED field to zero (0). 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP message. 7. Construct the SPP data payloads. A Query payload MUST be present in this message. 8. Local policy information related to the query MAY be included as Record payloads following the Query payloads. 9. A Policy Server record and a Cert Record SHOULD also be included in the message. A Cert record MUST be included if the query is a Cert Query to avoid a possible certificate query loop. 10. Calculate and place the timestamp value used for anti-replay attack protection. 11. If the Signature payload is required for message integrity and authentication, calculate a signature over the SPP header, SPP payloads, the PCL, TYPE, and LENGTH fields of the Signature payload. If required, the Signature payload MUST be the last payload in the message. When a policy server receives an SPP-Query message it MUST do the following: 1. Check for SPP access control. If enabled, read the IP address in the Sender's field of the SPP header. - Verify whether or not the message is allowed. If the message is not allowed then: o send an SPP-Reply message with the MCODE 2 or 7 o discard message and the event MAY be logged. - If the message is allowed, continue. Sanchez, Condell [page 29] Internet Draft Security Policy Protocol January 2002 2. Check timestamp field for anti-replay protection. If a replayed message is detected: - send an SPP-Reply message with the MCODE 3 or 7 - discard message and the event MAY be logged. 3. If the message requires signature validation. - If a certificate record is present, the server MUST process it, however, if the server already has a valid key for the host or server identified in the certificate, the certificate MAY be ignored. - Fetch certificate or key corresponding to the IP address found in the sender field of the SPP header. - If a certificate or key is not available the entity MAY, depending on configuration: o choose to abort validation process, send SPP-Reply message with MCODE 5 or 7, discard the message, and MAY log the event. o send an SPP-Query message to the source of the IP address found in the sender field of the SPP header with a CERT Query payload. Keep the SPP-Query message until the SPP-Reply returns. Extract certificate or key, validate it and proceed. - Once a validated certificate or key is available then validate signature. o If validation fails, send SPP-Reply message with MCODE 5 or 7, discard the message, and the event MAY be logged. 4. Parse the Query records. - If the SPP-Query message only contains cert queries: o If the Identity field identifies the server or a member of the server's security domain, send an SPP-Reply message per section 8.3 with one or more cert records with the certificates in the certification chain between the requested Identity and Certificate_Authority and MCODE 1. o Otherwise, send an SPP-Reply message per section 8.3 with with MCODE 9 or 7. Sanchez, Condell [page 30] Internet Draft Security Policy Protocol January 2002 - If the SPP-Query message does not only contain cert queries: o Check the Destination Address Data field to determine if the message received was intended for a node that is a member of the server's security domain. o Continue processing. 5. If the message is for a node that is a member of the server's security domain or the D bit in the SPP header is set and the server is the outermost server that is authoritative over the client or server that sent the message, then: - Using src, dst, and any other applicable fields found in the Query Payload, search the SPS database for an appropriate policy. o If a policy is found then construct an SPP-Reply message per section 8.3 with appropriate payloads and MCODE 1. o If a policy is not found then construct an SPP-Reply message per section 8.3 with appropriate payloads and MCODE 9 or 7. 6. If the message is for a node that is not part of the server's security domain then: - If the I and R bits are not set in the SPP header, check the Cache database for any relevant policies that apply to this communication. o If a policy is found then construct a SPP-Reply message per section 8.3 with appropriate payloads and MCODE 1. o If a policy is not found then continue. - Check the Local database for any relevant policies that apply to this communication. - If the server is authoritative for the source address of the query or a matching policy is found (A matching policy is defined as a policy that either produces a comsec record with an action attribute with the value "deny", or a policy that would produce an SA record with one or more IPsec action and IKE action attributes. A policy that only produces a comsec record with an action attribute with the value "permit" is not considered matching for this step.): o Generate a new SPP-Query message. The new message MUST use the same query payload as the old message. If the new query will include policy from the server, then the policy used SHOULD be the server's local policy merged with any policies received with the query message. The Sender Address will be the address of the server. The destination for this message MUST be the one in the original SPP-Query received. Sanchez, Condell [page 31] Internet Draft Security Policy Protocol January 2002 o Keep state. Upon reception of the corresponding SPP-Reply the policy server MUST send an SPP-Reply addressed to sender of the original SPP-Query. - If the server is not authoritative for the source address of the query and a matching policy is not found then: o The policy server MUST send the SPP-Query message unchanged. The SPP-Query message MUST use the same source port that was used to send it to the server so the next server that processes the query will return it to the correct port. This SPP-Query message MUST NOT be added to the retry queue (section 8.1). 8.3 Reply Message (SPP-Reply) Processing When creating a SPP-Reply message, the policy server MUST do the following: 1. Copy the Message ID value from the corresponding SPP-Query message into the Message ID field. 2. Set the value of the MTYPE field to 2 3. Set the MCODE value. 4. Set the QCOUNT and RCOUNT fields. All fields MUST be set to zero (0) when their corresponding payloads do no exist. 5. Set the flag bits accordingly and set the RESERVED field to (0). 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP message. 7. Copy the Query payloads from the SPP-Query message to the SPP-Reply message. 8. Construct the SPP data payload. Unless there is an error, at least one record corresponding to each Query payload MUST be present. 9. A policy server record and a CERT record MUST be added to the SPP-Reply message if the the query to which this is a reply did NOT have the T bit set. If the T bit is set, the records SHOULD NOT be added. 10. Calculate and place the timestamp value used for anti-replay attack protection. 11. If the Signature payload is required for message integrity and authentication, calculate a signature over the SPP header, SPP payloads, the PCL, TYPE, and LENGTH fields of the Signature payload. If present, the Signature payload MUST be the last payload in the message. Sanchez, Condell [page 32] Internet Draft Security Policy Protocol January 2002 12. The SPP-Reply message is sent to the host that is listed in the Sender ID field of the SPP-Query to which this is a reply. When a host or security gateway receives an SPP-Reply message it MUST do the following: 1. Read the Message ID field. If the value does not match the value of an outstanding SPP-Query message from a policy server then: - silently discard the message and the event MAY be logged. 2. If Message ID matches, Check the timestamp field for anti-replay protection. If a replayed message is detected the message is silently discarded and the event MAY be logged. 3. Establish if the message requires signature validation by searching for a Signature payload: - if signature validation is required proceed with step 4. - if signature validation is not required proceed with step 6. 4. Validate the signature on the message. - If a certificate record is present, the server MUST process it, however, if the server already has a valid key for the host or server identified in the certificate, the certificate MAY be ignored. - Fetch certificate or key corresponding to the IP address found in the sender field of the SPP header. - If a certificate or key is not available the entity MAY: o choose, depending on configuration, to abort validation process, discard the message and MAY log the event. o send an SPP-Query message to the source of the IP address found in the sender field of the SPP header with a CERT query payload. Keep SPP-Reply message until the corresponding SPP-Reply returns. Extract certificate or key, validate it and proceed. 5. Once a validated certificate or key is available then validate signature. If validation fails: - the message is silently discarded and the event MAY be logged If validation succeeds, continue processing. 6. For Policy Servers, validate the chain of trust. A valid chain proves that policy has only been applied by servers authorized to control policy over either the source or destination host of the requested policy. The "chain" represents the hierarchy of policy servers authoritative over Sanchez, Condell [page 33] Internet Draft Security Policy Protocol January 2002 the source of the communication and the heirarchy over the destination. The chain may have a single "break" between the two policy servers that represent the top of the two heirarchies. It is formed by the information in the Policy Server records and must be cryptographically proven that the relationships described in those records are true. - For each Policy Server record, verify that the Policy Server is authoritative over the Node. This MUST be verified cryptographically which MAY be accomplished using X.509 certificates [PKIXP1]. See section 11 for more details. - Use the Policy Server records to Create a chain of hosts from the destination host to this policy server where two records are linked if the Node in one is the Policy Server in another. - If the chain has no breaks, then this policy server MUST be authoritative over the sender of the reply, otherwise drop the message and stop processing it. - If the chain has one break, then the last policy server on the chain MUST be the sender of the reply, otherwise drop the message and stop processing it. - If the chain has two or more breaks, then there is an error in the chain so drop the message and stop processing it. - Verify that the Policy Server that is authoritative over the destination host is authoritative over ALL destination hosts in any comsec records. 7. If MCODE value is 2-7, 9 or 10: For hosts or security gateways: - clear all the state and stop processing For policy servers: - create an SPP-Reply message using the same MCODE value. 8. If the reply received correponds to a Cert query and the MCODE is either (1) or (8) (accept or partially unavailable), process message that was held up waiting for the cert. 9. For Policy Servers: - Search the Local Policy Database for a policy entry that matches the policy expressed in Query payload. - If the R bit is not set, merge the local and non-local policy information using the policy resolution proccess outlined in section 9. - If the R bit is set, include both the policies found in the Local Policy Database and the policies in the reply to send in the new reply. Sanchez, Condell [page 34] Internet Draft Security Policy Protocol January 2002 - If the merge fails send an SPP-Reply message with MCODE 10 or 7 and cache the failure. - If the merge succeeds or the R bit is set: o If the R and C bits are not set, cache policy information. This includes all Record payloads. o send an SPP-Reply message with the resulting policy records and MCODE 1. o If the R and D bits are not set and the merge indicated that policies should be sent to one or more security gateways, construct a signal for each gateway by creating an SPP-Pol message with the appropriate policy from the merge. 10. For hosts or security gateways: - verify that the information in the Record payload corresponds to the information in the Query payload. - extract the records and create a policy entry in the SPD according to local format. The policy is entered in the SPD ONLY if local configuration allows. 8.4 Policy Message (SPP-Pol) Processing When creating a SPP-Pol message, the entity (host, security gateway, or policy server) MUST do the following: 1. Generate the Message ID value. This value starts at zero (0) and MUST be incremented by (1) with every new message. 2. Set the value of the MTYPE field to 3. 3. Set the MCODE value to zero (0). 4. Set the RCOUNT field. The QCOUNT field MUST be set to zero (0) since no query payloads exist. 5. Set the flag bits accordingly and set the RESERVED field to (0). 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP message. 7. Construct the SPP data payloads. A Record payload MUST be present in this message. Query payloads MUST NOT be present. 8. Calculate and place the timestamp value used for anti-replay attack protection. 9. If the Signature payload is required for message integrity and authentication, calculate a signature over the SPP header, SPP payloads, the PCL, TYPE, and LENGTH fields of the Signature payload. If required, the Signature payload MUST be the last payload in the message. Sanchez, Condell [page 35] Internet Draft Security Policy Protocol January 2002 When a policy server receives an SPP-Pol message it MUST do the following: 1. Check for SPP access control. If enabled, read the IP address in the Sender's field of the SPP header. - Verify whether or not the message is allowed. If the message is not allowed then: o send an SPP-Pol_Ack message with the MCODE 2 or 7 o discard message and the event MAY be logged. - If the message is allowed, continue. 2. Check timestamp field for anti-replay protection. If a replayed message is detected: - send an SPP-Pol_Ack message with the MCODE 3 or 7 - discard message and the event MAY be logged. 3. If the message requires signature validation: - If a certificate record is present, the server MUST process it, however, if the server already has a valid key for the host or server identified in the certificate, the certificate MAY be ignored. - Fetch certificate or key corresponding to the IP address found in the sender field of the SPP header. - If a certificate or key is not available the entity MAY, depending on configuration: o choose to abort validation process, send SPP-Pol_Ack message with MCODE 5 or 7, discard the message and MAY log the event. o send an SPP-Query message to the source of the IP address found in the sender field of the SPP header with a CERT Query payload. Keep SPP-Pol message until the SPP-Reply returns. Extract certificate or key, validate it and proceed. - Once a validated certificate or key is available then validate signature. o If validation fails the message is silently discarded and the event MAY be logged 4. If signature was not required or upon successful validation of a signature parse the payloads. Sanchez, Condell [page 36] Internet Draft Security Policy Protocol January 2002 5. For hosts and security gateways: - extract the records and create a policy entry in the cache database. The policy MAY also be entered in the SPD, ONLY if configuration allows. 6. For Policy Servers: - extract the records, find corresponding policies in the server's SPS database, merge the two sets of policies, and create a policy entry in the cache database. 7. Send an SPP-Pol_Ack message with MCODE 1. 8.5 Policy Acknowledgement Message (SPP-Pol_Ack) Processing When creating a SPP-Pol_Ack message, the policy server MUST do the following: 1. Copy the Message ID value from the corresponding SPP-Pol message into the Message ID field. 2. Set the value of the MTYPE field to 4 3. Set the MCODE value. 4. Set the QCOUNT and RCOUNT fields. All fields MUST be set to zero (0). 5. Set the flag bits accordingly and set the RESERVED field to (0). 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP message. 7. Query or Record payloads MUST NOT be present. 8. Calculate and place the timestamp value used for anti-replay attack protection. 9. If the Signature payload is required for message integrity and authentication, calculate a signature over the SPP header, the PCL, TYPE, and LENGTH fields of the Signature payload. When a host, security gateway, or policy server receives an SPP-Pol_Ack message the entity MUST do the following: 1. Read the Message ID field. If the value does not match the value of an outstanding SPP-Pol message from a policy server then: - silently discard the message and the event MAY be logged. 2. If Message ID matches then check the timestamp field for anti-replay protection. If a replayed message is detected the message is silently discarded and the event MAY be logged. Sanchez, Condell [page 37] Internet Draft Security Policy Protocol January 2002 3. If the message is original (not replayed) and the message requires signature validation then: - If a certificate record is present, the server MUST process it, however, if the server already has a valid key for the host or server identified in the certificate, the certificate MAY be ignored. - Fetch certificate or key corresponding to the IP address found in the sender field of the SPP header. - If a certificate or key is not available the entity MAY: o choose, depending on configuration, to abort validation process, discard the message and MAY log the event. o send an SPP-Query message to the source of the IP address found in the sender field of the SPP header with a CERT Query payload. Keep SPP-Pol_ack message until the SPP-Reply returns. Extract certificate or key, validate it and proceed. 4. Once a validated certificate or key is available then validate the signature. If validation fails: - the message is silently discarded and the event MAY be logged If validation succeeds: - read the MCODE field and proceed accordingly. If no errors, clear all the state for this message and proceed. 8.6 Transfer Message (SPP-XFER) Processing When creating an SPP-Xfer message, the policy server MUST do the following: 1. Generate the Message ID value. This value starts at zero (0) and MUST be incremented by (1) with every new message. 2. Set the value of the MTYPE field to 5. 3. Set the MCODE value to (0). 4. Set the RCOUNT field. The QCOUNT field MUST be set to zero (0) since no query payloads exist. 5. Set the flag bits accordingly and set the RESERVED field to zero (0). 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP message. 7. Construct the SPP data payloads. A single Transfer Record MUST be present in this payload and MUST contain the master file used to configure this policy server. Sanchez, Condell [page 38] Internet Draft Security Policy Protocol January 2002 8. Calculate and place the timestamp value used for anti-replay attack protection. 9. If the Signature payload is required for message integrity and authentication, calculate a signature over the SPP header, SPP payloads, the PCL, TYPE, and LENGTH fields of the Signature payload. If required, the Signature payload MUST be the last payload in the message. When a security gateway receives an SPP-Xfer message it MUST do the following: 1. Check for SPP access control. If enabled, read the IP address in the Sender's field of the SPP header. - Verify whether or not the message is allowed. If the message is not allowed then: o discard message and the event MAY be logged. - If the message is allowed, continue. 2. Check timestamp field for anti-replay protection. If a replayed message is detected: - discard message and the event MAY be logged. 3. If the message requires signature validation: - If a certificate record is present, the server MUST process it, however, if the server already has a valid key for the host or server identified in the certificate, the certificate MAY be ignored. - Fetch certificate or key corresponding to the IP address found in the sender field of the SPP header. - If a certificate or key is not available the entity MAY, depending on configuration: o choose to discard the message, and MAY log the event. o send an SPP-Query message to the source of the IP address found in the sender field of the SPP header with a CERT Query payload. Keep the SPP-Query message until the SPP-Reply returns. Extract certificate or key, validate it and proceed. - Once a validated certificate or key is available then validate signature. o discard the message, and the event MAY be logged. Sanchez, Condell [page 39] Internet Draft Security Policy Protocol January 2002 4. If signature was not required or upon successful validation of a signature parse the payload. - extract the Transfer Record and save the master file that it contains. - Flush the contents of the SPS database, domain database, and cache. - Load the new information from the transferred master file into the databases. 8.7 KeepAlive Message (SPP-KEEP_ALIVE) Processing When creating an SPP-Keep_Alive message, the policy server MUST do the following: 1. Generate the Message ID value. This value starts at zero (0) and MUST be incremented by (1) with every new message. 2. Set the value of the MTYPE field to 6. 3. Set the MCODE value to zero (0). 4. Set the QCOUNT and RCOUNT fields. All fields MUST be set to zero (0). 5. Set the flag bits accordingly and set the RESERVED field to (0). 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP message. 7. Query or Record payloads MUST NOT be present. 8. Calculate and place the timestamp value used for anti-replay attack protection. 9. If the Signature payload is required for message integrity and authentication, calculate a signature over the SPP header, the PCL, TYPE, and LENGTH fields of the Signature payload. When a host or security gateway receives an SPP-Keep_Alive message it MUST do the following: 1. Check for SPP access control. If enabled, read the IP address in the Sender's field of the SPP header. - Verify whether or not the message is allowed. If the message is not allowed then discard message and the event MAY be logged. 2. Check timestamp field for anti-replay protection. If a replayed message is detected discard message and the event MAY be logged. Sanchez, Condell [page 40] Internet Draft Security Policy Protocol January 2002 3. If the message requires signature validation then: - If a certificate record is present, the server MUST process it, however, if the server already has a valid key for the host or server identified in the certificate, the certificate MAY be ignored. - Fetch certificate or key corresponding to the IP address found in the sender field of the SPP header. - If a certificate or key is not available the entity MAY depending on configuration: o choose to abort validation process, discard the message and the event MAY be logged. o send an SPP-Query message to the source of the IP address found in the sender field of the SPP header with a CERT Query payload. Keep SPP-Keep_Alive message until the SPP-Reply returns. Extract certificate or key, validate it and proceed. - Once a validated certificate or key is available then validate signature. o If validation fails the message is silently discarded and the event MAY be logged 4. If signature validation was not required or upon successful validation of a signature, the event MAY be logged. 9. Policy Resolution When a policy server receives a reply, it must merge its local policy for the communication with any non-local policies contained in the reply. The merging process creates a new policy that is the intersection of the local and remote policies. It then uses the merged policy as its reply to the query and caches it. The policy resolution process is as follows. A message (set of policies) consists of one comsec record and zero or more SA recs that apply to the communication in the comsec record. 1. Get local and remote policies for the requested communication. 2. Verify that the remote policy answer the query. This may be accomplished by intersecting the query with the comsec record int the answer and verify that they have a non-nil intersection. 3. Merge the local and remote comsec records. If they don't merge return error. If they do put merged comsec record in answer. Sanchez, Condell [page 41] Internet Draft Security Policy Protocol January 2002 4. Merge the two sets of policies (SA recs). The merge must: - Find the intersection of the policies between matching endpoints. o If the intersection is nil, then the policies do not permit the communication and an error should be returned. It is not necessary to continue processing other endpoints. o If the intersection is not nil, then the intersection should be added to the reply policy. - Take into account ipsec action locations when determining the endpoints to intersect. - preserve the ordering of the policies so that the SA recs are generated in the correct order. 5. The policy created by the intersections is the policy that should be cached and used as a reply to the query. Step 4 requires that the policy server must be able to determine all the sets of endpoints described by the policy. The endpoint information comes from two places: the source and destination addresses in the query (which is possibly more specific than those fields in the policies) and the location information in the ipsec_action attribute. Section 9.1 describes a method of processing this step in more detail. The location information may offer the policy server some flexibility in how it interprets endpoints for the communication. For example, if the policy indicates a tunnel must be established with any host or gateway in the source or destination host's domain, the policy server can choose the endpoint within the bounds of the policy. This choice can be made randomly, using a set policy (e.g., always choose the outermost gateway permitted by the policy), or using additional information the server may maintain for this purpose. For example, the server may keep track of previous policy decisions it made and use those as hints to which security associations may already exist. It can then try to make decisions that will allow these security associations to be reused. 9.1 Expansion of step 4 This section describes a method of merging two sets of policies. It describes which policies should be merged together and how to maintain the appropriate order of the policies. It does not describe the merging of individual policies which involves taking the intersecting the selectors and appliers. Other methods to implement the merge may be used. Start with two sets of ordered policies. One set is the remote set of policies that has been received through an SPP exchange. The other is a local set of policies that was found in a local policy database. Sanchez, Condell [page 42] Internet Draft Security Policy Protocol January 2002 1) Attempt to merge any records that may be merged and interleave messages to preserve ordering: for each SA rec in remote message: Check remote src, dst, location src, and location dst endpoints against SA recs in local message, in order. Check against the following rules which are grouped into three priorities. The high priority is for those policies that match and should be merged. The low priority is for those policies that don't merge, but care must be taken to insure that they are ordered correctly. The final group is policies that do not match in any way. Attempt to match each of the unprocessed local SA recs to the remote SA rec. Find the SA rec (or SA recs, there might be more than one applicable match) to find the highest priority match. If the highest priority match is a low priority match, compare it to the remaining remote SA recs. If there is a remote SA rec to which it has a high priority match, take the local SA rec and goto step 3. Otherwise, process the romote SA rec against each of the highest matching local SA recs as specified by their priority. High Priority Matches: o if both the remote src and dst match the local src and dst and either the remote location src and dst and the local location src and dst match or the local or remote location src and dst are set to zero and the other location src and dst match the src and dst - take each unprocessed SA rec in the local message before this matching one and goto 3. - merge the two SA recs and goto 3. o if (remote src and dst match the local location src and dst and the remote location src and dst either match the remote src and dst or are zero) or (local src and dst match the remote location src and dst and the local location src and dst either match the local src and dst or are zero), then: - take each unprocessed SA rec in the local message before this one and goto 3. Sanchez, Condell [page 43] Internet Draft Security Policy Protocol January 2002 - Take the SA rec with the location endpoints that matched the other src and dst and send it to step 3, but return the results here for further processing. - merge the other SA rec with the SA rec resulting from 3 that has the same src and dst. Take this merged SA rec and goto 3. If the sa rec that was sent to step 3 above was the local sa rec, send the remaining SA recs that resulted from 3 to step 3, otherwise send them to step 2. Low Priority Matches: o If both the remote src and dst match the local src and dst but the remote location src and dst and the local location src and dst do not match, then they do not merge. - take each unprocessed SA rec in the local message before this one and goto 3. - On a query, order the local SA rec before the remote SA rec. On a reply, order the remote SA rec before the local SA rec. Maintaining query/reply order, take the local SA rec to step 3 and the remote SA rec to step 2. o if the remote src and local src match, but the dsts do not, or the remote dst and local dst match and the srcs do not, then: - take each unprocessed SA rec in the local message before this one and goto 3. - On a query, order the local SA rec before the remote SA rec. On a reply, order the remote SA rec before the local SA rec. Maintaining query/reply order, take the local SA rec to step 3 and the remote SA rec to step 2. No Matches: o if no endpoints match, then goto 2. If there are any SA recs remaining in the local message, take each of them to step 3. 2) Verify local policies for non end-to-end SA recs. This involves finding policies that are being merged which involve intermediate enforcement points and check the local policy for the intermediate points. The SA rec is directly from the remote message so the communication must be verified: Sanchez, Condell [page 44] Internet Draft Security Policy Protocol January 2002 A) Check the src and dst and the location src and dst. If a pair is the same as the communication endpoints, zero, or is ambiguous, do not continue processing it. Continue processing any that do not fit these conditions. If neither pair continues processing, goto 3. o look in the local database for a policy that matches the communication described by these endpoints. o check the comsec record to verify that it is permitted. (If not deny entire communication). o For each SA rec from the local policy, except a matching SA rec, goto 3. o If there is a matching SA rec, merge it with the remote SA rec and goto 3. Else take the remote SA rec and goto 3. 3) Process location fields to resolve any ambiguities that they may describe and define any new SAs that the location fields may specify. If the loc fields are empty, then goto 4. - If the location fields and local decision making over any ambiguities indicate that a host or GW controlled by this PS should be a LOC DST, then replace the LOC DST with the gateway's ipaddress or DNS name. - If the location fields and local decision making over any ambiguities indicate that a host or GW controlled by this PS should be a LOC SRC, then replace the LOC SRC with the gateway's ipaddress or DNS name. - If both the location src and location dst fields are specific hosts or gateways (i.e. not ambiguous) and not the same as the src and dst fields, create a new SA rec to reflect the policy between the location src and dst. o create the new SA rec. - Take the original SA rec and any that have been added by this process and goto 4. 4) Create a reply message and signals to enforcement points as needed. If this is a query: Add the SA rec to the answer. Sanchez, Condell [page 45] Internet Draft Security Policy Protocol January 2002 If this is a reply: If SA rec dst is for GW controlled by this PS: - If no signal message exists for this GW, yet, create one with a comsec record formed from the information in the previous SA rec (in the order that has been established). - Add the SA rec to the signal for this GW. - Add SA rec to answer. If SA rec src is for GW controlled by this PS: - If no signal message exists for this GW, yet, create one with a comsec record formed from the information in the previous SA rec (in the order that has been established). - Add the SA rec to the signal for this GW. If neither endpoint is for GW controlled by this PS: - Add SA rec to answer. 10. IANA Considerations This document contains many "magic numbers" to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign numbers beyond the ones defined in this document. 10.1 Message Type The MTYPE field of the SPP Header (section 3.1) defines message exchange types for SPP. Requests for assignment of new message type values 7-250 must be accompanied by a reference to a standards-track or Informational RFC which describes the new message type and how it should be processed. Values 251-255 are for private use. 10.2 Message Code The MCODE field of the SPP Header (section 3.1) defines the acceptable return codes for an SPP message. Requests for assignment of new message code values 12-250 must be accompanied by a description of the conditions under which the code is returned. Values 251-255 are for private use. 10.3 Identity Type The Identity Type field of the SPP Header (section 3.1) defines the acceptable formats for identifying the sender of an SPP message. Requests for assignment of new identity types 4-250 must be accompanied by a description of the format of the corresponding SENDER IDENTITY field in the header. Values 251-255 are for private use. Sanchez, Condell [page 46] Internet Draft Security Policy Protocol January 2002 10.4 Payload Class The first octect of each payload header (section 3.2) defines the type of payload that follows it. Requests for assignment of new message type values 4-250 must be accompanied by a reference to a standards-track or Informational RFC which describes the format of the payload's header and data. Values 251-255 are for private use. 10.5 Query Type The query type (section 3.2.1) defines how the payload data will be interpreted and answered. Requests for assignment of new query type values 4-65000 must be accompanied by a reference to a standards-track or Informational RFC which describes the format of the data and how it should be used. Values 65001-65535 are for private use. 10.6 Record Type The record type (section 3.2.2) defines how the payload data will be interpreted. Requests for assignment of new record type values 4-65000 must be accompanied by a reference to a standards-track or Informational RFC which describes the format of the data and how it should be used. Values 65001-65535 are for private use. 10.7 Signature Type The signature type (section 3.2.3) defines the signature algorithm used to sign the SPP message. Requests for assignment of new signature type values 3-250 must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. Values 251-255 are for private use. 10.8 Certificate Type The Cert Type field of the Certificate query and record (section 3.1) defines the type of certificate requested or included in the payload. Requests for assignment of new certificate types 8-250 must be accompanied by a description of certificate and its encoding. Values 251-255 are for private use. 10.9 Certificate Identity Type The Identity Type and Authority Type fields of the certificate query (section 4.3) define the acceptable formats for identifying the host and its certificate authority for which a certificate is requested. Requests for assignment of new certificate identity types 5-250 must be accompanied by a description of the format of the corresponding IDENTITY and CERTIFICATE AUTHORITY fields in the payload. Values 251-255 are for private use. Sanchez, Condell [page 47] Internet Draft Security Policy Protocol January 2002 10.10 Attribute Data Type The Data_Type field of the attribute encoding (section 7) defines the type of attribute included in the data_value field. Requests for assignment of new attribute data types 30-49 and 52-3200 must be accompanied by a description of the X bit indicating if it is in TLV or TV format, a detailed description of the Data_Value field corresponding to the attribute type, and in which record and query data fields the type may be used. Values 3200-32767 are for private use. 10.11 User Name Type The Name_Type field of the user name attribute (section A.16) defines the data in the Name field of the attribute. Requests for assignment of new user name types 2-250 must be accompanied by a description of the corresponding Name field. Values 251-255 are for private use. 10.12 System Name Type The Name_Type field of the system name attribute (section A.17) defines the data in the Name field of the attribute. Requests for assignment of new system name types 9-249 must be accompanied by a description of the corresponding Name field. Values 251-255 are for private use. 10.13 IPsec Action Attribute The assigned values of Lifetime_Type, Cipher_Alg, Int_Alg_Esp, Int_Alg_Ah, and Ipcomp_Alg use the values of their associated fields in [Piper98] and are updated when the IANA updates their values in [Piper98]. The Loc_Type field of the IPsec action attribute (section A.30) defines the type of location address in the Loc_Src and Loc_Dst fields. Requests for assignment of new location types 5-250 must be accompanied by a description of the corresponding Loc_Src and Loc_Dst field. Values 251-255 are for private use. The Loc_Src and Loc_Dst fields of the IPsec action attribute (section A.30) may define a general location type. Requests for assignment of new general location values 5-250 must be accompanied by a description of the general location type. Values 251-255 are for private use. 10.14 IKE Action Attribute The assigned values of Group Description, Group_Type, Auth_Method, PRF, Lifetime_Type, Cipher_Alg, and Hash_Alg use the values of their associated fields in [Harkins98] and are updated when the IANA updates their values in [Harkins98]. Sanchez, Condell [page 48] Internet Draft Security Policy Protocol January 2002 The Mode field of the IKE action attribute (section A.31) defines the IKE Mode. Requests for assignment of new Modes 3-250 must only be done when new modes are added to the IKE protocol. Values 251-255 are for private use. 11. Security Considerations All SPP messages MUST be authenticated to prove which policy server sent the message and that it hasn't been modified en-route. The authentication MAY be provided using the signature payload provided by SPP or some other mechanism such as IPsec. However, since the policy data may change during SPP exchanges, the messages cannot maintain a signature from every policy server that is involved in the policy exchange. SPP depends on a chain-of-trust for end-to-end authentication. Messages between policy servers are authenticated and contain policy server records, which claim authorization over a node, and certificates, which include signed proof that the server is authoritative the node. The receiving server can use this information to create a chain of servers involved in the policy exchange from itself to the server authoritative over the destination of the query. This chain of authorized servers is used to prove that only servers that have authorization to be involved in the communication were involved. Section 8.3 for details on how the chain is created and verified. Policy information may be considered sensitive, since examining policies may expose expoitable weaknesses in the policies. The distribution of policies may be limited to reduce this risk. Policy distribution MAY be limited to those nodes that need to know the information. Limiting distribution any further negates the purpose of the protocol so is not allowed for proper use of SPP. Additional protections, such as privacy protection, may be desired by some domains. This can be achieved by encrypting SPP data. Encrypting SPP messages is out of scope of this document and may be discussed elsewhere. SPP uses timestamps to protect against replay attacks. This requires that nodes have adequately synchronized time-of-day clocks. It is necessary to choose an appropriately sized window of time in which timestamps may be accepted. If the window is too small, valid messages may be discarded. On the other hand, if the window is too large it may leave the server open to replay attacks. Sanchez, Condell [page 49] Internet Draft Security Policy Protocol January 2002 Acknowledgments The authors thank Charles Lynn, Steve Kent and John Zao for their participation in requirements discussions for the Security Policy System. Our gratitude to Charlie Lynn, Matt Fredette, Alden Jackson, Dave Mankins, Marla Shepard and Pam Helinek for the contributions to this document. We thank Joel Levin and Mary Hendrix (INS Corp.) for reviewing this document. We thank Isidro Castineyra for his contributions to the early parts of this work. References [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. [Kent98] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [KA98b] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [isakmp] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [RFC1305] Mills, D., "Network Time Protocol (Version 3): Specification, Implementation and Analysis", RFC 1305, March 1992. [RGSC00] F. Reichmeyer , D. Grossman, J. Strassner, M. Condell, "A Common Terminology for Policy Management" Internet Draft draft-reichmeyer-polterm-terminology-00.txt, March 2000. [PKIXP1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key Infrastructure: X.509 Certificate and CRL Profile". RFC 2459, January 1999. [Harkins98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [Piper98] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [SPS] M. Richardson, A. Keromytis, L. Sanchez, "IPsec Policy Discovery Protocol Requirements", Internet Draft, draft-richardson-ipsp-requirements-00.txt, October 1999. [SPSL] M. Condell, C. Lynn, J. Zao "Security Policy Specification Language", Internet Draft draft-ietf-ipsp-spsl-00.txt, March 2000 Sanchez, Condell [page 50] Internet Draft Security Policy Protocol January 2002 APPENDIX A DATA_TYPE Definitions The encoding of each selector and SA attribute is decribed here. Each attribute is described using the following set of data: X The value of the X bit in the attribute encoding. DATA_TYPE The value of the DATA_TYPE field in the attribute encoding. LENGTH The length of the data to use if X = 0. list 'yes' indicates the attribute may be used as a list as described below. DATA_VALUE Encoding of the DATA_VALUE field in the attribute encoding. Attributes generally encode "any" in one of two ways. If using the TLV format (X = 0) then the length is set to 0 to indicate any. If the TV format (X = 1) is used, then the value is set to 0; Attributes that may be expressed as lists provide the DATA_VALUE encoding for one element of the list. Multiple list elements may be expressed by concatenating multiple list elements. The LENGTH of attribute is the number of elements present times the length of one list element. Therefore, when reading an attribute that can be expressed as a list, the number of list elements may be determined by dividing the length by the size of a single list element. The remainder of this appendix describes the values and encoding for each selector and SA attribute specified in section 7. A.1 IPV4_ADDR X 0 DATA_TYPE 1 LENGTH 4 if an IP address is present, 0 if no IP address is present. list No DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ADDRESS An IPV4 address Sanchez, Condell [page 51] Internet Draft Security Policy Protocol January 2002 A.2 IPV6_ADDR X 0 DATA_TYPE 2 LENGTH 16 if an IP address is present, 0 if no IP address is present. list No DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ADDRESS An IPV6 address A.3 SRC_IPV4_ADDR X 0 DATA_TYPE 3 LENGTH 4 times the number of addresses in the list. A length of 0 indicates any address. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRC ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRC ADDRESS An IPV4 address representing the source host of a communication A.4 SRC_IPV4_ADDR_SUBNET X 0 DATA_TYPE 4 LENGTH 8 times the number of subnets in the list. A length of 0 indicates any subnet. list Yes DATA_VALUE Sanchez, Condell [page 52] Internet Draft Security Policy Protocol January 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUBNET ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUBNET MASK | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SUBNET ADDRESS An IPV4 address representing the source subnet of a communication SUBNET MASK An IPV4 address representing the source subnet mask of a communication A.5 SRC_IPV4_ADDR_RANGE X 0 DATA_TYPE 5 LENGTH 8 times the number of address ranges in the list. A length of 0 indicates any address. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOWER BOUND SRC ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UPPER BOUND SRC ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWER BOUND SRC ADDRESS An IPV4 address representing the includsive lower-bound of a range of source addresses of a communication. UPPER BOUND SRC ADDRESS An IPV4 address representing the includsive upper-bound of a range of source addresses of a communication. A.6 DST_IPV4_ADDR X 0 DATA_TYPE 6 LENGTH 4 times the number of addresses in the list. A length of 0 indicates any address. list Yes DATA_VALUE Sanchez, Condell [page 53] Internet Draft Security Policy Protocol January 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DST ADDRESS An IPV4 address representing the destination host of a communication A.7 DST_IPV4_ADDR_SUBNET X 0 DATA_TYPE 7 LENGTH 8 times the number of subnets in the list. A length of 0 indicates any subnet. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUBNET ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUBNET MASK | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SUBNET ADDRESS An IPV4 address representing the destination subnet of a communication SUBNET MASK An IPV4 address representing the destination subnet mask of a communication A.8 DST_IPV4_ADDR_RANGE X 0 DATA_TYPE 8 LENGTH 8 times the number of address ranges in the list. A length of 0 indicates any address. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOWER BOUND DST ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UPPER BOUND DST ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sanchez, Condell [page 54] Internet Draft Security Policy Protocol January 2002 LOWER BOUND DST ADDRESS An IPV4 address representing the includsive lower-bound of a range of destination addresses of a communication. UPPER BOUND DST ADDRESS An IPV4 address representing the includsive upper-bound of a range of destination addresses of a communication. A.9 SRC_IPV6_ADDR X 0 DATA_TYPE 9 LENGTH 16 times the number of addresses in the list. A length of 0 indicates any address. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRC | | ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRC ADDRESS An IPV6 address representing the source host of a communication A.10 SRC_IPV6_ADDR_SUBNET X 0 DATA_TYPE 10 LENGTH 32 times the number of subnets in the list. A length of 0 indicates any subnet. list Yes DATA_VALUE Sanchez, Condell [page 55] Internet Draft Security Policy Protocol January 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SUBNET | | ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SUBNET | | MASK | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SUBNET ADDRESS An IPV6 address representing the source subnet of a communication SUBNET MASK An IPV6 address representing the source subnet mask of a communication A.11 SRC_IPV6_ADDR_RANGE X 0 DATA_TYPE 11 LENGTH 32 times the number of address ranges in the list. A length of 0 indicates any address. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LOWER BOUND | | SRC ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | UPPER BOUND | | SRC ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWER BOUND SRC ADDRESS An IPV6 address representing the includsive lower-bound of a range of source addresses of a communication. Sanchez, Condell [page 56] Internet Draft Security Policy Protocol January 2002 UPPER BOUND SRC ADDRESS An IPV6 address representing the includsive upper-bound of a range of source addresses of a communication. A.12 DST_IPV6_ADDR X 0 DATA_TYPE 12 LENGTH 16 times the number of addresses in the list. A length of 0 indicates any address. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DST | | ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DST ADDRESS An IPV6 address representing the destination host of a communication A.13 DST_IPV6_ADDR_SUBNET X 0 DATA_TYPE 13 LENGTH 32 times the number of subnets in the list. A length of 0 indicates any subnet. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SUBNET | | ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SUBNET | | MASK | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sanchez, Condell [page 57] Internet Draft Security Policy Protocol January 2002 SUBNET ADDRESS An IPV6 address representing the destination subnet of a communication SUBNET MASK An IPV6 address representing the destination subnet mask of a communication A.14 DST_IPV6_ADDR_RANGE X 0 DATA_TYPE 14 LENGTH 32 times the number of address ranges in the list. A length of 0 indicates any address. list Yes DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LOWER BOUND | | DST ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | UPPER BOUND | | DST ADDRESS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOWER BOUND DST ADDRESS An IPV6 address representing the includsive lower-bound of a range of destination addresses of a communication. UPPER BOUND DST ADDRESS An IPV6 address representing the includsive upper-bound of a range of destination addresses of a communication. A.15 DIRECTION X 1 DATA_TYPE 15 LENGTH TV attribute, no length list No DATA_VALUE Sanchez, Condell [page 58] Internet Draft Security Policy Protocol January 2002 1 2 3 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DIRECTION | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DIRECTION In/Outbound 0 Inbound 1 Outbound 2 Direction is with respect to the senders interface. A.16 USER_NAME X 0 DATA_TYPE 16 LENGTH 1 plus the length of NAME A length of 0 indicates any name. list No DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME_TYPE | NAME ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NAME_TYPE 822_EMAIL 0 DIST_NAME 1 values 2-250 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. NAME Name of type NAME_TYPE: NAME_TYPE Description of NAME 822_EMAIL A fully-qualified user name string (e.g. "jdoe@example.com") as defined in RFC 822. The string must not contain any terminators DIST_NAME A fully-qualified distinguished name string (e.g. "CN=John Doe, O=Example, Inc, C=US ") as defined in RFC 1779. The string must not contain any terminators Sanchez, Condell [page 59] Internet Draft Security Policy Protocol January 2002 A.17 SYSTEM_NAME X 0 DATA_TYPE 17 LENGTH 1 plus the length of NAME A length of 0 indicates any name. list No DATA_VALUE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME_TYPE | NAME ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NAME_TYPE DNS_NAME 0 DIST_NAME 1 822_NAME 2 X400_ADDR 3 DIR_NAME 4 EDI_PARTY_NAME 5 URI 6 IPADDR 7 REGID 8 OTHER 250 values 9-249 are reserved to IANA. Values 251-255 are for private use among mutually consenting parties. NAME Name of type NAME_TYPE. Strings must not contain any terminators. NAME_TYPE Description of NAME DNS_NAME A DNS name string (e.g. "host.example.com") as defined in RFC 1034. DIST_NAME A fully-qualified distinguished name string (e.g. "CN=John Doe, O=Example Inc, C=US ") as defined in RFC 1779. 822_EMAIL A fully-qualified user name string (e.g. "jdoe@example.com") as defined in RFC 822. X400_ADDR A textual representation of an X.400 OR address string (e.g. "/CN=John Doe/O=Example Inc/C=US/") as defined in RFC 2156. Sanchez, Condell [page 60] Internet Draft Security Policy Protocol January 2002 DIR_NAME A relative distinguished name string (e.g. "OU=Engineering + CN=John Doe, O=Example Inc, C=US ") as defined in RFC 1779. EDI_PARTY_NAME An electronic data interchange name string. URI A uniform resource identifier string (e.g. "ftp://ftp.example.com/pub/doc.html") as defined in RFC 2396. IPADDR A 32-bit or 128-bit IP address. Note that this is NOT the string representation of the IP address. REGID A registered ID is represented by a string representation of the dotted integer representation of an object ID (OID) (e.g. "4.5.8.2.1"). OTHER This is an object identifier followed by object specific information. The OID is represented as above, however, its end is indicated by a colon ":" which is followed by the object specified inf