[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                         M. Condell, BBN/GTEI
Internet Draft                                   C. Lynn, BBN/GTEI
draft-ietf-ipsec-spsl-00.txt                      J. Zao, BBN/GTEI
Expires April, 1999                               October 21, 1998




                Security Policy Specification Language


Status of this Memo

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

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

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).


Abstract

This document describes the Security Policy Specification Language
(SPSL), a language designed to express security policies, security
domains, and the entities that manage the policies and domains.  The
syntax and semantics of the language are presented here.  SPSL
currently supports policies for packet filtering, IP Security (IPSec),
and ISAKMP exchanges, however, it may easily be extended to express
other types of policies.

















Condell, Lynn, Zao                                              [Page 1]


Internet Draft   Security Policy Specification Language     October 1998

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1 Language Requirements . . . . . . . . . . . . . . . . . . . . .  3
    1.1.1 Specification of Security Policies. . . . . . . . . . . . .  3
    1.1.2 Node and Domain Based Models. . . . . . . . . . . . . . . .  4
    1.1.3 Multiple Distributed Policy Enforcement Points. . . . . . .  5
    1.1.4 Authentication and Authorization Mechanisms . . . . . . . .  5
    1.1.5 Language Flexibility and Extensibility. . . . . . . . . . .  5
  1.2 Language Structure. . . . . . . . . . . . . . . . . . . . . . .  6
    1.2.1 Categories. . . . . . . . . . . . . . . . . . . . . . . . .  6
    1.2.2 Class Design. . . . . . . . . . . . . . . . . . . . . . . .  6
    1.2.3 Naming Scheme and Scope . . . . . . . . . . . . . . . . . .  8
    1.2.4 $INCLUDE Extension. . . . . . . . . . . . . . . . . . . . .  8

2. Primitive Data Types . . . . . . . . . . . . . . . . . . . . . . .  8

3. Management Agent Classes . . . . . . . . . . . . . . . . . . . . . 10
  3.1 mntner Class. . . . . . . . . . . . . . . . . . . . . . . . . . 10
  3.2 cert Class. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Network Entity Classes . . . . . . . . . . . . . . . . . . . . . . 14
  4.1 node Class. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  4.2 node-set Class. . . . . . . . . . . . . . . . . . . . . . . . . 15
  4.3 gateway Class . . . . . . . . . . . . . . . . . . . . . . . . . 15
  4.4 gateway-set Class . . . . . . . . . . . . . . . . . . . . . . . 16
  4.5 polserv Class . . . . . . . . . . . . . . . . . . . . . . . . . 17
  4.6 domain Class. . . . . . . . . . . . . . . . . . . . . . . . . . 18

5. Policy Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  5.1 policy Attribute (Short Format) . . . . . . . . . . . . . . . . 19
  5.2 policy Attribute (Long Format). . . . . . . . . . . . . . . . . 22
  5.3 ipsec-policy Class. . . . . . . . . . . . . . . . . . . . . . . 25
  5.4 Selectors and Actions . . . . . . . . . . . . . . . . . . . . . 28
  5.5 Policy Order. . . . . . . . . . . . . . . . . . . . . . . . . . 29

6. Remaining Issues . . . . . . . . . . . . . . . . . . . . . . . . . 30

7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 30

Appendix A.  BNF Form of SPSL . . . . . . . . . . . . . . . . . . . . 31
Appendix B.  PBSM Policy Model. . . . . . . . . . . . . . . . . . . . 38

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Author Information. . . . . . . . . . . . . . . . . . . . . . . . . . 43










Condell, Lynn, Zao                                              [Page 2]


Internet Draft   Security Policy Specification Language     October 1998

1.  Introduction

The Security Policy Specification Language (SPSL) is a vendor and
platform independent language for specifying communication security
policies, especially those controlling the use of IPSec and ISAKMP
protocols.  As the use of firewalls with strong authentication and
virtual private networks (VPNs) with level 2 and 3 encryption become
more popular, the need for managing these security services and
devices by means of security policies also becomes more acute.  SPSL
allows the security policies to be specified in an interoperable
language, stored in common databases and processed by management
systems distinguished from the security devices.  As such, SPSL is a
main component of a scalable policy based security management system
[SPS].

The syntax of SPSL and several of its supporting object classes were
derived from the Routing Policy Specification Language [RPSL].
However, the processing rules of SPSL are significantly different from
those of RPSL.  Although the language was designed initially for
specifying IPSec and ISAKMP policies, its flexible syntax allows it to
be used to express stateless and stateful packet filtering rules.
Moreover, the language is extensible: new object classes can be added
for the purpose of specifying policies of other security or
communication protocols.

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [Bra97].

1.1  Language Requirements

SPSL was designed to meet the following requirements:

* Support for IPSec/ISAKMP and general communication security
  policy specification,

* Support for both node and domain based policy models,

* Support for multiple distributed policy enforcement points,

* Support for authentication and authorization mechanisms to aid
  policy management,

* Support for flexibility and extensibility of the language.


1.1.1  Specification of Security Policies

In SPSL, a policy is defined as a binding between a set of
communication conditions and a corresponding set of security actions.
This abstraction is used to specify communication security policies in
general and IPSec/ISAKMP policies in particular.  If an on-going
communication (or one to be established) matches one of the conditions
then one of the prioritized alternative sets of actions must be taken

Condell, Lynn, Zao                                              [Page 3]


Internet Draft   Security Policy Specification Language     October 1998

to protect the communication.  This abstraction also captures current
policy enforcement practices.

The set of communication conditions in a policy are specified as one
or more tuples of selector values.  This is because IPSec transports
and tunnels depend on security associations that are attached to
specific values of chosen communication parameters, known as the
selectors.  SPSL supports all the selectors mentioned in IPSec
architecture document [Kent98] and a much extended collection as
described in Section 5.4.

The actions of a policy can affect different communication security
operations:

   * They may specify simple packet filtering actions: discard the
     packet, pass it, or forward it (via tunneling) to a designated
     network entity.

   * They may specify security proposals necessary for protecting
     ISAKMP exchanges.

   * They may specify IPSec tunnels or transports for passing the
     packets.  The possible security mechanisms to protect the tunnels
     and the transports are specified as ISAKMP proposals as specified
     in the IPSec Domain of Interpretation [DOI].

SPSL supports IPSec policy data model [PolMod] proposed by Pereira
and Bhattacharya in order to effect the last two types of actions.


1.1.2  Node and Domain Based Models

SPSL enables two ways to associate security policies with network
entities, known as the node based and the domain based policy
model.

In the node based model, security policies are bound to individual
network nodes and security devices, e.g., firewalls, hosts, etc.  The
policies associated with a network node specify the protection for the
communications to and from the node.  These policies are expected to
be enforced by the node itself.  The policies associated with a
security device (formally known as a policy enforcement agent) specify
the protection for the communications passing through these agents.
Either the source or the destination of the communication must be
among the nodes that the agent is authorized/expected to protect.  In
this model, both the network nodes and the security policy enforcement
agents manage their own policies.

In the domain based model, security policies are bound to a security
domain.  A security domain is defined as a connected set of network
entities that are protected by policy enforcement agents (PEA) placed
on every communication path going through the perimeter of the domain.
Every policy enforcement agent of the domain works to enforce the
common set of security policies associated with the domain.  Security

Condell, Lynn, Zao                                              [Page 4]


Internet Draft   Security Policy Specification Language     October 1998

domains may be completely disjoint, contained in one another,
comprised of several sub-networks, or just hosts that enforce their
own policy.  In this model, the policies associated with a domain are
managed by one or more special agents common to the entire domain.
These special agents act as policy servers.  They may be distinct
network entities or co-located with the nodes or the policy
enforcement agents of the domain.


1.1.3  Multiple Distributed Policy Enforcement Points

SPSL allows explicit selection of enforcement agent(s) of a security
policy.  The choices can be interfaces of end nodes, en-route security
gateways (SG), e.g., firewalls, specified by IP addresses.  The
explicit selection of an enforcement agent allows a system to choose a
communication path different than the one chosen by the routing
infrastructure.  This facility is especially useful for tunnel
establishment and management.


1.1.4  Authentication and Authorization Mechanisms

SPSL has object classes to support the following security services:

   1. data integrity, data origin authentication: every policy object
      is protected by using a public key signature.  Both RSA [RSA]
      and DSA [DSA] signature algorithms are supported.  This also
      offers non-repudiation proof of the issuer(s) of the policies.

   2. authentication and authorization of policy management entities:
      management objects such as maintainers have public key
      certificates associated with them so that they may issue
      policies and/or identify themselves to a security management
      system for access control purposes.

With these services, users of SPSL policy specifications can always
verify the integrity and the origin of the policies and allow only
authorized personnel to maintain the policies.


1.1.5  Language Flexibility and Extensibility

SPSL is a flexible and extensible language.  The language is flexible
because its present syntax enables it to specify policies for
different uses.  For example, it can be used to specify
non-cryptographic stateless packet filtering rules as well as IPSec
tunnels for virtual private networks.  It can also be used to effect
standard IPSec or fine grain selector matching.  In addition, it
supports both node and domain based models.

The language is also extensible.  It allows new object classes to be
created by following a syntactic rule similar to inheritance.
Consequently, the language can be extended for specifying policies of
different communication and security protocols/applications.

Condell, Lynn, Zao                                              [Page 5]


Internet Draft   Security Policy Specification Language     October 1998

1.2  Language Structure

SPSL uses the object paradigm although it is neither an object-
oriented nor a type based language.  The language defines a small set
of classes, which can instantiate objects maintaining data relevant to
policy specification.  The data are contained in the attributes
defined in the object classes.  There are no executable methods in the
classes.

New classes can be created as needed based on a syntactic rule similar
to inheritance in object-oriented languages.  For example, a new class
may have all the attributes of an existing class in addition to its
own attributes.  However, the old and the new classes are not related
by type polymorphic relations because the objects do not contain
types.  Objects in an SPSL file are distinguished and referred by the
unique values of their first attribute, known as the key attribute.


1.2.1  Categories

