idnits 2.17.1 draft-ietf-ipsec-spsl-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 8) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 23 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1520 has weird spacing: '...srr-dst tcp-...' == Line 1521 has weird spacing: '...srr-dst tcp-...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 1999) is 9059 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9' is mentioned on line 1986, but not defined == Missing Reference: '0-4' is mentioned on line 1984, but not defined == Missing Reference: '0-5' is mentioned on line 1984, but not defined ** Obsolete normative reference: RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8859' ** Obsolete normative reference: RFC 2401 (ref. 'Kent98') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2459 (ref. 'PKIXP1') (Obsoleted by RFC 3280) -- Possible downref: Normative reference to a draft: ref. 'PolMod' ** Obsolete normative reference: RFC 2280 (ref. 'RPSL') (Obsoleted by RFC 2622) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Normative reference to a draft: ref. 'SPS' Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Condell, BBN 2 draft-ietf-ipsec-spsl-01.txt C. Lynn, BBN 3 Expires January 2000 J. Zao, BBN 4 July 1, 1999 6 Security Policy Specification Language 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes the Security Policy Specification Language 32 (SPSL), a language designed to express security policies, security 33 domains, and the entities that manage the policies and domains. The 34 syntax and semantics of the language are presented here. SPSL 35 currently supports policies for packet filtering, IP Security (IPSec), 36 and IKE exchanges, however, it may easily be extended to express 37 other types of policies. 39 Table of Contents 41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 1.1 Language Requirements . . . . . . . . . . . . . . . . . . . . . 3 43 1.1.1 Specification of Security Policies. . . . . . . . . . . . . 3 44 1.1.2 Node- and Domain-Based Models . . . . . . . . . . . . . . . 4 45 1.1.3 Multiple Distributed Policy Enforcement Points. . . . . . . 5 46 1.1.4 Authentication and Authorization Mechanisms . . . . . . . . 5 47 1.1.5 Language Flexibility and Extensibility. . . . . . . . . . . 5 48 1.2 Language Structure. . . . . . . . . . . . . . . . . . . . . . . 6 49 1.2.1 Categories. . . . . . . . . . . . . . . . . . . . . . . . . 6 50 1.2.2 Class Design. . . . . . . . . . . . . . . . . . . . . . . . 6 51 1.2.3 Naming Scheme and Scope . . . . . . . . . . . . . . . . . . 7 52 1.2.4 $INCLUDE Extension. . . . . . . . . . . . . . . . . . . . . 8 54 2. Primitive Data Types . . . . . . . . . . . . . . . . . . . . . . . 8 56 3. Management Agent Classes . . . . . . . . . . . . . . . . . . . . . 10 57 3.1 mntner Class. . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 3.2 cert Class. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 4. Network Entity Classes . . . . . . . . . . . . . . . . . . . . . . 14 61 4.1 node Class. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 4.2 node-set Class. . . . . . . . . . . . . . . . . . . . . . . . . 15 63 4.3 gateway Class . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 4.4 gateway-set Class . . . . . . . . . . . . . . . . . . . . . . . 16 65 4.5 polserv Class . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 4.6 domain Class. . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 5. Policy Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 5.1 policy Attribute (Short Format) . . . . . . . . . . . . . . . . 19 70 5.2 policy Attribute (Long Format). . . . . . . . . . . . . . . . . 22 71 5.3 ipsec-policy Class. . . . . . . . . . . . . . . . . . . . . . . 26 72 5.4 Selectors and Actions . . . . . . . . . . . . . . . . . . . . . 30 73 5.5 Policy Order. . . . . . . . . . . . . . . . . . . . . . . . . . 31 75 6. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 32 77 7. Remaining Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 32 81 Appendix A. BNF Form of SPSL . . . . . . . . . . . . . . . . . . . . 33 83 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 84 Author Information. . . . . . . . . . . . . . . . . . . . . . . . . . 42 85 1. Introduction 87 The Security Policy Specification Language (SPSL) is a vendor and 88 platform independent language for specifying communication security 89 policies, especially those controlling the use of IPSec and IKE 90 protocols. As the use of firewalls with strong authentication and 91 virtual private networks (VPNs) with level 2 and 3 encryption become 92 more popular, the need for managing these security services and 93 devices by means of security policies also becomes more acute. SPSL 94 allows the security policies to be specified in an interoperable 95 language, stored in common databases and processed by management 96 systems distinguished from the security devices. As such, SPSL is a 97 main component of a scalable policy based security management system 98 [SPS]. 100 The syntax of SPSL and several of its supporting object classes were 101 derived from the Routing Policy Specification Language [RPSL]. 102 However, the processing rules of SPSL are significantly different from 103 those of RPSL. Although the language was designed initially for 104 specifying IPSec and IKE policies, its flexible syntax allows it to 105 be used to express stateless and stateful packet filtering rules. 106 Moreover, the language is extensible: new object classes can be added 107 for the purpose of specifying policies of other security or 108 communication protocols. 110 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 111 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 112 document, are to be interpreted as described in RFC 2119 [Bra97]. 114 1.1 Language Requirements 116 SPSL was designed to meet the following requirements: 118 * Support for IPSec/IKE and general communication security 119 policy specification, 121 * Support for both node- and domain-based policy models, 123 * Support for multiple distributed policy enforcement points, 125 * Support for authentication and authorization mechanisms to aid 126 policy management, 128 * Support for flexibility and extensibility of the language. 130 1.1.1 Specification of Security Policies 132 In SPSL, a policy is defined as a binding between a set of 133 communication conditions and a corresponding set of security actions. 134 This abstraction is used to specify communication security policies in 135 general and IPSec/IKE policies in particular. If an on-going 136 communication (or one to be established) matches one of the conditions 137 then one of the prioritized alternative sets of actions must be taken 138 to protect the communication. This abstraction also captures current 139 policy enforcement practices. 141 The set of communication conditions in a policy are specified as one 142 or more tuples of selector values. This is because IPSec transports 143 and tunnels depend on security associations that are attached to 144 specific values of chosen communication parameters, known as the 145 selectors. SPSL supports all the selectors mentioned in IPSec 146 architecture document [Kent98] and a much extended collection as 147 described in Section 5.4. 149 The actions of a policy can affect different communication security 150 operations: 152 * They may specify simple packet filtering actions: discard the 153 packet, pass it, or forward it to a designated network entity. 155 * They may specify security proposals necessary for protecting 156 IKE exchanges. 158 * They may specify IPSec tunnels or transports for passing the 159 packets. The possible security mechanisms to protect the tunnels 160 and the transports are specified as IKE proposals as specified 161 in the IPSec Domain of Interpretation [DOI]. 163 SPSL supports IPSec policy data model [PolMod] proposed by Pereira 164 and Bhattacharya in order to effect the last two types of actions. 166 1.1.2 Node- and Domain-Based Models 168 SPSL enables two ways to associate security policies with network 169 entities, known as the node-based and the domain-based policy 170 models. 172 In the node-based model, security policies are bound to individual 173 network nodes and security devices, e.g., firewalls, hosts, etc. The 174 policies associated with a network node specify the protection for the 175 communications to and from the node. These policies are expected to 176 be enforced by the node itself. The policies associated with a 177 security device (formally known as a policy enforcement point) specify 178 the protection for the communications passing through these agents. 179 Either the source or the destination of the communication must be 180 among the nodes that the agent is authorized/expected to protect. In 181 this model, both the network nodes and the security policy enforcement 182 agents manage their own policies. 184 In the domain-based model, security policies are bound to a security 185 domain. A security domain is defined as a connected set of network 186 entities that are protected by policy enforcement points (PEP) placed 187 on every communication path going through the perimeter of the domain. 188 Every policy enforcement point of the domain works to enforce the 189 common set of security policies associated with the domain. Security 190 domains may be completely disjoint, contained in one another, 191 comprised of several sub-networks, or just hosts that enforce their 192 own policy. In this model, the policies associated with a domain are 193 managed by one or more special agents common to the entire domain. 194 These special agents act as policy servers. They may be distinct 195 network entities or co-located with the nodes or the policy 196 enforcement agents of the domain. 198 1.1.3 Multiple Distributed Policy Enforcement Points 200 SPSL allows explicit selection of enforcement points(s) of a security 201 policy. The choices can be interfaces of end nodes, en-route security 202 gateways (SG), e.g., firewalls, specified by IP addresses. The 203 explicit selection of an enforcement agent allows a system to choose a 204 communication path different than the one chosen by the routing 205 infrastructure. This facility is especially useful for tunnel 206 establishment and management. 208 1.1.4 Authentication and Authorization Mechanisms 210 SPSL has object classes to support the following security services: 212 1. data integrity, data origin authentication: every policy object 213 is protected by using a public key signature. Both RSA [RSA] 214 and DSA [DSA] signature algorithms are supported. This also 215 offers non-repudiation proof of the issuer(s) of the policies. 217 2. authentication and authorization of policy management entities: 218 management objects such as maintainers have public key 219 certificates associated with them so that they may issue 220 policies and/or identify themselves to a security management 221 system for access control purposes. 223 With these services, users of SPSL policy specifications can always 224 verify the integrity and the origin of the policies and allow only 225 authorized personnel to maintain the policies. 227 1.1.5 Language Flexibility and Extensibility 229 SPSL is a flexible and extensible language. The language is flexible 230 because its present syntax enables it to specify policies for 231 different uses. For example, it can be used to specify 232 non-cryptographic stateless packet filtering rules as well as IPSec 233 tunnels for virtual private networks. It can also be used to effect 234 standard IPSec or fine grain selector matching. In addition, it 235 supports both node- and domain-based models. 237 The language is also extensible. It allows new object classes to be 238 created by following a syntactic rule similar to inheritance. 239 Consequently, the language can be extended for specifying policies of 240 different communication and security protocols/applications. 242 1.2 Language Structure 244 SPSL uses the object paradigm although it is not an object-oriented 245 language. The language defines a small set of classes, which can 246 instantiate objects maintaining data relevant to policy specification. 247 The data are contained in the attributes defined in the object 248 classes. There are no executable methods in the classes nor do the 249 classes form types. 251 New classes can be created as needed based on a syntactic rule similar 252 to inheritance in object-oriented languages. For example, a new class 253 may have all the attributes of an existing class in addition to its 254 own attributes. However, the old and the new classes are not related 255 by type polymorphic relations because the objects do not contain 256 types. Objects in an SPSL file are distinguished and referred by the 257 unique values of their first attribute, known as the key attribute. 259 1.2.1 Categories 261 SPSL is comprised of the following four categories: 263 Primitive Data - contain basic or atomic data elements used in 264 policy specification, e.g., object-name, ipv4-address, 265 integer-range, date, etc. 267 Management Agents - contain information relevant to the management 268 entities; the existing classes in this category are maintainer 269 (mntner) and certificate (cert). 271 Network Entities - depict the network elements that are relevant 272 to policy specification; the existing classes are node, 273 node-set, gateway, gateway-set, polserver, and domain. 275 Policies - contain the policy specification; there are only two 276 classes at the moment: class policy specifies general packet 277 filtering rules and class ipsec-policy specifies IPSec 278 selectors and actions. Objects of the policy class may appear 279 in two forms for short or long policy specification. 281 1.2.2 Class Design 283 Each class has a set of attributes which store information about the 284 objects of the class. Attributes can be mandatory (man) or optional 285 (opt). A mandatory attribute MUST be defined for all objects of the 286 class, and an optional attribute MAY be omitted. Attributes can also 287 be single valued (s-v) or multiple valued (m-v). A single valued 288 attribute MUST only appear once per object. A multiple valued 289 attribute MAY appear more than once per object. Each object is 290 uniquely identified by the key attribute of its class. 292 An SPSL object is textually represented as a list of attribute-value 293 pairs. An object's representation begins with the class-key 294 attribute-value pair. Each attribute-value pair is written on a 295 separate line. The attribute name precedes the first colon, ":", 296 and is followed by the value of the attribute. An attribute-value 297 pair may span multiple lines. A "\" MUST be used as the last 298 character of a line to indicate that the line is continued. 299 An object's representation ends when a blank line (i.e., a line 300 containing only whitespace characters such as spaces, tabs, and 301 carriage returns) is encountered. 303 The order of attributes within a signed object is significant. The 304 order of the written form of the attributes when signed must be 305 preserved until the object is validated or resigned. This ordering is 306 necessary to be able to verify signatures of objects. The class key 307 must always be the first attribute. If the 'char-set' attribute is 308 included, it must always precede any 'notes' attribute. The last 309 attribute in any object must be the 'signature' attribute(s). If 310 multiple 'policy' attributes are included in a single policy class 311 object then their ordering must be preserved, unless the policy is 312 being specifically changed. This is required since the ordering of 313 policies may affect how they are applied (section 5.5). 315 A value of an attribute may be a single data item or a list of data 316 items of the same type. A list is represented by separating the list 317 members by commas ",". Note that the options of having a list of 318 values and/or multiple values are two independent choices for an 319 attribute. A multiple valued attribute may appear multiple times 320 within an object, and the value in each occurrence may or may not be a 321 list. A single valued attribute may also have a list value. 323 The default character set is ISO 8859-1 (Latin-1) [ISO8859]. The 324 character set is an eight bit encoding where the lower 7 bits are 325 identical to the ASCII character set. This default MUST always be 326 used for all the attribute tags and attribute values. The character 327 set for the notes attribute value MAY be overridden by using the 328 'char-set' attribute. 330 An object's specification may contain comments. A comment may appear 331 anywhere in an object definition. It starts at the first "#" 332 character on a line and ends at the first end-of-line character. The 333 "\" character may be used to escape the comment character, so that it 334 will be used as a "#" character and not a comment. "\\" will be used 335 to represent the "\" character. Whitespace characters may be used to 336 improve readability. 338 1.2.3 Naming Scheme and Scope 340 Since an SPSL object is distinguished by and referenced by its key 341 attribute, the value of that attribute (which is usually a name) must 342 be unique in the entire policy specification file (SPSL file). The 343 actual scope of uniqueness may differ depending on the choice of 344 policy model. In the node-based model, the names must be unique 345 within a node or a security enforcement point that owns the policies. 347 In the domain-based model, the names must be unique within the set of 348 security servers that manage the policies of one or more domains in a 349 primary-secondary server configuration. Note that the name of an 350 object must be unique among all classes, not merely among its own 351 class. 353 A recommended method for satisfying this uniqueness requirement 354 is to adopt the following hierarchical naming scheme. A 355 hierarchical object name is a sequence of names (usually, domain, 356 node, or gateway names) separated by colons ":". The names are 357 arranged following a descending order starting with the highest level 358 name. For example, SG-BAZ:SG-BAR:SG-FOO is a valid hierarchical 359 object name with SG-BAZ being the top level name. 361 1.2.4 $INCLUDE Extension 363 An SPSL file may actually consist of multiple files containing 364 complete SPSL objects. One SPSL file may be included as part of 365 another file using the following: 367 $INCLUDE 369 The contents of are included in the SPSL file at the 370 exact place where the $INCLUDE line is in the SPSL file. As with 371 SPSL objects, this line must be separated from other SPSL objects 372 by a blank line. 374 2. Primitive Data Types 376 The following are the commonly used data types in SPSL. [Note: many 377 of these data types are identical to those specified in RPSL. [RPSL]] 379 All SPSL objects are identified by a name. An 380 is made up of letters, digits, the character 381 underscore "_", the character period ".", the character colon 382 ":", and the character hyphen "-"; the first character of a name 383 must be a letter, and the last character of a name must be a 384 letter or a digit. Names are case sensitive. 386 is made up of letters, digits, the character 387 underscore "_", the character period ".", the character colon 388 ":", the character hyphen "-", the character slash "/", and 389 the character backslash "\". ("\\" must be used to represent 390 a single "\". File names are case sensitive. 392 An IPv4 address represented as a sequence of four 393 integers in the range from 0 to 255 separated by the character 394 dot ".". For example, 172.17.128.5 represents a valid IPv4 395 address. 397 An IPv6 address represented as a sequence of eight 398 hexadecimal integers in the range from 0 to FFFF separated by 399 the character colon ":". The last two hexadecimal integers may 400 be replaced with an . A single string of one or 401 more hexadecimal integers with value zero (0) may be omitted. 403 For example, 129:0:0:0:5:800:20C2:F35B, 404 129:0:0:0:5:800:32.194.243.91, and 129::5:800:32.194.243.91 all 405 represent valid IPv6 addresses, and all encode the same value. 407 An or . 409 An address range is represented as an IP address 410 followed by the character dash "-" followed by a second IP 411 address, by an IP address followed by the keyword "mask" 412 followed by a second IP address, or by an IP address followed 413 by a slash "/" followed by an integer. The addresses MUST be 414 either both 's or both 's. The dash 415 form of an address range is inclusive. The following are valid 416 address ranges: 172.16.1.1-172.16.1.200, 172.16.1.1-172.16.3.33. 417 The mask form uses the second IP address to specify a bit mask. 418 One bits in the mask correspond to bits in the address that may 419 not vary. A valid masked address range is: 10.0.0.1 mask 420 255.255.0.255. The slash form uses the integer to indicate the 421 number of bits in the address, beginning from the 422 most-significant, that may not vary. A valid address range in 423 this form is: 192.168.2.0/24. 425 A date is represented as an eight digit integer of the form 426 YYYYMMDD where YYYY represents the year, MM represents the 427 month of the year (01 through 12), and DD represents the day of 428 the month (01 through 31). For example, June 24, 1996 is 429 represented as 19960624. 431 specifies an integer, minimum integer, maximum 432 integer, or range of integer values. It uses the following 433 syntax: 435 | min | max | - 437 The following are valid 's: 5, 67-100, min 50, 438 max 60. 440 is a phone or fax number. A phone number may 441 contain digits, spaces " ", plus "+", minus "-", and the letter 442 "x" to indicate extension numbers. The following are valid 443 s: +31 20 123-4676, +44 123 987654 x4711. 445 is as described in RFC-822 [rfc822]. 447 is as described in RFC-1034 [rfc1034]. 449 is a sequence of ASCII characters. 451 is a name of an object of type X. That is 452 is a name of a mntner object. 454 is an object identifier of type . 456 is an X.400 address of type . See Appendix 457 in [PKIXP1] for further definition of the syntax. 459 represents an X.500 distinguished 460 name of type . See Appendix in [PKIXP1] for further 461 definition of the syntax. 463 EDI Party Name of type . See Appendix 464 in [PKIXP1] for further definition of the syntax. 466 Uniform Resource Identifier of type . 468 is of the form . 469 describes the type of name used in . is a string 470 that identifies a name. Its format depends upon the 471 . The following name types and their corresponding 472 formats have been defined as follows (based on CRL 473 Distribution Points extension in [PKIXP1]): 475 description of type format 477 other Other Name 478 n822 RFC 822 Name 479 dns DNS Name 480 x400 X400 Address 481 dirname Directory Name list of 482 483 ediname EDI Party Name 484 uri Uniform Resource Identifier 485 ipaddr IP Address 486 regid Registered ID 488 3. Management Agent Classes 490 The classes mntner and cert and the attributes mnt-by and changed in 491 all classes contain information about the management agents of the 492 policy specification. Among them, the mntner class specifies what 493 entities can create, delete, and replace other objects. These classes 494 do not specify security policies. 496 3.1 mntner Class 498 The mntner class defines entities that can create, delete, and replace 499 SPSL objects. A provider, before creating SPSL objects, first needs 500 to create a mntner object. The attributes of the mntner class are 501 shown in Figure 1. 503 Attribute Value Type (Sect. 1.2.2) 505 mntner: man, s-v, key 506 char-set: opt, s-v 507 notes: opt, m-v 508 auth: man, m-v 509 address: man, m-v 510 phone: man, m-v 511 fax-no: opt, m-v 512 email: man, m-v 513 mnt-by: list of man, m-v 514 certs: list of man, m-v 515 changed: man, m-v 516 signature: see description below man, m-v 518 Figure 1: mntner Class Attributes 520 The 'mntner' attribute is mandatory and is the class key. Its 521 value is an SPSL name. The 'auth' attribute specifies the scheme that 522 will be used to identify and authenticate update requests from this 523 maintainer. It has the following syntax: 525 auth: 527 E.g., 528 auth: crypt-pw dhjsdfhruewf 530 The 's currently defined are: "cert", "pgp", and 531 "crypt-pw". The is additional information required by a 532 particular scheme: in the case of "crypt-pw", it is a password in UNIX 533 crypt format; and in the case of "pgp", it is a PGP public key; in the 534 case of "cert", it is a list of to match the public key 535 certificates in the 'cert' attribute. If multiple 'auth' attributes 536 are specified, an update request satisfying any one of them is 537 authenticated to be from the maintainer. 539 The 'char-set' attribute identifies the name of the character set used 540 for the value of the notes attribute in this object. The 'char-set' 541 does not apply to the attribute names; the default character set is 542 always used for them. If this attribute is not included, then the 543 default character set is used. 545 The 'address', 'phone', 'fax-no', and 'email' attributes provide contact 546 information for the maintainer. The 'address' attribute SHOULD contain 547 one complete address per instance of the attribute. 549 The 'notes' attribute contains a free-form textual description of the 550 object and other notes about the object. The 'mnt-by' attribute is a 551 list of mntner object names. The authorization for replacement or 552 deletion of this object is governed by any of the maintainer objects 553 referenced. The 'changed' attribute documents who last changed this 554 object, and when the change was made. This attribute is multi-valued 555 so that a history of who made changes and when MAY be kept. Only the 556 most recent change MUST be kept. If multiple 'changed' attributes are 557 saved, then they MUST be ordered from most to least recent. The 558 identifies who made the change. is the date of the 559 change. 561 The 'certs' attribute lists certificate objects that point to the public 562 key certificates for this mntner. 564 The 'signature' attribute contains a signature of the object. 565 Signatures are computed over the textual representation of all the 566 attributes in the object, except any 'signature' attributes. For 567 purposes of the signature, all white-space is reduced to a single 568 space, except for carriage returns which are included in the 569 signature. Line continuation characters and the following carriage 570 return are included in the signature. Comma separated lists do not 571 have a space on either side of the comma "," for the signature. There 572 SHOULD be at least one 'signature' line for each in 573 mnt-by. When an object is modified, all signature attributes MUST 574 either be recomputed or removed from the object so that all signatures 575 are valid. The attribute has the following syntax: 577 signature: 578 580 E.g., 581 signature: XYZ-IR-MNT XYZ-X509-CERT rsa-pkcs1 583 The and identify which mntner signed this 584 object and which certificate was used. is the 585 algorithm used to create the signature. Currently the following 586 signature algorithms are defined: "rsa-pkcs1", "dsa-sha1". 587 is the signature that was generated. 589 Figure 2 shows an example mntner object. In the example, "cert" 590 authentication is used. 592 mntner: XYZ-IR-MNT 593 notes: XYZ-IR Maintainer 594 auth: cert XYZ-IR-X509-CERT 595 address: XYZ Corp, 1 XYZ Place, Anytown, AS 12345, USA 596 phone: +1 617 5551234 597 email: jdoe@ir.xyz.com 598 mnt-by: XYZ-IR-MNT 599 certs: XYZ-IR-X509-CERT 600 changed: XYZ-IR-MNT 19970820 601 signature: XYZ-IR-MNT XYZ-IR-X509-CERT dsa-sha1 603 Figure 2: An example mntner object. 605 The 'char-set', 'notes', 'mnt-by', 'changed', and 'signature' 606 attributes are attributes of all SPSL classes. Their syntax, 607 semantics, and type (mandatory, optional, multi-valued, or 608 single-valued) are the same for for all SPSL classes. They are not 609 discussed further in the remaining sections. 611 3.2 cert Class 613 The cert class identifies a public key certificate that may be used to 614 sign SPSL objects. A cert object either specifies a certificate or 615 the location of a certificate. The 'cert' attribute identifies the 616 name of the object. 618 Attribute Value Type (Sect. 1.2.2) 620 cert: man, s-v, key 621 char-set: opt, s-v 622 notes: opt, m-v 623 certificate: see description below opt, s-v 624 certlocation: see description below opt, m-v 625 crllocation: see description below opt, s-v 626 mnt-by: list of man, m-v 627 changed: man, m-v 628 signature: see description in Section 3.1 man, m-v 630 Figure 3: cert class attributes 632 The 'certificate' attribute has the following syntax: 634 certificate: 636 describes the type of certificate represented. Currently 637 the following types are defined: "pkcs7", "pgp", "dnskey", "x509_sig", 638 "x509_ke", "kerberos", "spki". is the actual certificate 639 described by this object, encoded as a hexadecimal representation of 640 the certificate. 642 certificate type description 644 pkcs7 PKCS #7 wrapped X.509 certificate 645 pgp PGP certificate 646 dnskey DNS signed key 647 x509_sig X.509 certificate - signature 648 x509_ke X.509 certificate - key exchange 649 kerberos Kerberos tokens 650 spki SPKI certificate 652 The 'certlocation' attribute has the following syntax: 654 certlocation: 655 | filename | 656 rdn 658 is as defined above. specifies the 659 preferred protocol should be used to fetch the certificate from this 660 location. Currently the following protocols have been defined: "cdp", 661 "dns", "file". The location of the certificate is identified either 662 by using a or a when 663 fetching with CDP or DNS, or a when fetching from a locally 664 stored file. 666 The 'crllocation' attribute indicates where a certificate revocation 667 list (CRL) may be found for this certificate. It has the following 668 syntax: 670 crllocation: 671 | filename | 672 rdn 674 This is similar to the certlocation attribute, except that 675 is used in place of . describes the type of CRL 676 that may be found at this location. Currently, the following CRL type 677 has been defined: "x509". 679 At least one 'certificate' or 'certlocation' attribute MUST be present in 680 a cert object. It is possible for a 'certificate' and a 'certlocation' 681 attribute, or multiple 'certlocation' attributes to be present in a 682 single cert object, but they SHOULD all refer to the same certificate, 683 otherwise the wrong certificate may be used. 685 4. Network Entity Classes 687 4.1 node Class 689 The node class identifies a set of interfaces on a network entity that 690 may have policies associated with them. This definition allows a 691 single network entity to be represented by one or more node objects. 692 It also allows policies to be associated with specific interfaces or 693 addresses of a network entity. 695 Attribute Value Type (Sect. 1.2.2) 697 node: man, s-v, key 698 char-set: opt, s-v 699 notes: opt, m-v 700 name: man, s-v 701 alias: opt, m-v 702 ifaddr: man, m-v 703 mnt-by: list of man, m-v 704 changed: man, m-v 705 signature: see description in Section 3.1 man, m-v 707 Figure 4: node class attributes 709 The 'node' attribute is the class key, which uniquely identifies the 710 node object. 712 The 'name' attribute is a valid DNS name identifying the network entity 713 to which the interfaces in the object are attached. Each 'alias' 714 attribute, if present, should be a canonical DNS name of the network 715 entity. The 'ifaddr' attribute specifies the IP address of each 716 interface of the node. 718 Figure 5 shows two examples of node objects. 720 node: SQUATCH 721 name: squatch.foo.com 722 ifaddr: 172.16.3.11 723 ifaddr: 192.2.1.83 725 node: SG-FOO-FIREWALL:COTTON 726 name: cotton.foo.com 727 ifaddr: 172.16.5.196 729 Figure 5: node object examples 731 4.2 node-set Class 733 The node-set class provides a means to group several nodes into one 734 object. The class may be used to group together the interfaces of a 735 single host or of multiple hosts. The nodes in a node-set object are 736 expected to contain the interfaces of a common set of network 737 entities. 739 The node-set class is defined below: 741 Attribute Value Type (Sect. 1.2.2) 743 node-set: man, s-v, key 744 char-set: opt, s-v 745 notes: opt, m-v 746 members: list of 747 and/or man, m-v 748 mnt-by: list of man, m-v 749 changed: man, m-v 750 signature: see description in Section 3.1 man, m-v 752 Figure 6: node-set class attributes 754 The 'node-set' attribute is the class key, which uniquely identifies the 755 node-set object. The 'members' attribute is a list of the node objects 756 and node-set objects which are grouped by the node-set object. 758 4.3 gateway Class 760 The gateway class identifies a set of interfaces on a policy 761 enforcement agent, e.g., a security gateway, that can enforce the 762 security policies associated with the enforcement agent or the domain 763 for which it enforces policy. 765 Attribute Value Type (Sect. 1.2.2) 767 gateway: man, s-v, key 768 char-set: opt, s-v 769 notes: opt, m-v 770 name: man, s-v 771 alias: opt, m-v 772 ifaddr: man, m-v 773 preference: man, s-v 774 mnt-by: list of man, m-v 775 changed: man, m-v 776 signature: see description in Section 3.1 man, m-v 778 Figure 7: gateway class attributes 780 The 'gateway' attribute is the class key, which uniquely identifies the 781 gateway object. 783 The 'name' attribute is a valid canonical DNS name identifying the 784 network entity on which the policy enforcement agent is implemented. 785 Each 'alias' attribute, if present, should be a canonical DNS name of 786 the network entity. The 'ifaddr' attribute specifies the IP address of 787 an interface. 789 The 'preference' attribute gives a hint as to the preference of routing 790 to use this gateway. 1 is the highest preference and the preference 791 decreases as the integer increases. This is only used for purposes of 792 the domain object and is explained further in section 4.6. 794 Figure 8 shows two examples of gateway objects. 796 gateway: SG-FOO-FIREWALL 797 name: foo-firewall.foo.com 798 ifaddr: 172.16.0.1 799 ifaddr: 192.2.1.83 800 preference: 1 802 gateway: SG-FOO-FIREWALL:SG-IS-FIREWALL 803 name: is-firewall.foo.com 804 ifaddr: 172.16.5.196 805 preference: 3 807 Figure 8: gateway object examples 809 4.4 gateway-set Class 811 The gateway-set class provides a means to group gateways. It can be 812 used to group together the interfaces of a single gateway or the 813 interfaces of multiple gateways spread across several gateway objects, 814 so that they may be referred to as a single object. 816 The gateway-set class is defined below: 818 Attribute Value Type (Sect. 1.2.2) 820 gateway-set: man, s-v, key 821 char-set: opt, s-v 822 notes: opt, m-v 823 members: list of 824 and/or man, s-v 825 mnt-by: list of man, m-v 826 changed: man, m-v 827 signature: see description in Section 3.1 man, m-v 829 Figure 9: gateway-set class attributes 831 The 'gateway-set' attribute is the class key, which uniquely identifies 832 the gateway-set object. The 'members' attribute is a list of gateway 833 objects and/or gateway-set objects which are grouped by the gateway-set 834 object. 836 4.5 polserv Class 838 The polserv class defines the policy servers that are capable of 839 managing security policies. 841 Attribute Value Type (Sect. 1.2.2) 843 polserv: man, s-v, key 844 char-set: opt, s-v 845 notes: opt, m-v 846 name: man, s-v 847 alias: opt, m-v 848 ifaddr: man, m-v 849 mnt-by: list of man, m-v 850 changed: man, m-v 851 signature: see description in Section 3.1 man, m-v 853 Figure 10: polserv class attributes 855 The 'polserv' attribute is the class key, which uniquely identifies 856 the policy server object. The 'name' attribute is a valid DNS name 857 identifying the network entity on which the policy server is located. 858 Each 'alias' attribute, if present, should be a canonical DNS name of 859 the network entity. The 'ifaddr' attribute specifies the IP address of 860 an interface of the policy server. 862 Figure 11 shows a simple example of a policy server object. 864 polserv: PS-SECURITY 865 name: foo-pol-server.foo.com 866 ifaddr: 172.16.0.2 868 Figure 11: polserv object example 870 4.6 domain Class 872 The domain class provides a means to define a security domain, which 873 is a cluster of network entities protected by a common set of security 874 policies which are enforced by the policy enforcement pointss located 875 at the perimeter of the domain. 877 A security domain is the basic topological structure for a 878 domain-based security model [Section 1.1.2]. It consists of three 879 components: 881 1. Coverage - a security domain must be authorized to include a 882 specific set of network entities. That specification is provided 883 in the 'coverage' attribute, and can take the form of a list of IP 884 addresses, a list of IP address ranges, a list of nodes, and/or 885 a list of node-sets. 887 2. Policy Enforcement Points - the network entities included in a 888 security domain are protected by a set of policy enforcement 889 points located at the perimeter of the domain. The policy 890 enforcement points are specified by the 'gateways' attribute, 891 which may contain a list of gateways or gateway-sets. The 892 gateways in the list MAY be ordered using the 'gateways' 893 'preference' attribute. 895 3. Policy Servers - one or more policy servers are assigned to 896 the security domain to manage the security policies of the 897 domain. These servers are given in a list under the 'polservs' 898 attribute. The first member of the list MUST be the primary 899 server, and the rest are any secondary servers. 901 With these three components, the domain class is defined below. 902 Individual domain objects are uniquely identified by the 'domain' 903 attribute, which is the class key. 905 Attribute Value Type (Sect. 1.2.2) 907 domain: man, s-v, key 908 char-set: opt, s-v 909 notes: opt, m-v 910 coverage: [list of [,]] 911 [list of [,]] 912 [list of [,]] 913 [list of ] man, m-v 914 gateways: list of 915 and/or man, s-v 916 polservs: list of man, s-v 917 mnt-by: list of man, m-v 918 changed: man, m-v 919 signature: see description in Section 3.1 man, m-v 921 Figure 12: domain class attributes 923 5. Policy Class 925 A policy class object specifies a binding between a set of 926 communication conditions and a set of actions. 928 In the current version of SPSL, two policy classes are defined. The 929 general class described in sections 5.1 and 5.2 defines the conditions 930 and a transfer action that allows for specifying packet filtering 931 rules. The class described in Section 5.3 is to be used for 932 specifying IPSec and IKE policies. 934 Moreover, objects of the general policy class may take one of two 935 possible formats. The short format expresses the policy in a single 936 'policy' attribute and the long format expresses each part of a policy 937 in a distinct attribute. Each of the two formats is appropriate for 938 different applications. They will be discussed in the next two 939 sections, along with comments on their strengths and weaknesses. 941 Both formats of the policy class share three attributes. Figure 13 942 shows the class definition (in short format) in order to display the 943 common attributes. Among them, 'policy-name' gives the name of the 944 policy. The 'cache-expiry' attribute indicates, in seconds, the maximum 945 time that this policy should be cached. It can be regarded as a hint 946 to any entities that may cache this policy. If the attribute is 947 absent or has a value of zero then no expiration time is suggested. 949 The 'association' attribute specifies the names of one or more nodes, 950 gateways, or domains that own the policy. If a node-based or 951 domain-based policy model is being used, strict rules of association 952 must be observed depending on the model. In the node-based model, a 953 policy can be associated with an object from the node, node-set, 954 gateway, or gateway-set classes but never with a domain object. In 955 the domain-based model, a policy can be associated with an object from 956 the node, node-set, or domain classes but not with a gateway or 957 gateway-set object. This is because the policy associated with a 958 gateway or gateway-set object will be enforced by that particular 959 object instead of by all of the enforcement agents of a specific 960 domain. However, a node or node-set object is allowed its own 961 policies in a domain-based association because the object may be 962 regarded as a single/multiple node domain. 964 5.1 policy Attribute (Short Format) 966 The short format of the policy class specifies the policy in a 967 single 'policy' attribute that is structured as follows: 969 Attribute Value Type (Sect. 1.2.2) 971 policy-name: man, s-v, key 972 char-set: opt, s-v 973 notes: opt, m-v 974 association: | 975 | | 976 | man, s-v 977 cache-expiry: opt, s-v 978 policy: as described below opt, m-v 979 mnt-by: list of man, m-v 980 changed: man, m-v 981 signature: see description in Section 3.1 man, m-v 983 Figure 13: policy class attributes, short format 985 policy: dst * | any | list of [not] 986 | list of [not] 987 [port * | opaque | any | list of [not] 988 | list of [not] 989 [dynamic []]] 990 [src * | any | list of [not] 991 | list of [not] 992 [port * | opaque | any | list of [not] 993 | list of [not] 994 [dynamic []]]] 995 [xport-proto * | opaque | any | list of [not] 996 | list of [not] ] 997 [direction inbound | outbound [, symmetric]] 998 permit [, forward ] | deny [, forward ] 999 | forward 1001 The "dst" tag specifies a list of s or s to 1002 which this policy does (or does not) apply. The address may be 1003 specified as "any" or the wildcard, "*", to indicate this applies to 1004 traffic destined to all addresses. Otherwise, the address is a list 1005 of individual IP addresses, or address ranges specified by a minimum 1006 and maximum address (inclusive), or address ranges specified using an 1007 address and mask. 1009 An address may be preceded by the qualifier "not" to indicate that the 1010 address from a packet must not be the one specified. Note that it not 1011 useful to include some list members with the "not" qualifier and some 1012 without it. For a distinct X and Y, an expression "X or not Y" is 1013 equivalent to just "not Y". An expression "X and not Y" is equivalent 1014 to just "X". Note the special case where a list contained the same 1015 address both with and without "not" -- those two list members are 1016 equivalent to "any". Consequently, when a list contains no "not" 1017 qualifiers, the interpretation is "X or Y or Z", while if each list 1018 member has a "not" qualifier, the list is interpreted as "not X and 1019 not Y and not Z". 1021 Attribute "dst" may optionally be followed by "port" and a list of 1022 destination port numbers or ranges of port numbers to which this 1023 policy does (or does not) apply. Additionally, "port" may be followed 1024 by the tag "dynamic" and an optional range of port numbers. This 1025 specifies that a connection established by using one of the port 1026 numbers following the "port" tag, may then use dynamic ports for the 1027 rest of the communications using that connection. If a range of port 1028 numbers follows the dynamic tag, then dynamic ports are only allowed 1029 within that specified range. If the range is not specified, the port 1030 range defaults to "*". If the dynamic tag is not used, then dynamic 1031 ports are excluded from this policy. 1033 A source address and port(s) may optionally be specified in a similar 1034 manner using the "src" tag. The source address and source and 1035 destination ports default to "*" if they are not specified. 1037 The transport protocol may be specified using the optional tag 1038 "xport-proto", which defaults to "*" if not specified. The transport 1039 protocol may be specified as a single transport protocol number, a 1040 list of protocol numbers, or a range of protocol numbers in the form 1041 -. It may also be specified as "*", "any", or 1042 "opaque". Note that when a port is specified as described in the 1043 previous two paragraphs, then the protocol associated with those ports 1044 must be specified using the "xport-proto" phrase. 1046 The "direction" specification is used to specify whether a packet is 1047 entering the domain associated with the policy (inbound) or exiting it 1048 (outbound). If the optional qualifier "symmetric" is present, a 1049 second policy will automatically be created with the direction 1050 sensitive fields -- "src" and "dst", and src port and dst port -- 1051 switched. 1053 The transfer action of "permit" or "deny" must be specified to indicate 1054 whather packets that match this policy should be passed or dropped, 1055 respectively. The transfer action may additionally specify that 1056 the matching packets be forwarded to a specified destination, e.g., 1057 a policy server. The destination may be specified by either a DNS 1058 name, preceeded by "dns", or by an IP address. 1060 policy-name: foo 1061 association: sg-bar 1062 policy: dst 172.16.0.0-172.16.255.255 1063 src 192.168.100.0-192.168.100.255 1064 xport-proto 6 permit 1065 policy: dst 172.16.0.0-172.16.255.255 deny 1067 Figure 14: policy object example, short format 1069 In this example, this policy denies all packets destined to IP 1070 addresses from 172.16.0.0 to 172.16.255.255, unless they are from 1071 addresses 192.168.100.0 to 192.168.100.255 and use TCP. Note that the 1072 ordering of the 'policy' attributes is important (see section 5.5). 1074 5.2 policy Attribute (Long Format) 1076 The long format policy class makes each part of the policy attribute an 1077 explicit attribute. 1079 Attribute Value Type (Sect. 1.2.2) 1081 policy-name: man, s-v, key 1082 char-set: opt, s-v 1083 notes: opt, m-v 1084 association: | 1085 | | 1086 | man, s-v 1087 cache-expiry: opt, s-v 1088 valid-period: list of opt, m-v 1089 dst: see below opt, m-v 1090 src: see below opt, m-v 1091 xport-proto: see below opt, m-v 1092 direction: inbound | outbound [, symmetric] opt, s-v 1093 userid: * | any | list of [not] n822 1094 | list of [not] dn opt, m-v 1095 systemname: * | any | list of [not] 1096 | list of [not] dn opt, m-v 1097 ipv6-class: * | any | list of [not] opt, m-v 1098 ipv6-flow: * | any | list of [not] opt, m-v 1099 ipv4-tos: * | any | list of [not] opt, m-v 1100 seclabel: * | any | list of [not] opt, m-v 1101 see Section 5.4 for additional selectors opt, m-v 1102 tfr-action: see below opt, m-v 1103 mnt-by: list of man, m-v 1104 changed: man, m-v 1105 signature: see description in Section 3.1 man, m-v 1107 Figure 15: policy class attributes, long format 1109 The attributes are specified as follows: 1111 dst: * | any | list of [not] 1112 | list of [not] 1113 [port * | opaque | any | list of [not] 1114 | list of [not] [dynamic []]] 1116 src: * | any | list of [not] 1117 | list of [not] 1118 [port * | opaque | any | list of [not] 1119 | list of [not] [dynamic []]] 1121 xport-proto: * | opaque | any | list of [not] 1122 | list of [not] 1124 tfr-action: permit [, forward ] | deny [, forward ] 1125 | forward 1127 : [year yyyy-yyyy] [month 000000000000] 1128 [day-of-month 0000000000000000000000000000000] 1129 [day-of-week 0000000] [time [not] hh:mm:ss-hh:mm:ss] 1131 The 'valid-period' attribute describes one or more time periods in 1132 which the policy is valid. If more than one time period is expressed 1133 in an object, then the periods are related by a logical OR. Each time 1134 period consists optionally of a range of years, bitmask of months, 1135 bitmask of days-of-the-month and and -of-the-week, and a time period. 1136 These fields of a time period are related by a logical AND. 1138 The "year" is a range of years to which the policy applies. The 1139 "month" is a 12-bit bitmask of the months with January as the first 1140 bit and December the last bit. If a bit is set to 1, the policy is 1141 valid during that month, if 0, it is not valid during that month. The 1142 "day-of-month" is a 31-bit bitmask of the days-of-the-month with 1 as 1143 the first bit and 31 the last bit. If a bit is set to 1, the policy 1144 is valid during that day, if 0, it is not valid during that day. The 1145 "day-of-week" is a 7-bit bitmask of the days-of-the-week with Sunday 1146 as the first bit and Saturday the last bit. If a bit is set to 1, the 1147 policy is valid during that day-of-the-week, if 0, it is not valid 1148 during that day. The "time" describes a range of times during which 1149 the policy is (or is not) valid. The times use a 24-hour clock and 1150 their values MUST be expressed in Greenwich Mean Time (Zulu). If any 1151 period is not described that field is interpreted as "any." 1153 Attributes 'dst', 'src', 'xport-proto', 'direction', and 'tfr-action' 1154 (transfer action) are similar to their counterparts in the short 1155 format of the policy class. Note that the interpretation of a single 1156 selector attribute with a list value is similar to having each 1157 list member be a separate instance of the selector attribute since 1158 multiple occurances of these selectors (unlike the 'policy' selector) 1159 are interpreted as logical ORs. 1161 The direction MUST be specified either in the 'policy' attribute or the 1162 'direction' attribute. The 'tfr-action' attribute specifies an action 1163 that MUST be taken, as specified above. 1165 The 'user-id' attribute specifies either an email address or a 1166 distinguished name to identify a particular user. The 'systemname' 1167 attribute uses a DNS name, an X.500 general name, or an X.500 1168 distinguished name to identify a particular system. 1170 The 'seclabel' attribute is used to identify an implementation specific 1171 security label. This should correspond to the implementation of the 1172 security level selector in IPSec. This attribute is a good example of 1173 the difference between "*" and "any". When "any" is used, the packet 1174 must contain the field which contains the selector value. When "*" is 1175 used, the packet does not have to have that field. Thus "any" means 1176 that the packet must specify a security label, but its value is not of 1177 interest. A "*" would mean that a packet need not contain any 1178 security label. The value "opaque" is used to match packets for which 1179 a selector field cannot be found, typically due to compression, 1180 fragmentation, or confidentiality. 1182 Attributes 'ipv6-flow' and 'ipv6-class' specify a list of integers or 1183 integer ranges, optionally preceeded by "not", corresponding to the 1184 IPv6 flow label and transport class fields in the IPv6 header. 1185 'ipv4-tos' is a list of integers or integer ranges, optionally preceeded 1186 by "not", corresponding to the IPv4 type of service field in an IPv4 1187 header. These attributes default to "*" if they are not included. 1188 The 'tfr-action' and 'dst' attributes are mandatory, if the policy class 1189 is used in this format. 1191 In order to represent the policies described in the above example 1192 (Figure 14), two policy objects must be created. Note that the 1193 ordering of the policy objects is important (see section 5.5). 1195 policy-name: baz 1196 association: sg-bar 1197 dst: 172.16.0.0-172.16.255.255 1198 src: 192.168.100.0-192.168.100.255 1199 xport-proto: 6 1200 tfr-action: accept 1202 policy-name: foo 1203 association: sg-bar 1204 dst: 172.16.0.0-172.16.255.255 1205 tfr-action: deny 1207 Figure 16: policy object example, long format 1209 Generally, policy objects will use one of the two formats, but it is 1210 possible to combine the features of both. The combined policy class 1211 looks as follows: 1213 Attribute Value Type (Sect. 1.2.2) 1215 policy-name: man, s-v, key 1216 char-set: opt, s-v 1217 notes: opt, m-v 1218 association: | 1219 | | 1220 | man, s-v 1221 cache-expiry: opt, s-v 1222 valid-period: list of opt, m-v 1223 policy: as described above opt, m-v 1224 dst: as described above opt, m-v 1225 src: as described above opt, m-v 1226 xport-proto: as described above opt, m-v 1227 direction: inbound | outbound [',' symmetric] opt, s-v 1228 userid: * | any | list of [not] n822 1229 | list of [not] dn opt, m-v 1230 systemname: * | any | list of [not] 1231 | list of [not] dn opt, m-v 1232 ipv6-class: * | any | list of [not] opt, m-v 1233 ipv6-flow: * | any | list of [not] opt, m-v 1234 ipv4-tos: * | any | list of [not] opt, m-v 1235 seclabel: * | any | list of [not] opt, m-v 1236 see Section 5.4 for additional selectors opt, m-v 1237 tfr-action: as described above opt, m-v 1238 mnt-by: list of man, m-v 1239 changed: man, m-v 1240 signature: see description in Section 3.1 man, m-v 1242 Figure 17: policy class attributes, combined format 1244 If the 'policy' attribute is specified and any of the other attributes 1245 are also specified, those others apply to all the policy lines in this 1246 object. This holds true for sub-classes of the policy class, too. If 1247 a policy object has a conflict between a part of the policy attribute 1248 and one of the other attributes specified, it is an invalid object. 1250 Figure 18 illustrates the combination of the two formats. The first 1251 policy object uses the combined format of the policy class. It has 1252 two 'policy' attributes and an 'xport-proto' attribute. The 'xport-proto' 1253 attribute is applied as part of the policy described by each of the 1254 'policy' lines. This is equivalent to explicitly listing the 1255 'xport-proto' attribute in each policy line, as shown in the second 1256 policy object. 1258 policy-name: tcp-foo 1259 association: sg-bar 1260 policy: dst 172.16.0.0-172.16.255.255 1261 src 192.168.100.0-192.168.100.255 accept 1262 policy: dst 172.16.0.0-172.16.255.255 deny 1263 xport-proto: 6 1265 This is equivalent to: 1267 policy-name: tcp-foo 1268 association: sg-bar 1269 policy: dst 172.16.0.0-172.16.255.255 1270 src 192.168.100.0-192.168.100.255 1271 xport-proto 6 accept 1272 policy: dst 172.16.0.0-172.16.255.255 xport-proto 6 deny 1274 Figure 18: policy object example, combined format 1276 While both formats allow the same policies to be specified, they each 1277 have their advantages and disadvantages. The short format allows 1278 uncomplicated policies, such as general default policies, to be 1279 specified in a compact format since it allows multiple policies to be 1280 defined in a single object. The short format, however, is not capable 1281 of specifying complex policies. The long format allows complex 1282 policies to be specified in a more straightforward manner. Also, the 1283 ability to combine both formats of the policy class, allows greater 1284 flexibility in how policies may be defined. Correct specification of 1285 policies is made easier by being able to specify those policies in a 1286 straightforward manner. 1288 5.3 ipsec-policy Class 1290 The ipsec-policy class is a sub-class of the policy class. It is 1291 used to state IPSec policies specifying whether or not AH or ESP 1292 are required for a particular communication, and the choice of 1293 security mechanisms to be used with IPSec protocols. It also 1294 specifies the security mechanisms that may be negotiated by IKE 1295 using the IPSec DOI [DOI]. Since it is a sub-class of the general policy 1296 class, it inherits attributes from the policy class. The inherited 1297 attributes are marked with an "*" in Figure 19 below. 1299 Attribute Value Type (Sect. 1.2.2) 1301 *policy-name: man, s-v, key 1302 *char-set: opt, s-v 1303 *notes: opt, m-v 1304 *association: | 1305 | | 1306 | man, s-v 1307 *cache-expiry: opt, s-v 1308 *valid-period: list of opt, m-v 1309 *policy: as described above opt, m-v 1310 *dst: as described above opt, m-v 1311 *src: as described above opt, m-v 1312 *xport-proto: as described above opt, m-v 1313 *direction: inbound | outbound [',' symmetric] opt, s-v 1314 *userid: * | any | list of [not] n822 1315 | list of [not] dn opt, m-v 1316 *systemname: * | any | list of [not] 1317 | list of [not] dn opt, m-v 1318 *ipv6-class: * | any | list of [not] opt, m-v 1319 *ipv6-flow: * | any | list of [not] opt, m-v 1320 *ipv4-tos: * | any | list of [not] opt, m-v 1321 *seclabel: * | any | list of [not] opt, m-v 1322 * see Section 5.4 for additional selectors opt, m-v 1323 *tfr-action: as described above opt, m-v 1324 ipsec-action: see below opt, m-v 1325 ike-action: see below opt, m-v 1326 *mnt-by: list of man, m-v 1327 *changed: man, m-v 1328 *signature: see description in Section 3.1 man, m-v 1330 Figure 19: ipsec-policy class attributes 1332 ike-action: ikemode pfs 1333 auth 1334 cipher hash 1335 [group-desc | 1336 group-type 1337 ] 1338 [prf ] [field ] 1339 expiry ( seconds | kilobytes ) 1341 where is one of: "aggressive", "main", "quick" 1343 is either "false" or "true" 1345 is one of "any", "pre-shared", "dss", 1346 "rsa", "rsa-encrypt", "rsa-revised" or an 1347 as defined in [rfc2409], optionally 1348 preceded by "not" 1350 is a list of one or more of: 1351 [keylen ] 1353 is one of "any", "blowfish", "cast", 1354 "des", "des3", "idea", "rc5", or an 1355 as defined in [rfc2409], optionally 1356 preceded by "not" 1358 is "any", or one or more of: "md5", "sha1", "tiger", 1359 or an as defined in [rfc2409], optionally 1360 preceded by "not" 1362 is one of: "modp-768", "modp-1024", "ec2n-155", 1363 "ec2n-185", or an as defined in [rfc2409]. 1365 is one of: "modp", "ecp", "ec2n", or an 1366 as defined in [rfc2409]. 1368 ipsec-action: [ esp cipher 1369 [integrity ] 1370 [expiry ( seconds | kilobytes ) ] 1371 [tunnel | transport] 1372 [from [, ]] 1373 [to [, ]] 1374 ] 1375 [ ah integrity 1376 [expiry ( seconds | kilobytes ) ] 1377 [tunnel | transport] 1378 [from [, ]] 1379 [to [, ]] 1380 ] 1381 [ ipcomp ] 1383 where is one of "req", "opt" 1385 is a list of one or more of: 1386 [keylen ] 1387 [rounds ] 1389 is one of "any", "blowfish", "cast", 1390 "des", "des3", "idea", "idea3", "none", "rc4", 1391 "rc5", "rfc1829-iv32", "rfc1829-iv64", or an 1392 as defined in [rfc2407], optionally 1393 preceded by "not" 1395 is a list of one or more of: 1396 [keylen ] 1398 is one of "any", "hmacdes","hmacmd5", 1399 "hmacsha1", "kpdk", or an as defined 1400 in [rfc2407], optionally preceded by "not" 1402 is "any", or one or more of: "deflate", "lzs", 1403 "oui", or an as defined in [rfc2407], 1404 optionally preceded by "not" 1406 is "any", or one or more of: "dest", "host", 1407 "local-sg", "remote-sg", , 1408 "dns" 1410 Two action attributes, 'ipsec-action' and 'ike-action', in addition to 1411 the policy class attributes, form the ipsec-policy class. 1413 The 'ipsec-action' attribute specifies ESP, AH, and IP compression 1414 proposals that must be used to protect this communication. Each 1415 proposal may be either a required, "req," or optional, "opt," part of 1416 the specified communication. If a proposal is not included in the 1417 'ipsec-action' it is prohibited. 1419 If an ESP proposal is specified, the cipher algorithm to use is 1420 specified by the "cipher" tag and "any", a string describing a cipher 1421 algorithm, or a number corresponding to a cipher algorithm as defined 1422 in [rfc2407]. Each cipher algorithm may be further defined by an 1423 optional key length and number of rounds, if the cipher requires it. 1424 An integrity algorithm and its key length may optionally be specified. 1425 It defaults to "any" if not specified. Values are defined in 1426 [rfc2409]. The SA life type and life time may be specified with the 1427 "expiry" tag. If not used, the values default as described in section 1428 4.5 of [rfc2407]. Tunnel or transport mode may be specified with the 1429 "tunnel" or "transport" tags. If neither are specified, either may be 1430 used. The end points of the SA may be specified with the "to" and 1431 "from" tags which are described in detail below. 1433 If an AH proposal is specified, the integrity algorithm to use is 1434 specified by the "integrity" tag and "any", a string describing an 1435 integrity algorithm, or a number corresponding to an integrity 1436 algorithm as defined in [rfc2407]. Values are defined in [rfc2409]. 1437 The key length for each algorithm may also be specified. The SA life 1438 type and life time may be specified with the "expiry" tag. If not 1439 used, the values default as described in section 4.5 of [rfc2407]. 1440 Tunnel or transport mode may be specified with the "tunnel" or 1441 "transport" tags. If neither are specified, either may be used. The 1442 end points of the SA may be specified with the "to" and "from" tags 1443 which are described in detail below. 1445 If an IP compression proposal is specified, the compression algorithm 1446 to use is specified by the "ipcomp" tag and "any", a string describing 1447 a compression algorithm, or a number corresponding to a compression 1448 algorithm as defined in [rfc2407]. The SA life type and life time may 1449 be specified with the "expiry" tag. If not used, the values default 1450 as described in section 4.5 of [rfc2407]. 1452 The "to" and "from" tags identify the endpoints (policy enforcement 1453 points) of the security association that the proposal describes. A 1454 network node may be explicitly specified as an endpoint using either 1455 its IP address or its DNS name. This node MUST be used as the 1456 specified endpoint of the SA. The endpoints of the SA may also be 1457 specified using a generic specification that allows the policy 1458 decision points to determine at which enforcement point to end the SA. 1459 "any" allows any enforcement point to be chosen as long as it is not 1460 the same as the other endpoint. "host" specifies the appropriate 1461 (i.e. source or destination) endpoint of the communication. "dest", 1462 "local-sg" and "remote-sg" still need to be further thought and 1463 definition. [***] If the SA endpoints are not specified, they default 1464 to the source and destination endpoints specified in the policy 1465 object. 1467 The 'ike-action' attribute specifies attributes that may be negotiated 1468 during IKE pahase one and whether perfect forward secrecy must be used 1469 in quick mode. The "ikemode" tag specifies whether IKE should use 1470 this specification in main, aggressive, or quick mode. The "pfs" tag 1471 specifies if perfect forward secrecy should be used. "auth", 1472 "cipher", and "hash" describe the authentication method, encryption 1473 algorithm, and hash algorithm to be used. These may be specified by 1474 "any", a string describing the appropriate algorithm, or a number 1475 corresponding to an algorithm as defined in [rfc2409]. A key length 1476 for the encryption algorithm may optionally be specified with each 1477 cipher algorithm using the "keylen" tag. A predefined group or a 1478 user-defined group may optionally be specified. A predefined group 1479 uses the "group-desc" tag followed by a string describing the group, 1480 or a number corresponding to a group as defined in [rfc2409]. A 1481 user-defined group uses the "group-type" tag followd by the string or 1482 number describing a group type (as defined in [rfc2409]) and the group 1483 description: the group prime/irreducible polynomial, group generator 1484 1, group generator 2, group curve A, group curve B, and group order. 1485 A psuedo-random function may be specified with "prf" and the field 1486 size of a Diffie Hellman group may be specified with "field" and the 1487 size in bits. Finally, the life time and life type must be specified 1488 using the "expiry" tag. 1490 If multiple 'ipsec-action' attributes or multiple 'ike-action' 1491 attributes are specified, they should be taken as logical ORs. 1493 5.4 Selectors and Actions 1495 SPSL policies all contain two types of attributes: selectors and 1496 actions. Selectors are the policy attributes that are used to match 1497 packets with a particular policy. Currently, all the selectors that 1498 are defined are contained in the base policy class, though sub-classes 1499 may also contain additional selectors. The selectors currently 1500 defined in the IPSec DOI are: 1502 src dst 1503 src-port dst-port 1504 xport-proto userid 1505 systemname ipv6-class 1506 ipv6-flow ipv4-tos 1507 seclabel direction 1509 An extended list of selectors supported by SPSL includes: 1511 ah-hdr ipcomp-hdr rhv1-dst 1512 ah-nhdr ipcomp-nhdr rhv1-nhop 1513 direction iphdr rhv1-phop 1514 dop-hdr ipv4-dst seclabel 1515 dop-nhdr ipv4-frgm src 1516 dst ipv4-frgo src-port 1517 dst-port ipv4-hdr systemname 1518 esp-hdr ipv4-hlen tcp-ack 1519 esp-nhdr ipv4-id tcp-dato 1520 frag-hdr ipv4-opt-lsrr-dst tcp-dst-port 1521 frag-nhdr ipv4-opt-ssrr-dst tcp-fin 1522 hop-hdr ipv4-prot tcp-hdr 1523 hop-nhdr ipv4-src tcp-psh 1524 icmp4-code ipv4-tlen tcp-rst 1525 icmp4-gwy ipv4-tos tcp-src-port 1526 icmp4-hdr ipv4-ttl tcp-syn 1527 icmp4-id ipv6-class tcp-urg 1528 icmp4-mtu ipv6-dst tcp-urgp 1529 icmp4-seq ipv6-flow udp-cks 1530 icmp4-type ipv6-hdr udp-dst-port 1531 icmp6-code ipv6-nhdr udp-hdr 1532 icmp6-hdr ipv6-src udp-id 1533 icmp6-id ipver udp-src-port 1534 icmp6-mtu rh-hdr userid 1535 icmp6-seq rh-nhdr xport-prot 1536 icmp6-type rh-vers 1538 Actions are the policy attributes that are applied to outbound packets 1539 and are used to decide whether or not to accept inbound packets. The 1540 actions currently defined in SPSL are: 1542 tfr-action ipsec-action ike-action 1544 5.5 Policy Order 1546 Multiple policy objects and attributes are likely to apply to a 1547 particular communication. For example, most systems will have a 1548 default policy to deny all inbound communications. There will then be 1549 some more policies to permit specific inbound communications. A set 1550 of selector values (see section 5.4) that match one of the specific 1551 policies will also match the general default policy. SPSL must 1552 establish a rule so that the correct policy is applied to the 1553 communication. The rule must always provide the same answer when 1554 applied to the same set of policies, otherwise inconsistent policy 1555 enforcement may occur. 1557 SPSL uses a simple rule to determine which policy should be applied to 1558 the on-going communication - physical ordering of the policies. The 1559 policy applied should always be the first policy that matches all the 1560 selectors of the communication. This ordering holds for both the 1561 ordering of the policy objects and the ordering of 'policy' attributes 1562 within policy objects, if the long format of the policy class is used. 1563 The physical ordering is the ordering of the policies in a file of 1564 SPSL policy objects. This ordering must be maintained by the parser 1565 and other applications that use the SPSL objects. 1567 6. Security Considerations 1569 SPSL is used to define a set of security policies for a host or a 1570 domain. It is necessary to insure that the policies are only modified 1571 by authorized maintainers, so that the intended policies are enforced. 1572 The language provides the mechanisms to insure this and the integrity 1573 of the policies, however the mechanisms must be used to secure them. 1575 Tools that create and modify SPSL objects MUST use the 'auth' 1576 attribute in the mntner object to authenticate the maintainer before 1577 permitting any objects to be modified. When defining the maintianer 1578 initially, the relative strengths of the provided authentication 1579 mechanisms SHOULD be considered before using a particular one. The 1580 integrity of an SPSL policy file is only as strong as the weakest 1581 'auth' mechanism provided. 1583 Tools that modify or use SPSL objects SHOULD verify the signatures on 1584 the objects before using them. A successful verification indicates 1585 that the policy was written or modified by an authorized maintainer. 1586 If the policy fails verification, it is suspect and SHOULD NOT be 1587 used. 1589 7. Remaining Issues 1591 The following issues are not resolved in this first draft of language 1592 definition. Solutions will be developed and included in the 1593 subsequent revisions of the document. 1595 * General SA endpoints need to be thought out more, as noted in 1596 the document. 1598 * We are considering adding support for DNS names as policy 1599 endpoints and for domain coverage in addition to IP addresses. 1601 8. Acknowledgements 1603 The authors thank Luis Sanchez, David Mankins, Alden Jackson, and 1604 Steve Kent for their help in reviewing early drafts of this document 1605 and suggesting changes to the language. We thank Rajesh Krishnan and 1606 Matt Fredette for their work on an SPSL parser and suggested changes 1607 to make the language parseable. We also thank Pam Helinek and Marla 1608 Shepard for building an interface for creating, modifying, and 1609 processing SPSL files. 1611 Appendix A. BNF Form of SPSL 1613 spsl-file -> spslobjlist | (empty) 1615 spslobjlist -> spslobjlist spslobj | spslobj 1617 spslobj -> "mntner:" objectname line-term mntner-attributes blankline 1618 | "cert:" objectname line-term cert-attributes blankline 1619 | "node:" objectname line-term node-attributes blankline 1620 | "node-set:" objectname line-term node-set-attributes blankline 1621 | "gateway:" objectname line-term gateway-attributes blankline 1622 | "gateway-set:" objectname line-term gateway-set-attributes 1623 blankline 1624 | "domain:" objectname line-term domain-attributes blankline 1625 | "polserv:" objectname line-term polserv-attributes blankline 1626 | "policy-name:" objectname line-term policy-attributes blankline 1627 | line-term 1629 # checking for mandatory attributes is necessary after parsing 1630 mntner-attributes -> mntner-attributes mntner-attribute 1631 | mntner-attribute 1632 cert-attributes -> cert-attributes cert-attribute | cert-attribute 1633 node-attributes -> node-attributes node-attribute | node-attribute 1634 node-set-attributes -> node-set-attributes node-set-attribute 1635 | node-set-attribute 1636 gateway-attributes -> gateway-attributes gateway-attribute 1637 | gateway-attribute 1638 gateway-set-attributes -> gateway-set-attributes gateway-set-attribute 1639 | gateway-set-attribute 1640 domain-attributes -> domain-attributes domain-attribute 1641 | domain-attribute 1642 polserv-attributes -> polserv-attributes polserv-attribute 1643 | polserv-attribute 1644 policy-attributes -> policy-attributes policy-attribute 1645 | policy-attribute 1647 mntner-attribute -> shared-attribute | "auth:" auth-info line-term 1648 | "address:" string line-term | "phone:" phonenum line-term 1649 | "fax-no:" phonenum line-term | "email:" emailaddr line-term 1650 | "certs:" objectnamelist line-term 1652 cert-attribute -> shared-attribute 1653 | "certificate:" certtype hexstring line-term 1654 | "certlocation:" certtype fetchproto locname line-term 1655 | "crllocation:" crltype fetchproto locname line-term 1657 node-attribute -> shared-attribute | "name:" dnsname line-term 1658 | "alias:" dnsname line-term | "ifaddr:" ipaddress line-term 1660 node-set-attribute -> shared-attribute 1661 | "members:" objectnamelist line-term 1663 gateway-attribute -> shared-attribute | "name:" dnsname line-term 1664 | "alias:" dnsname line-term | "ifaddr:" ipaddress line-term 1665 | "preference:" integer line-term 1667 gateway-set-attribute -> shared-attribute 1668 | "members:" objectnamelist line-term 1670 domain-attribute -> shared-attribute 1671 | "coverage:" domaincover line-term 1672 | "gateways:" objectnamelist line-term 1673 | "polservs:" objectnamelist line-term 1675 polserv-attribute -> shared-attribute | "name:" dnsname line-term 1676 | "alias:" dnsname line-term | "ifaddr:" ipaddress line-term 1678 policy-attribute -> shared-attribute 1679 | "association:" objectnamelist line-term 1680 | "cache-expiry:" integer line-term | condition-attribute 1681 | action-attribute 1683 shared-attribute -> "char-set:" charset line-term 1684 | "notes:" string line-term | "mnt-by:" objectnamelist line-term 1685 | "changed:" objectname date line-term 1686 | "signature:" objectname objectname hash-alg signature-data 1687 line-term 1688 | comments blankline 1690 condition-attribute -> "policy:" "dst" addresslist ports-opt src-opt 1691 xport-opt dir-opt actiontype line-term 1692 | "valid-period:" valid-period-list line-term 1693 | "dst:" addresslist ports-opt line-term 1694 | "src:" addresslist ports-opt line-term 1695 | "xport-proto:" integerlist line-term 1696 | "direction:" dirtype symmetric-opt line-term 1697 | "userid:" user-namelist line-term 1698 | "systemname:" system-namelist line-term 1699 | "ipv6-class:" integerlist line-term 1700 | "ipv6-flow:" integerlist line-term 1701 | "ipv4-tos:" integerlist line-term 1702 | "seclabel:" seclabellist line-term 1703 | "ipver:" integerlist line-term 1704 | "ipv4-hlen:" integerlist line-term 1705 | "ipv4-tlen:" integerlist line-term 1706 | "ipv4-id:" integerlist line-term 1707 | "ipv4-frgm:" zeroone line-term 1708 | "ipv4-frgo:" integerlist line-term 1709 | "ipv4-ttl:" integerlist line-term 1710 | "ipv4-prot:" integerlist line-term 1711 | "ipv4-src:" ipv4list line-term 1712 | "ipv4-dst:" ipv4list line-term 1713 | "ipv4-opt-lsrr-dst:" ipv4list line-term 1714 | "ipv4-opt-ssrr-dst:" ipv4list line-term 1715 | "ipv6-dst:" ipv6list line-term 1716 | "ipv6-src:" ipv6list line-term 1717 | "ipv6-nhdr:" integerlist line-term 1718 | "rh-nhdr:" integerlist line-term 1719 | "rh-vers:" integerlist line-term 1720 | "rhv1-dst:" ipv6list line-term 1721 | "rhv1-nhop:" ipv6list line-term 1722 | "rhv1-phop:" ipv6list line-term 1723 | "ah-nhdr:" integerlist line-term 1724 | "dop-nhdr:" integerlist line-term 1725 | "esp-nhdr:" integerlist line-term 1726 | "frag-nhdr:" integerlist line-term 1727 | "hop-nhdr:" integerlist line-term 1728 | "ipcomp-nhdr:" integerlist line-term 1729 | "tcp-ack:" zeroone line-term 1730 | "tcp-dato:" integerlist line-term 1731 | "tcp-dst-port:" integerlist line-term 1732 | "tcp-fin:" zeroone line-term 1733 | "tcp-psh:" zeroone line-term 1734 | "tcp-rst:" zeroone line-term 1735 | "tcp-src-port:" integerlist line-term 1736 | "tcp-syn:" zeroone line-term 1737 | "tcp-urg:" zeroone line-term 1738 | "tcp-urgp:" integerlist line-term 1739 | "udp-cks:" integerlist line-term 1740 | "udp-dst-port:" integerlist line-term 1741 | "udp-src-port:" integerlist line-term 1742 | "icmp4-code:" integerlist line-term 1743 | "icmp4-gwy:" ipv4list line-term 1744 | "icmp4-id:" integerlist line-term 1745 | "icmp4-mtu:" integerlist line-term 1746 | "icmp4-seq:" integerlist line-term 1747 | "icmp4-type:" integerlist line-term 1748 | "icmp6-code:" integerlist line-term 1749 | "icmp6-gwy:" ipv6list line-term 1750 | "icmp6-id:" integerlist line-term 1751 | "icmp6-mtu:" integerlist line-term 1752 | "icmp6-seq:" integerlist line-term 1753 | "icmp6-type:" integerlist line-term 1755 action-attribute -> "tfr-action:" actiontype line-term 1756 | ipsec-attribute 1757 actiontype -> actionpd | actionfwd | actionpd "," actionfwd 1758 actionpd -> "permit" | "deny" 1759 actionfwd -> "forward" actionfwd-dst 1760 actionfwd-dst -> "dns" dnsname | ipaddress 1762 addresslist -> ipaddrlist | "any" | "*" 1764 auth-info -> "crypt-pw" string | "pgp" hexstring 1765 | "cert" objectnamelist 1767 certtype -> "dnskey" | "kerberos" | "pgp" | "pkcs7" | "spki" 1768 | "x509_ke" | "x509_sig" 1769 crltype -> "x509" 1770 date -> digit digit digit digit digit digit digit digit 1772 dir-opt -> "direction" dirtype symmetric-opt | (empty) 1773 dirtype -> "inbound" | "outbound" 1774 symmetric-opt -> "," "symmetric" | (empty) 1776 dn -> # see rfc 1779 1778 # DNS name based on RFC 1034 1779 dnsnamelist -> dnsnamelist "," dnsnamecomp 1780 dnsnamecomp -> dnsname 1781 dnsname -> dnsname "." label | label 1782 label -> letter label-end-opt 1783 label-end-opt -> ldh-string letdig | (empty) 1784 ldh-string -> ldh-string letdighyph | (empty) 1785 letdighyph -> letter | digit | "-" 1786 letdig -> letter | digit 1788 domaincover -> ipaddrlist | objectnamelist 1789 | ipaddrlist "," objectnamelist 1791 edipn -> string 1793 # email address from rfc 822 1794 emailaddr -> username "@" dnsname 1796 expiry-opt -> expiry | (empty) 1797 expiry -> "expiry" expiry-type integerrange 1798 expiry-type -> "seconds" | "kilobytes" 1800 fetchproto -> "cdp" | "dns" | "file" 1801 field-opt -> "field" integer | (empty) 1802 filename -> filename filechar | (empty) 1803 filechar -> alphanum | "_" | "-" | ":" | "." | "/" | "\" 1805 genname -> "dirname" rdnlist | "dns" dnsname | "ediname" edipn 1806 | "ipaddr" ipaddress | "n822" emailaddr | "other" oid string 1807 | "regid" oid | "uri" uri | "x400" or-address 1809 hash-alg -> "dsa-sha1" | "rsa-pkcs1" 1811 integerlist -> integerslist | "any" | "opaque" | "*" 1812 integerslist -> integerslist "," integercomp | integercomp 1813 integercomp -> integerrange | "not" integerrange 1814 integerrange -> "min" integer | "max" integer 1815 | integer "-" integer | integer 1816 integer -> integer digit | digit 1818 ipaddress -> ipv4address | ipv6address 1819 ipv4address -> two55 "." two55 "." two55 "." two55 1820 ipv6address -> v6digit ":" v6digit ":" v6digit ":" v6digit ":" 1821 v6digit ":" v6digit ":" v6digit ":" v6digit 1822 v6digit -> hexdigit | hexdigit hexdigit | hexdigit hexdigit hexdigit 1823 | hexdigit hexdigit hexdigit hexdigit | (empty) 1825 ipaddrlist -> ipaddrlist "," ipcomp | ipcomp 1826 ipcomp -> ipv4comp | ipv6comp 1828 ipv4list -> ipv4list "," ipv4comp | ipv4comp 1829 ipv4comp -> ipv4address | ipv4address-range 1830 | "not" ipv4address | "not" ipv4address-range 1831 ipv4address-range -> ipv4address "-" ipv4address 1832 | ipv4address "mask" ipv4address 1833 | ipv4address "/" integer 1835 ipv6list -> ipv6list "," ipv6comp | ipv6comp 1837 ipv6comp -> ipv6address | ipv6address-range 1838 | "not" ipv6address | "not" ipv6address-range 1839 ipv6address-range -> ipv6address "-" ipv6address 1840 | ipv6address "mask" ipv6address 1841 | ipv6address "/" integer 1843 ipsec-attribute -> "ipsec-action:" ipsec-action line-term 1844 | "ike-action:" ike-action line-term 1846 ipsec-action -> ipsec_action_esp_opt ipsec_action_ah_opt 1847 ipsec_action_ipcomp_opt 1849 ipsec_action_esp_opt -> esp-proposal ipsectype ipsecloc | (empty) 1850 ipsec_action_ah_opt -> ah-proposal ipsectype ipsecloc | (empty) 1851 ipsec_action_ipcomp_opt -> ipcomp-proposal | (empty) 1853 ipsectype -> "tunnel" | "transport" | (empty) 1854 usepfs -> "true" | "false" 1856 proposal-choice -> "req" | "opt" 1858 ah-proposal -> "ah" proposal-choice "integrity" 1859 integrity-alg-any expiry-opt | "ah" "proh" 1860 integrity-alg-any -> "any" keylen-opt | integrity-alg-list 1861 integrity-alg-list -> integrity-alg-list "," not-opt integrity-alg 1862 keylen-opt | not-opt integrity-alg keylen-opt 1863 integrity-alg -> "hmacdes" | "hmacmd5" | "hmacsha1" 1864 | "kpdk" | integer 1866 esp-proposal -> "esp" proposal-choice "cipher" ipsec-cipher-alg-any 1867 integrity-opt expiry-opt | "esp" "proh" 1868 ipsec-cipher-alg-any -> "any" keylen-opt rounds-opt 1869 | ipsec-cipher-alg-list 1870 ipsec-cipher-alg-list -> 1871 ipsec-cipher-alg-list "," not-opt ipsec-cipher-alg keylen-opt 1872 rounds-opt | not-opt ipsec-cipher-alg keylen-opt rounds-opt 1873 ipsec-cipher-alg -> "blowfish" | "cast" | "des" | "des3" | "idea" 1874 | "idea3" | "none" | "rc4" | "rc5" | "rfc1829-iv32" 1875 | "rfc1829-iv64" | integer 1876 rounds-opt -> "rounds" integerrange | (empty) 1877 integrity-opt -> "integrity" integrity-alg-any | (empty) 1878 ipcomp-proposal -> "ipcomp" proposal-choice ipcomp-alg-any 1879 | "ipcomp" "proh" 1880 ipcomp-alg-any -> "any" | ipcomp-alg-list 1881 ipcomp-alg-list -> ipcomp-alg-list "," not-opt ipcomp-alg 1882 | not-opt ipcomp-alg 1883 ipcomp-alg -> "deflate" | "lzs" | "oui" | integer 1885 ike-action -> "ikemode" ikemode "pfs" usepfs 1886 "auth" ike-auth-method-any 1887 "cipher" ike-cipher-alg-any "hash" ike-hash-alg-any 1888 ike-group-opt prf-opt field-opt expiry 1890 ikemode -> "main" | "aggressive" | "quick" 1892 ike-auth-method-any -> "any" | ike-auth-method-list 1893 ike-auth-method-list -> ike-auth-method-list "," not-opt 1894 ike-auth-method | not-opt ike-auth-method 1895 ike-auth-method -> "pre-shared" | "dss" | "rsa" | "rsa-encrypt" 1896 | "rsa-revised" | integer 1898 ike-cipher-alg-any -> "any" keylen-opt | ike-cipher-alg-list 1899 ike-cipher-alg-list -> ike-cipher-alg-list "," not-opt ike-cipher-alg 1900 keylen-opt | not-opt ike-cipher-alg keylen-opt 1901 ike-cipher-alg -> "blowfish" | "cast" | "des" | "des3" | "idea" 1902 | "rc5" | integer 1904 ike-hash-alg-any -> "any" | ike-hash-alg-list 1905 ike-hash-alg-list -> ike-hash-alg-list "," not-opt ike-hash-alg 1906 | not-opt ike-hash-alg 1907 ike-hash-alg -> "md5" | "sha1" | "tiger" | integer 1909 ike-group-opt -> "group-desc" ike-group-desc | 1910 "group-type" ike-group-type | (empty) 1911 ike-group-desc -> "modp-768" | "modp-1024" | "ec2n-155" 1912 | "ec2n-185" | integer 1913 ike-group-type -> ike-group-name hexstring hexstring hexstring 1914 hexstring hexstring hexstring 1915 ike-group-name -> "modp" | "ecp" | "ec2n" | integer 1917 ipsecloc -> from-opt to-opt 1918 from-opt -> "from" anylocation | (empty) 1919 to-opt -> "to" anylocation | (empty) 1920 anylocation -> "any" | locations 1921 locations -> locations "," location | location 1922 location -> "dest" | "host" | "local-sg" | "remote-sg" | ipaddress 1923 | "dns" dnsname 1925 keylen-opt -> "keylen" integerrange | (empty) 1926 locname -> genname | "rdn" rdn | "filename" filename 1927 not-opt -> "not" | (empty) 1928 objectnamelist -> objectnamelist "," objectname | objectname 1929 objectname -> extletter objectinternals alphanum | extletter alphanum 1930 | extletter 1931 objectinternals -> objectinternals objectinternal | (empty) 1932 objectinternal -> alphanum | "_" | "-" | ":" | "." 1934 oid -> objectname 1935 or-address -> string 1936 phonenum -> phonenum phonenum | digit | " " | "+" | "-" | "x" 1938 ports-opt -> "port" integerlist dynamic-opt | (empty) 1939 dynamic-opt -> "dynamic" portrange-opt | (empty) 1940 portrange-opt -> integerrange | (empty) 1942 prf-opt -> "prf" integer | (empty) 1943 rdnlist -> rdnlist rdn | rdn 1944 rdn -> # see rfc 1779 1946 src-opt -> "src" addresslist ports-opt | (empty) 1947 seclabellist -> seclabelslist | "*" | "opaque" 1948 seclabelslist -> seclabelslist "," not-opt seclabel | not-opt seclabel 1949 seclabel -> hexstring 1950 signature-data -> hexstring 1952 system-namelist -> system-nameslist | "*" | "any" 1953 system-nameslist -> system-nameslist "," not-opt system-name 1954 | not-opt system-name 1955 system-name -> genname | "dn" dn 1957 uri -> # see appendix A of draft-fielding-uri-syntax-03.txt 1958 username -> # see definition in RFC 822 1960 user-namelist -> user-nameslist | "*" | "any" 1961 user-nameslist -> user-nameslist "," not-opt user-name 1962 | not-opt user-name 1963 user-name -> "n822" emailaddr | "dn" dn 1965 valid-period-list -> valid-period-list "," valid-period 1966 | valid-period 1967 valid-period -> year-opt month-opt dayof-month-opt 1968 dayof-week-opt time-opt 1970 year-opt -> "year" integer "-" integer | (empty) 1971 month-opt -> "month" bitstring | (empty) 1972 dayof-month-opt -> "day-of-month" bitstring | (empty) 1973 dayof-week-opt -> "day-of-week" bitstring | (empty) 1974 time-opt -> "time" not-opt time "-" time | (empty) 1975 time -> integer ":" integer ":" integer 1977 xport-opt -> "xport-proto" integerlist | (empty) 1978 alphanum -> extletter | digit 1979 charset -> string 1980 digit -> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 1981 extletter -> A..Z | a..z | #140 | #156 | #192..#214 1982 | #216..#246 | #248..#255 1983 letter -> A..Z | a..z 1984 two55 -> [0-9] | [0-9][0-9] | 1[0-9][0-9] | 2[0-4][0-9] | 25[0-5] 1985 hexstring -> hexstring hexdigit | hexdigit 1986 hexdigit -> [0-9] | a | A | b | B | c | C | d | D | e | E | f | F 1987 string -> string char | (empty) 1988 zeroone -> 0 | 1 1989 bitstring -> bitstring zeroone | zeroone 1991 line-term -> comments blankline | blankline 1992 comments -> comments comment | comment 1993 comment -> "#" string 1995 blankline -> whitespace LF 1996 whitespace -> whitespace whitechar | (empty) 1997 whitechar -> tab | " " | ff 1999 char -> any character in ISO 8859-1 (Latin-1) except special characters 2000 ("#" and "\") which must be replaced by their escaped versions 2001 ("\#" and "\\"). 2003 References 2005 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 2006 Requirement Level," RFC-2119, March 1997. 2008 [DOI] D. Piper, "The Internet IP Security Domain of Interpretation 2009 for ISAKMP", RFC 2407, November 1998. 2011 [DSA] Federal Information Processing Standards Publication 2012 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 2014 [ISO8859] Information Processing - 8-bit Single-Byte Coded Graphic 2015 Character Sets. Part1: Latin Alphabet Number 1, ISO 8859-1, 2016 1987. 2018 [Kent98] S. Kent, R. Atkinson, "Security Architecture for the 2019 Internet Protocol", RFC 2401, November 1998. 2021 [PKIXP1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 2022 Public Key Infrastructure Certificate and CRL Profile", 2023 RFC 2459, January 1999. 2025 [PolMod] R. Pereira, P. Bhattacharya, "IPSec Policy Data Model", 2026 Internet Draft draft-ietf-ipsec-policy-model-00, February 1998. 2028 [rfc822] D. Crocker, "Standard for the Format of ARPA Internet 2029 Text Messages", RFC 822, August 1982. 2031 [rfc1034] P. Mockapetris, "Domain Names - Concepts and Facilities", 2032 RFC 1034, November 1987. 2034 [rfc2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 2035 RFC 2409, November 1998. 2037 [RPSL] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, D. 2038 Meyer, M. Terpstra, and C. Villamizer. "Routing Policy 2039 Specification Language (RPSL)". RFC 2280. January 1998. 2041 [RSA] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data 2042 Security, Inc., 3 June 1991. 2044 [SPS] L. Sanchez, M. Condell, "Security Policy System", 2045 Internet Draft draft-ietf-ipsec-sps-00.txt, November 1998. 2047 Author Information 2049 Matthew Condell 2050 BBN Technologies 2051 10 Moulton Street 2052 Cambridge, MA 02138 2053 USA 2054 Email: mcondell@bbn.com 2055 Telephone: +1 (617) 873-6203 2057 Charles Lynn 2058 BBN Technologies 2059 10 Moulton Street 2060 Cambridge, MA 02138 2061 USA 2062 Email: clynn@bbn.com 2063 Telephone: +1 (617) 873-3367 2065 John Zao 2066 BBN Technologies 2067 10 Fawcett Street 2068 Cambridge, MA 02138 2069 USA 2070 Email: jzao@bbn.com 2071 Telephone: +1 (617) 873-2438