SPSL is comprised of the following four categories:

   Primitive Data - contain basic or atomic data elements used in
      policy specification, e.g., object-name, ipv4-address,
      integer-range, date, etc.

   Management Agents - contain information relevant to the management
      entities; the existing classes in this category are maintainer
      (mntner) and certificate (cert).

   Network Entities - depict the network elements that are relevant
      to policy specification; the existing classes are node,
      node-set, gateway, gateway-set, polserver, and domain.

   Policies - contain the policy specification; there are only two
      classes at the moment: class policy specifies general packet
      filtering rules and class ipsec-policy specifies IPSec
      selectors and actions.  Objects of the policy class may appear
      in two forms for short or long policy specification.


1.2.2  Class Design

Each class has a set of attributes which store information about the
objects of the class.  Attributes can be mandatory (man) or optional
(opt).  A mandatory attribute must be defined for all objects of the
class, and an optional attribute may be omitted.  Attributes can also
be single valued (s-v) or multiple valued (m-v).  A single valued
attribute may only appear once per object.  A multiple valued
attribute may appear more than once per object.  Each object is
uniquely identified by the key attribute of its class.




Condell, Lynn, Zao                                              [Page 6]


Internet Draft   Security Policy Specification Language     October 1998

An SPSL object is textually represented as a list of attribute-value
pairs.  An object's representation begins with the class-key
attribute-value pair.  Each attribute-value pair is written on a
separate line.  The attribute name precedes the first colon, ":",
and is followed by the value of the attribute.  An attribute-value
pair may span multiple lines.  At the end of each line that is
continued, a "\" must be used to indicate that the line is continued.
An object's representation ends when a blank line (i.e., a line
containing only whitespace characters such as spaces, tabs, and
carriage returns) is encountered.

The order of attributes within a signed object is significant.  The
order of the written form of the attributes when signed must be
preserved until the object is validated or resigned.  This ordering is
necessary to be able to verify signatures of objects.  The class key
must always be the first attribute.  If the charset attribute is
included, it must always precede any notes attribute.  The last
attribute in any object must be the signature attribute(s).  If
multiple policy attributes are included in a single policy class
object then their ordering must be preserved, unless the policy is
being specifically changed.  This is required since the ordering of
policies may affect how they are applied.

A value of an attribute may be a single data item or a list of data
items of the same type.  A list is represented by separating the list
members by commas ",".  Note that the options of having a list of
values and/or multiple values are two independent choices for an
attribute.  A multiple valued attribute may appear multiple times
within an object, and the value in each occurrence may or may not be a
list.  A single valued attribute may also have a list value.

The default character set is ISO 8859-1 (Latin-1) [ISO8859].  The
character set is an eight bit encoding where the lower 7 bits are
identical to the ASCII character set.  This default MUST always be
used for all the attribute tags and attribute values.  The character
set for the notes attribute value MAY be overridden by using the
char-set attribute.

An object's specification may contain comments.  A comment may appear
anywhere in an object definition.  It starts at the first "#"
character on a line and ends at the first end-of-line character.  The
"\" character may be used to escape the comment character, so that it
will be used as a "#" character and not a comment.  "\\" will be used
to represent the "\" character.  Whitespace characters may be used to
improve readability.










Condell, Lynn, Zao                                              [Page 7]


Internet Draft   Security Policy Specification Language     October 1998

1.2.3  Naming Scheme and Scope

Since an SPSL object is distinguished by and referenced by its key
attribute, the value of that attribute (which is usually a name) must
be unique in the entire policy specification file (SPSL file).  The
actual scope of uniqueness may differ depending on the choice of
policy model.  In the node based model, the names must be unique
within a node or a security enforcement point that owns the policies.
In the domain based model, the names must be unique within the set of
security servers that manage the policies of one or more domains in a
primary-secondary server configuration.  Note that the name of an
object must be unique among all classes, not merely among its own
class.

A recommended method for satisfying this uniqueness requirement
is to adopt the following hierarchical naming scheme.  A
hierarchical object name is a sequence of names (usually, domain,
node, or gateway names) separated by colons ":".  The names are
arranged following a descending order starting with the highest level
name.  For example, SG-BAZ:SG-BAR:SG-FOO is a valid hierarchical
object name with SG-BAZ being the top level name.

1.2.4  $INCLUDE Extension

An SPSL file may actually consist of multiple files containing
complete SPSL objects.  One SPSL file may be included as part of
another file using the following:

   $INCLUDE <filename>

The contents of <filename> are included in the SPSL file at the
exact place where the $INCLUDE line is in the SPSL file.  As with
SPSL objects, this line must be separated from other SPSL objects
by a blank line.

2.  Primitive Data Types

The following are the commonly used data types in SPSL.  [Note: many
of these data types are identical to those specified in RPSL. [RPSL]]

   <object-name>  All SPSL objects are identified by a name.  An
      <object-name> is made up of letters, digits, the character
      underscore "_", the character period ".", the character colon
      ":", and the character hyphen "-"; the first character of a name
      must be a letter, and the last character of a name must be a
      letter or a digit.  Names are case sensitive.

   <ipv4-address>  An IPv4 address represented as a sequence of four
       integers in the range from 0 to 255 separated by the character
       dot ".".  For example, 172.17.128.5 represents a valid IPv4
       address.




Condell, Lynn, Zao                                              [Page 8]


Internet Draft   Security Policy Specification Language     October 1998

   <ipv6-address>  An IPv6 address represented as a sequence of eight
       hexadecimal integers in the range from 0 to FFFF separated by
       the character colon ":".  The last two hexadecimal integers may
       be replaced with an <ipv4-address>.  A single string of one or
       more hexadecimal integers with value zero (0) may be omitted.
       For example, 129:0:0:0:5:800:20C2:F35B,
       129:0:0:0:5:800:32.194.243.91, and 129::5:800:32.194.243.91 all
       represent valid IPv6 addresses, and all encode the same value.

   <ip-address>  An <ipv4-address> or <ipv6-address>.

   <address-range>  An address range is represented as an IP address
       followed by the character dash "-" followed by a second IP
       address, by an IP address followed by the keyword "mask"
       followed by a second IP address, or by an IP address followed
       by a slash "/" followed by an integer.  The addresses MUST be
       either both <ipv4-address>'s or both <ipv6-address>'s.  The dash
       form of an address range is inclusive.  The following are valid
       address ranges: 172.16.1.1-172.16.1.200, 172.16.1.1-172.16.3.33.
       The mask form uses the second IP address to specify a bit mask.
       One bits in the mask correspond to bits in the address that may
       not vary.  A valid masked address range is: 10.0.0.1 mask
       255.255.0.255.  The slash form uses the integer to indicate the
       number of bits in the address, beginning from the most-significant,
       that may not vary.  A valid address range in this form is:
       192.168.2.0/24.

   <date>  A date is represented as an eight digit integer of the form
       YYYYMMDD where YYYY represents the year, MM represents the
       month of the year (01 through 12), and DD represents the day of
       the month (01 through 31).  For example, June 24, 1996 is
       represented as 19960624.

   <integer-range>  specifies an integer, minimum integer, maximum
       integer, or range of integer values.  It uses the following
       syntax:

       <integer> | min <integer> | max <integer> | <integer>-<integer>

       The following are valid <integer-range>'s: 5, 67-100, min 50,
       max 60.

   <phone-number>  is a phone or fax number.  A phone number may
       contain digits, spaces " ", plus "+", minus "-", and the letter
       "x" to indicate extension numbers.  The following are valid
       <phone-number>s: +31 20 123-4676, +44 123 987654 x4711.

   <email-address>  is as described in RFC-822 [rfc822].

   <dns-name>  is as described in RFC-1034 [rfc1034].

   <free-form>  is a sequence of ASCII characters.



Condell, Lynn, Zao                                              [Page 9]


Internet Draft   Security Policy Specification Language     October 1998

   <X-name>  is a name of an object of type X.  That is <mntner-name>
       is a name of a mntner object.

   <oid>  is an object identifier of type <object-name>.

   <or-address>  is an X.400 address of type <free-form>.  See Appendix
       in [PKIXP1] for further definition of the syntax.

   <relative-distinguished-name>  represents an X.500 distinguished
       name of type <free-form>.  See Appendix in [PKIXP1] for further
       definition of the syntax.

   <edi-party-name>  EDI Party Name of type <free-form>.  See Appendix
       in [PKIXP1] for further definition of the syntax.

   <uri>  Uniform Resource Identifier of type <free-form>.

   <general-name>  is of the form <name-type> <name>.  <name-type>
       describes the type of name used in <name>.  <name> is a string
       that identifies a name.  Its format depends upon the
       <name-type>.  The following name types and their corresponding
       <name> formats have been defined as follows (based on CRL
       Distribution Points extension in [PKIXP1]):


   <name-type>  description of type          <name> format

   other        Other Name                   <oid> <freeform>
   n822         RFC 822 Name                 <email-address>
   dns          DNS Name                     <dns-name>
   x400         X400 Address                 <or-address>
   dirname      Directory Name               list of
                                           <relative-distinguished-name>
   ediname      EDI Party Name               <edi-party-name>
   uri          Uniform Resource Identifier  <uri>
   ipaddr       IP Address                   <ip-address>
   regid        Registered ID                <oid>


3.  Management Agent Classes

The classes mntner and cert and the attributes mnt-by and changed in
all classes contain information about the management agents of the
policy specification.  Among them, the mntner class specifies what
entities can create, delete, and replace other objects.  These classes
do not specify security policies.

3.1  mntner Class

The mntner class defines entities that can create, delete, and replace
SPSL objects.  A provider, before he/she can create SPSL objects,
first needs to create a mntner object.  The attributes of the mntner
class are shown in Figure 1.


Condell, Lynn, Zao                                             [Page 10]


Internet Draft   Security Policy Specification Language     October 1998

   Attribute      Value                              Type (Sect. 1.2.2)

   mntner:        <object-name>                           man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   auth:          <scheme-id> <auth-info>                 man, m-v
   address:       <free-form>                             man, m-v
   phone:         <phone-number>                          man, m-v
   fax-no:        <phone-number>                          opt, m-v
   email:         <email-address>                         man, m-v
   mnt-by:        list of <mntner-name>                   man, m-v
   certs:         list of <cert-name>                     man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description below                   man, m-v

                        Figure 1:  mntner Class Attributes

The mntner attribute is mandatory and is the class key attribute.  Its
value is an SPSL name.  The auth attribute specifies the scheme that
will be used to identify and authenticate update requests from this
maintainer.  It has the following syntax:

      auth: <scheme-id> <auth-info>

      E.g.,
           auth: crypt-pw dhjsdfhruewf

The <scheme-id>'s currently defined are: "cert", "pgpg", and
"crypt-pw".  The <auth-info> is additional information required by a
particular scheme: in the case of "crypt-pw", it is a password in UNIX
crypt format; and in the case of "pgp", it is a PGP public key; in the
case of "cert", it is a list of <cert-name> to match the public key
certificates in the cert attribute.  If multiple auth attributes are
specified, an update request satisfying any one of them is
authenticated to be from the maintainer.

The char-set attribute identifies the name of the character set used
for the value of the notes attribute in this object.  The char-set
does not apply to the attribute names; the default char-set is always
used for them.  If this attribute is not included, then the default
char-set is used.

The address, phone, fax-no, and email attributes provide contact
information for the maintainer.

The notes attribute contains a free-form textual description of the
object and other notes about the object.  The mnt-by attribute is a
list of mntner object names.  The authorization for replacement or
deletion of this object is governed by any of the maintainer objects
referenced.  The changed attribute documents who last changed this
object, and when the change was made.  The attribute is multi-valued
so that a history of who made changes and when MAY be kept.  Only the
most recent change MUST be kept.  If multiple changed attributes are


Condell, Lynn, Zao                                             [Page 11]


Internet Draft   Security Policy Specification Language     October 1998

saved, then they MUST be ordered from most to least recent.  The
<mntner> identifies who made the change.  <date> is the date of the
change.

The certs attribute lists certificate objects that point to the public
key certificates for this mntner.

The signature attribute contains a signature of the object.
Signatures are computed over all the attributes in the object, except
any signature attributes.  There MUST be at least one signature line
for each <mntner-name> in mnt-by.  The attribute has the following
syntax:

      signature: <mntner-name> <cert-name> <signature-alg> <signature-data>

      E.g.,
           signature: XYZ-IR-MNT XYZ-X509-CERT rsa <signature-data>

The <mntner-name> and <cert-name> identify which mntner signed this
object and which certificate was used.  <signature-alg> is the
algorithm used to create the signature.  Currently the following
signature algorithms are defined: "rsa-pkcs1", "dsa-sha1".
<signature-data> is the signature that was generated.

Figure 2 shows an example mntner object.  In the example, "cert"
authentication is used.

      mntner:      XYZ-IR-MNT
      notes:       XYZ-IR Maintainer
      auth:        cert XYZ-IR-X509-CERT
      address:     XYZ Corp
      address:     1 XYZ Place
      address:     Anytown, AS 12345
      address:     USA
      phone:       +1 617 5551234
      email:       jdoe@ir.xyz.com
      mnt-by:      XYZ-IR-MNT
      certs:       XYZ-IR-X509-CERT
      changed:     XYZ-IR-MNT 19970820
      signature:   XYZ-IR-MNT XYZ-IR-X509-CERT dsa-sha1 <signature>

                    Figure 2:  An example mntner object.

The char-set, notes, mnt-by, changed, and signature attributes are
attributes of all SPSL classes.  Their syntax, semantics, and type
(mandatory, optional, multi-valued, or single-valued) are the same for
for all SPSL classes.  They are not discussed or shown in examples in
the remaining sections.







Condell, Lynn, Zao                                             [Page 12]


Internet Draft   Security Policy Specification Language     October 1998

3.2  cert Class

The cert class identifies a public key certificate that may be used to
sign SPSL objects.  A cert object either specifies a certificate or
the location of a certificate.  The cert attribute identifies the name
of the object.

   Attribute      Value                              Type (Sect. 1.2.2)

   cert:          <object-name>                           man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   certificate:   see description below                   opt, s-v
   certlocation:  see description below                   opt, m-v
   crllocation:   see description below                   opt, s-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

                        Figure 3:  cert class attributes

The certificate attribute has the following syntax:

       certificate:  <cert-type> <cert-data>

<cert-type> describes the type of certificate represented.  Currently
the following types are defined: "pkcs7", "pgp", "dnskey", "x509_sig",
"x509_ke", "kerberos", "spki".  <cert-data> is the actual certificate
described by this object encoded in a hexadecimal representation of
the certificate.

        certificate type        description

        pkcs7                   PKCS #7 wrapped X.509 certificate
        pgp                     PGP certificate
        dnskey                  DNS signed key
        x509_sig                X.509 certificate - signature
        x509_ke                 X.509 certificate - key exchange
        kerberos                Kerberos tokens
        spki                    SPKI certificate

The certlocation attribute has the following syntax:

       certlocation: <cert-type> <fetch-protocol>
                     <general-name> | rdn <relative-distinguished-name>

<cert-type> is as defined above.  <fetch-protocol> specifies the
preferred protocol should be used to fetch the certificate from this
location.  Currently the following protocols have been defined: "cdp",
"dns".  The location of the certificate is identified either by using
a <general-name> or a <relative-distinguished-name>.




Condell, Lynn, Zao                                             [Page 13]


Internet Draft   Security Policy Specification Language     October 1998

The crllocation attribute indicates where a certificate revocation
list (CRL) may be found for this certificate.  It has the following
syntax:

       crllocation: <crl-type> <fetch-protocol>
                 <general-name> | rdn <relative-distinguished-name>

This is similar to the certlocation attribute, except that <crl-type>
is used in place of <cert-type>.  This describes the type of CRL that
may be found at this location.  Currently the following CRL type has
been defined: "x509".

At least one certificate or certlocation attribute MUST be present in
a cert object.  It is possible for a certificate and a certlocation
attribute, or multiple certlocation attributes to be present in a
single cert object, but they SHOULD all refer to the same certificate,
otherwise the wrong certificate may be used.


4.  Network Entity Classes

4.1  node Class

The node class identifies a set of interfaces on a network entity that
may have policies associated with them.  This definition allows a
network entity to be represented by one or more node objects.  It also
allows policies to be associated with specific interfaces or addresses
of a network entity.

   Attribute      Value                              Type (Sect. 1.2.2)

   node:          <node-name>                             man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   name:          <dns-name>                              man, s-v
   alias:         <dns-name>                              opt, m-v
   ifaddr:        <ip-address>                            man, m-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

                        Figure 4:  node class attributes

The node attribute is the class key, which uniquely identifies the
node object.

The name attribute is a valid DNS name identifying the network entity
to which the interfaces in the object are attached.  Each alias
attribute, if present, should be a canonical DNS name of the network
entity.  The ifaddr attribute specifies the IP address of each
interface of the node.




Condell, Lynn, Zao                                             [Page 14]


Internet Draft   Security Policy Specification Language     October 1998

Following are two examples of node objects.

      node:    SQUATCH
      name:    squatch.foo.com
      ifaddr:  172.16.3.11
      ifaddr:  192.2.1.83

      node:    SG-FOO-FIREWALL:COTTON
      name:    cotton.foo.com
      ifaddr:  172.16.5.196

          Figure 5:  node object examples


4.2  node-set Class

The node-set class provides a means to group several nodes into one
object.  The class may be used to group together the interfaces of a
single host or of multiple hosts.  The nodes in an node-set object are
expected to contain the interfaces on a common set of network
entities.

The node-set class is defined below:

   Attribute      Value                              Type (Sect. 1.2.2)

   node-set:      <node-set-name>                         man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   members:       list of <node-names>
                | list of <node-set-names>                man, m-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

             Figure 6:  node-set class attributes

The node-set attribute is the class key, which uniquely identifies the
node-set object.  The members attribute is a list of the node objects
and node-set objects belonging to the node-set object.


4.3  gateway Class

The gateway class identifies a set of interfaces on a policy
enforcement agent, e.g., a security gateway, that can enforce the
security policies associated with the enforcement agent or the domain
for which it enforces policy.







Condell, Lynn, Zao                                             [Page 15]


Internet Draft   Security Policy Specification Language     October 1998

   Attribute      Value                              Type (Sect. 1.2.2)

   gateway:       <gateway-name>                          man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   name:          <dns-name>                              man, s-v
   alias:         <dns-name>                              opt, m-v
   ifaddr:        <ip-address>                            man, m-v
   preference:    <integer>                               man, s-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

                  Figure 7:  gateway class attributes

The gateway attribute is the class key, which uniquely identifies the
gateway object.

The name attribute is a valid canonical DNS name identifying the
network entity on which the policy enforcement agent is implemented.
Each alias attribute, if present, should be a canonical DNS name of
the network entity.  The ifaddr attribute specifies the IP address of
an interface.

The preference attribute gives a hint as to the preference of routing
to use this gateway.  1 is the highest preference and the preference
decreases as the integer increases.  This is only used for purposes of
the domain object and is explained further in section 4.6.

Following are two examples of gateway objects.

      gateway:    SG-FOO-FIREWALL
      name:       foo-firewall.foo.com
      ifaddr:     172.16.0.1
      ifaddr:     192.2.1.83
      preference: 1

      gateway:    SG-FOO-FIREWALL:SG-IS-FIREWALL
      name:       is-firewall.foo.com
      ifaddr:     172.16.5.196
      preference: 3

                  Figure 8:  gateway object examples


4.4  gateway-set Class

The gateway-set class provides a means to group gateways.  It can be
used to group together the interfaces of a single gateway or the
interfaces of multiple gateways spread across several gateway objects,
so that they may be referred to as a single object.




Condell, Lynn, Zao                                             [Page 16]


Internet Draft   Security Policy Specification Language     October 1998

The gateway-set class is defined below:

   Attribute      Value                              Type (Sect. 1.2.2)

   gateway-set:   <gateway-set-name>                      man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   members:       list of <gateway-names>
                | list of <gateway-set-names>             man, s-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

             Figure 9:  gateway-set class attributes

The gateway-set attribute is the class key, which uniquely identifies
the gateway-set object.  The members attribute is a list of gateway
objects and/or gateway-set objects belonging to the object.


4.5  polserv Class

The polserv class defines the policy servers that are capable of
managing security policies.

   Attribute      Value                              Type (Sect. 1.2.2)

   polserv:       <policy-server-name>                    man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   name:          <dns-name>                              man, s-v
   alias:         <dns-name>                              opt, m-v
   ifaddr:        <ip-address>                            man, m-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

           Figure 10:  polserv class attributes

The polserv attribute is the class key, which uniquely identifies the
policy server object.

The name attribute is a valid DNS name identifying the network entity
on which the policy enforcement agent is implemented.  Each alias
attribute, if present, should be a canonical DNS name of the network
entity.

Following is a simple example of a policy server object.

      polserv: PS-SECURITY
      name:    foo-pol-server.foo.com
      ifaddr:  172.16.0.2

        Figure 11:  polserv object example

Condell, Lynn, Zao                                             [Page 17]


Internet Draft   Security Policy Specification Language     October 1998

4.6  domain Class

The domain class provides a means to define a security domain, which
is a cluster of network entities protected by a common set of security
policies enforced by the policy enforcement agents located at the
perimeter of the domain.

A security domain is the basic topological structure for a domain
based security model [Section 1.1.2].  It consists of three
components:

   1. Coverage - a security domain must be authorized to include a
      specific set of network entities.  That specification is provided
      in the coverage attribute, and can take the form of a list of IP
      addresses, a list of IP address ranges, a list of nodes, and/or
      a list of node-sets.

   2. Policy Enforcement Agents - the network entities included in a
      security domain are protected by a set of policy enforcement
      agents located at the perimeter of the domain.  The policy
      enforcement agents are specified by the gateways attribute,
      which may contain a list of gateways or gateway sets.  The
      gateways in the list MAY be ordered using the gateways'
      preference attribute.

   3. Policy Servers - one or more policy servers are attached to
      the security domain to manage the security policies of the
      domain.  These servers are given in a list under the polserv
      attribute.  The first member of the list MUST be the primary
      server, and the rest are the back-up servers.

With these three components, the domain class is defined below.
Again, individual domain objects are uniquely identified by the domain
attribute, which is the class key.

   Attribute      Value                              Type (Sect. 1.2.2)

   domain:        <domain-name>                           man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   coverage:      list of <ip-address >
                | list of <address-range>
                | list of <node-name>
                | list of <node-set-name>                 man, m-v
   gateways:      list of <gateway-name>
                | list of <gateway-set-name>              man, s-v
   polservs:      list of <policy-server-names>           man, s-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

             Figure 12:  domain class attributes



Condell, Lynn, Zao                                             [Page 18]


Internet Draft   Security Policy Specification Language     October 1998

5.  Policy Class

A policy class object specifies a binding between a set of
communication conditions and a set of security actions.

In the current version of SPSL, two policy classes are defined.  The
general one described in this section is meant to be used for
specifying packet filtering rules.  The one described in Section 5.3
is to be used for specifying IPSec/ISAKMP policies.  Moreover, objects
of the general policy class may take one of two possible formats.  The
short format expresses the policy in a single policy attribute and the
long format expresses each part of a policy in a distinct attribute.
Each of the two formats is appropriate for different applications.
They will be discussed in the next two sections, along with comments on
their strengths and weaknesses.

Both formats of the policy class share four attributes.  Figure 13
shows the class definition (in short format) in order to display the
common attributes.  Among them, policy-name gives the name of the
policy.  The cache-expiry attribute indicates, in seconds, the maximum
time that this policy should be cached.  It can be regarded as a hint
to the entities that may cache this policy.  If the attribute is
absent or has a value of zero then no expiration time is suggested.

The association attribute specifies the names of one or more nodes,
gateways, or domains that own the policy.  If a node-based or
domain-based policy model is being used, strict rules of association
must be observed depending on the model.  In the node-based model, a
policy can be associated with an object from the node, node-set,
gateway, or gateway-set classes but never with a domain object.  In
the domain-based model, a policy can be associated with an object from
the node, node-set, or domain classes but not with a gateway or
gateway-set object.  This is because the policy associated with a
gateway or gateway-set object will be enforced by that particular
object instead of by all of the enforcement agents of a specific
domain.  However, a node or node-set object is allowed its own
policies in a domain-based association because the object may be
regarded as a single/multiple node domain.

5.1  policy Attribute (Short Format)

The short format of the policy class specifies the policy in a
single policy attribute that is structured as follows:












Condell, Lynn, Zao                                             [Page 19]


Internet Draft   Security Policy Specification Language     October 1998

   Attribute      Value                              Type (Sect. 1.2.2)

   policy-name:   <object-name>                           man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   association:   <node-name> | <node-set-name>
                | <gateway-name> | <gateway-set-name>
                | <domain-name>                           man, s-v
   cache-expiry:  <integer>                               opt, s-v
   policy:        as described below                      opt, m-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

               Figure 13:  policy class attributes, short format

   policy: dst * | any | list of [not] <ip-address>
                 | list of [not] <address-range>
                [port * | opaque | any | list of [not] <port>
                        | list of [not] <port-range>
                     [dynamic [<port-range>]]]
           [src * | any | list of [not] <ip-address>
                  | list of [not] <address-range>
                [port * | opaque | any | list of [not] <port>
                        | list of [not] <port-range>
                     [dynamic [<port-range>]]]]
           [xport-proto * | opaque | any | list of [not] <proto>
                          | list of [not] <proto-range>]
           [direction inbound | outbound [, symmetric]]
           permit [, forward <dest>] | deny [, forward <dest>]
                | forward <dest>

The dst attribute specifies a list of <ip-address>s or
<address-range>s to which this policy does (or does not) apply.  The
address may be specified as "any" or "*" to indicate this applies to
traffic destined to all addresses.  Otherwise, the address is a list
of individual IP addresses, or address ranges specified by a minimum
and maximum address (inclusive), or address ranges specified using
an address and mask.

An address may be preceded by the qualifier "not" to indicate that the
address from a packet must not be the one specified.  Note that it not
useful to include some list members with the "not" qualifier and some
without it.  For a distinct X and Y, an expression "X or not Y" is
equivalent to just "not Y".  An expression "X and not Y" is equivalent
to just "X".  Note the special case where a list contained the same
address both with and without "not" -- those two list members are
equivalent to "any".  Consequently, when a list contains no "not"
qualifiers, the interpretation is "X or Y or Z", while if each list
member has a "not" qualifier, the list is interpreted as "not X and
not Y and not Z".




Condell, Lynn, Zao                                             [Page 20]


Internet Draft   Security Policy Specification Language     October 1998

Attribute dst may optionally be followed by "port" and a destination
port number or list of destination port numbers to which this policy
does (or does not) apply.  Additionally, port may be followed by the
tag "dynamic" and an optional range of port numbers.  This specifies
that a connection established by using one of the port numbers
following the port tag, may then use dynamic ports for the rest of the
communications using that connection.  If a range of port numbers
follows the dynamic tag, then dynamic ports are only allowed within
that specified range.  If the range is not specified, the port range
defaults to "*".  If the dynamic tag is not used, then dynamic ports
are excluded from this policy.

A source address and port(s) may optionally be specified in a similar
manner using the src tag.  The source address and source and
destination ports default to "*" if they are not specified.

The transport protocol may be specified using the optional tag
"xport-proto", which defaults to "*" if not specified.  The xport-proto
may be specified as a single transport protocol number, a list of
protocol numbers, or a range of protocol numbers in the form
<number>-<number>.  It may also be specified as "*", "any", or
"opaque".  Note that when a port is specified as described in the
previous two paragraphs, then the protocol associated with those ports
must be specified using the xport-proto phrase.

The direction specification is used to specify whether a packet is
entering the domain associated with the policy (inbound) or exiting it
(outbound).  If the optional qualifier "symmetric" is present, a
second policy will automatically be created with the direction
sensitive fields -- src and dst, and src port and dst port --
switched.

The transfer action of permit or deny must be specified to indicate
whather packets that match this policy should be passed or dropped,
respectively.  The transfer action may additionally specify that
the matching packets be forwarded to a specified destination, e.g.,
a policy server.  The destination may be specified by either a DNS
name, preceeded by "dns", or by an IP address.

      policy-name: foo
      association: sg-bar
      policy:      dst 172.16.0.0-172.16.255.255
                   src 192.168.100.0-192.168.100.255
                   xport-proto 6 permit
      policy:      dst 172.16.0.0-172.16.255.255 deny

               Figure 14:  policy object example, short format


In this example, this policy denies all packets destined to IP
addresses from 172.16.0.0 to 172.16.255.255, unless they are from
addresses 192.168.100.0 to 192.168.100.255 and use TCP.  Note that the
ordering of the policy attributes is important (see section 5.5).


Condell, Lynn, Zao                                             [Page 21]


Internet Draft   Security Policy Specification Language     October 1998

5.2  policy Attribute (Long Format)

The long format policy class makes each part of the policy attribute an
explicit attribute.

   Attribute      Value                              Type (Sect. 1.2.2)

   policy-name:   <object-name>                           man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   association:   <node-name> | <node-set-name>
                | <gateway-name> | <gateway-set-name>
                | <domain-name>                           man, s-v
   cache-expiry:  <integer>                               opt, s-v
   dst:           see below                               opt, m-v
   src:           see below                               opt, m-v
   xport-proto:   see below                               opt, m-v
   direction:     inbound | outbound [, symmetric]        opt, s-v
   userid:        * | any | list of [not] n822 <email-addr>
                | list of [not] dn <distinguished-name>   opt, m-v
   systemname:    * | any | list of [not] <general-name>
                | list of [not] dn <distinguished-name>   opt, m-v
   ipv6-class:    * | any | list of [not] <integer-range> opt, m-v
   ipv6-flow:     * | any | list of [not] <integer-range> opt, m-v
   ipv4-tos:      * | any | list of [not] <integer-range> opt, m-v
   seclabel:      * | any | list of [not] <seclabel>      opt, m-v
      see Section 5.4 for additional selectors            opt, m-v
   tfr-action:    see below                               opt, m-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

               Figure 15:  policy class attributes, long format

   The attributes are specified as follows:

   dst: * | any | list of [not] <ip-address>
          | list of [not] <address-range>
        [port * | opaque | any | list of [not] <port>
                | list of [not] <port-range> [dynamic [<port-range>]]]

   src: * | any | list of [not] <ip-address>
          | list of [not] <address-range>
        [port * | opaque | any | list of [not] <port>
                | list of [not] <port-range> [dynamic [<port-range>]]]

   xport-proto: * | opaque | any | list of [not] <proto>
                  | list of [not] <proto-range>

   tfr-action: permit [, forward <dest>] | deny [, forward <dest>]
                | forward <dest>




Condell, Lynn, Zao                                             [Page 22]


Internet Draft   Security Policy Specification Language     October 1998

Attributes dst, src, xport-proto, direction, and tfr-action (transfer
action) are similar to their counterparts in the short format of the
policy class.  Note that the interpretation of a single selector
attribute with a list value is different than having each list member
be a separate instance of the selector attribute.  A packet must match
each selector attribute in order for the policy to be applicable.
Thus one would usually only have a single instance of each selector
attribute in a policy specification.

The direction MUST be specified either in the policy attribute or the
direction attribute.  The tfr-action attribute specifies an action
that MUST be taken, as specified above.

The user-id attribute specifies either an email address or a
distinguished name to identify a particular user.  The systemname
attribute uses a DNS name, an X.500 general name, or an X.500
distinguished name to identify a particular system.

The seclabel attribute is used to identify an implementation specific
security label.  This should correspond to the implementation of the
security level selector in IPSec.  This attribute is a good example of
the difference between "*" and "any".  When "any" is used, the packet
must contain the field which contains the selector value.  When "*" is
used, the packet does not have to have that field.  Thus "any" means
that the packet must specify a security label, but its value is not of
interest.  A "*" would mean that a packet need not contain any
security label.  The value "opaque" is used to match packets for which
a selector field cannot be found, typically due to compression,
fragmentation, or confidentiality.

Attributes ipv6-flow and ipv6-class specify a list of integers or
integer ranges, optionally preceeded by "not", corresponding to the
IPv6 flow label and transport class fields in the IPv6 header.
ipv4-tos is a list of integers or integer ranges, optionally preceeded
by "not", corresponding to the IPv4 type of service field in an IPv4
header.  These attributes default to "*" if they are not included.
The tfr-action and dst attributes are mandatory, if the policy class
is used in this format.

In order to represent the policies described in the above example
(Figure 14), two policy objects must be created.  Note that the
ordering of the policy objects is important (see section 5.5).













Condell, Lynn, Zao                                             [Page 23]


Internet Draft   Security Policy Specification Language     October 1998

      policy-name:    baz
      association:    sg-bar
      dst:            172.16.0.0-172.16.255.255
      src:            192.168.100.0-192.168.100.255
      xport-proto:    6
      tfr-action:     accept

      policy-name:    foo
      association:    sg-bar
      dst:            172.16.0.0-172.16.255.255
      tfr-action:     deny

            Figure 16:  policy object example, long format


Generally, policy objects will use one of the two formats, but it is
possible to combine the features of both.  The combined policy class
looks as follows:

   Attribute      Value                              Type (Sect. 1.2.2)

   policy-name:   <object-name>                           man, s-v, key
   char-set:      <char-set>                              opt, s-v
   notes:         <free-form>                             opt, m-v
   association:   <node-name> | <node-set-name>
                | <gateway-name> | <gateway-set-name>
                | <domain-name>                           man, s-v
   cache-expiry:  <integer>                               opt, s-v
   policy:        as described above                      opt, m-v
   dst:           as described above                      opt, m-v
   src:           as described above                      opt, m-v
   xport-proto:   as described above                      opt, m-v
   direction:     inbound | outbound [',' symmetric]      opt, s-v
   userid:        * | any | list of [not] n822 <email-addr>
                | list of [not] dn <distinguished-name>   opt, m-v
   systemname:    * | any | list of [not] <general-name>
                | list of [not] dn <distinguished-name>   opt, m-v
   ipv6-class:    * | any | list of [not] <integer-range> opt, m-v
   ipv6-flow:     * | any | list of [not] <integer-range> opt, m-v
   ipv4-tos:      * | any | list of [not] <integer-range> opt, m-v
   seclabel:      * | any | list of [not] <seclabel>      opt, m-v
      see Section 5.4 for additional selectors            opt, m-v
   tfr-action:    as described above                      opt, m-v
   mnt-by:        list of <mntner-name>                   man, m-v
   changed:       <mntner-name> <date>                    man, m-v
   signature:     see description in Section 3.1          man, m-v

        Figure 17:  policy class attributes, combined format

If the policy attribute is specified and any of the other attributes
are also specified, those others apply to all the policy lines in this
object.  This holds true for sub-classes of the policy class, too.  If
a policy object has a conflict between a part of the policy attribute
and one of the other attributes specified, it is an invalid object.

Condell, Lynn, Zao                                             [Page 24]


Internet Draft   Security Policy Specification Language     October 1998

Figure 18 illustrates the combination of the two formats.  The first
policy object uses the combined format of the policy class.  It has
two policy attributes and an xport-proto attribute.  The xport-proto
attribute is applied as part of the policy described by each of the
policy lines.  This is equivalent to explicitly listing the
xport-proto attribute in each policy line, as shown in the second
policy object.

      policy-name:    tcp-foo
      association:    sg-bar
      policy:         dst 172.16.0.0-172.16.255.255
                      src 192.168.100.0-192.168.100.255 accept
      policy:         dst 172.16.0.0-172.16.255.255 deny
      xport-proto:    6

      This is equivalent to:

      policy-name:    tcp-foo
      association:    sg-bar
      policy:         dst 172.16.0.0-172.16.255.255
                      src 192.168.100.0-192.168.100.255
                      xport-proto 6 accept
      policy:         dst 172.16.0.0-172.16.255.255 xport-proto 6 deny

        Figure 18:  policy object example, combined format

   While both formats allow the same policies to be specified, they
each have their advantages and disadvantages.  The short format allows
uncomplicated policies, such as general default policies, to be
specified in a compact format since it allows multiple policies to be
defined in a single object.  The short format, however, is not very
good for specifying complex policies.  The long format allows them to
be specified in a more straightforward manner.  Also, the ability to
combine both formats of the policy class, allows greater flexibility
in how policies may be defined.  Correct specification of policies is
made easier by being able to specify those policies in a
straightforward manner.


5.3  ipsec-policy Class

The ipsec-policy class is a sub-class of the policy class.  It is
used to state IPSec policies specifying whether or not AH or ESP
are required for a particular communication, and the choice of
security mechanisms to be used with IPSec protocols.  It also
specifies the security mechanisms that may be negotiated by ISAKMP
using the IPSec DOI [DOI].  Since it is a sub-class of the general policy
class, it inherits attributes from the policy class.  The inherited
attributes are marked with an "*" in Figure 19 below.






Condell, Lynn, Zao                                             [Page 25]


Internet Draft   Security Policy Specification Language     October 1998

   Attribute      Value                              Type (Sect. 1.2.2)

   *policy-name:  <object-name>                           man, s-v, key
   *char-set:     <char-set>                              opt, s-v
   *notes:        <free-form>                             opt, m-v
   *association:  <node-name> | <node-set-name>
                | <gateway-name> | <gateway-set-name>
                | <domain-name>                           man, s-v
   *cache-expiry: <integer>                               opt, s-v
   *policy:       as described above                      opt, m-v
   *dst:          as described above                      opt, m-v
   *src:          as described above                      opt, m-v
   *xport-proto:  as described above                      opt, m-v
   *direction:    inbound | outbound [',' symmetric]      opt, s-v
   *userid:       * | any | list of [not] n822 <email-addr>
                | list of [not] dn <distinguished-name>   opt, m-v
   *systemname:   * | any | list of [not] <general-name>
                | list of [not] dn <distinguished-name>   opt, m-v
   *ipv6-class:   * | any | list of [not] <integer-range> opt, m-v
   *ipv6-flow:    * | any | list of [not] <integer-range> opt, m-v
   *ipv4-tos:     * | any | list of [not] <integer-range> opt, m-v
   *seclabel:     * | any | list of [not] <seclabel>      opt, m-v
   *  see Section 5.4 for additional selectors            opt, m-v
   *tfr-action:   as described above                      opt, m-v
   ipsec-action:  see below                               opt, m-v
   isakmp-action: see below                               opt, m-v
   *mnt-by:       list of <mntner-name>                   man, m-v
   *changed:      <mntner-name> <date>                    man, m-v
   *signature:    see description in Section 3.1          man, m-v

        Figure 19:  ipsec-policy class attributes

   isakmp-action: ikemode <ikemode> pfs <usepfs>
                  cipher <isakmpcipheralg> hash <hashalg>
                  [keylen <integer-range>] [group <integer-range>]
                  expiry ( seconds | kilobytes ) <integer-range>

   where <ikemode> is one of: "aggressive", "main", "quick"

         <usepfs> is either "false" or "true"

         <isakmpcipheralg> is "any", or one or more of: "blowfish",
                  "cast", "des", "des3", "idea", "rc5", optionally
                  preceded by "not"

         <hashalg> is "any", or one or more of: "md5", "sha1", "tiger",
                  optionally preceded by "not"








Condell, Lynn, Zao                                             [Page 26]


Internet Draft   Security Policy Specification Language     October 1998

   ipsec-action:  [ esp cipher <ipseccipheralg> [keylen <integer-range>]
                    [rounds <integer-range>]
                    [integrity <integrityalg>] [group <integer-range>]
                    [expiry ( seconds | kilobytes ) <integer-range>]
                    [tunnel | transport]
                    [from <location> [, <location>]]
                    [to <location> [, <location>]]
                  ]
                  [ ah integrity <integrityalg> [group <integer-range>]
                    [expiry ( seconds | kilobytes ) <integer-range>]
                    [tunnel | transport]
                    [from <location> [, <location>]]
                    [to <location> [, <location>]]
                  ]
                  [ ipcomp <ipcompalg>
                    [expiry ( seconds | kilobytes ) <integer-range>]
                    [from <location> [, <location>]]
                    [to <location> [, <location>]]
                  ]

   where <ipseccipheralg> is "any", or one or more of: "blowfish",
                  "cast", "des", "des3", "idea", "idea3", "none", "rc4",
                  "rc5", "rfc1829-iv32", "rfc1829-iv64", optionally
                  preceded by "not"

         <integrityalg> is "any", or one or more of: "hmacdes",
                  "hmacmd5", "hmacripem", "hmacsha1", "keyedmd5",
                  optionally preceded by "not"

         <ipcompalg> is "any", or one or more of: "deflate", "lzs",
                  "oui", "v42bis", optionally preceded by "not"

         <location> is "any", or one or more of: "dest", "host",
                  "local-sg", "remote-sg", <ip-address>,
                  "dns" <dns-name>

Two action attributes, ipsec-action and isakmp-action, are added to
the ipsec-policy class.

The ipsec-action attribute consists of the following parts:
ipsec-proposal, ipsec-type (optional), and location (optional).

The ipsec-proposal part describes DOI conforming IPSec proposals for
the ISAKMP exchange.  It allows any combination of ESP, AH, and IP
compression proposals to be specified.  Note that ipsec-type is only
applicable to AH and ESP, not to IP compression.  A single
ipsec-proposal specifies a suite of the protocols.  The order of the
protocols within a proposal is significant.  If multiple proposals are
included, they should be taken as logical ORs.

If ESP is specified, the cipher algorithm to use must be specified.
Optionally, the key length, rounds, integrity algorithm, group and
expiry may be specified.  If AH is specified, the integrity algorithm
must be specified.  Optionally, group and expiry information may be

Condell, Lynn, Zao                                             [Page 27]


Internet Draft   Security Policy Specification Language     October 1998

specified.  If IP Compression is specified, the IP compression
algorithm must be specified and the expiry may optionally be
specified.  For AH and ESP, a group attribute with value 1 should only
be present if the pfs attribute has been specified in the
isakmp-action.

The ipsec-type part specifies which mode (tunnel or transport) the
IPSec protocols must use.  If no mode is specified then either mode
may be used for that protocol.

The location part specifies the possible enforcement agents for
ipsec-action.  It may take a generic specification such as "any",
"dest", "host", "local-sg", or "remote-sg".  In those cases, a network
node or an policy enforcement agent that is associated with the policy
and matches the specification can be chosen.  The location
specification can also designate a network node by giving an explicit
IP address or a DNS name.  In that case, the designated node must be
used to enforce the action.  If the location specification is absent
then the management system may choose any enforcement agent bound to
the policy by the association attribute.

Similarly, the isakmp-action attribute consists of three parts:
isakmp-mode, pfs, and isakmp-proposal.  The isakmp-mode part specifies
whether ISAKMP should use its main, aggressive, or quick mode.
The pfs part specifies if perfect forward secrecy should be used.  The
isakmp-proposal part describes an ISAKMP proposal, which includes
cipher algorithm, hash algorithm, and expiry for the ISAKMP
negotiations.  It may describe the group and keylength for the
negotiations.  If the group is not specified, it defaults to 1.  The
keylen attribute should only be used with the cipher algorithms that
permit different key lengths, e.g.: "cast", "rc5", and "blowfish".  If
multiple isakmp-action attributes are included, they should be taken
as logical ORs.


5.4  Selectors and Actions

Note that SPSL policies all contain two types of attributes: selectors
and actions.  Selectors are the policy attributes that are used to
match packets with a particular policy.  Currently, all the selectors
that are defined are contained in the base policy class, though
sub-classes may also contain additional selectors.  The selectors
currently defined in the IPSec DOI are:

        src               dst
        src-port          dst-port
        xport-proto       userid
        systemname        ipv6-class
        ipv6-flow         ipv4-tos
        seclabel          direction





Condell, Lynn, Zao                                             [Page 28]


Internet Draft   Security Policy Specification Language     October 1998

   An extended list of selectors supported by SPSL includes:

        ah-hdr            ipcomp-hdr          rhv1-dst
        ah-nhdr           ipcomp-nhdr         rhv1-nhop
        direction         iphdr               rhv1-phop
        dop-hdr           ipv4-dst            seclabel
        dop-nhdr          ipv4-frgm           src
        dst               ipv4-frgo           src-port
        dst-port          ipv4-hdr            systemname
        esp-hdr           ipv4-hlen           tcp-ack
        esp-nhdr          ipv4-id             tcp-dato
        frag-hdr          ipv4-opt-lsrr-dst   tcp-dst-port
        frag-nhdr         ipv4-opt-ssrr-dst   tcp-fin
        hop-hdr           ipv4-prot           tcp-hdr
        hop-nhdr          ipv4-src            tcp-psh
        icmp4-code        ipv4-tlen           tcp-rst
        icmp4-gwy         ipv4-tos            tcp-src-port
        icmp4-hdr         ipv4-ttl            tcp-syn
        icmp4-id          ipv6-class          tcp-urg
        icmp4-mtu         ipv6-dst            tcp-urgp
        icmp4-seq         ipv6-flow           udp-cks
        icmp4-type        ipv6-hdr            udp-dst-port
        icmp6-code        ipv6-nhdr           udp-hdr
        icmp6-hdr         ipv6-src            udp-id
        icmp6-id          ipver               udp-src-port
        icmp6-mtu         rh-hdr              userid
        icmp6-seq         rh-nhdr             xport-prot
        icmp6-type        rh-vers

Actions are the policy attributes that are applied to outbound packets
and are used to decide whether or not to accept inbound packets.  The
actions currently defined in SPSL are:

        tfr-action        ipsec-action        isakmp-action


5.5  Policy Order

Multiple policy objects and attributes are likely to apply to a
particular communication.  For example, most systems will have a
default policy to deny all inbound communications.  There will then be
some more policies to permit specific inbound communications.  A set
of selector values (see section 5.4) that match one of the specific
policies will also match the general default policy.  SPSL must
establish a rule so that the correct policy is applied to the
communication.  The rule must always provide the same answer when
applied to the same set of policies, otherwise inconsistent policy
enforcement may occur.







Condell, Lynn, Zao                                             [Page 29]


Internet Draft   Security Policy Specification Language     October 1998

SPSL uses a simple rule to determine which policy should be applied to
the on-going communication, i.e., physical ordering of the policies.
The policy applied should always be the first policy that matches all
the selectors of the communication.  This ordering holds for both the
ordering of the policy objects and the ordering of policy attributes
within policy objects, if the long format of the policy class is used.
The physical ordering is the ordering of the policies in a file of
SPSL policy objects.  This ordering must be maintained by the parser
and other applications that use the SPSL objects.


6.  Remaining Issues

The following issues are not resolved in this first draft of language
definition.  Solutions will be developed and included in the
subsequent revisions of the document.

   * Current specification of management agent classes were adopted
     from RPSL.  Some of these class definitions may be changed as we
     further develop the authentication and authorization scheme of
     SPSL.

   * We are considering adding support for DNS names as policy
     endpoints and for domain coverage in addition to IP addresses.

   * Associating particular gateways within a domain with particular
     policies is an issue that is being considered.

7.  Acknowledgements

The authors thank Luis Sanchez, David Mankins, Alden Jackson, and
Steve Kent for their help in reviewing early drafts of this document
and suggesting changes to the language.  We also thank Rajesh Krishnan
and Matt Fredette for their work on an SPSL parser and suggested
changes to make the language parseable.




















Condell, Lynn, Zao                                             [Page 30]


Internet Draft   Security Policy Specification Language     October 1998

Appendix A.  BNF Form of SPSL

   spsl-file -> spslobjlist | (empty)

   spslobjlist -> spslobjlist spslobj | spslobj

   spslobj -> "mntner:" objectname line-term mntner-attributes blankline
        | "cert:" objectname line-term cert-attributes blankline
        | "node:" objectname line-term node-attributes blankline
        | "node-set:" objectname line-term node-set-attributes blankline
        | "gateway:" objectname line-term gateway-attributes blankline
        | "gateway-set:" objectname line-term gateway-set-attributes
                blankline
        | "domain:" objectname line-term domain-attributes blankline
        | "polserv:" objectname line-term polserv-attributes blankline
        | "policy-name:" objectname line-term policy-attributes blankline
        | line-term

   # checking for mandatory attributes is necessary after parsing
   mntner-attributes -> mntner-attributes mntner-attribute
        | mntner-attribute
   cert-attributes -> cert-attributes cert-attribute | cert-attribute
   node-attributes -> node-attributes node-attribute | node-attribute
   node-set-attributes -> node-set-attributes node-set-attribute
        | node-set-attribute
   gateway-attributes -> gateway-attributes gateway-attribute
        | gateway-attribute
   gateway-set-attributes -> gateway-set-attributes gateway-set-attribute
        | gateway-set-attribute
   domain-attributes -> domain-attributes domain-attribute
        | domain-attribute
   polserv-attributes -> polserv-attributes polserv-attribute
        | polserv-attribute
   policy-attributes -> policy-attributes policy-attribute
        | policy-attribute

   mntner-attribute -> shared-attribute | "auth:" auth-info line-term
        | "address:" string line-term | "phone:" phonenum line-term
        | "fax-no:" phonenum line-term | "email:" emailaddr line-term
        | "certs:" objectnamelist line-term

   cert-attribute -> shared-attribute
        | "certificate:" certtype hexstring line-term
        | "certlocation:" certtype fetchproto locname line-term
        | "crllocation:" crltype fetchproto locname line-term

   node-attribute -> shared-attribute | "name:" dnsname line-term
        | "alias:" dnsname line-term | "ifaddr:" ipaddress line-term

   node-set-attribute -> shared-attribute
        | "members:" objectnamelist line-term




Condell, Lynn, Zao                                             [Page 31]


Internet Draft   Security Policy Specification Language     October 1998

   gateway-attribute -> shared-attribute | "name:" dnsname line-term
        | "alias:" dnsname line-term | "ifaddr:" ipaddress line-term
        | "preference:" integer line-term

   gateway-set-attribute -> shared-attribute
        | "members:" objectnamelist line-term

   domain-attribute -> shared-attribute
        | "coverage:" domaincover line-term
        | "gateways:" objectnamelist line-term
        | "polserv:" objectnamelist line-term

   polserv-attribute -> shared-attribute | "name:" dnsname line-term
        | "alias:" dnsname line-term | "ifaddr:" ipaddress line-term

   policy-attribute -> shared-attribute
        | "association:" objectnamelist line-term
        | "cache-expiry:" integer line-term | condition-attribute
        | action-attribute

   shared-attribute -> "char-set:" charset line-term
        | "notes:" string line-term | "mnt-by:" objectnamelist line-term
        | "changed:" objectname date line-term
        | "signature:" objectname objectname hash-alg signature-data
                line-term
        | comments blankline

   condition-attribute -> "policy:" "dst" addresslist ports-opt src-opt
                xport-opt dir-opt actiontype line-term
        | "dst:" addresslist ports-opt line-term
        | "src:" addresslist ports-opt line-term
        | "xport-proto:" integerlist line-term
        | "direction:" dirtype symetric-opt line-term
        | "userid:" user-namelist line-term
        | "systemname:" system-namelist line-term
        | "ipv6-class:" integerlist line-term
        | "ipv6-flow:" integerlist line-term
        | "ipv4-tos:" integerlist line-term
        | "seclabel:" seclabellist line-term
        | "ipver:" integerlist line-term
        | "ipv4-hlen:" integerlist line-term
        | "ipv4-tlen:" integerlist line-term
        | "ipv4-id:" integerlist line-term
        | "ipv4-frgm:" zeroone line-term
        | "ipv4-frgo:" integerlist line-term
        | "ipv4-ttl:" integerlist line-term
        | "ipv4-prot:" integerlist line-term
        | "ipv4-src:" ipv4list line-term
        | "ipv4-dst:" ipv4list line-term
        | "ipv4-opt-lsrr-dst:" ipv4list line-term
        | "ipv4-opt-ssrr-dst:" ipv4list line-term
        | "ipv6-dst:" ipv6list line-term
        | "ipv6-src:" ipv6list line-term
        | "ipv6-nhdr:" integerlist line-term

Condell, Lynn, Zao                                             [Page 32]


Internet Draft   Security Policy Specification Language     October 1998

        | "rh-nhdr:" integerlist line-term
        | "rh-vers:" integerlist line-term
        | "rhv1-dst:" ipv6list line-term
        | "rhv1-nhop:" ipv6list line-term
        | "rhv1-phop:" ipv6list line-term
        | "ah-nhdr:" integerlist line-term
        | "dop-nhdr:" integerlist line-term
        | "esp-nhdr:" integerlist line-term
        | "frag-nhdr:" integerlist line-term
        | "hop-nhdr:" integerlist line-term
        | "ipcomp-nhdr:" integerlist line-term
        | "tcp-ack:" zeroone line-term
        | "tcp-dato:" integerlist line-term
        | "tcp-dst-port:" integerlist line-term
        | "tcp-fin:" zeroone line-term
        | "tcp-psh:" zeroone line-term
        | "tcp-rst:" zeroone line-term
        | "tcp-src-port:" integerlist line-term
        | "tcp-syn:" zeroone line-term
        | "tcp-urg:" zeroone line-term
        | "tcp-urgp:" integerlist line-term
        | "udp-cks:" integerlist line-term
        | "udp-dst-port:" integerlist line-term
        | "udp-src-port:" integerlist line-term
        | "icmp4-code:" integerlist line-term
        | "icmp4-gwy:" ipv4list line-term
        | "icmp4-id:" integerlist line-term
        | "icmp4-mtu:" integerlist line-term
        | "icmp4-seq:" integerlist line-term
        | "icmp4-type:" integerlist line-term
        | "icmp6-code:" integerlist line-term
        | "icmp6-gwy:" ipv6list line-term
        | "icmp6-id:" integerlist line-term
        | "icmp6-mtu:" integerlist line-term
        | "icmp6-seq:" integerlist line-term
        | "icmp6-type:" integerlist line-term

   action-attribute -> "tfr-action:" actiontype line-term
        | ipsec-attribute
   actiontype -> actionpd actionfwd-opt
   actionpd -> "permit" | "deny"
   actionfwd-opt -> "," "forward" actionfwd-dst | (empty)
   actionfwd-dst -> "dns" dnsname | ipaddress

   addresslist -> ipaddrlist | "any" | "*"

   auth-info -> "crypt-pw" string | "pgp" hexstring
        | "cert" objectnamelist

   certtype -> "dnskey" | "kerberos" | "pgp" | "pkcs7" | "spki"
        | "x509_ke" | "x509_sig"
   crltype -> "x509"



Condell, Lynn, Zao                                             [Page 33]


Internet Draft   Security Policy Specification Language     October 1998

   date -> digit digit digit digit digit digit digit digit

   dir-opt -> "direction" dirtype symetric-opt | (empty)
   dirtype -> "inbound" | "outbound"
   symetric-opt -> "," "symmetric" | (empty)

   dn -> # see rfc 1779

   # DNS name based on RFC 1034
   dnsnamelist -> dnsnamelist "," dnsnamecomp
   dnsnamecomp -> dnsname
   dnsname -> dnsname "." label | label
   label -> letter label-end-opt
   label-end-opt -> ldh-string letdig | (empty)
   ldh-string -> letdighyph ldh-string | (empty)
   letdighyph -> letter | digit | "-"
   letdig -> letter | digit

   domaincover -> ipaddrlist | objectnamelist
        | ipaddrlist "," objectnamelist

   edipn -> string

   # email address from rfc 822
   emailaddr -> username "@" dnsname

   expiry-opt -> "expiry" expiry-type integerrange | (empty)
   expiry-type -> "seconds" | "kilobytes"

   fetchproto -> "cdp" | "dns"

   genname -> "dirname" rdnlist | "dns" dnsname | "ediname" edipn
        | "ipaddr" ipaddress | "n822" emailaddr | "other" oid string
        | "regid" oid | "uri" uri | "x400" or-address

   group-opt -> "group" integerrange | (empty)

   hash-alg -> "dsa-sha1" | "rsa-pkcs1"

   integerlist -> integerlist "," integercomp | integercomp
        | "any" | "opaque" | "*"
   integercomp -> integerrange | "not" integerrange
   integerrange -> "min" integer | "max" integer
        | integer "-" integer | integer
   integer -> integer digit | digit

   ipaddress -> ipv4address | ipv6address
   ipv4address -> two55 "." two55 "." two55 "." two55
   ipv6address -> v6digit ":" v6digit ":" v6digit ":" v6digit ":"
        v6digit ":" v6digit ":" v6digit ":" v6digit
   v6digit -> hexdigit | hexdigit hexdigit | hexdigit hexdigit hexdigit
        | hexdigit hexdigit hexdigit hexdigit | (empty)



Condell, Lynn, Zao                                             [Page 34]


Internet Draft   Security Policy Specification Language     October 1998

   ipaddrlist -> ipaddrlist "," ipcomp | ipcomp
   ipcomp -> ipv4comp | ipv6comp

   ipv4list -> ipv4list "," ipv4comp | ipv4comp
   ipv4comp -> ipv4address | ipv4address-range
        | "not" ipv4address | "not" ipv4address-range
   ipv4address-range -> ipv4address "-" ipv4address
        | ipv4address "mask" ipv4address
        | ipv4address "/" integer

   ipv6list -> ipv6list "," ipv6comp | ipv6comp

   ipv6comp -> ipv6address | ipv6address-range
        | "not" ipv6address | "not" ipv6address-range
   ipv6address-range -> ipv6address "-" ipv6address
        | ipv6address "mask" ipv6address
        | ipv6address "/" integer

   ipsec-attribute -> "ipsec-action:"  ipsec-action line-term
        | "isakmp-action:" isakmp-action line-term

   ipsec-action -> ipsec_action_esp_opt ipsec_action_ah_opt
        ipsec_action_ipcomp_opt

   ipsec_action_esp_opt -> esp-proposal ipsectype ipsecloc | (empty)
   ipsec_action_ah_opt -> ah-proposal ipsectype ipsecloc | (empty)
   ipsec_action_ipcomp_opt -> ipcomp-proposal ipsecloc | (empty)

   ipsectype -> "tunnel" | "transport" | (empty)
   usepfs -> "true" | "false"

   ah-proposal -> "ah integrity" integrity-alg-any group-opt expiry-opt
   integrity-alg-any -> "any" | integrity-alg-list
   integrity-alg-list -> integrity-alg-list "," not-opt integrity-alg
        | not-opt integrity-alg
   integrity-alg -> "hmacdes" | "hmacmd5" | "hmacripem" | "hmacsha1"
        | "keyedmd5"

   esp-proposal -> "esp cipher" ipsec-cipher-alg-any keylen-opt
        rounds-opt integrity-opt group-opt expiry-opt
   ipsec-cipher-alg-any -> "any" | ipsec-cipher-alg-list
   ipsec-cipher-alg-list ->
        ipsec-cipher-alg-list "," not-opt ipsec-cipher-alg
        | not-opt ipsec-cipher-alg
   ipsec-cipher-alg -> "blowfish" | "cast" | "des" | "des3" | "idea"
        | "idea3" | "none | "rc4" | "rc5" | "rfc1829-iv32" | "rfc1829-iv64"
   rounds-opt -> "rounds" integerrange | (empty)
   integrity-opt -> "integrity" integrity-alg-any | (empty)

   ipcomp-proposal -> "ipcomp" ipcomp-alg-any expiry-opt
   ipcomp-alg-any -> "any" | ipcomp-alg-list
   ipcomp-alg-list -> ipcomp-alg-list "," not-opt ipcomp-alg
        | not-opt ipcomp-alg
   ipcomp-alg -> "deflate" | "lzs" | "oui" | "v42bis"

Condell, Lynn, Zao                                             [Page 35]


Internet Draft   Security Policy Specification Language     October 1998

   isakmp-action -> "ikemode" ikemode "pfs" usepfs
        "cipher" ike-cipher-alg-any "hash" ike-hash-alg-any
        keylen-opt group-opt
        "expiry" expiry-type integerrange line-term

   ikemode -> "main" | "aggressive" | "quick"

   ike-cipher-alg-any -> "any" | ike-cipher-alg-list
   ike-cipher-alg-list -> ike-cipher-alg-list "," not-opt ike-cipher-alg
        | not-opt ike-cipher-alg
   ike-cipher-alg -> "blowfish" | "cast" | "des" | "des3" | "idea"
        | "rc5"

   ike-hash-alg-any -> "any" | ike-hash-alg-list
   ike-hash-alg-list -> ike-hash-alg-list "," not-opt ike-hash-alg
        | not-opt ike-hash-alg
   ike-hash-alg -> "md5" | "sha1" | "tiger"

   ipsecloc -> from-opt to-opt
   from-opt -> "from" anylocation | (empty)
   to-opt -> "to" anylocation | (empty)
   anylocation -> "any" | locations
   locations -> locations ',' location | location
   location -> "dest" | "host" | "local-sg" | "remote-sg" | ipaddress
        | "dns" dnsname

   keylen-opt -> "keylen" integerrange | (empty)
   locname -> genname | "rdn" rdn
   not-opt -> "not" | (empty)

   objectnamelist -> objectnamelist "," objectname | objectname
   objectname -> extletter objectinternals alphanum | extletter alphanum
        | extletter
   objectinternals -> objectinternals objectinternal | objectinternal
        | (empty)
   objectinternal -> alphanum | "_" | "-" | ":" | "."

   oid -> objectname
   or-address -> string
   phonenum -> phonenum phonenum | digit | " " | "+" | "-" | "x"

   ports-opt -> "port" integerlist dynamic-opt | (empty)
   dynamic-opt -> "dynamic" portrange-opt | (empty)
   portrange-opt -> integerrange | (empty)

   rdnlist -> rdnlist rdn | rdn
   rdn -> # see rfc 1779

   src-opt -> "src" addresslist ports-opt | (empty)
   seclabellist -> seclabellist "," not-opt seclabel | not-opt seclabel
        | "any" | "opaque" | "*"
   seclabel -> hexstring
   signature-data -> hexstring


Condell, Lynn, Zao                                             [Page 36]


Internet Draft   Security Policy Specification Language     October 1998

   system-namelist -> system-namelist "," system-namelist
        | not-opt system-name | "*" | "any"
   system-name -> genname | "dn" dn

   uri -> # see appendix A of draft-fielding-uri-syntax-03.txt
   username -> # see definition in RFC 822

   user-namelist -> user-namelist "," not-opt user-name
        | not-opt user-name | "*" | "any"
   user-name -> "n822" emailaddr | "dn" dn

   xport-opt -> "xport-proto" integerlist | (empty)

   alphanum -> extletter | digit
   charset -> string
   digit -> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
   extletter -> A..Z | a..z | #140 | # 156 | #192..#214
        | #216..#246 | #248..#255
   letter -> A..Z | a..z
   two55 -> [0-9] | [0-9][0-9] | 1[0-9][0-9] | 2[0-4][0-9] | 25[0-5]
   hexstring -> hexstring hexdigit | hexdigit
   hexdigit -> [0-9] | a | A | b | B | c | C | d | D | e | E | f | F
   string -> string char | (empty)
   zeroone -> 0 | 1

   line-term -> comments blankline | blankline
   comments -> comments comment | comment
   comment -> "#" string

   blankline -> whitespace LF
   whitespace -> whitespace whitechar | (empty)
   whitechar -> tab | " " | ff

   char -> any character in ISO 8859-1 (Latin-1) except special characters
        ("#" and "\") which must be replaced by their escaped versions
        ("\#" and "\\").



















Condell, Lynn, Zao                                             [Page 37]


Internet Draft   Security Policy Specification Language     October 1998


Appendix B.  PBSM Policy Model

   The PBSM policy model covers three policy areas: policy items from
   the IPSec DOI that may be negotiated with ISAKMP, IPSec selectors,
   and other attributes that may be used to make policy decisions.
   The IPSec DOI items have been described in [PolMod].  As in
   [PolMod], the policy models are represented in ASN.1 notation for
   the sake of clarity.


B.1  IPSec DOI/IKE Data Model

   SPSL uses the IPSec data model described in [PolMod] to describe
   the policies that cover IKE policies and IPSec DOI policies.


B.2  IPSec Selectors Data Model

   IPSec selectors used to match communications with the appropriate
   security associations necessary to protect the communication.
   Security policies may be developed from the selectors to define the
   granularity of the communications that SAs may be used to protect.
   IPSecSelectors describes the required selectors that are defined in
   [Kent98].

   IPSecSelectors :: =
     SEQUENCE {
       destination    HostandPort,
       source         HostandPort OPTIONAL,
       xportproto     TransportProtocol OPTIONAL,
       ipsecproto     IPSecProtocol OPTIONAL,
       userid         UserID OPTIONAL,
       systemname     SystemName OPTIONAL,
       seclabel       IA5String OPTIONAL
     }

   IPSecSelectors identifies the list of selectors that may be
   specified.  Further definitions of the selectors are listed below.

   HostandPort ::=
     SEQUENCE {
       host  HostName,
       port  Port OPTIONAL
     }

   HostName ::=
     CHOICE {
      ipaddress       OCTET STRING,
      ipaddressrange  IPAddressRange,
      wildcard        OCTET STRING
     }



Condell, Lynn, Zao                                             [Page 38]


Internet Draft   Security Policy Specification Language     October 1998

   IPAddressRange ::=
     SEQUENCE {
      startrange OCTET STRING,
      endrange   OCTET STRING
     }

   Host names may either be an IP address, a range of IP addresses or
   a wildcard (netmask) address.

   Port ::=
     CHOICE {
       port      INTEGER
       portlist  SEQUENCE OF INTEGER,
       wildcard  PortOther
     }

   PortOther ::=
     ENUMERATE {
      wildcard
     }

   The source and/or destination UDP/TCP port may be specified as a
   single port number, a list of port numbers, or a wildcard.

   TransportProtocol ::=
     CHOICE {
      protocolNumber INTEGER,
      protocolList   SEQUENCE OF INTEGER,
      protocolRange  ProtocolRange,
      protocolOther  ProtocolOther
     }

   ProtocolRange ::=
     SEQUENCE {
      startrange INTEGER,
      endrange   INTEGER
     }

   ProtocolOther ::=
     ENUMERATE {
      wildcard,
      opaque
     }

   The transport protocol may be specified as an individual protocol
   number, a list of protocol numbers, a range of protocol numbers, a
   wildcard, or "Opaque".

   IPSecProtocol ::=
     SEQUENCE {
      AHRequiredMode   IPSECMode OPTIONAL,
      ESPRequiredMode  IPSECMode OPTIONAL
     }


Condell, Lynn, Zao                                             [Page 39]


Internet Draft   Security Policy Specification Language     October 1998

   IPSECMode ::=
     ENUMERATE {
      transport,
      tunnel,
      wildcard
     }

   Either AH, ESP, or AH and ESP may be required for a communication.
   They may be required to use transport mode, tunnel mode, or either
   mode may be acceptable.

   UserID ::=
     CHOICE {
      FullyQualifiedUserName  IA5String,
      X500DistinguiushedName  DistinguishedName,
     }

   A user may be specified using either a fully qualified user name or
   an X.500 distinguished name.

   SystemName ::=
     CHOICE {
      FullyQualifiedDNSName   IA5String,
      X500DistinguiushedName  DistinguishedName,
      X500GeneralName         GeneralName
     }

   GeneralName ::= CHOICE {
        otherName                       [0]     AnotherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   A system may be named using either a fully qualified DNS name, an
   X.500 distinguished name or an X.500 General Name.
   DistinguishedName, AnotherName, ORAddress, Name, and EDIPartyName
   type definitions may be found in the appendix of [PKIXP1].


B.3  Other Attributes Data Model

   There are other attributes that may be desired as part of a
   security policy.  These may be used as selectors would.  The
   following attributes are currently defined as part of PBSM, though
   this model may be extended to include other attributes.





Condell, Lynn, Zao                                             [Page 40]


Internet Draft   Security Policy Specification Language     October 1998

   MiscAttributes ::=
     SEQUENCE {
      ActionAllowed  Allowed,
      TrafficFlow    Direction OPTIONAL,
      V6Class        INTEGER OPTIONAL,
      V6Flow         INTEGER OPTIONAL,
      V4TOS          INTEGER OPTIONAL
     }

   Allowed ::=
     ENUMERATE {
      permit,
      deny
     }

   Direction ::=
     ENUMERATE {
      inbound,
      outbound
     }

   ActionAllowed is the only required to note whether the specified
   traffic is permitted or should be rejected by the gateway.  Traffic
   Flow indicates the direction of the traffic flow.  The other
   attributes specify their corresponding fields in IPv4 and IPv6.


B.4  Policy

   These three parts of the policy data model may be combined to form
   the complete model.

   PolicyModel ::=
     SEQUENCE {
      iPSecSelectors    IPSecSelectors,
      miscAttributes    MiscAttributes
      isakmpDescriptor  IsakmpDescriptor OPTIONAL,
      ipsecDescriptor   IpsecDescriptor OPTIONAL,
     }
















Condell, Lynn, Zao                                             [Page 41]


Internet Draft   Security Policy Specification Language     October 1998

References

   [Bra97]   S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Level," RFC-2119, March 1997.

   [DOI] D. Piper, "The Internet IP Security Domain of Interpretation
       for ISAKMP", Internet Draft draft-ietf-ipsec-ipsec-doi-10,
       July 1998.

   [DSA] Federal Information Processing Standards Publication
       (FIPS PUB) 186, Digital Signature Standard, 18 May 1994.

   [ISO8859] Information Processing - 8-bit Single-Byte Coded Graphic
       Character Sets.  Part1: Latin Alphabet Number 1, ISO 8859-1,
       1987.

   [Kent98] S. Kent, R. Atkinson, "Security Architecture for the
       Internet Protocol", Internet Draft
       draft-ietf-ipsec-arch-sec-07, July 1998.

   [PKIXP1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public
       Key Infrastructure: X.509 Certificate and CRL Profile".
       Internet Draft draft-ietf-pkix-ipki-part1-10, September 1998.

   [PolMod] R. Pereira, P. Bhattacharya, "IPSec Policy Data Model",
       Internet Draft draft-ietf-ipsec-policy-model-00, February 1998.

   [rfc822] D. Crocker, "Standard for the Format of ARPA Internet
       Text Messages", RFC 822, August 1982.

   [rfc1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
       RFC 1034, November 1987.

   [RPSL] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, D.
       Meyer, M. Terpstra, and C. Villamizer.  "Routing Policy
       Specification Language (RPSL)".  RFC 2280. January 1998.

   [RSA] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data
       Security, Inc., 3 June 1991.

   [SPS] L. Sanchez, M. Condell, "Security Policy System",
       Working Draft, October 1998.













Condell, Lynn, Zao                                             [Page 42]


Internet Draft   Security Policy Specification Language     October 1998


Author Information

   Matthew Condell
   BBN Technologies/
   GTE Internetworking
   10 Moulton Street
   Cambridge, MA 02138
   USA
   Email: mcondell@bbn.com
   Telephone: +1 (617) 873-6203

   Charles Lynn
   BBN Technologies/
   GTE Internetworking
   10 Moulton Street
   Cambridge, MA 02138
   USA
   Email: clynn@bbn.com
   Telephone: +1 (617) 873-3367

   John Zao
   BBN Technologies/
   GTE Internetworking
   10 Fawcett Street
   Cambridge, MA 02138
   USA
   Email: jzao@bbn.com
   Telephone: +1 (617) 873-2438


























Condell, Lynn, Zao                                             [Page 43]